**** BEGIN LOGGING AT Thu Jul 18 02:59:58 2013 Jul 18 03:45:21 there we go, added —sysroot= to systemd-tmpfiles and ran it against ${IMAGE_ROOTFS} manually fine, now for integration and working out the kinks, then need a volatiles to tmpfiles.d migration story.. Jul 18 03:45:49 (using systemd-tmpfiles recipe built for native) Jul 18 04:40:35 can I override a package variable within a distro.conf. i.e. I want to change EXTRA_OEMAKE for a specific package in the distro.conf rather than modifying the .bb file. Jul 18 04:41:02 Should I be wanting to do this? or am I trying to do things backwards. Jul 18 07:57:52 morning all Jul 18 08:07:23 bluelightning: morning! Jul 18 08:07:31 so, i got more information from our dev. Jul 18 08:07:51 his problem is a 'permission denied' issue during rm_work on gcc-runtime. Jul 18 08:08:32 hi ndec Jul 18 08:08:33 his 'pseudo' environment is very similar to mine. LD_LIBRARY_PATH has both /lib and /lib64. Jul 18 08:09:01 permission denied? hmm - can you tell what it's trying to delete when it fails? Jul 18 08:09:41 we just made an interesting finding. on his 'corporate' linux PC, he is required to install a 'Linux SDK', which in turns is enabling setuid on chmod and chown... Jul 18 08:10:03 so i am pretty sure that this is the origin of the problem. Jul 18 08:10:14 bluelightning: rm: cannot remove `image/usr/include/c++/unordered_set': Permission denied Jul 18 08:10:14 rm: cannot remove `image/usr/include/c++/cfloat': Permission denied Jul 18 08:10:14 rm: cannot remove `image/usr/include/c++/cstdbool': Permission denied Jul 18 08:11:20 what's stopping it I wonder... Jul 18 08:11:36 do_rm_work isn't a fakeroot task so pseudo shouldn't be in the way Jul 18 08:12:00 yeah. i finally don't think it's related to pseudo. Jul 18 08:12:35 but the files mentioned above are owned by 'root'. though. that's why i initially thought it was related to pseudo. Jul 18 08:20:44 ndec: owned by root outside of the pseudo environment? how is that possible? Jul 18 08:21:48 bluelightning: ok... just got confirmation that the problem was the setuid. Jul 18 08:22:06 ndec: suid of what specifically? Jul 18 08:22:43 as i said above, on his 'corporate' machine, we figured out that chown, chmod and mknod are setuid. Jul 18 08:23:49 so, i guess that OE uses those, and as a consequence some files ended up as 'root'. then in rm_work that explains the perm denied. Jul 18 08:24:49 bluelightning: after doing the following commands, everything is back to normal: Jul 18 08:24:49 sudo chmod -s `which mknod` Jul 18 08:24:49 sudo chmod -s `which chmod` Jul 18 08:24:49 sudo chmod -s `which chown` Jul 18 08:28:06 bluelightning: hehe... in gcc-runtime do_install, i found this: chown -R root:root ${D} | Jul 18 08:29:47 perhaps we should add a 'sanity' check for that situation. and make sure critical commands don't have +s bit. Jul 18 08:30:08 ndec: the question is how did they come to have that bit set in the first place? Jul 18 08:30:39 bluelightning: by installing a 'company required' SDK on his linux pc. Jul 18 08:30:45 oh dear Jul 18 08:31:08 yeah... if they wanted to increase security, that's lame ;-) Jul 18 08:31:16 someone ought to point out to whoever produces that SDK what a massive security hole they're enforcing on their users Jul 18 08:32:02 yep... and I won't name that company, but it's a very well known very large corporation ;-) Jul 18 08:33:21 bluelightning: do you think we should add a sanity check for that? since we now know that it does break the build... Jul 18 08:34:19 if it's likely to be encountered by more than a few users in an isolated environment then it seems like we should have a check for it Jul 18 08:38:52 ndec: if you haven't already it would be good to run through a full fresh build on the machine with those things disabled just to make sure that was definitely the cause of the problem Jul 18 08:38:56 I somehow remember there was a bit of discussion about that chown Jul 18 08:47:05 http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-devtools/gcc/gcc-configure-runtime.inc?id=db99a65b3e93dfacc27ea821c788f15b5de3a497 Jul 18 08:47:37 bluelightning: yes, a fresh build works now. Jul 18 08:48:13 ant_work: well, i think that line in this commit, is exactly what's causing the problem. Jul 18 08:48:33 on the machine which had chown with +s bit. Jul 18 08:48:48 http://lists.openembedded.org/pipermail/openembedded-core/2011-June/042775.html Jul 18 08:49:41 no, this one Jul 18 08:49:42 http://lists.openembedded.org/pipermail/openembedded-core/2011-June/043556.html Jul 18 08:50:55 specifically gcc Jul 18 08:50:56 http://lists.openembedded.org/pipermail/openembedded-core/2011-June/043831.html Jul 18 09:24:28 morning all Jul 18 09:29:01 hi eren Jul 18 09:32:05 bluelightning: https://lists.yoctoproject.org/pipermail/yocto/2013-July/017268.html Jul 18 09:32:23 libcurl disables sftp, I am wondering if we should add it with PACKAGECONFIG Jul 18 09:32:30 however, we should first package libssh2 library Jul 18 09:32:33 any idea? Jul 18 09:32:47 eren: right, we'd have to have a libssh2 recipe somewhere before adding that I think Jul 18 09:33:39 I searched and there is only a libssh recipe in some unofficial layer which I'm guessing is not the same thing anyway Jul 18 09:37:36 bluelightning: is it worth packaging? Jul 18 09:37:42 there seems to be one case, actually Jul 18 09:38:00 I'm not sure if libcurl with sftp is desired by most people Jul 18 09:38:34 right, any additional libssh2 library would probably go into another layer such as meta-networking or meta-oe Jul 18 09:41:01 A question to any number of the yocto project here - If I have written a significant number of recipes, many of which did not exist in advance, and want to contribute to the project - Should I just create my own layer and place it in a public repository, or is there a recommend procedure or collection of recipes somewhere where I could place them? Jul 18 09:41:06 *member of the Jul 18 09:52:42 Stygia: in the general case it depends on what category the recipes fall into Jul 18 09:53:07 Stygia: for your specific perl recipe case, we don't have a specific place for perl recipes outside OE-Core, so it seems reasonable to create one Jul 18 09:53:21 bluelightning, In this case, I have mostly cpan recipes, and then a few regular programs. Jul 18 09:53:28 bluelightning, Create one on my own repo, or as part of the project? Jul 18 09:53:52 bluelightning, I also made one for CCRYPT today, not related to the (presumably so-named) future meta-cpan layer. Jul 18 09:54:34 Stygia: unrelated recipes would go somewhere else; if there's no obvious place they could go to meta-oe Jul 18 09:55:04 bluelightning, I'm still somewhat in doubt. You are saying to contribute it directly back to OE/Yocto, as opposed to just hosting it all on my own repository, yes? Jul 18 09:55:54 Stygia: the OE community is fine with people maintaining layers in their own repos Jul 18 09:56:33 Stygia: it just gets a bit tricky if we have recipes in more central layers such as meta-oe depending on recipes in a layer that isn't in the same repository Jul 18 09:56:39 bluelightning, Well, alright, I will do that then. Is there a central place to help people find existing layers, not for hosting, but maybe just as a navigational aid? Jul 18 09:57:01 bluelightning, If not I think maybe there should be. Jul 18 09:57:09 Stygia: at the moment no such dependencies exist though; the issue can be addressed later if need be Jul 18 09:57:20 Stygia: sure, there's the layer index at http://layers.openembedded.org Jul 18 09:58:27 that provides a way for people to find out about the existence of any particular recipe no matter which layer it's in Jul 18 09:59:02 bluelightning, Yes exactly, great, that's what I needed. :) Well in that case I think I"m pretty set (until the next recipe gives me trouble), I'll finish up, make the repo public, and add it to that listing. Jul 18 09:59:25 Stygia: awesome :) Jul 18 09:59:37 bluelightning, Although, I think maybe CCRYPT could be included in the actual core distribution, maybe, it doesn't fit with meta-cpan and has no dependencies outside virtual/something which came build-in. Jul 18 10:00:24 Stygia: for that one it's probably best to submit a patch to add it to meta-oe Jul 18 10:01:30 bluelightning, Alright, I will do. Since I've honestly never contributed to an open-source project before... if I check out meta-oe, add my file and push it, then they will look at it and review my commit, yes? Jul 18 10:01:53 Stygia: this should help: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Jul 18 10:02:17 bluelightning, Thanks dude. Jul 18 10:02:22 bluelightning, Or dudeette, whatever. Jul 18 10:02:47 Stygia: dude in this case, but nice of you to consider the inherent ambiguity :) Jul 18 10:07:53 bluelightning, In my language it's much easier to just say something like 'dude' without worrying about gender. Jul 18 10:08:15 bluelightning, We do say 'man' to women but nobody really "notices" Jul 18 10:08:19 bluelightning, Only as slang. Jul 18 10:08:57 unforgivable ;) Jul 18 10:12:16 ant_work, Actually in most languages the male pronoun is the recognized "default". :P He doesn't always imply gender. Jul 18 10:12:26 ant_work, Although I think that only applies to English/Anglosax language group. Jul 18 10:13:23 i'd say "he" does imply gender in english, but it's abused because there isn't a non-gendered word that isn't archaic Jul 18 10:14:07 rburton, Well it does, but it is also the default pronoun AFAIK. Thou/thee is too old, but AFAIK "he" is what's supposed to be the default. Jul 18 10:14:21 rburton, I know books that consistently use "she" throws me off, because it's unusual, whereas "he" just gets skimmed. Jul 18 10:14:38 rburton, Although that is simply force of habit I do believe it's a semi-official convention, yea? Jul 18 10:15:20 You can use "they" in some circumstances - a bit rude referring to people in the 3rd person if they're present though :-D Jul 18 10:15:40 he is certainly the default option if the gender is unknown, but that's mainly just #everydaysexism ;) Jul 18 10:15:53 pev, Our "they"/thee is uber-polite, but not as archeic as Thou/Thee Jul 18 10:16:14 rburton, Well yes it is, but at this point trying to mess with the default pronoun is pointless and confusing IMHO. Jul 18 10:17:01 Stygia: Interesting! I like it when languages evolve but keep polite bits in still. I think it says something about the culture and personality of the people using the language... Jul 18 10:17:28 pev, Yes it does, although now we only use "thee" for really oldish people, it's like "Sir"/Mam to us, but a bit more archeic. Jul 18 10:17:32 pev, Danish, FYI. Jul 18 10:18:09 That would make sense ; all the Danes I've met have been very polite! Jul 18 10:18:41 Although the "Sir" thing in the states always confuses me - it comes across as polite but the way people act while saying it generally makes it feel really false...! Jul 18 10:25:25 I always hate being called sir Jul 18 11:06:24 Hmm, if I have a recipe installing files into a shared area where those files already exist, and I am using automation (such as inherit cpan), can I prevent the warnings/errors without having to make a FILES_${PN} array for each recipe? Jul 18 11:07:54 Stygia: it's not really a FILES issue; the clashing files shouldn't be being installed in do_install (or more precisely, only one recipe should be doing that) Jul 18 11:08:20 bluelightning, Well, I'm not manually doing it for either recipe, I have two CPAN recipes, both using "inherit cpan", and they're conflicting. Jul 18 11:08:53 Stygia: no, it's likely an upstream issue; the workaround is to just add a do_install_append to delete the files Jul 18 11:09:16 bluelightning, Ah right, I will do that then. Presumably, upstream as in CPAN, yes? Jul 18 11:09:26 bluelightning, And not as in the maintainers of cpan.bbclass\ Jul 18 11:09:35 Stygia: the specific cpan package I would think Jul 18 11:09:50 bluelightning, Seems likely, it's not the first package to install things provided by other packages. Jul 18 11:10:30 Stygia: I'm assuming it's not a case of a cpan script auto-downloading dependencies... Jul 18 11:10:50 bluelightning, Not in this case, I don't think. Jul 18 11:10:56 ok Jul 18 11:11:46 bluelightning, Although, looking back to my first week of barely being able to use bb, presumably that's exactly went wrong with my DateTime recipe back then. Jul 18 11:12:23 bluelightning, Not that it matters now though. :) Jul 18 11:12:54 bluelightning, After these couple of weeks, I could probably troll this newsgroup and be of help to news when you or rburton weren't around. Jul 18 11:44:02 Hm, does DEPENDS imply RDEPENDS or do I need to set both? Jul 18 11:45:23 pev, They're different. Jul 18 11:45:35 pev, DEPENDS, AFAIK, lists build-time dependencies. Jul 18 11:45:40 pev, Things needed to actually build the package. Jul 18 11:45:57 pev, Whereas RDEPENDS is runtime dependencies, i.e. things needed for the package to even run. Jul 18 11:46:08 Am I right in thinking DEPENDS relate to recipe names and RDEPENDS is package names? Jul 18 11:46:09 pev, Ask bluelightning or rburton for confirmation, but I am pretty sure. Jul 18 11:46:19 pev, Nope, both recipe names AFAIK Jul 18 11:46:40 pev, The difference is, a DEPENDS will not necessarily be included in the image that uses the package that DEPENDS on it, whereas an RDEPENDS means "build this and include it" Jul 18 11:48:16 Stygia: Ahhh http://www.yoctoproject.org/docs/1.4/ref-manual/ref-manual.html#var-RDEPENDS Jul 18 11:49:20 pev, Huh. Well then clearly you are right. Jul 18 11:49:41 pev, Although, if I'm not mistaken, aren't package names _usually_ equal to recipe names? Jul 18 11:50:28 Stygia: Not sure, I think so - except a recipe can define quite a few package names based off the same root name e.g. -dev -dbg etc? Jul 18 11:50:33 *superset Jul 18 11:51:11 pev, Ah right, I do think so then. Unless you specify a package name explicitly, I think it becomes everything before _ in the recipe name. Jul 18 11:51:22 bluelightning, rburton would know. Jul 18 11:52:36 Stygia: So, I'm trying to test I've got it right. Is the right thing to do to blow away my three interdependent recipies via bitbake -c cleanall and then retest building the recipe that needs its dependencies satisfied? Jul 18 12:02:18 pev, Yes, in my experience. Jul 18 12:02:29 pev, But we warned cleanall removes changes to config from a menuconfig action Jul 18 12:12:30 DEPENDS is a build-time dependency, RDEPENDS is runtime Jul 18 12:13:04 the value of PN is derived from the recipe file name yes Jul 18 12:13:26 bluelightning, Thanks. :) Thought so. Jul 18 12:14:34 you can see how in conf/bitbake.conf, if you're interested Jul 18 12:15:29 bluelightning, Immediately, there's no such file in my build/conf directory. Jul 18 12:16:45 Stygia: meta/conf/bitbake.conf Jul 18 12:16:56 (sorry, I should be more specific) Jul 18 12:17:36 bluelightning, Heh, the more specific version would be sources/poky/meta/conf/bitbake.conf Jul 18 12:17:55 bluelightning, I was in the build directory which also has a conf dir, was confused. :) But I'd have lived anway, locate is installed after all. Jul 18 12:18:38 well, above meta/ it depends on where you've cloned it and what name you've cloned it as :) Jul 18 12:19:10 bluelightning, Ah, fair enough. I did not know that. :) My boss set all this up and then set me to work writing recipes. Jul 18 12:19:19 ah right, fair enough Jul 18 12:20:46 bluelightning, He's really the embedded guy, and I'm the "normal" dev, we're just a busy, tiny company. Jul 18 12:32:55 bluelightning, Hey, which is more correct, RPROVIDES, or RPROVIDES_${PN}? Jul 18 12:34:12 Stygia: the latter Jul 18 12:34:19 bluelightning, Thanks. Jul 18 12:34:50 Stygia: you'll get a warning if you use the former since it would apply to all packages in the recipe, which 99% of the time is not what you want Jul 18 12:39:28 bluelightning, Ah alright, I did use the latter ,but then I saw a comment on a patch saying the former was wrong (without explaination), and I wondered Jul 18 13:30:07 bluelightning: hi, one more question.. I'm using opkg and I noticed that on rootfs creation the package database didn't make it into the image Jul 18 13:32:41 bluelightning: hi, one more question.. I'm using opkg and I noticed that on rootfs creation the package database didn't make it into the image. is this known? a feature? Jul 18 13:33:05 did you includes package-management in your image features? Jul 18 13:33:06 /var/lib/opkg is empty in my image. :} Jul 18 13:33:37 rburton: yeah, but I assume there is probably another variable I need to set. I am slowly upgrading from edison to master Jul 18 13:36:03 zecke: package-management needs to be in IMAGE_FEATURES and you need to avoid adding remove_packaging_data_files to ROOTFS_POSTPROCESS_COMMAND (as core-image-minimal used to) Jul 18 13:39:38 bluelightning_: ah yeay, package-management is missing. what is the most sensible place for it? the image.bb? Jul 18 13:40:59 zecke: it's up to you really; it depends on whether package management is something fundamental to the image, or all images in your distro config Jul 18 13:45:40 bluelightning: thanks! Jul 18 13:46:23 rburton: how open are you to include changes like this? http://lists.freedesktop.org/archives/systemd-devel/2013-July/012115.html? Jul 18 13:51:21 zecke: seems reasonable Jul 18 13:57:59 Hi guys. Hello everybody. I've got a problem listed at the end of this paste: http://pastebin.com/afUBJyUs Jul 18 13:59:11 to sum it up: I have a custom image based on fsl-image-gui on which I added a custom layer to which I added lirc from https://github.com/Guacamayo/meta-guacamayo/blob/master/meta-guacamayo/recipes-support/ Jul 18 14:00:46 i'm having this do_rootfs problem, I think due to the fact I added DRIVER ?= "--with-driver=irman" to lirc-config.inc Jul 18 14:01:11 now I've commented lirc from my image, but still get the error. Jul 18 14:02:19 2 things: 1) how do I clean out the error? bitbake -c my-image-sdk doesn't seem to help. 2) How do I debug do_rootfs fuction? I don't really know what's causing that error! Jul 18 14:04:45 Net147: Hello Jonathan Jul 18 14:05:18 Net147: related to http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=b52d2bb46ed7c893077ccf9e5a83dc7f11c7f61b Jul 18 14:05:43 Net147: boot-directdisk: allow specifying custom MBR disk signature Jul 18 14:05:58 panda84kde: the issue is in meta/classes/license.bbclass Jul 18 14:06:34 panda84kde: for some reason it can't find a package directory for the package that's going to be installed Jul 18 14:06:56 panda84kde: aside from that it shouldn't really be erroring out like that though Jul 18 14:07:22 bluelightning: first of all hi and thank you :) Jul 18 14:08:34 bluelightning: step2: how did you get it's a problem of licence.bbclass? Just because there were warnings about license in the previous lines? Jul 18 14:09:53 panda84kde: that and I also have seen this error before, although I've never been able to reproduce it Jul 18 14:15:09 rburton: should I just remove the added patch for mesa git? Jul 18 14:15:55 rburton: I was thinking since it is set to 9.1.5 release it should have the same patches Jul 18 14:17:08 bluelightning: should be this "ls": http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/license.bbclass#n31 Jul 18 14:17:39 Net147: just sent another mail - the git "upgrade" was actually a downgrade Jul 18 14:17:58 Net147: regarding issue https://bugzilla.yoctoproject.org/show_bug.cgi?id=4859; seems to be somehow caused by the aforementioned patch Jul 18 14:18:00 Bug 4859: major, High, 1.5 M3, cristian.iorga, IN PROGRESS DESIGN , Build Appliance does not boot in vmWare Player Jul 18 14:18:55 panda84kde: which packages have been created by lirc-modules? Jul 18 14:19:27 cristianiorga: seems odd Jul 18 14:20:02 Net147: well; you tested that patch with syslinux as the primary bootloader, right? Jul 18 14:20:14 cristianiorga: yes Jul 18 14:21:05 Net147: in case of BA, the primary bootloader is the BIOS, which (most probabnly) loads the first 440bytes and executes from MBR Jul 18 14:22:04 Net147: but according to wikipedia, the MBR with the disk signature info in it has the first 440 bytes different from the content of the MBR without disk signature Jul 18 14:22:14 ant_work: could you please detail the question a bit further? I have no files generated by lirc-modules, I already have lirc modules in my kernel Jul 18 14:22:57 christianiorga: parted actually generates a disk signature when I checked it. but it's not really random enough. Jul 18 14:22:59 Net147: see https://en.wikipedia.org/wiki/Master_boot_record#PTE, Sector layout section, the two MBR formats, classical generic MBR and Structure of a modern standard MBR Jul 18 14:23:10 panda84kde: I'm afk so cannot check but I see https://github.com/Guacamayo/meta-guacamayo/blob/master/meta-guacamayo/recipes-support/lirc/lirc-modules_0.9.0.bb Jul 18 14:24:09 ant_work: yes, I have and empty lirc-modules package Jul 18 14:24:31 christianiorga: yes I consulted that page when writing the patch Jul 18 14:25:30 Net147: yes, but mbr.bin does not change if disk signature is included or not; or I am wrng on that assumption? Jul 18 14:25:38 panda84kde: RDEPENDS_${PN} = "lirc-modules" doesn't pull kernel-module-lirc-dev Jul 18 14:25:43 afais Jul 18 14:26:42 panda84kde: should lirc-modules even be used now that LIRC Is in the mainline kernel? Jul 18 14:27:34 cristianiorga: mbr.bin is 440 bytes so it isn't supposed to touch the disk signature Jul 18 14:28:07 Net147: Build Appliance is not starting in vmWare Player with a Missing Operating system error; to be honest, I saw that string in mbr.bin file, so ATM I am not sure that is displayed by vmWare emulated BIOS or by syslinux Jul 18 14:28:58 Net147: no, but the format of first 440 bytes are different depending if disk signature is present in MBR or not; right? Jul 18 14:28:59 ant_work: yes. I'm wondering why is my do_rootfs failing like that if kernel-module-lirc-dev is not mentioned? Jul 18 14:29:35 Net147: that's according to wikipedia Jul 18 14:30:34 cristianiorga: in my testing, parted creates the disk signature. so the patch doesn't change the fact that a disk signature is being created. Jul 18 14:31:04 panda84kde: you can inspect the dependency chain Jul 18 14:31:21 ant_work: any hint on how to do that? Jul 18 14:33:00 try bitbake -g -u depexp Jul 18 14:33:00 Net147: I might be wrong, but in your patch, the disk signature is not generated with parted, but using uuid module Jul 18 14:33:52 panda84kde: are you installing the main "kernel-modules" meta-package perhaps? Jul 18 14:34:05 cristianiorga: parted generates one, but we overwrite it using one generated from uuid module Jul 18 14:35:33 Net147: right; on the HW you used for testing, BIOS reads the MBR and starts syslinux, or syslinux is started directly as the initial bootloader? I am asking, because I don't know Jul 18 14:35:57 cristianiorga: BIOS reads MBR and starts syslinux Jul 18 14:37:41 cristianiorga: theoretically, changing the disk signature shouldn't affect the bootability unless there it is overwriting outside of the 4 byte range Jul 18 14:39:50 Writing a package for a Python script. It RDEPENDS on perl, pretty obviously, but how can I figure out the various Perl libraries that it RDEPENDS on to include them too? Jul 18 14:40:16 Whoops, "a Python script" should be "a Perl script". Jul 18 14:41:12 panda84kde: I fail to find a maintainer of the layer but at first sight it needs some love Jul 18 14:41:39 Net147: can you do a basic test with your change using vmware player, we clearly are seeing an issue, it might be the bios that vmware uses or ??? Jul 18 14:42:08 cristianiorga: sgw_: what image type? Jul 18 14:42:10 Net147: overwriting is a possibility, but does not seem to happen; If I would take a wild guess here, is that the emulated BIOS of vmWare Player machine does not play well with that added disk signature; according to the diagrams, if a disk signature is added, the format of the first 440 bytes changes; this does not happen in our syslinux, which provides the first 440 bytes from mbr.bin Jul 18 14:42:46 cristianiorga: a disk signature is added regardless because parted adds one Jul 18 14:43:21 Hi how do I enlarge the size of the file system for qemu in yocto Jul 18 14:43:30 Do I have to enlarge the rootfs? Jul 18 14:43:39 or do I have to modify something in qemu? Jul 18 14:44:05 Net147: it uses IMAGE_FSTYPES = "vmdk" Jul 18 14:44:07 Net147: yes, but maybe the BIOS of that specific board that you tested with is smarter than the BIOS of vmware and manages the change Jul 18 14:44:16 cristianiorga: I tested in QEMU as well Jul 18 14:45:29 Net147: Build Appliance runs in vmWare Player, not qemu; like I said, it might be an issue with vmWare machine BIOS Jul 18 14:45:55 bluelightning: I'm not adding "kernel-modules" in my image. Could it be in "fsl-image-gui"? Jul 18 14:46:59 cristianiorga: downloading vmware player... Jul 18 14:47:11 Net147: thanks a bunch Jul 18 14:47:13 fenrig: you can use IMAGE_ROOTFS_EXTRA_SPACE which will add space in your rootfs Jul 18 14:47:23 ant_work: thanks. Jul 18 14:47:41 sgw_: is it in kilobytes, megabytes, ...? Jul 18 14:47:56 k Jul 18 14:47:57 fenrig: KB Jul 18 14:48:02 panda84kde: there are machine specific overrides together with lower versions of some packages Jul 18 14:48:09 yes KB thanks all Jul 18 14:51:48 ant_work: yeah. I just needed lirc but it seems it has been removed from poky: http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/packages/lirc/?h=elroy Jul 18 14:52:30 sgw_: Thx it worked Jul 18 14:53:17 ant_work: is by chace depexp a GUI tool? Jul 18 14:53:22 *chance Jul 18 14:56:27 reply-to-self: yes, it is. Jul 18 14:57:30 cristianiorga: in my testing, if I convert the image I use to vmdk format and boot, it boots syslinux and kernel but fails to find disk by the identifier Jul 18 14:57:52 cristianiorga: so VMware doesn't boot. VirtualBox boots it fine though. Jul 18 14:58:10 christianiorga: it would probably boot if using /dev/sda1 though Jul 18 15:02:29 cristianiorga: I mean /dev/hda2 Jul 18 15:07:04 Net147, sgw_ : So we know that it doesn't work; We don't know why :-) Ok, I will continue the investigation Jul 18 15:08:02 cristianiorga: probably a start would be to do bitbake -C bootdirectdisk theimage, copy the vmdk somewhere, revert patch, bitbake -C bootdirectdisk theimage, compare the two images Jul 18 15:08:25 cristianiorga: the differences should only be at offsets 440, 441, 442, 443 Jul 18 15:09:09 Net147: Do you think that is possible to add the testing steps that you performed in order to test with vmware player in the YB4859 bug report? Jul 18 15:09:51 cristianiorga: I haven't got image for vmdk set up, so I just replicate command that vmdk class uses to convert the raw image to vmdk Jul 18 15:10:03 Net147: Did that; I know what's causing it, I don't know how Jul 18 15:10:21 cristianiorga: qemu-img convert -O vmdk image.hdddirect image.vmdk is that I did Jul 18 15:10:38 cristianiorga: so are the differences only in those 4 bytes at most? Jul 18 15:11:41 Net147: no, there are other differences, but those other differences might be generated by other factors, like timestamps, etc Jul 18 15:12:20 ant_work: lirc-modules "Runtime Depends" on lirc-modules and lirc-modules-dev. I don't get the meaning of depending on itself, but anyhow I still don't get how kernel-module-lirc-dev gets in... Jul 18 15:12:42 cristianiorga: well yes there is a disk timestamp that is optional 6 bytes Jul 18 15:12:57 cristianiorga: but that should have been part of mbr.bin anyway Jul 18 15:13:50 Net147: I will continue the investigation tomorrow, I will leave office now Jul 18 15:14:05 cristianiorga: 0-439 is mbr.bin, 440-443 is disk signature, 444-445 is 0000, 446-509 is partition table (should be same), 510-511 should be 55aa Jul 18 15:14:33 cristianiorga: any invalidating bootdirectdisk should change the first sector Jul 18 15:15:01 cristianiorga: the rest same Jul 18 15:15:17 Net147: well, disk signature is changing the first 512 bytes, right? Jul 18 15:15:35 cristianiorga: I only change 4 bytes in at offsets 440, 441, 442, 443 Jul 18 15:30:39 I'm currently trying to build a yocto image under ubuntu 13.04 x64 for an i.MX6 Q7 module. So far everything is working fine, but I can't figure out how to build gdb-cross with python support. Any help? Jul 18 15:49:04 bluelightning: and another bug.. no one appears to install depmod these days Jul 18 15:51:12 So, I'm working on consolidating volatiles and tmpfiles.d. the approach i'm taking is to add a build of systemd-tmpfiles separate from systemd, and b uild and use it for both systemd and sysvinit builds, have a separate binary package, and create a -native version with --sysroot= support for rootfs build time for read-only-rootfs. Jul 18 15:51:22 does this seem like a sane approach? Jul 18 15:55:37 zecke: I'll admit I don't know how it's normally supposed to be brought in, but it is supposed to be because module package postinstalls expect to be able to run it Jul 18 15:56:08 doesn't kmod provide that now? maybe i'm behind Jul 18 15:56:22 i need to spend more quality time at runtime on real hardware, all i do is builds lately Jul 18 15:56:26 heh Jul 18 15:56:26 getting rusty Jul 18 15:56:35 I think it does, but I'm not able to find how that is normally pulled in as a runtime dependency Jul 18 15:57:52 huh Jul 18 15:58:05 brb changing networks Jul 18 15:58:06 not seeing it either, strange Jul 18 15:59:49 kergoth: Yeah, module-init-tools-depmod installs depmod.. (depmod.kmod) but I don't know if systemd (linking to kmod) actually needs depmod at all. :} Jul 18 16:00:25 probably not, unless it wants to run modprobe Jul 18 16:00:34 or the api function to do a modprobe Jul 18 16:00:36 * kergoth shrugs Jul 18 16:00:59 kergoth: it does somehow load modules. I have not looked at the code.. but most likely an api call. :) Jul 18 16:01:07 * kergoth nods Jul 18 16:01:23 * zecke looks at this nice Oops in the TCPv4 stack on this v3.4 kernel. :} Jul 18 16:01:30 ouch Jul 18 16:02:43 kergoth: GCC4.8 made my v3.2er kernel oops in do_loopup.c of namei.c :} Jul 18 16:02:51 ah Jul 18 16:02:52 but more often than the tcp crash. :) Jul 18 16:03:08 I try to figure out if my move to v3.4 is progress or just change Jul 18 16:03:49 zecke: oh, debugging gcc and kernel Jul 18 16:04:18 :/ he couldn't stand seeing the words gcc and kernel in the same sentence, I guess Jul 18 16:04:19 :P Jul 18 16:05:37 heheh Jul 18 16:06:13 i need to stop missing the yocto technical calls, so i can stay current on 1.5 progress Jul 18 17:01:51 Can someone remind me who we contact about ssh keys for git.yoctoproject.org, again? Jul 18 17:01:55 drawing a blank Jul 18 17:04:02 kergoth: halstead Jul 18 17:04:12 ah, right, thanks Jul 18 17:06:05 kergoth, Yep. Just e-mail michael@yoctoproject.org. Jul 18 17:41:00 khem: ping? Jul 18 17:49:06 so close … Computing transaction...error: Can't install qtbase-tools-5.0.2-r2.0@armv7a_vfp_neon: no package provides /usr/bin/perl Jul 18 18:18:07 so, intercept scripts are teh things that get run once per package manager invocation, or once for the entire rootfs population, rather than repeatedly for each related package, correct? e.g. depmod, ldconfig, .. Jul 18 19:12:17 hmm, debian has dpkg set up to support something like our do_rootfs intercepts, i wonder if we support that too, or if all we can handle is do_rootfs time bits right now Jul 18 19:12:22 i expect the latterp Jul 18 19:13:10 kergoth: we were talking about %posttrans the other day from rpm Jul 18 19:13:34 ah, so taking advantage of such things will likely become a future task Jul 18 19:25:27 kergoth: dpkg triggers are nice Jul 18 19:25:35 kergoth: just need someone to make opkg do the same ;) Jul 18 19:26:58 indeed Jul 18 19:27:05 or just bite the bullet and make a replacement Jul 18 19:27:07 opkg hurts my head Jul 18 19:27:12 :) Jul 18 19:27:26 if someones doing that they might as well use dpkg, i suspect Jul 18 19:27:47 apt-get sucks on embedded. if they don't need network, sure Jul 18 19:46:35 opkg isn't so bad... Jul 18 19:47:06 i can remember ipkg being a bit wonky at times Jul 18 22:29:02 Anyone knowledgeable with wireless-crda? I'm getting a nasty stack trace saying CRDA cannot be updated. This only happened when I have no internet connection Jul 18 23:01:33 b1gtuna: nope Jul 18 23:01:55 maybe if your nick was hottuna... Jul 18 23:18:17 mr_science: LAWL next life i will be Jul 18 23:36:50 let me try again, how do I use full (proper tools?) instead of busybox? Jul 18 23:36:57 Thanks in advance :) Jul 18 23:37:30 (I think udhcpc is conflicting with networkmanager, so I'm trying to get rid of the former) Jul 19 02:00:32 I'll look Jul 19 02:44:32 b1gtuna: 1) there are update-alternatives for most of the "proper tools" vs. busybox Jul 19 02:45:02 so if you install the proper packages, they should replace the busybox commands Jul 19 02:46:09 2) to replace dropbear with openssh, add ssh-server-openssh to IMAGE_FEATURES Jul 19 02:49:24 3) i don't know, try adding dhcp-client to the packages in your image Jul 19 02:50:11 you can also make a blacklist file, but i don't think you should have to do that... Jul 19 02:56:59 i just did an opkg remove busybox-udhcpc and it didn't complain, so you should be able to replace it with dhcp-client **** ENDING LOGGING AT Fri Jul 19 02:59:58 2013