**** BEGIN LOGGING AT Wed Jan 15 02:59:59 2014 Jan 15 03:37:16 I seem to recall a tool named bb(?) that allowed one to examine bitbake dependencies and package manifests. Does this still exist? I'm having trouble googling it. Jan 15 03:59:03 ahoy Jan 15 04:00:44 sr105: https://github.com/kergoth/bb Jan 15 04:00:52 ah, thanks! Jan 15 04:01:52 otavio: when that happens and it's really a 404, you'll need to download it from another source Jan 15 04:09:26 probably worth a bug if there isn't one already Jan 15 07:06:48 Hi, have a question related to selction of package for compilation. If there are 2 packages in different layers with different version, How do I choose the required version? Jan 15 10:15:51 JaMa: I found a workaround for the grub/debug edit issue Jan 15 10:19:41 hum, I get an interesting issue Jan 15 10:20:14 I'm using: Jan 15 10:20:16 http://code.bulix.org/8bx3x2-85439 Jan 15 10:20:42 as wpa-supplicant_2.0.bbappend Jan 15 10:21:10 This is not working as expected because of pkg_postinst_wpa-supplicant () in wpa-supplicant-2.0.inc Jan 15 10:23:07 koen: great, one world build issue down, 40 more to go :) Jan 15 10:28:53 any idea on how to solve that ? Jan 15 10:32:29 JaMa: I didn't fix the grub_2.00.bb recipe, only the _git one Jan 15 10:39:02 koen: I'll be happy to set P_V in world builds :) Jan 15 10:40:24 :) Jan 15 10:40:40 I need to sort out x86 issues with the _git recipe Jan 15 10:40:56 grub 2.02 will be out soon and I want to be prepared for that Jan 15 10:42:05 koen: grub-efi_git and grub_git conflict with each other right? (as files in sysroot etc) Jan 15 10:42:23 koen: can you exclude grub-efi_git from world if that's so? Jan 15 10:44:48 well, after some more testing I don't think I'll submit grub-efi_git Jan 15 10:44:59 it seems its only use use to supply grub-mkimage Jan 15 10:45:52 fair enough, I was just reading the mail Jan 15 10:46:15 I don't really get why that recipe exists Jan 15 10:47:36 btw: what do you think about python-mako/python-numpy/piglit move, have you heard some new reasons why oe-core cannot be tested with another layer? Jan 15 10:47:56 I should have asked yesterday in TSC Jan 15 10:51:00 I've mostly given up trying to discuss things like that Jan 15 10:51:08 what intel want, intel gets Jan 15 10:51:40 I'm more worried about broken and non-review patches in pull requests Jan 15 10:52:11 JaMa: to be honest, I'll be glad to get rid of numpy, it's a nightmare Jan 15 10:53:12 JaMa: I predict qt5 going into OE-core as well, no matter what happens during the "discussion" Jan 15 10:56:14 koen: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4082 Jan 15 10:57:05 heh Jan 15 10:57:12 that bugreport is funny Jan 15 10:57:43 it seems to completely gloss over grub vs grub-efi vs grub-efi-native Jan 15 10:58:28 EFI isn't hard Jan 15 10:58:47 just put a boot.efi in a vfat partition and you're done Jan 15 10:59:10 people thinks it's hard because grub mandated that byzantine install method Jan 15 10:59:26 actually Jan 15 10:59:45 just install a kernel with efi stub and a startup.nsh to call that stub with the right cmdline Jan 15 11:00:19 and/or build the right cmdline into the kernel Jan 15 11:03:04 morning all Jan 15 11:11:14 morning pb_, all Jan 15 11:14:49 hi bluelightning Jan 15 11:29:08 koen: sometimes decisions get made which you won't agree with. Can you please move on and deal with it. I think its actually move important we make decisions and move than get stuck into a trap of having every single person bought in 100% to every decision. There are decisions which go the way you want and others dislike too, they don't make a big thing about them. We could change that of course. Jan 15 11:34:44 ah Jan 15 11:34:55 so that's how patches that only get NAKs go in Jan 15 11:36:09 I think disagree-and-commit works fine Jan 15 11:36:53 but I absolutely hate when patches go up for review on the mailinglist and later decisions are being made base don discussion in a (nonpublic) backchannel Jan 15 11:38:10 koen: which nonpublic back channel? Jan 15 11:38:38 koen: I'm not even sure which NAK'd patches you're referring to? Jan 15 11:39:07 right before 1.4 you applied patches where 75% of the replies were NAKs Jan 15 11:39:49 koen: FWIW I do think those changes were a mistake. There wasn't anything non-public about them though Jan 15 11:40:04 but as I said, I've given up discussing issues like this Jan 15 11:40:23 I'm more interested in finding a way to ensure pull requests match the reviewed patches Jan 15 11:40:57 koen: I'm doing what I can to ensure that does happen Jan 15 11:41:15 I know that Jan 15 11:41:23 and I don't want to imply laziness or malice Jan 15 11:47:33 I think the easiest fix is to have the pull request script output the hash of FETCH_HEAD as well so you can copy/paste the line to pull in a specific rev instead of only a branch Jan 15 11:50:35 koen: so no more "I've fixed that on the branch"? Jan 15 11:52:07 hi. Is there a gcc-git or gcc-svn recipe somewhere? Current master seems to only have a tarball based 4.8 Jan 15 11:52:39 current openembedded-core master, that is Jan 15 11:53:06 koen: The standard git request-pull does output the hash (though not as part of the default cut'n'paste line). Jan 15 11:55:50 * broonie would just not take pull requests from people he couldn't trust but YMMV. Jan 15 11:57:54 bluelightning: seeing we had 2 screwups reported in the last 7 days, I really want less handwaving about changes in pull request branches Jan 15 11:59:45 judging from how much git-review screams at me for local diff and extra commits I know I can't be trusted to "fixed in branch" correctly Jan 15 11:59:59 and I am sure I'm not the only accident prone developer here :) Jan 15 12:04:44 * XorA hides behind koen Jan 15 12:10:14 if git-review wouldn't suck so much (no default reviewers, seriously?) I would advocate using it for OE-core Jan 15 12:11:57 * koen hurls fwts at XorA Jan 15 12:12:13 * XorA punts it into the sewers where it belongs Jan 15 12:19:21 broonie: Given where the mistakes have happened, I couldn't trust anyone :( Jan 15 12:53:46 RP, I propose sgw send koen some beer Jan 15 13:00:16 koen, JaMa I agree on numpy. There is some unresolved pain in that recipe :) Jan 15 13:02:11 blindvt`: I don't think there is, but it shouldn't be all that hard to adapt the 4.8 recipe to build the trunk from svn. Jan 15 13:04:18 blindvt`: it was originaly checked out from svn and then replaced with snaphost, so you can find the exact modification you need to undo in history Jan 15 13:06:39 RP: Well, git am is pretty easy to use... Jan 15 13:08:07 broonie: that isn't the problem, the problem is we have a lot of patches floating around in various states of testing/review/merge and sometimes the wrong thing ends up in the wrong tree. Its user error, I've made mistakes with it before... Jan 15 13:09:39 We're averaging ~13 patches a day which whilst not huge compared to the kernel, is a lot when you consider the number of people doing consolidation Jan 15 13:10:25 RP: Sure, but it's the only way I know of to make sure that what just got reviewed is what got applied other than using something like gerrit. Jan 15 13:11:58 Any kernel VFS experts around? When creating a directory, could userspace see it as file briefly? Jan 15 13:13:07 * RP is looking at a race which would be explained if a directory was seen as a file by some code Jan 15 13:13:45 I can't think how that could happen on any reasonable filesystem. directory-ness is a property of the inode and that ought to be stable by the time the dentry is created. Jan 15 13:16:45 but, if there are any kernel h4x0rs around, I have a question for them too: does the reloading of cp15 control in the ARM syscall path still serve any useful purpose on modern platforms? Jan 15 13:17:55 pb_: ext4 which should presumably be a reasonable filesystem Jan 15 13:18:06 yeah Jan 15 13:24:03 its even created by our own code (bb.utils.mkdirhier(controldir)) (its rpm and deb racing over a DEBIAN directory despite there being code in rpm to ignore such directories) Jan 15 13:24:53 hi. i am facing a strange issue. i moved 1 library from recipe_A to recipe_B. and recipe_C links against this lib. even after i wiped tmp folder, in the .ipk file for recipe_C i can see reference to recipe_A. so when doing the image, it tried to install recipe_A which doesn't even exist anymore. Jan 15 13:25:40 if i look at the do_package log for recipe_C, it clearly says that the lib is coming from recipe_B. somewhere during .ipk generated i inherit from old data. Jan 15 13:26:16 i haven't cleaned up the entire folder, just build/tmp, and I haven't cleaned up the sstate. Jan 15 13:26:20 ndec: there is probably still pkgdata around about the mapping Jan 15 13:26:22 did the recipes change arch? Jan 15 13:26:37 koen: indeed. Jan 15 13:27:09 it's a lib that used to be MACHINE (HAL) that has been reimplemented to become generic, hence no longer MACHINE Jan 15 13:27:17 right Jan 15 13:27:26 where would the pkgdata reside? Jan 15 13:27:36 JaMa has a lot of experience with that bug Jan 15 13:27:50 that's what i was thinking, but couldn't find where the date is. Jan 15 13:27:51 data Jan 15 13:27:59 TMPDIR/pkgdata iirc Jan 15 13:28:26 do a find for the old recipe name in TMPDIR, excluding work and sysroot Jan 15 13:29:31 ndec: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4102 Jan 15 13:30:01 ndec: tmp/sysroots//pkgdata Jan 15 13:30:28 but even if i delete tmp, i can still reproduce. Jan 15 13:30:41 wipe sstate as well? Jan 15 13:31:01 well, i didn't cleansstate for recipe_C Jan 15 13:31:02 old sstate with old architecture shouldn't be used after deleting tmp Jan 15 13:31:35 ndec: you can also revert the change in the recipe, cleansstate it and then revert the revert (if you don't want to mess with "find") Jan 15 13:34:31 JaMa: koen: RP: well, ok. so deleting manually all the instances of recipe_A in my sstate, solved the problem... Jan 15 13:34:49 i am on dylan. was that 'behavior' fixed since that? Jan 15 13:38:23 ndec: I'd hope so. If it wasn't we need to fix it Jan 15 13:38:55 ok. thanks! Jan 15 13:39:03 ndec: I suspect not cleansstate for recipe_C would have been the issue Jan 15 13:39:32 ndec: once you'd got the "bad" data from pkgdata sstate wouldn't put it back but it would restore a previously badly built recipe_C Jan 15 13:40:00 you mean recipe_A, i think. recipe_C is the application that uses the linb. Jan 15 13:40:03 lib Jan 15 13:40:22 i had done cleansstate on recipe_C, not recipe_A. Jan 15 13:42:34 ndec: "well, i didn't cleansstate for recipe_C" - I'm getting confused :) Jan 15 13:43:18 hehe... sorry, it was 'i did'. Jan 15 13:46:48 ndec: that does somewhat change things :) Jan 15 14:36:59 koen: ping Jan 15 17:50:46 hi Jan 15 17:50:58 is there some documentation for setting up a PR server? Jan 15 17:51:43 hi crofton Jan 15 17:51:47 okay found something Jan 15 17:51:53 heh Jan 15 17:52:30 woglinde, I think som ejava/cacao questions came up during TSC meeting yesterday Jan 15 17:52:51 hm okay Jan 15 17:52:56 is it in the minutes? Jan 15 17:53:08 hm oh yesterday Jan 15 17:53:12 okay we have to wait Jan 15 17:53:28 I will be at fosdem by the way Jan 15 17:54:01 awesome Jan 15 17:54:14 you know about meta-java? Jan 15 17:54:28 17:41:58 meta-java is one of layers which we have most commonly having Jan 15 17:54:29 issues at OS. From time to time mario-goulart ends needing getting build failure Jan 15 17:54:29 s Jan 15 17:55:08 I fixed all stuff Jan 15 17:55:51 and sorry I can not work paid and parttime on it Jan 15 17:56:16 woglinde, understood Jan 15 17:56:16 hm maybee I can Jan 15 17:56:23 but nobody stepped up Jan 15 17:56:27 to pay something Jan 15 17:56:28 *g* Jan 15 17:56:30 I just wanted to make sure you knew the question had come up Jan 15 17:56:47 okay Jan 15 17:56:48 thanks Jan 15 17:57:00 I need to update the versions Jan 15 17:57:22 there are some TLS issues in jsse modul Jan 15 17:58:54 we can also look for a co-maintainer Jan 15 18:14:59 bluelightning: I booked my eurostar tickets for fosdem. What is the favourite hotel nowadays? Jan 15 18:17:12 he pb Jan 15 18:17:23 hi woglinde Jan 15 18:17:50 pb I should look how many pounds I have left Jan 15 18:18:10 so I can kindly ask you to bring me some walker chips over Jan 15 18:18:17 heh Jan 15 18:18:20 yes, no problem Jan 15 18:23:24 pb_, some of us are at the Saint Nicolas on the chicken market Jan 15 18:23:42 XorA, and hrw are nearby, but I forget their hotel name Jan 15 18:24:06 basically, most of us stay near the Grand Place Jan 15 18:24:23 will you be helping man the stand? if so, please add yourself to the wiki Jan 15 18:24:40 I am tied up Sunday with the software radio devroom Jan 15 18:38:36 I'm trying to add both cups-dev and alsa-dev to my image. I get /usr/include/cups... but no /usr/include/alsa/... is there something special about alsa? Jan 15 18:50:11 aim proably a bug Jan 15 18:50:24 aim not many testing dev stuff on the target device Jan 15 18:51:17 woglinde: ok, thanks. if I copy the alsa-dev...ipk to my image and opkg install it I get what I "want". Jan 15 18:52:41 Crofton|work: XorA is in Novotel, I am in Ibis nearby Jan 15 18:55:19 hi hrw Jan 15 18:55:44 aim so maybee it was not included in the image Jan 15 18:55:56 aim did you check with opkg? Jan 15 18:56:42 woglinde: not being included in the image is the bit I didn't understand. adding cups-dev I get /usr/include/cups/... Jan 15 18:57:38 woglinde: what should I check with opkg? Running opkg on target with alas-dev add the /usr/include bits and pieces. Are you suggesting I run this on my build host? Jan 15 19:03:55 opkg listinstalled or so Jan 15 19:04:08 sorry have no machine to test at the moment Jan 15 19:04:19 but help of opkg list all commands Jan 15 19:05:44 Crofton|work: hrw gave you the correct infos Jan 15 22:05:32 FFS, we need to figure out how to remove the bitbake packages from various distros! Jan 15 22:05:50 I'm convinced some distros package bitbake to discredit OE Jan 15 22:54:07 cronfton I put my name on the fosdem site Jan 15 22:54:15 and good nite Jan 15 22:54:46 thanks! Jan 16 01:44:51 it was good while it lasted... Jan 16 01:45:42 i found out about, and subscribed to, the automated-testing mailing list yesterday Jan 16 01:45:48 then today... Jan 16 01:46:01 * tlwoerner has been unsubscribed from the automated-testing mailing list Jan 16 01:48:29 heh Jan 16 01:48:33 I just got subscribed Jan 16 01:48:38 halstead, ping **** ENDING LOGGING AT Thu Jan 16 02:59:59 2014