**** BEGIN LOGGING AT Sat Dec 24 02:59:57 2011 Dec 24 10:10:19 sakoman__: looks like it might not be finding the key files somehow... Dec 24 10:12:37 RP__: googling for that error message showed that some folks had permissions issues, another claimed installing gpg fixed the issue Dec 24 10:13:01 installing gpg didn't fix the issue for me Dec 24 10:13:20 still investigating, but kind of back burner effort Dec 24 10:13:38 sakoman__: I'd probably resort to some print statements within rpm at that point - figure out where it was expecting the file and where it was in reality Dec 24 10:13:56 sakoman__: We've had a few issues with rpm paths needing to be set correcting to be within the sysroot and so on Dec 24 10:14:06 sakoman__: I don't think anyone has tried a signed repo before Dec 24 10:14:24 sakoman__: There were even some commits to master just made that might help Dec 24 10:14:36 I know clients are going to want signed repos, so I eventually need to get it working Dec 24 10:15:00 sakoman__: I doubt its anything really difficult, just some config thats wrong somewhere Dec 24 10:15:04 I'll take a look at the latest commits and see if they help Dec 24 10:15:09 agreed Dec 24 10:15:36 sakoman__: feel free to file a bug documenting how to setup what you've done if that doesn't help Dec 24 10:15:46 still undergoing the pain of transitioning from oe-classic, so there is so much to do to get back to square one!! Dec 24 10:15:56 sakoman__: Its unlikely anything will happen over the holidays but it would be good to fix ti Dec 24 10:16:17 I'll send a patch if I come up with a fix Dec 24 10:16:38 sakoman__: I'd be interested to know what is missing and if there is anything that can be done to help... Dec 24 10:16:44 I have a few patches almost ready to submit for other things Dec 24 10:17:13 mostly just a bunch of recipes that need to be added to meta-openembedded Dec 24 10:17:32 sakoman__: right, meta-oe is lagging behind a little :/ Dec 24 10:18:04 every client seems to have a different set of packages they need, and the union of them all make a pretty big list! Dec 24 10:18:26 so I need to start migrating the easiest ones :-) Dec 24 10:19:12 sakoman__: hopefully the migration shouldn't be too hard and there are plenty of examples out there... Dec 24 10:19:33 sakoman__: It should mostly be a case of deleting bits Dec 24 10:19:50 I've been using oe for years, so none of this is really too hard Dec 24 10:20:02 just a lot of tedious work :-) Dec 24 10:20:26 sakoman__: FWIW I think sstate is going to be appreciated by people a lot in the future Dec 24 10:20:44 sakoman__: Its amazing the difference its made on the autobuilders now its working right Dec 24 10:21:30 and the various cleanups it brings such as much more consistent sysroots Dec 24 10:22:17 one needs to remember during development of recipes that bitbake -c clean doesn't suffice after recipes changes! Dec 24 10:22:35 you need to bump pr or clear out the sstate! Dec 24 10:22:49 that bit me a few times when I got started! Dec 24 10:23:06 "why don't my changes take affect!"??? Dec 24 10:23:17 sakoman__: Is that changes to the patchset? Dec 24 10:23:39 sakoman__: It should detect most changes, apart from the pieces in SRC_URI (which is something I do want to fix) Dec 24 10:23:48 yeah Dec 24 10:24:36 gave me a few WTF moments Dec 24 10:24:58 ideally you should never have to run cleansstate Dec 24 10:25:23 it has gotten better recently as there were some dependencies missing which we found Dec 24 10:25:31 I didn't know there was a cleansstate :-) Dec 24 10:25:37 I should RTFM Dec 24 10:26:03 you have clean, cleansstate and cleanall Dec 24 10:26:14 :-) Dec 24 10:26:15 the latter wipes out bits of DL_DIR too Dec 24 10:26:26 thanks! that helps a lot Dec 24 10:27:03 what find I miss the most is beging able to 'git grep" the entire metadata Dec 24 10:27:42 I must admit I grep the metadata a lot but generally just meta* Dec 24 10:28:01 sakoman__: we could probably put something in scripts/ for that Dec 24 10:28:11 * RP__ would take a patch :) Dec 24 10:28:27 yup 'git grep foo | grep bar' is one of my most often used expressions :-) Dec 24 10:29:13 I'll add that script to my list :-) Dec 24 10:29:24 it is getting long! Dec 24 10:29:32 * RP__ knows that feeling Dec 24 10:29:48 RP__: what about my patch to disable sstate package? :) Dec 24 10:30:05 JaMa|Off: It didn't seem to be that much of a performance difference Dec 24 10:30:46 JaMa|Off: If I take that patch it implies we'll start to support it and I'm not sure I like the implications. For example it likely will stop sharing content between different machines Dec 24 10:30:50 because that was fast machine Dec 24 10:31:29 JaMa|Off: for example if you have two machines both using armv5te I think you just doubled your build time Dec 24 10:31:50 (roughly speaking) Dec 24 10:32:15 yes, but I'm used to this because of rm_work... Dec 24 10:32:34 JaMa|Off: rm_work shouldn't cause that and if it does, we need to figure out what and fix it Dec 24 10:33:16 and if someone is really building only for himself and for his only device than sstate is not usefull for him except rebuild from it if he wipes only TMPDIR Dec 24 10:33:40 JaMa|Off: The question is how many different codepaths do we want to maintain Dec 24 10:33:45 RP__: it does cause it and it was described in my last e-mail about sstate Dec 24 10:34:15 JaMa|Off: I need to dig into that then but there seem to have been higher priority issues :( Dec 24 10:34:53 JaMa|Off: The system is already way too complex so adding in extra codepaths for people to confuse themselves with is not something I'm keen on :/ Dec 24 10:35:00 I don't mind maintaining that simple patch in my branch until then :) Dec 24 10:35:32 JaMa|Off: Can you file a bug about the sstate reuse thing please? Dec 24 10:35:45 JaMa|Off: email is find for short lived stuff but this seems to be a longer standing issue Dec 24 10:35:52 and the bugzilla tracks those better Dec 24 10:35:58 sstate code does handle the case of emptied sstate-cache dir well, so this doesn't add much complexity Dec 24 10:36:10 ok, will add it and sumarize e-mails in it Dec 24 10:37:28 JaMa|Off: every choice we add to the system adds complexity. For something that was a 3% speed difference, I'm very reluctant (and I appreciate it varies by machine) Dec 24 10:37:51 I'd much rather we fixed bitbake's memory usage for example which should give more than a 3% speedup Dec 24 10:38:17 * RP__ -> brb Dec 24 10:40:23 ok, but there is also disk usage which some people also care about, but I agree that there are issues with higher priority Dec 24 10:47:07 btw there is rm_old_work in meta-micro which I'm currently using instead of rm_work on one of my buildhost, it works much better wrt sstate, but it doesn't save as much WORKDIR space as rm_work does Dec 24 10:49:40 only problem with it is that some bbclass (which does packaging of sources in -dbg) depends on WORKDIR name and all sources ends in /usr/src/${PV} instead of expected ${PF} (I have work around for that in meta-smartphones's version of rm_old_work) Dec 24 10:59:01 JaMa|Off: Have you a pointer to that code? Dec 24 10:59:18 JaMa|Off: I am also concerned at disk space usage Dec 24 11:00:04 JaMa|Off: I'm also cautious as rm_work was initially added as a quick hack without much thought and became something we had to support and caused a lot of problem Dec 24 11:24:47 hello ppl Dec 24 11:25:16 I've created a patch which should be applied to u-boot_2011.06 to support the mini2440 board Dec 24 11:25:25 however, my bbappend is failing Dec 24 11:25:38 ERROR: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception ValueError: need more than 1 value to unpack Dec 24 11:26:19 SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git; file://u-boot-v2011.06-mini2440-support.patch;md5=145a0f4b1599dc5d4ddef8dbdb98df7f" Dec 24 11:27:53 what else do I need to do? Dec 24 12:10:13 RP__: http://git.openembedded.org/meta-micro/commit/?id=fcf525654915edb9650f1a6c2852f336366f8b2f and http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=0d4c17de1ba7343d82bb10c311754e29d573c485 Dec 24 21:57:30 * kergoth ponders Dec 24 23:25:57 DEBUG: Mirror fetch failure for url http://mirror.gbxs.net/pub//linux/utils/kernel/hotplug/udev-145.tar.gz/udev-145.tar.gz (original url: http://kernel.org/pub/linux/utils/kernel/hotplug/udev-145.tar.gz) Dec 24 23:26:04 what the heck. hrm Dec 24 23:26:12 * kergoth looks at his MIRRORS Dec 24 23:29:42 this is odd. Dec 24 23:30:00 * kergoth wonders if the uri_replace code is bugged, or he's missing something in his mirrors usage, lets see.. Dec 24 23:30:21 yeah, this doesn't look right.. Dec 25 00:13:20 merry christmas everyone Dec 25 02:07:06 Merry CHristmas Dec 25 02:07:14 although I still have a few hours to go Dec 25 02:23:24 indeed, merry christmas Dec 25 02:40:48 merry xmas eve Dec 25 02:40:53 :) **** ENDING LOGGING AT Sun Dec 25 02:59:57 2011