**** BEGIN LOGGING AT Tue Jun 17 02:59:58 2014 Jun 17 07:24:56 hello everybody Jun 17 07:25:41 after solving yesterday's bad CRC issue with uboot loading the kernel i am stuck in a situation where my kernel does not say a word when launched Jun 17 07:26:20 i've taken a .config from an old 2.6 which works on my machine Jun 17 07:26:35 used that as the defconfig in my linux_yocto.bb Jun 17 07:26:46 early printk is enabled Jun 17 07:27:00 serial console works in my setup (proven by old kernel) Jun 17 07:27:26 uboot loads kernel+dtb Jun 17 07:27:53 do i need necessarily compile the kernel with a the same dtb? Jun 17 07:36:53 good morning Jun 17 07:37:45 petero: what is your machine and pastebin your kernel command line or better your printenv Jun 17 07:38:10 i have a powerpc icecube equivalent Jun 17 07:40:44 mckoan, http://pastebin.com/T4szM46X Jun 17 07:44:44 like i said, the setup i am using works with legacy kernel + rootFS Jun 17 07:54:54 petero: moving from 2.6.x to 3.x is never straightforward Jun 17 07:55:23 sure, but i thought at least i would have some output on the screen. Jun 17 07:56:01 i have to add that i am using U-Boot 2010.06-00073-g54841ab-dirty (Apr 22 2013 - 10:40:19) Jun 17 07:56:27 if the 3.10 kernel gets stuck somewhere in the boot process, that's fine Jun 17 07:56:39 but having absolutely no output at all is strange Jun 17 07:56:53 all CPU related features in my .config are the same Jun 17 07:57:05 comapring 2.6 .config and 3.10 .config Jun 17 07:57:46 the only thing i didn't do is incorporating the dtb when compiling the kernel. however, uboot gets the dtb via TFTP Jun 17 08:05:51 morning! bitbake-prserv --help says: "-l LOGFILE, --log=LOGFILE --> log filename(default: prserv.log)". in what directory will the file be created? Jun 17 08:42:55 petero_: I haven't really looked at dts/dtb on powerpc; but when it comes to ARM, the dts/dtb is very much in flux and an updated kernel will normally require a new dts/dtb. Jun 17 08:43:27 AndersD, thanks, i will try to make my kernel compile with the corresponding dtb Jun 17 08:43:32 wouldn't hurt anyway Jun 17 08:43:33 petero_: I think powerpc is more stable, though you're taking a huge step kernel-wise. Jun 17 08:43:47 yep Jun 17 08:44:15 like i said, breaking at some point down the road would be fine with me. but having no output at all looks suspicious to me Jun 17 08:44:21 petero_: and while you're at it, compare the kernel configurations once again. Quite a few kernel options have been renamed during this time frame. Jun 17 08:44:59 i only checked CPU features and serial console related stuff as i think this is essential for message output Jun 17 08:45:02 I think SDKPATH is buggy if it isn't set to its default value. The resulting SDK is missing most of the host sysroot but as soon as I turn SDKPATH back to default it's all there. Jun 17 08:45:38 AndersD: to at least get one single line...however, the very first line on the working kernel is the one reporting which dtb was taken :) Jun 17 08:45:58 AndersD, i mean I checked CPU related CONFIG items and the ones related to serial output Jun 17 08:46:27 petero_: Yep, that's the problem when something goes wrong way too early.. ;) Jun 17 08:47:08 petero_: You could also check that the kernel's name for your serial console hasn't been changed. It has happened on a few ARM SoC's during the years. Jun 17 08:47:31 AndersD, kernel name for serial console? Jun 17 08:48:16 petero_: What you supply on the kernel cmd-line: console=ttyS0,115200, check if it's ttyS0 or something else. Jun 17 08:48:18 AndersD, you mean the serial console's name for the kernel cmdline param? Jun 17 08:48:23 Yes Jun 17 08:48:26 IC, good point Jun 17 09:22:29 petero_: actually you have console=ttyPSC0,115200 Jun 17 09:23:07 yes, PSC0 is the S0 equivalent on the powerpc board i am using Jun 17 09:23:13 just checked with the kernel sources Jun 17 09:24:16 i am now baking a kernel uImage with the correct device tree included Jun 17 09:59:33 is there a way to provide a device tree in compiled dtb format instead of speciying a dts file? Jun 17 10:03:06 or does he insist in building it himself? Jun 17 10:09:22 petero_: don't you have your dtb in image directory? Jun 17 10:09:34 mckoan, nope Jun 17 10:09:37 do i have to? Jun 17 10:10:21 i have specified my dtb as KERNEL_DEVICETREE="motion5200b.dtb" in conf/machine/mymachine.conf Jun 17 10:10:43 then he uses that dtb file as a make target during do_install Jun 17 10:14:58 i have now created arch/powerpc/boot/dts in the files directory in recipes-kernel/linux/ and added it to the files variable in my linux_yocto.bb Jun 17 10:15:26 i hope that will work Jun 17 10:29:55 mckoan, i see the image directory in the tmp directory. but my dts file is not in there Jun 17 10:31:29 basically what i want to do is to make him place my .dts file into the directory where he finally compiles the kernel in Jun 17 10:31:46 my files:// variable in linux_yocto.bb has not worked Jun 17 10:38:23 i modified my files variable with a "image/usr/src/kernel" prefix Jun 17 10:38:46 and moved the dts file inside the files directory accordingly Jun 17 10:38:58 that way it should end up in the image directory Jun 17 10:47:21 mckoan, I have SRC_URI = file://image/usr/src/kernel/arch/powerpc/boot/dts/motion5200b.dts in linux_yocto.bb Jun 17 10:47:50 however, the dts file is not copied into image/usr/src/kernel/arch/powerpc/boot/dts Jun 17 11:20:10 hi every one. my host system is gentoo and I want to run qemu on it. Jun 17 11:20:19 but it doesnt work Jun 17 11:20:34 how can I fix it? Jun 17 11:21:50 if anybody knows any thing about this problem, I can give more details. Jun 17 11:30:28 my host system is gentoo and I want to run qemu on it. but it doesnt work. how can I fix it? if anybody knows any thing about this problem, I can give more details about my error... Jun 17 11:31:46 sm_: very useful if you tell us what the error *is* Jun 17 11:33:48 rburton:"couldnt initialize SDL: No avalaible video device" Jun 17 11:38:16 rburton: "no protocol specified" \ " couldnt initialize SDL: No avalaible video device : exiting " Jun 17 12:39:53 bluelightning, i sent "[yocto] [PATCH] populate_sdk_base: add auto-completion in setup" last week and I just checked the mailing list, there were no replies. Should I have sent it to someone in particular or what will happen now? Jun 17 12:58:04 hi! Jun 17 12:59:36 Denwid: i can see a couple of non technical issues with your patch/email. 1) you should send patches to oe-core mailing list, not yocto. 2) you are missing proper git commit and signed-off-by tag, 3) you should sent patches inline, not as attachement. Jun 17 12:59:48 I have a question about udev :) Jun 17 13:00:08 I have a poky dist but I have a problem : when I boot the board with an usb stick connected, the usb stick isn't found by udev (no /dev/sda), I must disconnect and reconnect it Jun 17 13:00:59 ndec, thanks for your feedback! I will resubmit accordingly to oe-core mailing list. Jun 17 13:01:31 I have also tried to do a : $ echo add /sys/bus/usb/blabla.../uevent to resend uevent for udev, it's work but It's not clean... Jun 17 13:02:22 So my question, is it possible to force udev to rescan uevent to add missing devices? Jun 17 13:02:53 bluelightning: RP: btw, i was trying to find 'good' pointers to get started for new yocto developers , and it doesn't look like there is something easy to find. the website leads to https://www.yoctoproject.org/tools-resources/community, which leads to https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide Jun 17 13:04:02 ndec: the one I would recommend is http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Jun 17 13:04:23 ndec: we probably need to both improve that documentation and ensure it's easier to find though Jun 17 13:04:26 yes, i know this one. but it's not 'reachable' for someone new willing to contribute to 'yocto' Jun 17 13:05:01 ndec: where were you looking in particular? Jun 17 13:05:37 from yoctoproject.org. to 'emulate' somebody new. Jun 17 13:05:49 anybody konows anything about my problem? Jun 17 13:08:21 and mine also ? :p Jun 17 13:26:21 ndec, I resubmitted, I hope it's formally correct now :). Yes it would probably be helpful to make this info more visible. Jun 17 13:29:59 sm_: what SDL is telling you is that out of all the ways it has to display something, none could be enabled Jun 17 13:30:04 Denwid: i am not seeing your patch on the list. not sure if it's a problem on my end, or yours. Jun 17 13:30:11 sm_: is DISPLAY set in your environment? Jun 17 13:34:59 bluelightning: thanks for responding. I should leave here now. i'll come back later... Jun 17 13:38:51 ndec, mhh that's really strange, I didn't get any error. However on the yocto list there is a little delay sometimes (up to 15 minutes) until they show up on the actual list. Might also be our IT. Don't know. Jun 17 13:39:05 I haven't received my own mail from the list, too Jun 17 13:39:32 did you send as plain text or html? maybe html are rejected on the list? Jun 17 13:40:05 ndec, as plain as it gets. used git send-email as suggested by the wiki page Jun 17 13:40:16 ok Jun 17 13:40:21 actually copy-pasted the mail command from there Jun 17 13:41:07 ok, it's arrived. Jun 17 13:46:06 cool! Jun 17 13:54:28 Anybody know if is it possible to force udev to rescan uevent to add missing devices (uevent send by the kernel before init of udev) ? Jun 17 13:58:30 plopppp: boots which involve removable media should do a udev settle already Jun 17 14:01:28 plopppp: does " udevadm trigger --action=add " works for you ? Jun 17 14:01:33 rburton, yes, but this point is ok on my target, if I remove and replug the usb stick, rules provide to udev good way to add my node Jun 17 14:02:45 maxin, yes it works fine Jun 17 14:04:32 plopppp: run "udevadm monitor" in one terminal and " udevadm trigger --action=add " in another terminal to see if it triggers the required events Jun 17 14:08:03 maxin, ok, I did that, I have 3 lines about sda : Jun 17 14:08:11 maxin, KERNEL[32.266245] add /devices/platform/fsl-ehci.1/usb1/1-1/1-1.1/1-1.1:1.0/host0/target0:0:0/0:0:0:0/block/sda (block) Jun 17 14:08:20 maxin, KERNEL[32.266651] add /devices/platform/fsl-ehci.1/usb1/1-1/1-1.1/1-1.1:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 (block) Jun 17 14:10:06 maxin, http://pastebin.com/H0Ba9kwG# Jun 17 14:12:47 plopppp: from the logs, it can find the sda1. We should be able to mount it, if we have a udev rule. Jun 17 14:15:15 maxin, yes, it works dine with your cmd line (I can see my device into the /mnt folder), but finally I don't understand why udev don't see missing uevent itself? Jun 17 14:19:13 maxin, for example, there's an option to say to udev : "At startup don't check missing uevent to optimize the boot time"? Or (I think yes but) udev can check itself missing uevents? Jun 17 14:20:27 hello, can somebody tell me if it is possible to install the "apt-get" package manager in a yocto distribution ? What is the package name ? Jun 17 14:20:39 "apt" Jun 17 14:20:50 the package is apt, there's an apt-get command Jun 17 14:20:51 (same as debian) Jun 17 14:23:01 So in short, I just have to add the line "IMAGE_INSTALL += apt" in my "local.conf" and then I will be able to use "apt-get" Jun 17 14:23:49 well, maybe. set PACKAGE_CLASSES to package_deb and ensure you have the package-management IMAGE_FEATURE added. Jun 17 14:24:12 and of course you will need a package feed Jun 17 14:24:35 if you don't set the package type then you won't have debs, and if you don't add package-management then you won't have a working apt Jun 17 14:24:50 is there an existing image that has "apt-get" install ? Jun 17 14:25:04 (demo image..) Jun 17 14:25:08 if you do what i said, you'll get apt installed Jun 17 14:25:18 ok.. I will try it Jun 17 14:25:22 thanks ! Jun 17 14:26:17 another question... I don't mind to use "smart" as the package manager.. I was wondering if there is a tutorial somewhere on how to create a new Smart package Jun 17 14:26:50 for example, if a package doesn't exist , then I could prepare it... but I just don't know where to start... (on how to do it..) Jun 17 14:26:53 smart is a rpm package manager Jun 17 14:27:31 you don't write rpms or debs, you write a .bb recipe and bitbake will make the relevant package Jun 17 14:28:06 ok, do you have some doc on how to create a .bb recipe ? Jun 17 14:28:55 (sorry i am very new to yocto..!) Jun 17 14:29:21 yotta, please start here: https://www.yoctoproject.org/documentation Jun 17 14:29:43 there is a quick start, and if you got to "View All" you'll find a development manual Jun 17 14:30:06 http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html Jun 17 14:31:24 ok, it seems section 5.3 has what I need (ie: 5.3. Writing a New Recipe)... Jun 17 14:31:36 plopppp: It is safe to add that command-line part to ensure that we don't miss any devices.. Jun 17 14:32:18 thanks for the quick answer.. this is great.. It is more clear now ! see ya Jun 17 14:55:39 Hi, anybody uses the Address Sanitizer feature in gcc 4.9 for arm (-fsanitize=address) ? Jun 17 14:57:22 YPTM: Armin is here Jun 17 14:57:44 YPTM: Corneliu joined Jun 17 14:58:40 YPTM: Participant passcode: 42001078 Dial-in number: 1.972.995.7777 US Toll Free number: 1.877.561.6828 Jun 17 14:58:58 YPTM: Stephen Joined Jun 17 14:59:40 YPTM: Melissa joined Jun 17 15:00:00 YPTM: Darren has joined Jun 17 15:00:07 YPTM: Cristian joined Jun 17 15:00:12 YPTM: Tom Z on Jun 17 15:01:11 YPTM: Saul is here Jun 17 15:01:34 YPTM: Michael on the call. Jun 17 15:02:05 YPTM: Paul Eggleton is on Jun 17 15:03:28 YPTM: Nitin Kamble is on the call Jun 17 15:04:09 otavio: damn CONFIG_TOUCHSCREEN_EGALAX_SINGLE_TOUCH Jun 17 15:04:16 otavio: ;-) Jun 17 15:04:18 YPTM: Matthew on the call Jun 17 15:05:41 YPTM: sorry I'm late from a previous meeting... Jun 17 15:07:10 I thought 1.4 was no longer under maint Jun 17 15:16:48 YPTM is done! Jun 17 15:17:49 doh. Jun 17 15:17:59 * zeddii realizes now that he forgot it was Tuesday. Jun 17 15:18:02 *sigh* Jun 17 15:18:07 zeddii, it's tuesday Jun 17 15:18:16 :) Jun 17 15:18:41 * zeddii finishes his pull request for evidence he was yocto-hacking while missing the call. Jun 17 15:18:49 ;-) Jun 17 15:22:38 anyone know a good resource for explaining TERM= handling under linux? With a number of my images, I'm actually using the terminal to look at logs files and finding the actual screen is like 72 characters wide while more and less are acting like much wider is shown. Jun 17 15:23:10 vi actually pans right. Jun 17 15:23:18 mckoan: oh Jun 17 15:23:34 mckoan: but I am unsure this expected to be kept set Jun 17 15:23:43 mckoan: let's see what people say's Jun 17 15:28:49 otavio: I expected a backward compatibility at least for Freescale eval boards Jun 17 15:28:58 Well Jun 17 15:29:10 mckoan: being a build time option it is not easy Jun 17 15:30:05 otavio: BTW I already sent a patch to meta-freescale ML Jun 17 15:32:32 otavio: the most astonishing thing is that nobody complained about the tslib failure Jun 17 15:33:01 Most people been using X or Qt5 Jun 17 15:33:30 otavio: I use qt5 with tslib Jun 17 15:37:23 mckoan: you could use it with linuxinput Jun 17 15:38:44 Jefro, https://www.yoctodev.org/downloads Jun 17 15:39:33 blloyd: could check the columns and rows settings for the tty with stty (stty -a), as a starting point Jun 17 15:42:33 maxin, ok, thk lot for your help ;) Jun 17 15:44:14 plopppp: welcome :) I know my explanation wasn't enough.. anyway, have a look at here: https://github.com/ash211/systemd-arch-units/blob/master/service/cups.service Jun 17 15:45:17 ploppp: should explain why some devices don proper enumeration Jun 17 15:45:41 don't do Jun 17 15:47:17 whee. Jun 17 15:47:20 make: *** No rule to make target `/home/paul/poky/build/tmp/sysroots/intel-corei7-64/usr/lib/dbus-1.0/include/dbus/dbus-arch-deps.h', needed by `dbus/dbus_old.o'. Stop. Jun 17 15:47:35 otavio: I'll try thanks Jun 17 15:47:48 and none of our dbus pkgs are 1.0 and none of them put anything in the sysroot either. Jun 17 15:47:57 * paulg investigates further. Jun 17 15:48:14 this is yesterday's master fwiw. Jun 17 15:49:27 Anyway, I need some help in memory sanitizer support for gcc 4.9 ... Apparently, it needs libsanitizer Jun 17 15:50:43 still, can't locate it .. Jun 17 15:58:33 paulg: 1.0 is the dbus abi Jun 17 15:59:41 bluelightning, https://www.yoctodev.org/downloads Jun 17 16:00:32 zeddii warned me that dbus can be interesting to work with. Jun 17 16:01:45 *cough* debian package name mapping. *cough* Jun 17 16:02:30 paulg: what are you building? dbus builds here. Jun 17 16:02:55 rburton, a variant of build-appliance, with multilib enabled. Jun 17 16:03:30 aha, I do have these... Jun 17 16:03:33 paul@yow-pgortmak-d4:~/poky/build/tmp/sysroots$ find . -name '*dbus*'|grep arch Jun 17 16:03:33 ./x86_64-linux/usr/lib/dbus-1.0/include/dbus/dbus-arch-deps.h Jun 17 16:03:33 ./intel-corei7-64/usr/lib64/dbus-1.0/include/dbus/dbus-arch-deps.h Jun 17 16:03:33 paul@yow-pgortmak-d4:~/poky/build/tmp/sysroots$ Jun 17 16:04:12 so it is the lib vs lib64 that fscked me (hence multilib is to blame) Jun 17 16:17:29 RP: it also seems there are cases where bitbake -S printdiff shows a delta even though a build will go 100% from sstate Jun 17 16:17:37 RP: haven't nailed down exactly when, yet, though Jun 17 16:17:56 kergoth: i've noticed gcc-cross often causes false-positives and generally upsets printdiff Jun 17 16:36:40 kergoth, rburton: I'd suspect the gcc shared work pieces Jun 17 16:38:05 we've seen those issues even with the external toochain. not reliably, though, will try to put together a reproducer next time it comes up Jun 17 16:43:05 RP: I'm sorry I haven't sent the stats from m4 dependencies improvement in world build... currently it's too broken to trust the logs.. Jun 17 16:43:39 JaMa: broken due to the patch or for other reasons? Jun 17 16:49:20 other reasons Jun 17 16:49:51 so most failures will be "hidden" by their broken dependencies Jun 17 16:51:03 meta-oe layers still didn't recover from B!=S (without the blanket B=S/autotools-broken sep patch I'm using in world builds) :/ Jun 17 16:51:50 JaMa: I'm sorry to hear that :( Jun 17 16:52:07 JaMa: I'll perhaps have to see if I can help out a bit there then :/ Jun 17 16:52:25 * RP doesn't like to have "caused" problems like that :( Jun 17 16:52:38 JaMa: I think I have fixed that grub failure at least... Jun 17 16:53:05 RP: I don't blame you for causing it :) Jun 17 16:53:24 RP: even with blanket B=S change in meta-oe it's better "default" Jun 17 16:54:02 the only problem is lack of meta-oe/* contributors which will fix remaining issues (in possibly unused recipes) Jun 17 16:54:34 the same does apply for *-config -> pkg-config changes Jun 17 16:54:59 JaMa: if they haven't been fixed by now surely a blanket autotools -> autotools-brokensep for the ones that are failing would be the right thing to do? Jun 17 16:55:10 it's good goal, but "community" layers lack manpower to keep up with oe-core changes Jun 17 16:57:10 bluelightning: I've created the blanket one just by comparing failed recipes in B!=S and B=S builds (in couple iteration) so a lot of them will have very simple fix like adding ${S} in do_configure_prepend or something like that Jun 17 16:57:43 so I was hopping few more commits where autotools-brokensep is added only to "hard-to-fix-recipes" Jun 17 16:58:44 it's not so complicated, I've cleaned e.g. meta-efl recipes in few hours, but it nicely shows lack of manpower to maintain other less used recipes :/ Jun 17 16:59:09 well we still don't have daisy README update as well Jun 17 17:01:00 and as described in "quality of meta-oe .." e-mail I don't blame oe-core or anyone in this channel for this, oe-core progress shouldn't be slowed down just because of other layers not keeping up with it Jun 17 17:01:29 but in long term we really need to find way to motivate more people/companies to contribute to "comunity" layers if we want this model to work Jun 17 17:02:41 JaMa: at the end of the day it's hard to solve the "drive-by submission" of recipes which is a problem we had for a long time even in OE-Classic Jun 17 17:03:11 even I've been guilty of it - I haven't checked, maybe some I submitted to meta-oe are still on the broken list; I'll have a look Jun 17 17:03:45 it would be great to see some "usage" statistics like we had in tinderbox Jun 17 17:04:25 wiull they fix the underlying code issues upstream one day? Jun 17 17:04:31 but I don't have that even for e.g. SHR binary feed where it should be relatively easy to generate from apache logs Jun 17 17:06:21 i think its hard to drum up any real enthusiasm for recipes that live in a pile of random stuff. layers with a purpose, like meta-filesystems or meta-networking, are likely easier to get contributors to help with, if they use them to accomplish their goals Jun 17 17:06:22 * kergoth shrugs Jun 17 17:06:25 bluelightning: and yes it's hard to know if some "drive-by submission" is still used by someone (or maybe it will be used again in 6 months time when there is new stable release) or if it's not worth fixing anymore, because the contributor and the only user of it left completely Jun 17 17:07:26 heh, wasn't the lack-of-janitors issue already discussed? Jun 17 17:07:46 it was, but without any sollution or improvement :) Jun 17 17:08:03 I'm trying more direct approach like http://lists.openembedded.org/pipermail/openembedded-devel/2014-June/096318.html Jun 17 17:08:32 but it's hard to map all "open issues" to individual contributions in e-mail Jun 17 17:08:36 lol, I missed it Jun 17 17:08:50 worth a try ;) Jun 17 17:09:22 pester the last committer or the last two maybe... Jun 17 17:10:48 yes, that's the idea, but often it's me from big indentation change a year ago or someone who was just drive-by fixing some other random change Jun 17 17:11:32 yes, random-fixes can easily happen Jun 17 17:13:06 in worse case we can do something like gentoo did long time ago (in experimental gcc ebuilds) and show warning when parsing meta-oe which can be hidden only by setting I_REALLY_PROMISE_TO_SUBMIT_PATCHES_TO_UPSTREAM = "Y" Jun 17 17:13:11 i'd look more at the oldest commits, the ones that added the recipe in the first place. might need to list all files that have ever existed in the repo, grep out the recipe name, that way you get the various versions of the reicpe Jun 17 17:13:15 hah Jun 17 17:13:52 kergoth: I've tried that many times, but even those people don't even reply to my e-mails in too many cases :/ Jun 17 17:13:53 https://github.com/kergoth/dotfiles/blob/master/scripts/git-ls-files-ever Jun 17 17:13:57 ah, that sucks Jun 17 17:15:12 so in the end I rather spend time trying to fix those issues instead of trying to find people which could be "responsible" Jun 17 17:15:41 so looking over the list I might be able to fix a few Jun 17 17:15:48 lcdproc was one of mine and the issue seems trivial Jun 17 17:15:55 and "status" e-mails should help with finding volunteers Jun 17 17:15:58 hello everybody Jun 17 17:16:18 i am having a hard time compiling a yocto kernel with my custom device tree file Jun 17 17:17:06 setting KERNEL_DEVICETREE to the dts file makes him call that as a make target in the kernel source directory in the image directory Jun 17 17:17:17 but my .dts is not in there Jun 17 17:17:29 so in the end it's problem of maintaining big pile of Currently Rarely Accessed Packages without having people I can pester/assign to fix them Jun 17 17:18:55 might be worth just flagging them as broken / blacklisting them as broken. anyone using it should see the message, and if they want it fixed, they can fix it? Jun 17 17:18:56 * kergoth shrugs Jun 17 17:19:47 kergoth: that's what I'm partially doing now (for lost cases), but I think a lot of their users are tracking stable branches Jun 17 17:20:00 so they will see this blacklist only after upgrading to next release Jun 17 17:20:17 where it could be too late to fix it (e.g. by upgrading the version) Jun 17 17:21:29 and blacklisting recipes just because of missing ${S} in do_configure_prepend seems a bit drastic Jun 17 17:22:45 but on the other hand it's better than just autotools -> autotools-brokensep blanket change, because it will remove such unmaintained recipe completely and I won't need to care about building it and future issues in it Jun 17 17:31:33 * kergoth nods Jun 17 17:35:12 ok there's pv and lcdproc fixed at least Jun 17 17:35:17 maybe I can fix a few more later Jun 17 17:39:09 bluelightning: thanks! Jun 17 17:41:30 * paulg wonders what the difference between ACCEPTED and RESOLVED is wrt. bug status Jun 17 17:41:54 accepted = checked in, and resolved = checked in and tested ? Jun 17 17:43:17 oh wait, I get it. Accepted means the _bug_ was accepted, I bet. Jun 17 17:44:08 * paulg marks YOCTO #6440 as resolved Jun 17 17:48:38 paulg, yes, it means the assignee acknowledges the bug and is working on it Jun 17 17:49:44 dvhart_, yep thanks. minor moment of brain fade on my part. Jun 17 17:57:48 :-) Jun 17 17:58:54 oh, and it turns out the wpa-supplicant fail went away when I poked at the Makefile in a devshell; and I couldn't reproduce it after a forced cleanall and rebuild. Jun 17 17:59:09 so, some sort of transient from switching on multilib, I guess. Jun 17 18:00:57 wpa builds up the makefile fragments into various text files and the pre-multilib path was stored in one of those. **** ENDING LOGGING AT Wed Jun 18 02:59:58 2014