**** BEGIN LOGGING AT Wed Nov 20 02:59:58 2019 Nov 20 05:40:15 New news from stackoverflow: Device is unable to BOOT or INSTALL with generated .hddimg Nov 20 11:58:27 Hi, is there a way to create a sdcard image directly out of yocto? I read that its only creating wic images from 2.5 on Nov 20 12:00:00 GeneralStupid: use wic and dd the resulting image to your sdcard Nov 20 12:11:16 RP, rburton: is it a horrible idea to drop lrzsz and minicom from oe-core? Nov 20 12:16:44 kanavin i tried already Nov 20 12:17:02 waa waaa i want to use xmodem waa waa ;) Nov 20 12:17:42 kanavin: please do try again :) Nov 20 12:18:06 kanavin: got annoyed at something and now i'm building rpm without NSS Nov 20 12:19:20 qschulz: Hm ok, maybe i need some postbuild scripts then. Nov 20 12:22:12 what magic is the rpi sdcard image actually doing Nov 20 12:22:45 GeneralStupid: anyway, wic being recommended doesnt' stop anyone using another image types, like sdcard Nov 20 12:23:48 GeneralStupid: nah, you don't need any magic scripts. its just that the filename does not end in "sdcard" Nov 20 12:23:49 rburton: ah my bad then, I thought sdcard was replaced by wic. Mixed up things again I guess. Nov 20 12:24:23 qschulz: i've no idea what rpi is up to :) Nov 20 12:24:32 GeneralStupid: so if you've got something that creates a file that ends in "wic", it means that its a binary thing thats meant to be used directly. Nov 20 12:25:37 kanavin: not saying i'm awesome but i think rpm was actually the last user of nspr/nss in oe-core Nov 20 12:25:48 kanavin: that's got be a good win right Nov 20 12:26:01 rburton, you better check what needs it in meta-oe Nov 20 12:26:08 I suspect that'd be mozjs, and thus polkit Nov 20 12:26:22 which we plan on bringing into oe-core, so duh Nov 20 12:26:29 damnit! Nov 20 12:26:59 well i'm just happy nspr/nss isn't on the path to get packaging going Nov 20 12:27:08 ah that is certainly a win Nov 20 12:27:32 they're not using parallel builds for one thing Nov 20 12:27:42 but i'm confused why building *anything* is causing a kernel build Nov 20 12:27:59 i'm bitbaking rpm rpm-native and its building the kernel. Nov 20 12:28:14 rburton: the "sdcard" FSTYPE is no longer available Nov 20 12:28:32 LetoThe2nd: Ok, its just gunzipped. But your right, i guess my colleagues will figure it out :) Nov 20 12:29:04 rburton: because more is more Nov 20 12:29:06 rburton: https://www.youtube.com/watch?v=QHZ48AE3TOI Nov 20 12:29:14 GeneralStupid: there never has been a sdcard type in oe-core. Nov 20 12:29:39 rburton: "we have always been at war with..." Nov 20 12:30:00 meta-rpi has a sdcard_image-rpi Nov 20 12:30:06 ah then my BSP removed it Nov 20 12:30:09 right Nov 20 12:30:29 they probably just moved to wic to make the same thing Nov 20 12:30:37 this is not really an issue. Nov 20 12:30:41 correct Nov 20 12:31:55 i wish i had gotten a dollar for each time somebody asked me about {rpi, fsl} .sdcard IMAGE_FSTYPE Nov 20 12:31:59 or at least a beer., Nov 20 12:32:17 deffo take beer over dollars Nov 20 12:35:17 Is there a way of listing the files that went into the wic without mounting the file system? Nov 20 12:35:50 farnerup: the deploy dir has an image manifest listing the packages that went in Nov 20 12:35:54 farnerup: for the rootfs, yes. for the wic, not by definition. Nov 20 12:36:06 Well, the rootfs Nov 20 12:37:29 farnerup: if you happen to also build a tar.gz or tar.bz2 or similar image, you can directly get a list of contents. if not, then you have to enable BUILD....something. we have some magic for it, i just can't properly memorize its name Nov 20 12:37:45 (its actually the planned topic for the next lilve coding session) Nov 20 12:38:10 BUILDSTATS? BUILDHISTORY? Nov 20 12:40:35 yeah buildhistory has image contents in Nov 20 12:41:16 New news from stackoverflow: Yocto - creating a dependency for WIC to cpio.gz image Nov 20 12:41:20 rburton: thx. how much do you charge for acting as my external brains? Nov 20 12:42:47 you'll find out when you get the invoice Nov 20 12:43:14 oO( is an invoice actually the opposite of an outvoice? ) Nov 20 12:53:26 Thanks, buildhistory was useful Nov 20 13:14:11 would be trivial to write a class to that puts a full file listing in deploydir Nov 20 13:14:31 if that's what you're after Nov 20 14:29:22 Hello, with https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html it is stated that "Added m68k architecture definitions" and "Added mcf5441x cpu type tuning". I was wandering what kind of MACHINE in local.conf should I select to build for this architecture? And where I find the extra layer to this MACHINE.conf? Nov 20 14:32:27 Tamis: its the arch definitions conf/machine/include/m68k, not a concrete machine. search layers.openembedded.org for the machine you're targetting, or write a new machine yourself. Nov 20 14:41:20 rburton: That's what I was suspecting also. Thanks a lot. Nov 20 15:11:39 New news from stackoverflow: Patch Kernel-Module Makefile Nov 20 15:40:01 Hm i try to use my own defconfig but yocto is not using it... Nov 20 15:44:33 GeneralStupid: for which recipe? Nov 20 15:44:53 kanavin: comparing building rpm from scratch with nss vs libgcrypt: -352.6s -4.6% 2:07:25.1 (7645.1s) -> 2:01:32.5 (7292.5s) Nov 20 15:45:34 rburton, cool, why didn't we use gcrypt before? is it a new feature? Nov 20 15:45:39 yeah Nov 20 15:45:47 its not in the release we use yet Nov 20 15:45:51 are you on top of my 4.15 patches? Nov 20 15:45:57 aah no Nov 20 15:46:08 I sent them the other day... :) Nov 20 15:46:11 huh Nov 20 15:46:46 if you're using bbappend, check that your bbappend is detected with bitbake-layers show-appends Nov 20 15:46:48 ah yes there they are Nov 20 15:46:58 GeneralStupid: ^ Nov 20 15:47:05 kanavin: fine i'll rebase :) Nov 20 15:47:34 kanavin: didn't land in 4.15 either by the look of it Nov 20 15:47:44 GeneralStupid: make sure you have a FILEEXTRAPATHS_prepend := (prepend and := are both equally important) Nov 20 15:47:48 hm should have, odd. Nov 20 15:47:57 qschulz: for linux-imx (from NXP) i added a "bbappend" file Nov 20 15:48:29 GeneralStupid: are you even sure this recipe supports defconfig taken from yocto? Nov 20 15:48:49 qschulz: maybe this is the right question :D Nov 20 15:48:52 GeneralStupid: is it somewhere in a repo where we could see? Nov 20 15:49:43 rburton, it did: https://github.com/rpm-software-management/rpm/blob/rpm-4.15.x/configure.ac Nov 20 15:49:52 there is a clear choice for gcrypt there Nov 20 15:50:25 kanavin: yeah for some reason github isn't doing the right thing Nov 20 15:50:38 still need a fiddle to stop libgcrypt-config exploding Nov 20 15:50:54 qschulz: https://github.com/Freescale/meta-freescale/tree/thud/recipes-kernel/linux Nov 20 15:51:34 iam using 4.9.123 Nov 20 15:54:19 I built a new image w/systemd enabled.. and starting "postinst" has been running for several minutes. Is there any way to know what it is currently doing? Nov 20 15:54:29 I can't get ssh or console access in this state. Nov 20 15:55:19 /var/lib/opkg/info has a lot of .postinst files Nov 20 15:57:48 GeneralStupid: it seems like they do Nov 20 15:58:11 GeneralStupid: can you give me the exact path from the root of your layer to your defconfig? Nov 20 15:59:27 recipes-kernel/linux-imx/fslc/defconfig_small Nov 20 16:00:10 i added this filename to my SRC_URI and i tried with KERNEL_DEFCONFIG_machine = Nov 20 16:00:42 Iam also fine with using a simple "defconfig" but it is not using my defconfig. Everytime i boot up i still have CAN drivers etc.etc. in Nov 20 16:00:53 it has to be name defconfig Nov 20 16:01:04 qschulz: i have to leave now, but i will read backlog later. thanks for your help Nov 20 16:01:14 qschulz: thanks. i thought i could rename it. but good to know Nov 20 16:01:16 there's little consistency in how defconfig is used in kernel recipes, sadly Nov 20 16:01:41 kanavin: recipe has '# libraries are also LGPL - how to express this?' above the license field, might want to review the packaging and license variables Nov 20 16:01:42 most commonly defconfig is in SRC_URI under that exact name, then kernel.bbclass's do_configure copies WORKDIR/defconfig to .config, but therer are many varations depending on the recipe Nov 20 16:02:44 GeneralStupid: 1) defconfig has to be named defconfig 2) I heavily suspect OVERRIDES is in play here. Even when bbappends are in the story, they can still not override original recipes if where the local files are stored are some kind of machine specific Nov 20 16:03:21 GeneralStupid: read kergoth for explanation on how defconfig is usually taken into account by kernel recipes Nov 20 16:04:25 GeneralStupid: to find out in where the defconfig is taken from, you can either read the log in WORKDIR/temp/log.do_fetch or WORKDIR/temp/run.do_fetch (but it should be log IIRC). There you should be able to see which paths are tried first. You can also use bitbake -e if you want. Nov 20 16:04:54 rburton, which recipe? Nov 20 16:05:28 GeneralStupid: basically, some directories have precedence depending on how they are named. Highest precedence to lowest precedence = rightmost to leftmost in OVERRIDES Nov 20 16:06:01 ah rpm Nov 20 16:07:07 LetoThe2nd: I'd put OVERRIDES and "specifiers" (FOO_) on the TODO list for tutorials if not already there. I found that is a tricky and not very explicit topic Nov 20 16:07:52 LetoThe2nd: I wanted to talk to you about that topic but forgot, now that the topic was just brought up again, I remembered :) Nov 20 16:10:07 GeneralStupid: to sum up, I think either fslc (that you use in your path) is either not in OVERRIDES, or is in lower "precedence" over imx or imx8 Nov 20 16:11:46 i think the most thorough current coverage on overrides is in the bitbake user manual, but even that isn't perfect Nov 20 16:12:06 afaik not everything in that manual is in the yocto mega manual Nov 20 16:12:37 kergoth: the whole OVERRIDES stuff goes so far in consequences and is kind of complex in conjunction with _append et al. Nov 20 16:13:12 yep, that's covered specifically, including brief coverage on the difference between FOO__append and FOO_append_, which are entirely different things Nov 20 16:14:00 admittedly i'm not the best writer, so the quality of the wording in the bitbake user manual isn't as good as the yocto manuals, but the key aspects are there Nov 20 16:17:12 kergoth: (also, I might have read this whole thing (or maybe only the mega-manual) a long time ago when it was not so clear) I should re-read again before criticizing :) Nov 20 16:19:10 like i siad, definitely room for improvement, just happens to be a document with less visibility than the rest of the yocto stuff, so is often unknown Nov 20 17:01:00 I am trying to create the dir /var/lib/redis via bbappend recipe, but it's not created in the final image. how can I create a dir at /var/lib? Nov 20 17:05:12 rcrudo: install -d "${D}${localstatedir}/lib/redis Nov 20 17:05:21 " Nov 20 17:15:01 qschulz: I used install command as well but with hardcoded /var instead of ${localstatedir}. should that make the difference? Nov 20 17:15:55 if you have ${D} in front of it no Nov 20 17:16:12 qschulz: II have Nov 20 17:17:00 rcrudo: is there any change to FILES_${PN} by any chance in that recipe? Nov 20 17:17:29 iirc /var/lib is usually in our tmpfs via volatile, you probably need to use tmpfiles for systemd and volatiles for sysvinit to ensure it's created on boot Nov 20 17:17:47 FILES_${PN} by default has /var/lib in it Nov 20 17:18:27 I don't have FILES_${PN} in the append, only FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" Nov 20 17:19:28 rcrudo: does not mean that the original recipe you're appending to is not changing FILES_${PN}. Though I'd try to check what kergoth said :) Nov 20 17:21:25 kergoth: my mount shows "/dev/mmcblk1p1 on /var type ext4" Nov 20 17:24:02 just tested creating a new dir at /var/lib. it persists after the a reboot Nov 20 17:27:38 I see the dir exists at ./tmp/work/imx6ulmdb-oe-linux-gnueabi/image/1.0-r0/rootfs/var but not at ./tmp/work/imx6ulmdb-oe-linux-gnueabi/image/1.0-r0/ostree-rootfs/var Nov 20 18:29:23 Let's say that I wanted to have a working gcc in my image.. is there a package for this? gcc seems to be the host, not the target. Nov 20 18:30:46 fullstop: You might be able to add "tools-sdk" to EXTRA_IMAGE_FEATURES Nov 20 18:31:16 Otherwise, that IMAGE_FEATURES should be tied to a packagegroup and you could manually include that also Nov 20 18:33:22 thanks, JPEW Nov 20 18:38:15 someone adding tools-sdk seems to be building a ton of stuff, so maybe that's a good thing. Nov 20 18:38:49 Someone here seems to be incapable of cross compiling their own stuff for some reason. Nov 20 18:55:46 all good things must come to an end. fatal error: sys/ustat.h: No such file or directory Nov 20 18:58:20 fullstop: Is that in bitbake or on target? Nov 20 18:58:49 JPEW bitbake, but I'm stuck using gcc 7.2 because nvidia Nov 20 18:59:22 ah, that's too bad Nov 20 18:59:39 yes, it is. Nov 20 18:59:55 This person will have to get used to cross compiling. Nov 20 19:01:54 fullstop, is this because of nvidai tools needing old gcc? Nov 20 19:02:03 leon-anavi, may have some slides Nov 20 19:02:04 On target development isn't really all that great anyway. I like my complicated vim config :) Nov 20 19:02:17 Crofton|work: yes Nov 20 19:03:31 anyone know if the slides from YP Summit are online? Day 2? I hope Leon gave that talk :) Nov 20 19:47:39 armpit: i hope the india-style in writing was intended :) Nov 20 19:58:56 Generally you want few other things with gcc on target Nov 20 19:59:44 EXTRA_IMAGE_FEATURES_append = " tools-sdk tools-debug dev-pkgs dbg-pkgs packagegroup-core-buildessential gawk git git-perltools" Nov 20 19:59:58 e.g. will get you git working on target with toolchain fully functional Nov 20 20:00:15 I use it often to build glibc on target Nov 20 20:01:00 cross compiling is too much when it comes to edit-compile-debug cycles :) Nov 20 20:02:23 oh and for your dotfiles issue create a git repo with all your dot config gold and clone it first thing on target Nov 20 20:41:09 RP: wow! great article on lwn (i'm probably late to the party, like always...) Nov 20 20:42:52 is this the new YP naming convention? https://where2walk.co.uk/walks/lake_district/great-dun-fell-from-dufton/ https://where2walk.co.uk/walks/lake_district/fleetwith-pike/ ? Nov 20 20:43:53 tlwoerner: nah, i'm alwways late on lwn parties because i have to wait until the articles are free Nov 20 20:47:40 JaMa: apparently so, although i suspect our fearless leader rode his motorcycle instead of walked... ? Nov 20 20:49:24 * tlwoerner pays for his lwn subscription with his own money :-/ Nov 20 20:51:28 the point about lwn for me is that actually only like 2 or 3 articles per year are really interesting to me. and then the subscription would be, well... bearing a bad price/value ratoin Nov 20 20:54:12 i've met the people, and they are good people :-) i like their conference reports (since i don't get to many conferences) i don't read lwn as much as i should, but i appreciate their work (and therefore support it) Nov 20 20:54:40 tlwoerner: I fear that these places mark where something broke on his motorcycle or him :) Nov 20 20:54:55 JaMa: hahaha lol Nov 20 20:54:56 tlwoerner: absolutely true. Nov 20 20:56:19 tlwoerner: i just already have a selection of things that i support for many years, and, lwn didn't make it onto the list. Nov 20 20:56:44 LetoThe2nd: i had no hesitation paying (whatever it was) to subscribe to , and all it did was waste my time and make me more stupider Nov 20 20:57:02 LetoThe2nd: so i quit the and sent my money to lwn instead! Nov 20 20:57:53 * JaMa feels sorry for LetoThe2nd's Yocto steaming service :) Nov 20 20:58:02 +r Nov 20 20:58:07 tlwoerner: now thats a good choice indeed. i on the other hand have a long standing habit of not subscribing to things that i do not actively enjoy, so there is nothing i could quit. Nov 20 20:58:17 JaMa: my "steaming service"? Nov 20 20:59:20 (do we have new release names, by the way, or what?) Nov 20 20:59:33 LetoThe2nd: yes: https://wiki.yoctoproject.org/wiki/Releases Nov 20 20:59:34 yes, https://wiki.yoctoproject.org/wiki/Releases was updated Nov 20 20:59:47 ah Nov 20 21:01:14 support level "dreaming" ++ Nov 20 21:04:14 anyways, gn8 Nov 20 21:35:52 tlwoerner: glad you liked it :) Nov 20 21:36:39 JaMa: I wondered how long people would take to notice :) Nov 20 21:37:33 JaMa: I like your theory too :) Nov 20 21:47:39 RP: :) is there any reason why you haven't pushed the oe-core/bitbake tags for older releases (as discussed in last OE TSC meeting)? Nov 20 21:48:15 JaMa: I simply forgot, sorry :( Nov 20 21:48:27 JaMa: I wanted to check up on key signing and then got distracted Nov 20 21:48:49 no problem, just wanted to check if something else is expected from me Nov 20 21:49:00 JaMa: no, my fault, sorry Nov 20 21:49:29 I didn't sign the tags, only made them annotated Nov 20 21:52:58 JaMa: right, I just wanted to check some things to compare with our other release tags Nov 20 21:55:24 RP: today I looked at the ipk you attached at https://bugzilla.yoctoproject.org/show_bug.cgi?id=13638 Nov 20 21:55:25 Bug 13638: normal, Undecided, ---, alejandro.delcastillo, NEW , opkg double free when reproducibile builds enabled Nov 20 21:55:37 I believe its not a well formed xz file Nov 20 21:56:11 I have a patch to prevent opkg from segfaulting on invalid data.tar.* files, but wanted to let you know (dunno which process created the ipk) Nov 20 21:56:47 adelcast: in my local tests, the xz bit seemed fine and the problem then becomes a zero size tar file Nov 20 21:57:03 adelcast: should be been created by opkg-build in the usual way Nov 20 21:57:17 adelcast: I am however also puzzled how we generated it :/ Nov 20 21:57:59 mm, really? I opened it directly via vim, then got: Nov 20 21:58:03 " tar.vim version v29 Nov 20 21:58:03 " Browsing tarfile /tmp/test/data.tar.xz Nov 20 21:58:03 " Select a file with cursor and press ENTER Nov 20 21:58:03 tar: This does not look like a tar archive Nov 20 21:58:03 tar: Exiting with failure status due to previous errors Nov 20 21:58:20 and libarchive fails too, when uncompressing Nov 20 21:58:29 adelcast: (I tested by ar -x xxx.ipk and then xz -d data.tar.xz) Nov 20 21:58:44 that gives a zero byte data.tar Nov 20 21:59:00 * RP isn't surprised tar doesn't like that Nov 20 22:00:19 adelcast: I'm not claiming its a valid file, just explaining where the problem is (as I understand it) Nov 20 22:01:33 weird.....maybe I am missing a libarchive flag for empty archives Nov 20 22:03:30 adelcast: I've been unable to trackdown which build generates this or how/why :/ Nov 20 22:03:51 adelcast: perhaps I'd have more luck adding errors to opkg-build for empty files Nov 20 22:06:45 RP: yes, capturing the call/inputs that generate the empty file makes sense to me Nov 20 22:07:46 adelcast: anyhow, thanks for fixing opkg so we at least get sensible errors for this (and presumably no longer have the double free if libarchive fails?) Nov 20 22:08:09 adelcast: all we can do is fix the different pieces this is highlight problems with and keep going until we find the source! Nov 20 22:08:57 RP: yes, I have the libarchive patch ready, just want to get to the bottom of why libarchive is failing on empty xz while the xz command is not.... Nov 20 22:11:28 adelcast: fair enough. I haven't looked into that enough to know whether this should work or not as yet :/ Nov 20 22:25:14 RP: yes, opkg was missing support for empty archives, that needs to be explicitly enabled on libarchive Nov 20 22:25:41 I have a path ready to enable it, which makes the problematic ipk install correctly Nov 20 22:25:58 no idea why we haven't seen this before on virtual packages Nov 20 22:56:59 adelcast: interesting. More questions than answers! :) Nov 20 22:57:12 adelcast: patches look good though thanks **** ENDING LOGGING AT Thu Nov 21 02:59:57 2019