**** BEGIN LOGGING AT Tue Nov 10 02:59:59 2015 Nov 10 06:03:21 is it possible to do a bitbake build that skips the creation of binary (ipk, deb, rpm) packages? Nov 10 06:03:39 * csmart is trying to speed up CI test builds that don't need rpms Nov 10 06:07:42 hmm I'm guessing you can't disable package_classes, "Since images are generated from packages, a packaging class is needed to enable image generation." https://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#ref-classes-package Nov 10 08:04:15 good morning Nov 10 08:19:18 morning all Nov 10 08:21:08 hai Nov 10 08:34:21 hi guys Nov 10 09:07:45 hello everyone Nov 10 09:07:56 <[Sno]> rburton: wrt. libusb1 update to 1.0.20 - I proved the Makefile.am and resulting Makefile - looks fine for me, libusb-1.0.la has among other things ...linux-netlink.lo as dependency Nov 10 09:08:45 does anyone know which perl module i should add to get the Socket.pm? I tried to list all the available perl modules by doing a bitbake perl -e | grep ^PACKAGES= like i did for python packages but i didn't manage to get the appropriate module :( Nov 10 09:13:36 <[Sno]> drou: perl-module-socket from poky or socket-perl from meta-cpan ;) Nov 10 09:17:59 [Sno]: i have nothing matching perl-module-socket in poky (i'm using fido atm), ERROR: Nothing PROVIDES 'perl-module-socket' Nov 10 09:18:11 i thought i could find this module in meta-perl. Nov 10 09:18:31 <[Sno]> drou: it is part of perl recipe Nov 10 09:19:13 <[Sno]> for meta-cpan on fido you'll need some adjusting patches in poky, too Nov 10 09:28:55 indeed it's part of the perl recipe, but i can't figure out why the Socket.pm is not installed on my rpi Nov 10 09:54:56 <[Sno]> drou: see the package split of perl recipe Nov 10 09:58:38 is there some handy way to get the components of the target triple for e.g. the target system? Nov 10 09:59:14 <[Sno]> Ulfalizer: context, please Nov 10 09:59:16 in this case i need to refer to a directory within ${STAGING_DIR_HOST} whose name depends on the architecture Nov 10 10:00:17 e.g., ${STAGING_DIR_HOST}/${libdir}/ruby/i386-linux, where the last part depends on the system type Nov 10 10:00:58 needing to refer to it is related to cross-compiling ruby gems Nov 10 10:02:19 <[Sno]> Ulfalizer: I still don't get whether you want host or target triple components Nov 10 10:02:56 <[Sno]> Ulfalizer: I suggest you do a bitbake -e | less and scan for matching keys ... Nov 10 10:03:04 ah, sorry, i'm being unintentionally confusing. i need the host triple components (where "host" is in the sense of STAGING_DIR_HOST). Nov 10 10:03:22 sounds like a good idea Nov 10 10:03:59 <[Sno]> Ulfalizer: maybe having a look into recipes-devtools/perl how to cross-compile perl modules and https://github.com/rehsack/meta-cpan how to cross-compile perl-modules then Nov 10 10:04:13 <[Sno]> find the cpan*.bbclass in poky/meta/classes Nov 10 10:08:19 [Sno]: i nearly have it working. only problem left is hardcoding that i386-linux part. Nov 10 10:08:36 another option would be to patch that path component out of ruby Nov 10 10:08:44 <[Sno]> Ulfalizer: eg. ${PACKAGE_ARCH} might help Nov 10 10:08:44 * Ulfalizer digs through bitbake -e Nov 10 10:09:02 <[Sno]> nearly have it working means "works for you (tm)" ;) Nov 10 10:09:15 Hello, is there a way to check for an OVERRIDE value in a bash function? Nov 10 10:13:49 [Sno]: cross-compiling gems, and especially with ruby 1.9.2, is a huge pain in general. few people seem to even bother. :/ Nov 10 10:14:43 tools ignore CC, etc. there's some tailored hacks for cross-compiling for windows. Nov 10 10:16:27 [Sno]: i have the Socket.pm in my package-split, but i'm wondering if the perl-module-socket is shipped. Nov 10 10:17:18 autotools.bbclass is a nice reference. looks like HOST_ARCH might work Nov 10 10:18:45 <[Sno]> drou: RDEPENDS_${PN} might help Nov 10 10:18:56 <[Sno]> Ulfalizer: same for Perl :( Nov 10 10:22:57 * Ulfalizer wonders why there's a patch that forces i386 by adding target_cpu=`echo $target_cpu | sed s/i.86/i386/` to ruby's configure.in Nov 10 10:23:30 commit message is a generic "imported this from elsewhere" Nov 10 10:43:24 is putting e.g. '${HOST_ARCH}' directly into an inline python expansion a bad idea, as opposed to d.getVar('HOST_ARCH', True)? Nov 10 10:44:36 https://git.congatec.com/yocto/meta-openembedded/commit/bda4fdf91217a0cd35053053146b649ed62afb2f.patch does it, though with BUILD_SYS Nov 10 10:48:26 Ulfalizer: personally I prefer to use d.getVar() in such expressions since it's a bit less ugly, but we have a bunch of places where we use a variable reference Nov 10 10:48:56 are there any important semantic differences? Nov 10 10:51:06 I don't think so; AFAIK the variable reference will be expanded first and then the python expression will be evaluated, but that's going to happen at about the same time Nov 10 10:52:13 I can imagine it making a difference if you wanted to put actual python into the variable's value, but that would be just hideous ;) Nov 10 10:52:30 would there be a difference is the variable does not exist? i can't remember when bitbake considers that an error. Nov 10 10:52:36 always? Nov 10 10:52:58 heh, yeah, that'd be pretty horrible :P Nov 10 10:53:28 if a variable's value is undefined (and I mean undefined, not set to "") then the expression will be left unexpanded Nov 10 10:54:12 ok, and what would the d.getVar() version do? Nov 10 10:54:14 it's a bit odd, but the thinking was for shell functions (or variable values that end up in shell functions) the expression can then be intepreted by the shell i.e. as an environment variable Nov 10 10:54:35 d.getVar() will return None for an undefined variable Nov 10 10:54:58 i thought that was disambiguated via ${foo} vs. $foo, but some weird people use ${foo} when programming shell too :P Nov 10 10:55:07 which is why you'll often see things like: d.getVar('VARNAME', True) or "" Nov 10 10:55:13 yes, indeed Nov 10 10:55:30 it's much better to avoid ${...} in a shell function when you can use $... Nov 10 10:56:08 less visual clutter too, even if you're not using bitbake Nov 10 10:56:16 but i might be a bit opinionated :P Nov 10 10:56:51 right... I think the main reason for ${...} in shell is where you want to immediately follow with something that might otherwise be treated as part of the variable name Nov 10 10:56:58 but that's rare Nov 10 10:57:26 of course POSIX (and bash) let you do a bunch of funky stuff within ${...} as well Nov 10 11:12:24 bluelightning: Hey blue Nov 10 11:12:42 actually let me fix something first Nov 10 11:13:09 the artist previously known as raykinsella78 Nov 10 11:18:28 bluelightning: I want to add an extra config to the cross compiler when it is getting built with a EXTRA_OECONF_append_pn-gcc-cross .... Nov 10 11:19:03 bluelightning: I can't presume I know the host environment ... little unsure of how to do this. Nov 10 11:26:41 mortderire: I'm not quite sure what you're trying to do yet - can you elaborate? Nov 10 11:28:26 bluelightning: I want to pass an (autotools) configure option to the cross-compiler ... Nov 10 11:29:43 bluelightning: so when do_configure is getting called on gcc-cross, I want to tag ' --enable-yadda-yadda' onto the end ... Nov 10 11:30:38 I assume EXTRA_OECONF_append_pn-gcc-cross = " --enable-yadda-yadda" would do it... Nov 10 11:44:50 bluelightning: looks like it is getting ignored ... regardless of whether I do a EXTRA_OECONF_append_pn-gcc-cross or EXTRA_OECONF_append_pn-gcc hum .. Nov 10 11:46:40 mortderire: so you probably need to trace it using bitbake -e Nov 10 11:47:04 mortderire: i.e. run bitbake -e gcc-cross and check if the final EXTRA_OECONF value is what you expect it to be Nov 10 11:47:12 bluelightning: I did, the reciepe seems to override everything ... Nov 10 11:47:22 the recipe can't really override _append Nov 10 11:47:43 what does the history say in bitbake -e gcc-cross for EXTRA_OECONF ? Nov 10 11:48:52 Do I understand this correctly - to report bugs for recipes I have to *subscribe* to the mailing list before I can post there? Nov 10 11:50:39 bluelightning: http://pastebin.com/uvCRrncQ Nov 10 11:51:01 gatisp: recipes in which layer? Nov 10 11:51:31 bluelightning, openembedded-core Nov 10 11:51:40 bluelightning: the gcc recipe actually provides a variable to control the feature LTO, which it sets to " --enable-lto" .... Nov 10 11:52:44 mortderire: I don't see a _append[pn-gcc-cross] in there... where are you putting that statement? Nov 10 11:53:31 gatisp: so if you want to post to the mailing list you do need to subscribe; but genuine bugs / feature requests for OE-Core are tracked at bugzilla.yoctoproject.org Nov 10 11:56:17 bluelightning, somehow this is very frustrating :) There is no clear component in bugzilla which would say "recipe bugs", and last time i reported something there I was told to report things in openembedded-devel. Nov 10 11:56:17 bluelightning: I might have my setup backwards, shouldn't meta-intel be prioritized over OE ? Nov 10 11:56:46 gatisp: yes, that was a recipe in meta-oe was it not? Nov 10 11:56:53 but subscribing to a mailing list to report bugs occasionally seems bit too much Nov 10 11:57:19 yes, the bug that i want to report now is is meta-oe Nov 10 11:57:27 *is in Nov 10 11:57:39 gatisp: you just said openembedded-core above though... ? Nov 10 11:58:02 right, i mean *-core Nov 10 11:59:03 I'm confused now - which recipe is it exactly? Nov 10 11:59:15 gnupg Nov 10 11:59:55 right, so that is in OE-Core in which case the correct place would be bugzilla.yoctoproject.org Nov 10 12:00:13 bluelightning: http://pastebin.com/KW9XcUNk Nov 10 12:00:39 ok, I'ļl do that Nov 10 12:00:47 gatisp: file a bug -> Build System & Metadata -> OE‑Core -> core (for want of a better category, I don't think there is one) Nov 10 12:02:43 done https://bugzilla.yoctoproject.org/show_bug.cgi?id=8672 :) Nov 10 12:02:44 Bug 8672: normal, Undecided, ---, ross.burton, NEW , gpgconf has incorrect paths when installing in host toolchain Nov 10 12:02:50 mortderire: hang on, if it's the --enable-lto option you want to replace why not just set LTO ? Nov 10 12:03:04 mortderire: since that appears to be where that's coming from Nov 10 12:03:05 bluelightning: it get's overriden ... Nov 10 12:03:31 # $LTO [2 operations] Nov 10 12:03:31 # set /build/yocto/meta-intel/conf/machine/include/intel-quark-common.inc:15 Nov 10 12:03:31 # " --disable-lto" Nov 10 12:03:31 # set /build/yocto/poky/meta/recipes-devtools/gcc/gcc-5.2.inc:87 Nov 10 12:03:31 # "--enable-lto" Nov 10 12:03:32 # pre-expansion value: Nov 10 12:03:32 # "--enable-lto" Nov 10 12:03:33 LTO="--enable-lto" Nov 10 12:03:48 mortderire: try LTO_pn-gcc-cross = "" Nov 10 12:04:12 mortderire: the override will apply in place of the value set with = Nov 10 12:05:25 bluelightning: # $LTO [3 operations] Nov 10 12:05:26 # set /build/yocto/meta-intel/conf/machine/include/intel-quark-common.inc:15 Nov 10 12:05:26 # " --disable-lto" Nov 10 12:05:26 # set /build/yocto/poky/meta/recipes-devtools/gcc/gcc-5.2.inc:87 Nov 10 12:05:26 # "--enable-lto" Nov 10 12:05:26 # override[pn-gcc-cross]:set /build/yocto/meta-intel/conf/machine/include/intel-quark-common.inc:16 Nov 10 12:05:26 # " --disable-lto" Nov 10 12:05:27 # pre-expansion value: Nov 10 12:05:27 # "--enable-lto" Nov 10 12:05:28 LTO="--enable-lto" Nov 10 12:05:55 mortderire: that's the output of bitbake -e or bitbake -e gcc-cross ? Nov 10 12:06:11 bluelightning: bitbake -e gcc-cross Nov 10 12:06:33 bluelightning: well gcc-cross-i586 ... to be percise. Nov 10 12:06:40 oh Nov 10 12:06:43 that's why it's not working Nov 10 12:06:50 bluelightning: gotcha Nov 10 12:06:58 PN gets set to include the architecture for gcc-cross Nov 10 12:07:25 btw this isn't very good because it means the ostensibly same-for-all-i586 compiler is now being made machine-specific for quark Nov 10 12:07:36 bluelightning: makes sense ... so the override is ignored. Nov 10 12:08:22 # Nov 10 12:08:23 # $LTO [3 operations] Nov 10 12:08:23 # set /build/yocto/meta-intel/conf/machine/include/intel-quark-common.inc:15 Nov 10 12:08:23 # " --disable-lto" Nov 10 12:08:23 # set /build/yocto/poky/meta/recipes-devtools/gcc/gcc-5.2.inc:87 Nov 10 12:08:23 # "--enable-lto" Nov 10 12:08:23 # override[pn-gcc-cross-i586]:set /build/yocto/meta-intel/conf/machine/include/intel-quark-common.inc:16 Nov 10 12:08:24 # " --disable-lto" Nov 10 12:08:24 # pre-expansion value: Nov 10 12:08:25 # " --disable-lto" Nov 10 12:08:25 LTO=" --disable-lto" Nov 10 12:08:40 bluelightning: ok that worked (sorry for all the spam in the chat window). Nov 10 12:08:59 np, but pastebin is a useful alternative for future reference ;) Nov 10 12:10:27 bluelightning: the is an upper limited for pasting in to the chat window versus paste bin :-) Nov 10 12:10:54 nothing written down... but I would say "more than a few lines" ;) Nov 10 12:11:56 bluelightning: ok - I think this is going to work ... its only an override on gcc-cross when people use the MACHINE="intel-quark" Nov 10 12:13:44 bluelightning: thanks for your help. Nov 10 12:17:08 hey. when i build meta-toolchain-qt5, why does bitbake display: DISTRO = "fsl-networking"? Nov 10 12:20:28 qknight: somewhere your DISTRO is being set to that, and it doesn't relate to meta-toolchain-qt5 Nov 10 12:20:55 qknight: if you're unsure as to where, bitbake -e | less and search for DISTRO and the variable history will tell you Nov 10 12:21:13 ah, good point! Nov 10 12:48:24 http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-support/boost/boost.inc <- there is a BOOST_LIBS = .. list Nov 10 12:48:43 how can i alter that list when building my image? seems chrono and log is not enabled by default but i require it Nov 10 12:49:36 btw: i'm on daisy Nov 10 12:49:38 qknight: bbappend the boost recipe and set BOOST_LIBS Nov 10 12:49:49 (you can't set this from the image) Nov 10 12:50:13 bluelightning: ah, ok so i have to alter the source Nov 10 12:50:14 thanks Nov 10 12:50:36 you have to change how boost is built, to be precise Nov 10 12:50:49 you can do that from a bbappend in your own layer though Nov 10 12:55:14 s/can/should/ :-) Nov 10 12:55:51 yes :) Nov 10 13:32:52 How can one exclude RRECOMMENDS_${PN} += "some_recipe" for nativesdk-* builds? I remember seeing this functionality somewhere, but can not find anymore. Nov 10 13:42:23 ah, found it "_class-target" Nov 10 14:00:00 hi, i am using yocto/meta-raspberry to build an image for RPi1. its using an ext3 by default. I'd like to change that to btrfs. Nov 10 14:00:12 how do i do this? Nov 10 14:03:29 is there any way to have static SRVREV instead of ${AUTOREV}? in order to be able to reproduce the build with exactly the same versions, several times? Nov 10 14:06:04 fmeerkoetter: set IMAGE_FSTYPES = "btrfs" Nov 10 14:10:47 drou: if you mean still keeping SRCREV = "${AUTOREV}" in the recipe, yes, one way is to enable buildhistory, run a build and then use buildhistory-collect-srcrevs to create an inc file that fixes the SRCREV values which you can then include Nov 10 14:27:23 bluelightning: thanks, but i have to do this for every single recipe that has a ${AUTOREV}? Nov 10 14:30:14 drou: what do you mean "every single recipe" -- where do you have a lot of those? Nov 10 14:32:46 drou: the method I mentioned will pick up all of the ones that have been built and produce output that can go into a single inc file which you can include in your configuration - so it's relatively painless Nov 10 14:33:00 no modifications required to any individual recipes Nov 10 14:33:29 bluelightning: ah i got it, i'll try, thanks Nov 10 14:38:48 hi guys, is there some way of changing DISTRO_FEATURES from an image recipe or do I need to create a whole new layer. my DISTRO_FEATURES includes "wayland" and I want an image variant that uses "x11" instead.. Nov 10 14:40:00 * rink notes, you shouldn't resist against creating a layer Nov 10 14:40:05 it's easy and makes things much clearer IMO Nov 10 14:40:20 Are Wayland and X11 protocol compatible, or completely different fish? Nov 10 14:40:37 wayland is an x11 replacement as I understand it Nov 10 14:40:59 rink: trouble is when you end up with too many layers, there is a balance. Nov 10 14:41:00 mortderire: entirely different, though you can effectively run one under the other Nov 10 14:41:05 customer wants to use wayland for building their apps, but we have our testing framework implemented in x11+qt so I need to be able to build both variants Nov 10 14:41:36 bluelightning: wayland on X11 i assume ... Nov 10 14:41:56 xerent: you'll effectively need two distros if you want two different configurations; however you could have a single DISTRO_FEATURES value that enabled both at the same time then just include the appropriate packages in either image Nov 10 14:42:06 mortderire: and X11 apps under Wayland as well Nov 10 14:42:33 mortderire: (the latter is known as XWayland) Nov 10 14:42:57 maybe xwayland could work for us Nov 10 14:43:25 I tried including both x11 and wayland in distro features but then wayland wouldn't build. some issue with the freescale BSP in graphics driver I think Nov 10 14:43:35 (building for iMX6) Nov 10 14:44:08 you'd probably need to talk to Freescale or possibly otavio about that, but AFAIK both should be able to be enabled at the same time Nov 10 14:44:38 and I think it's what you want to be doing in this case Nov 10 14:45:25 wouldn't having x11 as a distro feature include stuff on the image even if nothing used it Nov 10 14:46:54 xerent: if it's in distro features, then likely something will use it Nov 10 14:47:12 well say that nothing in one image configuration will use it Nov 10 14:47:48 then I'd want to omit it because of space concerns Nov 10 14:51:09 xerent: not necessarily; DISTRO_FEATURES just turns on build-level functionality; in the absence of hard dependencies you still have control over which packages get included in the image Nov 10 14:51:41 a lot of recipes will modify their _default_ configuration if x11 is in distro features: then packages will end up depending on X libraries Nov 10 14:51:53 right, a hard dependency in that case Nov 10 14:55:01 well, I could modify the script that generates the BSP for the customer to include a different layer config where x11 isn't enabled Nov 10 14:55:08 it's ugly, but it'll work I guess Nov 10 15:35:20 I am trying to fix https://bugzilla.yoctoproject.org/show_bug.cgi?id=8672 What i see is the prefix that is used by gpgconf tool is determined at build time with --bindir and similar autotools switches. I don't see any way how this could be changed later when installing toolchain. Maybe somebody has experience with similar setup? Nov 10 15:35:22 Bug 8672: normal, Undecided, ---, ross.burton, NEW , gpgconf has incorrect paths when installing in host toolchain Nov 10 15:36:50 gatisp: one way we sometimes handle this kind of thing is using a wrapper script Nov 10 15:37:17 gatisp: that's assuming the software in question can be patched to read the path from the environment or a command line switch (or already can do so) Nov 10 15:38:12 "git grep create_wrapper" for examples Nov 10 15:38:30 bluelightning, I think at the moment there is not way to set this at runtime. At least i did not find anything after googling and looking at the source code. Nov 10 15:38:40 will grep for wrapper examples Nov 10 15:39:21 for rpm5 we patch in the ability to do this, there may be others where we do that as well Nov 10 15:39:59 bluelightning, do you usually upstream that kind of stuff later? or it always stays as a patch in yocto Nov 10 15:41:19 Is it somehow possible to chain two on a variable? Like 'VAR_distro_machine=' Nov 10 15:41:39 gatisp: in the case of rpm5 it's stayed as a patch in OE-Core, I don't know of other examples... depends if it's generally useful to others or not Nov 10 15:42:11 DatGizmo: two overrides? it is, yes - exactly like that Nov 10 15:42:44 bluelightning: hm.. then I've made a mistake.. thanks Nov 10 15:43:06 bluelightning, I just don't feel very confident adding envnvars in code that is all about security :) thats why i was wondering about upstreaming Nov 10 15:48:44 better yet, patch it to find all of its paths relative to the binary location, so it's completely relocatable on its own, then we wouldn't need to use wrappers at all :) but sadly that often involves invasive changes.. Nov 10 15:48:47 * kergoth sighs Nov 10 15:53:14 FYI the rpm5 wrapper.. it's specific to OE/YP so that is why we're carrying it. There is no upstream desire for this functionality.. (in fact there is justified resistance) Nov 10 15:54:26 bluelightning: thanks for your help. this helped us really greatly Nov 10 16:03:27 qknight: no problem Nov 10 17:59:54 bluelightning: about "set IMAGE_FSTYPES = "btrfs"" Nov 10 18:00:03 this worked only halfways for me Nov 10 18:00:18 it did indeed build a btrfs.rootfs Nov 10 18:00:20 but Nov 10 18:00:53 it is not creating an rpi specific .sdimg from it Nov 10 18:01:15 i understand that this is specific to the rpi bsp Nov 10 18:01:34 right, I'm not intimately familiar with how that layer does its SD card image generation Nov 10 18:02:20 well, i'll have to look into it. thanks! Nov 10 18:02:33 however, looking at the class just now, it looks like you can just set SDIMG_ROOTFS_TYPE = "btrfs" Nov 10 18:02:40 give that a try Nov 10 18:02:58 in addition to the IMAGE_FSTYPES? Nov 10 18:03:16 it's possible you don't need to set IMAGE_FSTYPES actually Nov 10 18:03:27 ok. i'll try Nov 10 18:15:46 bluelightning: only adding SDIMG_ROOTFS_TYPE = "btrfs" to my local.conf has the effect the two rootfs images are generated. an ext3 and a btrfs. Nov 10 18:16:04 the problem is that the ext3 one is picked up for generating the sdimage Nov 10 18:16:49 fmeerkoetter: I know that's what was happening earlier - have you checked it's still that now having set the new variable? Nov 10 18:18:07 bluelightning: how do I do this? removing the images in tmp/deploy/images/... and retry? Nov 10 18:18:30 fmeerkoetter: I mean, have you checked the sdimg file? Nov 10 18:18:51 ah. you mean dd it and boot? Nov 10 18:18:58 no Nov 10 18:19:00 will try Nov 10 18:28:41 bluelightning: ok, you were right it worked Nov 10 18:28:43 kind of Nov 10 18:28:45 :-) Nov 10 18:29:01 ah - what do you mean by that? Nov 10 18:29:07 now the kernel halts during boot bc. it doesn't know how to handle a btrfs Nov 10 18:29:08 :- Nov 10 18:29:10 ) Nov 10 18:29:20 ah right... heh Nov 10 18:29:30 [ 1.984034] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2) Nov 10 18:29:31 you'll need to ensure it's enabled in the kernel config I guess Nov 10 18:29:54 yeah. lets try Nov 10 19:11:49 how do I install a package with the files owned by a particular user? I've modified fs-perms.txt, and added a chown command in my do_install, but the rpm still lists everything as owned by root. Nov 10 19:12:58 the entries in the pseudo files.db list the correct perms too, fwiw Nov 10 19:15:41 tkilbourn: how are you ensuring that user gets created on the target? Nov 10 19:16:54 I have a useradd stanza in my image file. I'm also using numeric ids in my fs-perms and chown commands. Nov 10 19:17:20 sorry, extrausers Nov 10 19:20:33 in more detail: I have FILESYSTEM_PERMS_TABLES set in my distro's .conf file, pointing to a file making /home/user1 owned by user1, with walk set to true Nov 10 19:20:46 but using user1's numeric uid Nov 10 19:21:15 are you setting the numeric uid in the useradd parameter or allowing the system to define it? Nov 10 19:21:23 then, in my image recipe, I inherit extrausers and use EXTRA_USERS_PARAMS to create the users Nov 10 19:21:30 yes I'm setting the numeric id Nov 10 19:21:37 You should not usually use the numeric id though in the fs-perms.. Nov 10 19:22:16 by uncommenting some bb.notes in package.bbclass, I can tell that fixup_perms is correctly handling it Nov 10 19:22:19 (the reason is that there are ways to override the ID numbers.. and if someone were to do that, hard coding the number in the fs-perms won't allow it to be overwritten like a name would) Nov 10 19:22:26 ok good to know Nov 10 19:22:45 but the package class doesn't have access to my usernames, if my image recipe is run last? Nov 10 19:22:47 but both name and number should both work in the fs-perms Nov 10 19:22:48 or are users added earlier? Nov 10 19:23:23 users are added when the recipe is built that has the 'add' in it.. Nov 10 19:23:41 if you need to use the ID earlier.. you need an explicit dependency or each recipe needs to have a copy of the 'add Nov 10 19:24:09 so a separate recipe to create users could be useful. Nov 10 19:24:19 would that still explain the problems between the pseudo steps and the rpmbuild though? Nov 10 19:25:09 afaict, ownership and permissions are only set during packaging Nov 10 19:25:24 so everything should look correct in the deploy rpms, right? Nov 10 19:25:36 but everything is listed as root:root in the rpm Nov 10 19:26:13 bluelightning: /dev/mmcblk0p2 on / type btrfs (rw,relatime,ssd,space_cache) Nov 10 19:26:19 success :-) Nov 10 19:27:02 fmeerkoetter: :) Nov 10 19:31:59 to sum it up. Nov 10 19:32:02 SDIMG_ROOTFS_TYPE = "btrfs" Nov 10 19:32:29 ther kernel commandline contained rootfstype=ext3 which i changed to btrfs Nov 10 19:32:46 and i needed to compile in the btrfs support into the kernel Nov 10 19:32:52 it was in there as a module Nov 10 19:33:12 why i needed to compile it in i don't know Nov 10 19:33:15 bluelightning: ^ Nov 10 19:33:58 it would need to be compiled in unless you were using some form of initramfs with that module in it Nov 10 19:34:14 the kernel command line thing is a bit bothersome Nov 10 19:34:45 bluelightning: ah. i am using a config without initramfs Nov 10 19:34:59 so this is also explained Nov 10 19:36:48 I'm not sure where the kernel command line reference comes from ; FWIW it's nowhere to be found in the metadata Nov 10 19:47:16 creating the users in a separate recipe instead of in my image recipe seems to have fixed the problem Nov 10 19:55:04 we really ought to be doing validation on this... thought I thought we added some in the current release Nov 10 19:55:22 (or should I say imminent release) **** ENDING LOGGING AT Wed Nov 11 02:59:58 2015