**** BEGIN LOGGING AT Tue Apr 18 03:00:01 2017
Apr 18 06:42:43 <mckoan> good morning
Apr 18 08:12:55 <ChrysD> Hi Everyone, little question here. When we use "RDEPENDS" on a recipe like a.bb  RDEPENDS=" b ". Does it means that it will add b in the final image ? Thanks by advance.
Apr 18 08:17:59 <bluelightning> ChrysD: yes, if *package* a is in the image, package b will also be
Apr 18 08:20:29 <ChrysD> bluelightning : Thank you. I was looking to which recipes i should patch to add a qt5 library to avoid adding them on my local.conf in build directories. I thought that the only way of adding something on the image was by IMAGE_INSTALL using for example packagroups :) Nice to know thanks !
Apr 18 12:14:36 <windy_miller> I'm a yocto newbie, what is the best linux distribution for the build host ? Can build host run windows ?
Apr 18 12:16:20 <Crofton|work> can't run windows
Apr 18 12:16:33 <Crofton|work> other than that what are you comfortable with?
Apr 18 12:41:48 <phako[m]> has anyone actually tried that on the win10 linux subsystem?
Apr 18 12:42:59 <Son_Goku> it doesn't work
Apr 18 12:58:01 <kanavin> I believe MiskaX has actually tried yocto with win10 linux
Apr 18 13:02:57 <LetoThe2nd> wasn't the official stanza to stick to CROPS?
Apr 18 13:04:49 <Crofton|work> LetoThe2nd, people still want to try clever things
Apr 18 13:18:28 <Crofton|work> rburton, you back?
Apr 18 13:25:06 <rburton> Crofton|work: yes
Apr 18 13:25:44 <Son_Goku> kanavin: hey
Apr 18 13:25:50 <Son_Goku> how is the dnf stuff going?
Apr 18 13:26:24 <Crofton|work> SO I ran a an sdk from the M# autobuilder thing
Apr 18 13:26:32 <Crofton|work> and it doesn't have python in th esdk
Apr 18 13:26:36 <rburton> Son_Goku: dnf is integrated into master
Apr 18 13:26:36 <kanavin> Son_Goku: I have the version updates ready in a private branch, marquiz can cherry pick them if he wants to work on feed signing now
Apr 18 13:26:36 <Crofton|work> so you can build u-boot
Apr 18 13:26:50 <Crofton|work> if you have python in the sdk, you can't build u-boot
Apr 18 13:28:27 <kanavin> Son_Goku: do you mean something specific?
Apr 18 13:28:37 <Son_Goku> kanavin: well, the feed signing stuff
Apr 18 13:28:45 <kanavin> Son_Goku: you need to ask marquiz :)
Apr 18 13:28:49 <Son_Goku> also, did you make sure gpgme is switched fully to gpg2
Apr 18 13:29:35 <kanavin> Son_Goku: no idea; dnf runs and passes tests without errors and I'm fine with that :)
Apr 18 13:29:45 <Son_Goku> hmm, I guess it's fine then
Apr 18 13:30:04 <kanavin> Son_Goku: does dnf use gpgme for anything else than feed signing?
Apr 18 13:30:16 <Son_Goku> gpgme is used for all signature verification
Apr 18 13:30:23 <Son_Goku> packages and repodata
Apr 18 13:30:49 <kanavin> Son_Goku: really? I thought rpm is using nss for packages signature verification
Apr 18 13:30:57 <kanavin> Son_Goku: and gpgme for signing packages
Apr 18 13:30:57 <Son_Goku> that's rpm
Apr 18 13:31:05 <Son_Goku> rpm uses gpg directly
Apr 18 13:31:09 <Son_Goku> it doesn't use gpgme for anything
Apr 18 13:31:23 <kanavin> Son_Goku: so what exactly does dnf do when you say 'packages'?
Apr 18 13:32:12 <Son_Goku> well, it reads the signature digest in the RPM and attempts to match it to a fingerprint
Apr 18 13:32:21 <Son_Goku> if it can't, it'll trigger the import key request
Apr 18 13:32:33 <Son_Goku> this is before it reaches rpm, because at the moment, rpm doesn't have a callback for it
Apr 18 13:33:09 <Son_Goku> one of the goals for rpm 4.14 is to move more of the signature verification logic to RPM itself, including adding a callbac
Apr 18 13:33:12 <Son_Goku> *callback
Apr 18 13:33:18 <Son_Goku> so that package managers like DNF can use that instead
Apr 18 13:34:04 <kanavin> Son_Goku: we have a test where an image is created from signed packages, and it passes :)
Apr 18 13:34:13 <Son_Goku> then everything should be fine
Apr 18 13:35:38 <kanavin> Son_Goku:  rpm key is imported as a separate step, before dnf install is invoked
Apr 18 13:35:49 <Son_Goku> ah
Apr 18 13:36:09 <Son_Goku> does Yocto use gpg2 by default or gpg1?
Apr 18 13:37:05 <kanavin> Son_Goku: that's the sad part: we use whatever the host distro is providing
Apr 18 13:37:14 <Son_Goku> :(
Apr 18 13:38:22 <kanavin> Son_Goku: on target images, it's gnupg 2.1.18 though
Apr 18 13:38:29 <Son_Goku> good :D
Apr 18 13:39:18 <rburton> kanavin: have you ever seen 'FATAL ERROR: python callback ??? failed, aborting!'' from rpm/dnf?
Apr 18 13:39:28 <kanavin> rburton: nope
Apr 18 13:41:13 <rburton> kanavin: can you try enabling rm_work, and package_rpm, then bitbake core-image-minimal core-image-minimal:do_populate_sdk
Apr 18 13:41:21 <rburton> kanavin: if i do that, 80% of the time it fails
Apr 18 13:41:42 <kanavin> rburton: how does one enable rm_work, and what does it do?
Apr 18 13:42:01 <rburton> INHERIT += "rm_work"
Apr 18 13:42:09 <rburton> it just deletes work directories after the recipe has built
Apr 18 13:42:48 <kanavin> rburton: sure, when the current build finishes
Apr 18 13:44:12 <kanavin> rburton: a question for you: could this bug be caused by a malformed or truncated image? https://bugzilla.yoctoproject.org/show_bug.cgi?id=11312
Apr 18 13:44:13 <yocti> Bug 11312: normal, Medium+, 2.3 M4, davidx.lopez.barriba, NEEDINFO , [Test Case 1735] test_dnf_help fails and all the others dnf test are skipped
Apr 18 13:44:28 <kanavin> note that it's not just dnf; logrotate also has missing files in the image
Apr 18 13:45:06 <rburton> kanavin: malformed image is meant to be pretty impossible, nothing should be in deploy that failed
Apr 18 13:45:42 <kanavin> rburton: I'm trying to reproduce that now - pulling in meta-intel should not affect anything, but who knows
Apr 18 13:45:54 <mivond> Hi, is anyone here?
Apr 18 13:46:05 <kanavin> mivond: 259 people in room
Apr 18 13:46:32 <ChrysD> Hi, how to distinguish the name of the recipe and the name of the package ? I know that most of the time both have the same name.. But how to set the good one ?
Apr 18 13:46:37 <ChrysD> Thanks by advance.
Apr 18 13:47:47 <mivond> Has anyone here used mender? (https://github.com/mendersoftware/meta-mender) I'm trying to build the meta-mender-raspberrypi layer, but I keep getting a weird systemd error.
Apr 18 13:49:11 <mivond> Unfortunately, their irc channel is pretty dead
Apr 18 13:49:24 <jku> ChrysD: can you explain the situation where you have a problem?
Apr 18 13:49:56 <rburton> mivond: pastebining the error might help
Apr 18 13:50:37 <mivond> k, one second
Apr 18 13:51:40 <ChrysD> jku : It's not really a problem but for example the name of a recipe is the same as the name of the package. But sometimes not. As i'm a beginner in yocto and creating recipes, i would like to know when I add a component to my image, how I get the name of the packages. On internet you can check for example a recipe called net-snmp but the packages are net-snmp-client and net-snmp-server. Where those information are detailed ? etc etc et
Apr 18 13:51:44 <ChrysD> jku : thanks.
Apr 18 13:52:49 <mivond> rburton: https://pastebin.com/1B0zx6Uh
Apr 18 13:53:05 <mivond> I also included my bblayers and local.conf
Apr 18 13:53:16 <kanavin> ChrysD: custom package naming is generally recipe specific, you can start with the simplest possible approach and put everything into one package which is named same as recipe
Apr 18 13:54:35 <mivond> I'm following the steps from https://docs.mender.io/1.0/artifacts/building-mender-yocto-image
Apr 18 13:56:55 <jku> ChrysD: if you look in the meta-snmp recipe you'll find a line that adds items to PACKAGES variable
Apr 18 13:57:17 <ChrysD> kanavin : Thanks for the reply.  For example, I made a recipe called gpio-driver_0.1.bb which compile a kernel module. And when I put IMAGE_INSTALL = " gpio-driver " it add to the image my kernel module. I would like to know how he get the fact that my recipe I called gpio-driver have also a package nameed the same. Does it is something like if you specify nothing, the package name is the same as the recipe name ?
Apr 18 13:58:07 <mivond> rburton: notice that it's saying systemd isn't found in DISTRO_FEATURES, and yet I'm appending it in my local.conf
Apr 18 13:58:09 <jku> ChrysD: and later on you'll find FILES_* variables that define what files each of those packages contains
Apr 18 13:58:56 <ChrysD> jku : If i understand there is always 4 packages for one recipes right ? And FILES_* it's to know to which packages it will go.
Apr 18 13:59:10 <kanavin> ChrysD: that's right - and it also creates a few other packages where for instance headers and documentations go. Depending on what classes you inherit in your recipe, there could be other packages defined and populated - or you can also define them directly in the recipe, if you find the default package layout isn't suitable.
Apr 18 14:00:59 <ChrysD> kanavin : So when I add a package in " IMAGE_INSTALL_append ", i should put the recipe names of my custom recipe, but also the one with -dev -dbg -doc if I would like to do it well. And I should do readme.txt file which i put on package-doc right ?
Apr 18 14:04:19 <ChrysD> jku : I correct myself, there is always " at least" 4 packages. And with the PACKAGES variable  I define the packages names and with FILE_PACKAGENAME I define which file comes to which packages.
Apr 18 14:04:24 <ChrysD> jku : thank you for your help.
Apr 18 14:04:33 <kanavin> ChrysD: IMAGE_INSTALL_append in general is a bit of a quick hack - instead you should add the packages you want to your image definition
Apr 18 14:06:44 <ChrysD> kanavin : right. So it's the better to do its own recipe image that inherit from the one which we based our development if I understand.
Apr 18 14:07:20 <ChrysD> kanavin : outch my english is so bad. Sorry for that.
Apr 18 14:07:29 <kanavin> ChrysD: yes
Apr 18 14:09:02 <kanavin> ChrysD: also, read the description of EXTRA_IMAGE_FEATURES in local.conf to see how debug, dev and doc packages are usually installed into images
Apr 18 14:09:05 <ChrysD> kanavin : thanks a lot for your help.
Apr 18 14:09:16 <ChrysD> kanavin : ok
Apr 18 14:14:47 <ChrysD> kanavin : I see from somebody project. That he have done a recipe image really basic, and another one with more features. He have put " require + the minimalist image recipe " and put IMAGE_FEATURES = " " with some features.  SO If I get what's done. IMAGE_FEATURE takes packages from the first image recipde. Everything that finish with _FEATURES is came from an original image recipe right ?
Apr 18 14:16:30 <kanavin> mivond: try bitbake -e
Apr 18 14:18:15 <kanavin> ChrysD: I'm afraid I don't understand your question without seeing the recipes
Apr 18 14:19:39 <ChrysD> kanavin : https://github.com/jruffin/meta-yogurt/blob/fido/recipes-images/images/phytec-qt5demo-image.bb
Apr 18 14:20:32 <mivond> kanavin: i piped it to a file, it's 1MB
Apr 18 14:20:36 <mivond> bitbake -e
Apr 18 14:21:02 <ChrysD> kanavin : Tell me if correct. If I would like to do the same. I should put require " + the recipe of the one i would like to bases my image " + IMAGE_FEATURES = " list of features coming from the image i've required ".
Apr 18 14:22:17 <kanavin> ChrysD: you should do 'inherit <image-recipe> and then add your custom tweaks
Apr 18 14:22:43 <kanavin> those custom tweaks can be additional IMAGE_FEATURES, or they can be additional packages to install via IMAGE_INSTALL
Apr 18 14:24:56 <mivond> kanavin: I grep'd through the output for DISTRO_FEATURES
Apr 18 14:24:56 <mivond> https://pastebin.com/dt89L9Ma
Apr 18 14:25:22 <mivond> it looks like systemd is in there on line 11
Apr 18 14:25:26 <ChrysD> kanavin : require is just only if I need some packages from an image but not the whole. But inherit is like an extension of another image; right ?
Apr 18 14:26:18 <kanavin> mivond: if d.getVar('MACHINE', False) != 'vexpress-qemu' and not bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d):
Apr 18 14:27:24 <mivond> wait, so it's requiring that it's NOT in distro_features?
Apr 18 14:27:56 <mivond> I don't get it, it IS in there
Apr 18 14:29:02 <kanavin> mivond: I don't get it either, but clearly both conditions hold true
Apr 18 14:29:10 <mivond> right
Apr 18 14:29:35 <mivond> my machine is 'raspberrypi', and we can clearly see that systemd is in DISTRO_FEATURES
Apr 18 14:29:46 <mivond> sorry, 'raspberrypi3'
Apr 18 14:30:58 <kanavin> ChrysD: https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#sharing-functionality
Apr 18 14:35:07 <kanavin> mivond: try modifying the code just before the exception to print the contents of DISTRO_FEATURES
Apr 18 14:35:25 <mivond> ok, one second
Apr 18 14:39:29 <mivond> kanavin: I tried to print it
Apr 18 14:39:38 <mivond> Can I just print(DISTRO_FEATURES) ?
Apr 18 14:39:40 <mivond> Exception: NameError: name 'DISTRO_FEATURES' is not defined
Apr 18 14:39:43 <kanavin> mivond: nope
Apr 18 14:39:44 <mivond> I got this error
Apr 18 14:39:54 <ChrysD> kanavin : Sorry for disturbin you. I guess I need more google search because it become harder and harder to understand the differences between concepts but thank you for your precious help and have a nice day.
Apr 18 14:42:13 <kanavin> mivond: d.getVar('DISTRO_FEATURES')
Apr 18 14:42:31 <mivond> ok thanks
Apr 18 14:44:01 <mivond> kanavin: https://pastebin.com/n43j33pJ
Apr 18 14:44:03 <mivond> it's there
Apr 18 14:44:05 <mivond> :(
Apr 18 14:44:30 <mivond> That print is on the line immediately before the check that raises the Exception
Apr 18 14:45:06 <mivond> kanavin: except, it looks like it changes DISTRO_FEATURES at some point to only contain x11?
Apr 18 14:45:13 <mivond> That's when it throws the exception
Apr 18 14:45:18 <kanavin> mivond: yup!
Apr 18 14:46:01 <mivond> Great, we have a lead :)
Apr 18 14:46:13 <mivond> Now, I need to figure out why/where it changes this
Apr 18 14:49:10 <kanavin> mivond: DISTRO_FEATURES_NATIVE="x11" could be perhaps?
Apr 18 14:49:16 <kanavin> from bitbake -e output
Apr 18 14:49:49 <kanavin> it's hard to tell what happens, as you removed the context of how that line was formed
Apr 18 14:50:24 <mivond> right, I will investigate
Apr 18 15:02:36 <mivond> kanavin: I added DISTRO_FEATURES_NATIVE_append = " systemd"
Apr 18 15:02:38 <mivond> to local.conf
Apr 18 15:02:59 <mivond> It helped https://pastebin.com/Ssr2w9XK
Apr 18 15:03:09 <mivond> Must be another place it's setting it though
Apr 18 15:04:34 <mivond> ./openembedded-core/meta/conf/bitbake.conf:795:DISTRO_FEATURES_NATIVESDK ?= "x11 libc-charsets libc-locales libc-locale-code"
Apr 18 15:04:47 <mivond> I added DISTRO_FEATURES_NATIVESDK_append = " systemd"
Apr 18 15:04:53 <mivond> seems to be running!
Apr 18 15:07:53 <mivond> kanavin: They really ought to specify in the docs these 2 extra variables you need to set
Apr 18 15:08:05 <mivond> Maybe I will raise an issue on github with them
Apr 18 15:11:59 <theben> Hi guys, I'm trying to create a yocto build [morty] for raspberry pi and I'm setting up MACHINE var, I'd like to create an image that is able to boot on RPi B(v1) as well as on RPi B(v3). Any ideas on how can I do it? Here's my complete subject on ML (https://lists.yoctoproject.org/pipermail/yocto/2017-April/035623.html)
Apr 18 15:12:48 <theben> When I set Machine to "raspberrypi" it only boots on v1 boards, the same goes for "raspberrypi3" (on v3 boards)
Apr 18 16:52:08 <kergoth> RP: https://gist.github.com/kergoth/57f98fb0532e362b34eb365ebb377f2e might find that of interest. apparently psutil grabs the private dirty info from smaps, so we can distinguish between private and shared memory for the process easily. was having a hell of a time gathering useful info excluding COW pages and shared libraries
Apr 18 17:47:13 <jophish> Seeing the release names while downloading yocto brought back a bunch of happy TA memories, thanks!
Apr 18 17:57:44 <LocutusOfBorg> ok I need some yocto developer here
Apr 18 17:57:54 <LocutusOfBorg> do we have any constraint against upper case bb files?
Apr 18 17:58:12 <LocutusOfBorg> Foo_git.bb fOo.bb or similar? are them allowed?
Apr 18 17:58:40 <LocutusOfBorg> damn I found the worst bug in the world :(
Apr 18 18:01:50 <fray> as far as I know, the PN is case sensitive, and PN is derived from the .bb name
Apr 18 18:01:57 <LocutusOfBorg> of course
Apr 18 18:02:09 <LocutusOfBorg> to be clear, ${PN} is derived  from it
Apr 18 18:02:18 <mivond> LocutusOfBorg: great name
Apr 18 18:02:18 <LocutusOfBorg> ${PN}_${PV}.bb or similar
Apr 18 18:02:22 <fray> yes
Apr 18 18:02:23 <LocutusOfBorg> thanks
Apr 18 18:02:48 <LocutusOfBorg> the problem is that for recipes with a number of upper case characters >=1, SYSTEMD_SERVICE doesn't work :/
Apr 18 18:03:04 <LocutusOfBorg> I spent the whole day trying to understand why the postinst script was not created correctly
Apr 18 18:03:50 <fray> is it the processing within the oe classes, or is it systemd itself?
Apr 18 18:03:57 <LocutusOfBorg> SYSTEMD_SERVICE_${PN} is not replaced in the postinst call
Apr 18 18:04:12 <LocutusOfBorg> you can see "systemctl $OPTS enable $SYSTEMD_SERVICE"
Apr 18 18:04:15 <LocutusOfBorg> without being replaced
Apr 18 18:04:26 <LocutusOfBorg> funny, changing the recipe to be lower case works :/
Apr 18 18:04:37 <LocutusOfBorg> fray, systemd.bbclass seems correct
Apr 18 18:04:45 <LocutusOfBorg> I suspect some underlying oe issue
Apr 18 18:05:02 <fray> systemd.bbclass:            if d.getVar('SYSTEMD_SERVICE_' + pkg):
Apr 18 18:05:04 <LocutusOfBorg> I did put a ton of code in systemd.bbclass
Apr 18 18:05:10 <LocutusOfBorg> yes fray correct
Apr 18 18:05:16 <fray> the part after the systemd_service is the 'pkg' name.  from 'PACKAGES' variable
Apr 18 18:05:27 <LocutusOfBorg> yes, but it isn't replaced
Apr 18 18:05:54 <fray> no..
Apr 18 18:05:57 <fray>         for pkg in d.getVar('SYSTEMD_PACKAGES').split():
Apr 18 18:05:57 <fray>             systemd_check_package(pkg)
Apr 18 18:05:58 <fray>             if d.getVar('SYSTEMD_SERVICE_' + pkg):
Apr 18 18:06:06 <fray> it's the SYSTEMD_PACKAGES variable, which defaults to PN..
Apr 18 18:06:31 <fray> 'systemd_check_package will verify 'pkg' is inside of the PACKAGES variable..
Apr 18 18:06:40 <LocutusOfBorg> add this: +        bb.warn(postinst) around line 100
Apr 18 18:06:44 <fray> you should double check the value of SYSTEMD_PACKAGES and PACKAGES (using bitbake -e)
Apr 18 18:06:47 <LocutusOfBorg> and you will see
Apr 18 18:06:54 <LocutusOfBorg> I did that :p
Apr 18 18:07:13 <LocutusOfBorg> but I forgot the outcome
Apr 18 18:07:26 <LocutusOfBorg> they seems correct, but now I know the issue double checking doesn't hurt
Apr 18 18:11:53 <fray> I just went into meta-networking, and renamed 'dovecot' to 'DOVEcot'... below is what I got:
Apr 18 18:12:08 <fray> SYSTEMD_PACKAGES="DOVEcot"
Apr 18 18:12:18 <fray> SYSTEMD_SERVICE_DOVEcot="dovecot.service dovecot.socket"
Apr 18 18:12:53 <LocutusOfBorg> yes, I agree
Apr 18 18:12:56 <LocutusOfBorg> the same happens here
Apr 18 18:13:02 <fray> and under the postinst/prerm, the SYSTEMD_SERVICE was not expanded
Apr 18 18:13:07 <LocutusOfBorg> exactly
Apr 18 18:13:15 <fray> restoring it back:
Apr 18 18:13:17 <LocutusOfBorg> so, the SYSTEMD_AUTO_ENABLE is a no-op
Apr 18 18:13:35 <LocutusOfBorg> it is driving me crazy, I spent the whole day
Apr 18 18:13:38 <fray> SYSTEMD_SERVICE_dovecot="dovecot.service dovecot.socket"
Apr 18 18:13:50 <fray> it also was not expanded in that config..
Apr 18 18:14:02 <LocutusOfBorg> true
Apr 18 18:14:05 <LocutusOfBorg> the PN is the clue
Apr 18 18:14:20 <fray> so it looks the 'same'.. I'm not sure what should be expanding the SYSTEMD_SERVICE, it may be the packaging step
Apr 18 18:14:50 <LocutusOfBorg> I'm opening a bug against bitbake
Apr 18 18:14:54 <fray> but the SYSTEMD_SERVICE_<pkg> was right in both cases, I'd need to generate a package itself to see what was different..
Apr 18 18:15:02 <fray> but it's consistent on the surface at least
Apr 18 18:15:56 <LocutusOfBorg> fray, if you print SYSTEMD_SERVICE in systemd.bbclass, it is printed correctly
Apr 18 18:16:02 <LocutusOfBorg> this is what I don't understand
Apr 18 18:16:30 <fray> you have different points of expansion.. bitbake -e is early expansion.. later on (in packaging) there is another level that can't be diagnosed via -e
Apr 18 18:16:39 <fray> you have to actually build the package and check the resulting system
Apr 18 18:17:48 <LocutusOfBorg> but so, after do_package you mean
Apr 18 18:17:56 <LocutusOfBorg> or after the systemd.bbclass at least
Apr 18 18:19:20 <fray> when systemd is enabled, in do_package (it has to be running) it will expand the packages entries when it processes pre/post install scriplets..
Apr 18 18:19:26 <fray> that is the part you won't see in a bitbake -e
Apr 18 18:19:38 <LocutusOfBorg> yes, I agree
Apr 18 18:19:38 <fray> for rpm, you can do rpm -qp <package> --scriptlets to see what the end results are
Apr 18 18:19:54 <fray> but the expansion doesn't happen in systemd.bbclass, it happens in package_<type>.bbclass
Apr 18 18:21:27 <LocutusOfBorg> oh, you just cat tmp/work/$ARCH/$PN/$PV/pkgdata/runtime/$PN
Apr 18 18:21:46 <LocutusOfBorg> you can read just the pkg_postinst_$PN script
Apr 18 18:22:28 <fray> those havn't been expanded AFAIK
Apr 18 18:22:34 <fray> it's only when the packages are written they are expanded
Apr 18 18:22:41 <LocutusOfBorg> they are
Apr 18 18:22:51 <LocutusOfBorg> I can see the difference here with lower/upper case
Apr 18 18:26:52 <LocutusOfBorg> hey legitimize_package_name WTF are you doing? your code looks suspicious
Apr 18 18:30:46 <LocutusOfBorg> I don't think this is an rpm specific issue, but rather a package.bbclass one
Apr 18 18:38:39 <gdg> I just started with Yocto; currently I run dd every time to program the SD card, but I would like to have a non-zipped filesystem on the card that I can upgrade incrementally (something like a package manager based approach, e.g. apt-get or yum); is there a way to do that?
Apr 18 18:40:14 <kanavin> rburton: looks like you sorted the issue?
Apr 18 18:45:28 <LocutusOfBorg> gdg, yes, you can use a package manager and install just the rpm/dep/ipk package
Apr 18 18:46:08 <gdg> LocutusOfBorg: does that break any "philosophy" in the Yocto framework
Apr 18 18:46:10 <gdg> ?
Apr 18 18:46:42 <LocutusOfBorg> mmm why?
Apr 18 18:46:54 <gdg> what I mean, at that point the packages on the SD will be not the same as the packages that I have originally installed
Apr 18 18:47:02 <LocutusOfBorg> mmm ok
Apr 18 18:47:23 <gdg> if you say that is a common practice, I will accept it
Apr 18 18:47:34 <LocutusOfBorg> it isn't
Apr 18 18:47:43 <gdg> like the Yocto system allows me to bootstrap a system that eventually I will populate
Apr 18 18:47:44 <gdg> oh
Apr 18 18:47:46 <LocutusOfBorg> I usually use rpm/deb to upgrade my development system
Apr 18 18:47:47 <kergoth> i don't see what makes a package management feed in opposition to yocto
Apr 18 18:47:51 <kergoth> angstrom is highly feed oriented
Apr 18 18:48:02 <LocutusOfBorg> but to my customer I give a full build
Apr 18 18:48:03 <kergoth> and angstrom is one of many oe based distros
Apr 18 18:48:15 <kergoth> but there are a wide variety of update mechanisms for embedded systems around nowadays
Apr 18 18:48:20 <kergoth> worth evaluating the options
Apr 18 18:48:23 <gdg> ok
Apr 18 18:48:38 <LocutusOfBorg> actually I prefer to give them the full filesystem, to be coherent with what I/they have
Apr 18 18:48:55 <gdg> I am working with Zynq / Xilinx
Apr 18 18:48:59 <LocutusOfBorg> but if you want to develop/test scp'ing a binary/rpm is better/faster
Apr 18 18:49:07 <gdg> ok
Apr 18 18:49:22 <LocutusOfBorg> as usual, yocto gives you an high flexibility
Apr 18 18:49:34 <LocutusOfBorg> be careful, with great powers... (citation needed)
Apr 18 18:49:41 <gdg> is there a way to trace which were the updates on the SD to improve the recipes?
Apr 18 18:49:57 <LocutusOfBorg> probably some apt/rpm log?
Apr 18 18:50:01 <gdg> or is it just up to me remember
Apr 18 18:50:02 <gdg> ok
Apr 18 18:50:27 <gdg> last question, I have a 8GB SD card
Apr 18 18:50:33 <gdg> but if I df -h
Apr 18 18:50:35 <LocutusOfBorg> I'm a Debian developer, and we log apt logs under /var
Apr 18 18:50:42 <LocutusOfBorg> not sure how yocto implemented it :p
Apr 18 18:51:09 <gdg> I see only 2 GB (used/unused)
Apr 18 18:51:21 <gdg> what could be the reason of that?
Apr 18 18:52:19 <kergoth> gdg: filesystems and partitions have fixed sizes, they don't automagically grow to the size of the media you put them on
Apr 18 18:52:36 <kergoth> but there is a script that uses parted and e2fsprogs to do it for ext[34] root filesystems
Apr 18 18:52:48 <kergoth> we're using it to grow our rootfs to the size of our sd cards on first boot
Apr 18 18:53:33 <gdg> mmm, I was assuming that if I have 32gb card the dd was "copying" all of the filesystem and giving me the freedom to use all of the extra space
Apr 18 18:53:51 <kergoth> all dd does is writes the image byte by byte to the media
Apr 18 18:53:57 <kergoth> it doesn't grow anything
Apr 18 18:54:16 <gdg> on the contrary if you say /var/tmp/wic/build/sdimage-bootpart-* has a fixed size
Apr 18 18:54:17 <kergoth> it has zero knoweldge of what's inside the image
Apr 18 18:54:35 <gdg> how can I set the size of the target SD
Apr 18 18:54:58 <kergoth> use a fixed size wks, or use the image size variables in the metadata, but eh fixed size wks would be easier
Apr 18 18:55:10 <kergoth> or just let it grow on first boot with resize-helper from 96boards-tools
Apr 18 18:55:15 <gdg> do you have a reference doc for that?
Apr 18 18:55:18 <kergoth> https://layers.openembedded.org/layerindex/branch/master/layer/meta-96boards/, https://github.com/96boards/96boards-tools
Apr 18 18:55:44 <kergoth> add meta-96boards to your bblayers.conf, add 96boards-tools to your image
Apr 18 18:56:04 <kergoth> that'll run resize-helper on first boot, which will grow the rootfs if it's possible to do so — https://github.com/96boards/meta-96boards/blob/master/recipes-bsp/96boards-tools/96boards-tools_0.10.bb#L26
Apr 18 18:56:08 <gdg> ok
Apr 18 18:56:20 <gdg> let me try on the fly
Apr 18 18:57:35 <gdg> in the meantime, I want to compile a complex package as TensorFlow, did anybody try?
Apr 18 18:57:45 <kergoth> there's value to both approaches. i.e. when using a read only rootfs, obviously it's not possible to grow it on first boot, so a fixed size is the only option
Apr 18 18:57:52 <kergoth> check the layer index
Apr 18 18:58:02 <kergoth> https://layers.openembedded.org/layerindex/branch/master/recipes/
Apr 18 19:15:15 <rburton> kanavin: yes, race after all
Apr 18 19:27:31 <mivond> kanavin: I was finally able to build/flash my image to my sd card :) Booting from the raspberrypi3, it hangs on Loading Kernel
Apr 18 19:28:03 <mivond> https://github.com/mendersoftware/meta-mender/tree/master/meta-mender-raspberrypi seems it could be a uboot issue
Apr 18 19:58:26 <gdg> does anybody use smart? is it better than apt-get?
Apr 18 19:59:24 <gdg> I saw this presentation, and apparently smart has still some bugs
Apr 18 19:59:25 <gdg> http://elinux.org/images/c/c6/Smart_r002.pdf
Apr 18 20:00:01 <gdg> see slide 25-...
Apr 18 20:03:45 <kergoth> gdg: smart/rpm5 was ditched in favor of dnf/rpm4 for 2.3.
Apr 18 20:03:49 <kergoth> afaik anyway
Apr 18 20:04:01 <gdg> oh
Apr 18 20:04:56 <gdg> is there a manual for that?
Apr 18 20:05:45 <gdg> at the moment I only found something like https://community.nxp.com/docs/DOC-328199 or http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/package-manager-white-paper.pdf
Apr 18 20:05:59 <gdg> and those are for smart
Apr 18 20:10:34 <kergoth> http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#runtime-package-management-target-rpm
Apr 18 20:39:32 <LocutusOfBorg> thanks fray BTW, will followup tomorrow when my testing is finished :)
Apr 18 20:40:58 <fray> I'm still running here
Apr 18 20:41:28 <LocutusOfBorg> each time I insert debug code in some .py stuff the world  is rebuilt
Apr 18 20:41:49 <fray> what is the magic to enable systemd?  I'm trying to do this on oe-core, but I'm missing the flag.. (apparently)
Apr 18 20:42:21 <fray> wait, no I did find it.. distro features needs systemd added..
Apr 18 21:07:00 <fray> ok.. what I see is that NO scripts were added at all, not just systemd
Apr 18 21:08:57 <locutus_> interesting
Apr 18 22:11:25 <mivond> http://imgur.com/Mif38pf does anyone have any idea about this error?
Apr 18 22:11:28 <mivond> It's just hanging
Apr 18 22:11:53 <mivond> I can get into the U-Boot command prompt, but I can't get it to do anything useful
Apr 18 22:12:10 <mivond> This is after I added meta-mender-raspberrypi
Apr 18 22:12:16 <mivond> this is a pi3
Apr 18 22:17:51 <mivond> I did add more space by adding this in local.conf: MENDER_STORAGE_TOTAL_SIZE_MB = "4096"
Apr 18 22:18:03 <mivond> I was getting an error that mender didn't have enough space for roofs
**** ENDING LOGGING AT Wed Apr 19 03:00:03 2017