**** BEGIN LOGGING AT Tue Nov 27 02:59:59 2012 Nov 27 08:11:15 morning all Nov 27 08:40:21 good morning Nov 27 08:43:27 Good morning. Nov 27 09:17:38 morning all Nov 27 09:27:28 Good morning Nov 27 09:32:21 there is something like "feh" in oe? Nov 27 09:32:43 hi bluelightning, hi mckoan Nov 27 09:34:20 silvio: there's a feh recipe in OE-Classic you could update Nov 27 09:35:06 bluelightning, thanks Nov 27 09:57:40 how to do do_stage in oe-core? Nov 27 09:59:30 i mean i don know how to convert this: Nov 27 09:59:33 autotools_stage_includes Nov 27 10:06:29 silvio: I guess you can drop this... Nov 27 10:09:18 florian, ok, thanks Nov 27 10:45:12 levonmaa: are you looking at it ? Nov 27 10:56:37 please, can someone rename dhcp_4.2.4-P1.bbappend to dhcp_4.2.4-P2.bbappend in meta-systemd Nov 27 10:57:31 pwgen: there is patch for that in patchwork Nov 27 10:59:57 hmm, where is patchwork ? Nov 27 11:00:07 JaMa: if you have access can you just merge it? Nov 27 11:00:32 shouldn't be controversial... Nov 27 11:01:14 pwgen: http://patchwork.openembedded.org/project/oe/list/ Nov 27 11:01:24 thx Nov 27 11:02:01 bluelightning: I don't have access afaik Nov 27 11:02:21 oh, I thought you were Koen's backup on meta-oe... Nov 27 11:38:50 systemd seems broken. udev-systemd is fighting against systemd .. Nov 27 11:39:01 pwgen: Uh? Nov 27 11:42:16 has anyone experience in solving the udev-systemd vs udev conflict ? Nov 27 11:42:38 pwgen: I am using both Nov 27 11:42:51 pwgen: I am using systemd-udevd as udevd and systemd Nov 27 11:42:57 pwgen: this is your question? Nov 27 11:43:05 how did you build it ? Nov 27 11:44:08 the usual problem, someone is updating something and everything is broken ..(:-(( Nov 27 11:50:04 bluelightning: and you were right about wrong CC in license email (I forgot quotes around Beth name, but she should be CCed properly, there is just one extra invalid CC entry pointing to my host) Nov 27 11:50:55 JaMa: hmm, I only saw one broken CC entry here Nov 27 11:56:45 hi all Nov 27 11:58:03 JaMa: in patchwork was a renaming systemd patch , that helped, with the name but systemd is only buildable with bitbake -b Nov 27 11:59:58 what is "renaming systemd patch" and what do you mean "with the name"? Nov 27 12:00:31 http://patchwork.openembedded.org/patch/39627/ Nov 27 12:02:53 this patch looks like a " mv dhcp_4.2.4-P1.bbappend dhcp_4.2.4-P2.bbappend" Nov 27 12:04:15 yes it is Nov 27 12:06:10 and this solved the errors regarding dhcp_4.2.4-P., but now i have following error http://pastebin.com/R4tHPc4n Nov 27 12:09:13 interesting, can you check line 246 /home/ew/BUILD-core-image-minimal/oe-core/BUILD-qemux86-64/tmp-eglibc/sysroots/x86_64-linux/usr/bin/opkg-build: 246: 0: not found Nov 27 12:12:34 pwgen: JaMa: sounds like the result of -b to me Nov 27 12:13:19 actually upon closer inspection, perhaps not... Nov 27 12:13:21 on my opkg-build there is "fi" on that line Nov 27 12:13:34 copy same on mine Nov 27 12:13:59 and this one line before : pkg_file=$dest_dir/${pkg}_${version}_${arch}.ipk Nov 27 12:14:22 try to cleansstate udev first Nov 27 12:14:41 s/udev/systemd/ Nov 27 12:20:21 no, cleansstated udev systemd , with no sucess, maybe i cleanssate everything .. Nov 27 12:26:38 bluelightning: is there some special requirement to resolve bug in yocto bugzilla as verified? (I'm reporter in this case) Nov 27 12:37:52 ok, so I just pulled to master and all the do_patch functions have broken, a -c clean seems to fix them but I can't do that for every recipe, anyone seen this? Nov 27 12:53:57 : updated bitbake to 0.17 ? Nov 27 12:54:36 s/0\.17/1\.17/ Nov 27 13:03:44 clean build did not help . seems i have to wait until someone will fix this Nov 27 13:09:12 pwgen: yes, I pulled to master on everything Nov 27 13:29:36 JaMa: if you're the reporter and you've verified the fix it would be much appreciated if you could mark it as verified Nov 27 13:33:07 ok, thx Nov 27 14:18:17 I removed tmp and now I am getting this: Nov 27 14:18:19 /home/otavio/hacking/fsl-community-bsp-mx6/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find -lpthread Nov 27 14:18:22 | /home/otavio/hacking/fsl-community-bsp-mx6/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find -lgcc Nov 27 14:18:25 Any clue? Nov 27 15:46:21 Hello. Nov 27 15:46:35 I'm having problems while analysing one receipe: Nov 27 15:46:45 PV = "84" Nov 27 15:46:45 PV_dm7025 = "83" Nov 27 15:46:55 SRC_URI = "http://sources.dreamboxupdate.com/download/7020/secondstage-${MACHINE}-${PV}.bin" Nov 27 15:47:09 When PV_dm7025 is used? Nov 27 15:49:47 Wow this is a hack! Nov 27 15:50:01 When the machine is dm7025! Nov 27 15:50:15 I do not know. Nov 27 15:50:25 But I have to set different versions for different machines. Nov 27 15:50:41 And I'm trying to get to now how it works. Nov 27 15:55:43 NOTE: package dreambox-secondstage-86-r0: task Fetch failed: Unable to fetch URL http://sources.dreamboxupdate.com/download/7020/secondstage-dm7020hd-86.bin from any source.: Failed Nov 27 15:55:56 This URL is working. Nov 27 15:56:01 What th hell? Nov 27 15:57:08 otwieracz: check the do_fetch log. IIRC, bitbake reports a do_fetch error when the file hashes don't match. Nov 27 15:59:32 its possible make a opkg repository that use some authentication, like gpg key? Nov 27 16:14:57 Is buildhistory suppose to break the build of some packages? Without buildhistory I can build openjdk-6-jre. If I set buildhistory to be generated, the build of openjdk-6-jre fails (details here: http://paste.debian.net/212766/). Do you know what may be causing that? Nov 27 16:16:49 mario-goulart: it's not supposed to break anything, no... I can't really tell what's going wrong in that output Nov 27 16:17:52 mario-goulart: enabling it will force do_package to re-run and that may trigger re-execution of some tasks; if those tasks are not written properly such that they can be re-executed a second time you may get failures Nov 27 16:18:04 that could be what is happening here Nov 27 16:19:27 bluelightning: yeah, it's weird. The error is "...tmp/work/i586-poky-linux/openjdk-6-jre-6b24-1.11.5-r20.0/icedtea6-1.11.5/build/bootstrap/jdk1.6.0/bin/java: No such file or directory", but that file actually exists. Nov 27 16:20:24 I have a feeling that ant script may be related. Nov 27 16:24:52 mario-goulart: usually when that sort of thing happens it's some kind of race condition Nov 27 16:25:27 otavio: ping Nov 27 16:25:41 levonmaa: pong Nov 27 16:25:53 otavio: yes, I fixed the tool issue Nov 27 16:26:06 but now running into a really weird problem Nov 27 16:26:56 even when I configure it with glib it does not use it and then complains abt it Nov 27 16:26:58 when lining Nov 27 16:27:02 linking that is Nov 27 16:27:20 qthread_unix.cpp:(.text+0x2b0): undefined reference to `QEventDispatcherGlib::versionSupported()' Nov 27 16:27:43 also it is not findign the correct zlib Nov 27 16:28:11 it is trying to use the on from the native side Nov 27 16:31:32 the glib one is especially odd as when I look at the config output, it is there and detected and even listed Nov 27 16:36:29 levonmaa: Well I think you should post the change for the tool Nov 27 16:36:37 levonmaa: and we move forward and focus on it Nov 27 16:48:08 otavio: my fix is not complete yet as I had to manually link the mkspec under the STAGING_DATADIR_NATIVE/qt/mkspecs and I Nov 27 16:48:24 am still contemplating weather that is the right place for it... Nov 27 16:49:02 levonmaa: I don't think you should need to link it but make qmake to understand where is it Nov 27 16:49:09 levonmaa: is qt.conf right? Nov 27 16:49:34 yes, that was what I thought as well but have not yet found a way to tell qmake that ;) Nov 27 16:49:49 levonmaa: qt.conf Nov 27 16:50:00 Use QT_CONFIG_PATH to point to it Nov 27 16:50:07 well, tried that... Nov 27 16:50:55 qmake seems hell bent on using the path from the native side Nov 27 16:56:12 levonmaa: so we'll need to debug qmake Nov 27 17:33:14 https://gist.github.com/4133101 - if anyone didn't see this on the bitbake list, any opinions? Nov 27 17:37:50 kergoth: I like it.. I started writing something similar but never got as far as this Nov 27 17:45:46 one of those long standing annoyances that never got irritating enough to do much about Nov 27 17:45:50 kergoth: looks good to me Nov 27 17:45:50 heh Nov 27 17:45:57 kergoth: would it make sense to be able to specify the task? Nov 27 17:46:07 kergoth: when reading that thread I was thinking about 2 things Nov 27 17:46:35 bluelightning: hmm, that'd let you examine after task- overrides are applied.. i could see that being useful.. Nov 27 17:46:38 * kergoth ponders Nov 27 17:46:39 kergoth: 1) I usually "cache" -e output because I usually discover that I would like to expect more variables then one Nov 27 17:46:55 kergoth: not often, but sometimes... could be a future improvement Nov 27 17:46:58 * kergoth nods Nov 27 17:47:11 kergoth: also you need to add a copyright statement ;) Nov 27 17:47:19 kergoth: 2) good that your version does not support that groupping as I cannot imagine how such groups should be defined Nov 27 17:47:21 I'm debating trying to turn this into the start of a subcommand based bitbake UI, turn this into 'show' Nov 27 17:47:28 heh Nov 27 17:47:35 bluelightning: oh, right, thanks Nov 27 17:49:02 kergoth: how hard would be to add -b param? Nov 27 18:16:37 Is it possible to disable the debian-style renaming of sub-packages (e.g. when breaking out library files from a large recipe: lighttpd-modules-* style)? Nov 27 19:02:19 gm Nov 27 20:58:52 otavio: it seems that we were also missing uic from our native tool set Nov 27 22:11:28 Is it possible to disable the debian-style renaming of sub-packages (e.g. when breaking out library files from a large recipe: lighttpd-modules-* style)? Nov 27 22:11:32 any thoughts Nov 27 22:11:38 he is sitting next to me Nov 27 22:14:04 i'd say read debian.bbclass and see what variables it obeys. Nov 27 22:14:14 it's what renames packages based on sonames Nov 27 22:17:36 runexe, ping Nov 27 22:18:53 you can disable debian renaming Nov 27 22:19:06 per recipe? Nov 27 22:19:09 it can be disabled globally or or on a per recipe basis Nov 27 22:19:24 (when I debug, I generally disable it globally.. I had what it does) Nov 27 22:19:30 someone is presenting now, so we will ned to work on this in a bit again :) Nov 27 22:19:32 hate? Nov 27 22:19:45 yes.. I think the rename is confusing and unnecessary.. Nov 27 22:20:10 confusing especially to someone reading the recipe.. since the target of the rename isn't known until the recipe builds Nov 27 22:20:23 it's DEBIAN_NAMES = "0" if I remember right Nov 27 22:20:33 hmm..maybe not Nov 27 22:21:03 fray: it's pretty pointless for rpm anyway, given rpm knows about the files packages contain.. and you'd think it'd be pretty trivial to do something similar to debian.bbclass, but which *adds* additional rprovides for the other package managers, but doens't actually rename the packages themselves.. Nov 27 22:21:08 * kergoth ponders Nov 27 22:21:17 ya Nov 27 22:24:11 I didn't realize deb/ipk didn't have the knowledge fo the package name in the provides Nov 27 22:24:30 https://gist.github.com/4157566 Nov 27 22:24:39 first pass, but getting there.. Nov 27 22:24:56 BTW I couldn't find a way to disable it per-package.. there used to be a way from wha i can tell Nov 27 23:02:51 fray, kergoth: Thanks, I would be curious to know why it is no longer possible to disable per-package Nov 27 23:03:08 no idea.. Nov 27 23:03:38 and maybe it can be and I was just looking in the wrong place.. but if I was, it means the in-code documentation is 'lacking' Nov 27 23:18:29 is there anywhere that explains debian package renaming? Nov 27 23:19:19 I'm guesisng the debian policy document.. ;) Nov 27 23:19:28 yeah Nov 27 23:19:33 I knew that was coming Nov 27 23:19:34 but that's likely not what you want Nov 27 23:19:55 I just want to sort of understand what runexe is complaining about :) Nov 27 23:38:07 Crofton: the naming policy essentially seems to be that packages containing (only?) shared libraries must be named lib* Nov 27 23:38:51 ah Nov 27 23:38:52 ok Nov 27 23:39:30 So I think my complaint/question essentially comes down to either complying with that policy, or disabling it within the recipe Nov 27 23:40:07 does it really matter if you just let it rename them? Nov 27 23:40:34 I'm coming around to the thinking that I'm ok with it being renamed ;). Nov 27 23:40:40 yeah Nov 27 23:40:50 the nam estill makes sense? Nov 27 23:41:28 It does beg the question: if rpm-targeting builds *don't* rename, then we would be inconsistent with names between deb/ipk and rpm, and that may be confusing Nov 27 23:53:33 runexe: it isn't lib, it's based on the SONAME in the shared library, whatever that may be. not tied directly to recipe or package naming Nov 27 23:54:03 ya, it reads the first soname out of the recipe and then mundles it into a format that it uses for the rename Nov 27 23:54:24 rpm-targeting builds -do- rename, if the debian rename class is enabled.. (which it is by default) Nov 27 23:54:31 ipk/deb don't have to rename -- if that is disabled.. Nov 27 23:57:09 maybe gnuradio has stupid SONAME's? Nov 27 23:57:18 kergoth: yes, right. Nov 27 23:58:53 that isn't unusual... Nov 27 23:59:12 easy to check.. just use objdump -x look at the SONAME fields.. Nov 27 23:59:18 * fray heads home for the evening Nov 27 23:59:25 gn Nov 28 00:03:53 gn Nov 28 01:02:16 otavio,JaMa: checkout arm-testing branch under my fork of meta-qt5 five Nov 28 01:03:25 hey. did bitbake change the file fetcher on master to account for file permissions? Nov 28 01:04:22 or some other oe-core policy? Nov 28 01:05:09 FILESDIR went away and the like, not sure if anything else has changed Nov 28 01:05:17 actually... mine is a stupid question Nov 28 01:05:53 well, for some reason bitbake is redoing the same package, and when doing do_fetch again the files it cannot overwrite files with r-- permisions Nov 28 01:06:06 sorry for the bad wording Nov 28 01:06:41 otavio,JaMa: it compiles and links under arm now, but it installs the module pri files and mkspecs wrongly Nov 28 01:06:46 for some reason it tries to build u-boot again in the same work folder it already is built Nov 28 01:49:30 is there a way to spit a toolchain out from an image recipe Nov 28 01:53:19 woot Nov 28 01:53:32 anyone here hacked a mdoc to embed a bootloader Nov 28 01:53:42 I don't give a shit about the 256mb storage it has **** ENDING LOGGING AT Wed Nov 28 02:59:59 2012