**** BEGIN LOGGING AT Wed Feb 03 02:59:58 2016 Feb 03 03:00:42 " Feb 03 03:00:42 WARNING: Failed to fetch URL ftp://invisible-island.net/ncurses/current/ncurses-5.9-20150329.tgz, attempting MIRRORS if available Feb 03 03:00:45 WARNING: Failed to fetch URL http://kernel.org/pub/linux/kernel/v4.x/linux-4.1.tar.xz, attempting MIRRORS if available Feb 03 03:00:48 ERROR: Fetcher failure: Fetch command failed with exit code 4, output: Feb 03 03:00:50 wget: unable to resolve host address 'kernel.org' Feb 03 03:00:53 ERROR: Function failed: Fetcher failure for URL: 'http://kernel.org/pub/linux/kernel/v4.x/linux-4.1.tar.xz'. Unable to fetch URL from any source. Feb 03 03:00:56 ERROR: Logfile of failure stored in: /home/jackzhang1992/poky/build/tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/linux-libc-headers/4.1-r0/temp/log.do_fetch.8031 Feb 03 03:00:59 ERROR: Task 961 (/home/jackzhang1992/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.1.bb, do_fetch) failed with exit code '1' Feb 03 03:01:02 WARNING: Failed to fetch URL http://ymorin.is-a-geek.org/download/kconfig-frontends/kconfig-frontends-3.12.0.0.tar.xz, attempting MIRRORS if available Feb 03 03:01:05 ERROR: Fetcher failure: Fetch command failed with exit code 4, output: Feb 03 03:01:07 wget: unable to resolve host address 'ymorin.is-a-geek.org' Feb 03 03:01:10 ERROR: Function failed: Fetcher failure for URL: 'http://ymorin.is-a-geek.org/download/kconfig-frontends/kconfig-frontends-3.12.0.0.tar.xz'. Unable to fetch URL from any source. Feb 03 03:01:13 ERROR: Logfile of failure stored in: /home/jackzhang1992/poky/build/tmp/work/i686-linux/kconfig-frontends-native/3.12.0.0-r0/temp/log.do_fetch.8067 Feb 03 03:01:16 ERROR: Task 728 (virtual:native:/home/jackzhang1992/poky/meta/recipes-devtools/kconfig-frontends/kconfig-frontends_3.12.0.0.bb, do_fetch) failed with exit code '1' Feb 03 03:01:19 WARNING: Failed to fetch URL http://dotat.at/prog/unifdef/unifdef-2.10.tar.xz, attempting MIRRORS if available Feb 03 03:01:22 NOTE: Tasks Summary: Attempted 152 tasks of which 0 didn't need to be rerun and 2 failed. Feb 03 03:01:25 it seems most of them are fetcher failures Feb 03 03:02:15 I just follow the README file in the "meta-raspberrypi" directory to configure Feb 03 03:02:38 my rpi board is raspberrypi2 B+ Feb 03 03:02:48 Thanks Feb 03 03:03:17 jackzhang1992: seems that files aren't in the servers... Feb 03 03:03:26 what release are you using? Feb 03 03:03:44 I guess the latest version Feb 03 03:03:59 jackzhang1992: i can download http://dotat.at/prog/unifdef/unifdef-2.10.tar.xz may be in your network Feb 03 03:04:14 also http://ymorin.is-a-geek.org/download/kconfig-frontends/kconfig-frontends-3.12.0.0.tar.xz' works Feb 03 03:04:53 alimon, yes ,I can download the file, too. that's the most weird thing! Feb 03 03:05:01 uhmmm Feb 03 03:05:27 jackzhang1992: if you try to download one by one, bitbake kconfig-frontends-native -c fetch Feb 03 03:05:31 and see what happens Feb 03 03:06:15 which diretory should I put these files? Feb 03 03:06:27 jackzhang1992: i mean download using bitbake, Feb 03 03:06:31 bitbake kconfig-frontends-native -c fetch Feb 03 03:06:57 ok, I can try it now! Feb 03 03:06:58 Thanks Feb 03 03:07:38 may be your network gets exhausted with multiple requests.... Feb 03 03:07:42 i'm guessing... Feb 03 03:07:53 jackzhang1992: are you using wireless? Feb 03 03:08:08 i see this behaviour using low wireless signal Feb 03 03:08:11 yes, I am using wireless,and the linux is run under vmware Feb 03 03:08:20 jackzhang1992: may be is the problem Feb 03 03:08:39 when i had low wifi this kind of errors appears Feb 03 03:09:00 so how about I connect the cable to my computer? Feb 03 03:09:09 and try bit bake again? Feb 03 03:09:14 jackzhang1992: good idea Feb 03 03:09:28 for discard the wifi thing Feb 03 03:09:45 ok the result of "bitbake kconfig-frontends-native -c fetch" Feb 03 03:09:52 comes out Feb 03 03:10:16 "NOTE: Preparing RunQueue" Feb 03 03:10:16 NOTE: Executing RunQueue Tasks Feb 03 03:10:16 NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded. Feb 03 03:10:25 it seems to work Feb 03 03:10:52 really? Feb 03 03:11:07 so now I could bitbake rpi-hwup-image again? Feb 03 03:11:35 ok,now, I will connect the cable, and try the bitbake again Feb 03 03:12:31 yep Feb 03 03:12:32 good idea Feb 03 06:17:05 Hi, I have recipe version for example 2.8.3.0 but on some reason I need just the 2.8.3 - part. is there a way to divide the ${PV} to get that? it can end up in different variable. Feb 03 06:17:52 I need to give that 2.8.3 part to Makefile to be used in compilation Feb 03 07:13:50 teemu_: you can use some python magic Feb 03 07:14:14 e.g. see icu_download_version in icu recipe at meta/recipes-support/icu Feb 03 07:16:14 yes, I actually did just that Feb 03 07:28:07 Hi. I'm making other layer recipes to be systemd compatible from my layer. I'm doing this by adding .bbappend recipes from my layer. I've placed all the .service files in a directory called 'files' in my layer Feb 03 07:28:46 I'm facing this error --> SYSTEMD_SERVICE_openbox value openbox.service does not exist Feb 03 07:29:13 How do I specify the directory in which .service files should be searched for? Feb 03 07:36:31 you need to add FILESEXTRAPATHS Feb 03 07:37:06 and add these new files to src uri Feb 03 07:37:21 then install them to Feb 03 07:37:35 systemd_unitdir Feb 03 07:38:58 FILESEXTRAPATHS_prepend := "${THISDIR}/files:" Feb 03 08:30:40 @khem It builds. Thank you :) Feb 03 08:34:46 good morning Feb 03 09:25:05 I've 2 versions of reciepes for chromium. How do I know which bitbake file is being used? Feb 03 09:28:53 rtr_: bitbake -s Feb 03 09:50:28 @CTtpollard THanks Feb 03 09:51:43 rtr_: np Feb 03 10:51:46 I wonder is pybootchartgui meant to work on a headless server. Tried using it on my buildstats and get a segmentation fault. Feb 03 10:52:53 (and a lot of failed assertions as warnings) Feb 03 10:57:10 ok, all I needed to do is to specify an output file :p Feb 03 12:26:39 what's the point of d.expand("${PACKAGELOCK}") in package.bbclass? won't ${PACKAGELOCK} be expanded even before the function is called? Feb 03 12:26:55 other variables seem to be expanded within string literals Feb 03 12:30:15 is it normal that sstate cache contains no siginfo files for _configure or _compile and thus compile steps are always redone? it seems to contain just _patch, _fetch, _unpack, _populate_lic Feb 03 12:35:55 unless it's set at a later point or something... Feb 03 12:37:48 Ulfalizer: for python it's inconsistent whether expansion happens before the source is executed, and we're making it so it's not Feb 03 12:38:28 ah, good to know Feb 03 12:42:40 do you have any idea how the following ad-hoc QA check could cause package contents to differ even though the QA check never triggers? https://dpaste.de/CmL1 Feb 03 12:43:25 the only thing i can think of is that something might be getting expanded and causing side effects somehow, or that some extra problematic dependencies are detected Feb 03 12:43:50 i guess i should rewrite it to use d.expand() too Feb 03 12:47:36 likely a rebuild discovering more dependencies in the sysroot and auto-enabling? Feb 03 12:48:41 i built with a fresh sysroot in both cases Feb 03 12:49:59 i'll try just adding a comment instead of that patch as a sanity check... Feb 03 13:32:45 Hi guys. I'm trying to add Webmin inter-module dependencies (some modules depend on other modules): I've tried using "d.setVar('RDEPENDS_webmin-module-time', 'webmin-module-webmincron')" right after line 147 http://cgit.openembedded.org/meta-openembedded/tree/meta-webserver/recipes-webadmin/webmin/webmin_1.750.bb#n147 but I still obtain images with webmin-module-time but without webmin-module-webmincron. Should I do it Feb 03 13:32:46 in a different way? Am I doing something wrong? Feb 03 13:40:30 when I have multiple packages generated from one recipe, which one will do_install be applied to? $PN? Also, is it possible to customize through something like "do_install_$PN-foo" or so? Feb 03 13:49:54 install happens before packages exist as a concept Feb 03 13:50:03 that happens in do_package, which is after do_install Feb 03 13:50:19 lpapp: AFAIK the do_install task is recipe related. Package split enters stage at a later step when 'package split' step is performed Feb 03 13:59:46 ok, so if I have got like 4-5 packages in a recipe, will do_install(_append) execute when I install one of those 4-5 packages with opkg? Feb 03 13:59:55 i.e. when I do not flash the whole rootfilesystem Feb 03 14:01:00 lpapp: do_install is execute by bitbake when 'cooking' your recipe, not by the package manager at the OS level. Feb 03 14:02:12 riiiiight, now I remember what bluelightning told me back then, sort of. Feb 03 14:02:24 there was some other thing to do that executes as a post-maintainer script. Feb 03 14:02:32 http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-tasks-install Feb 03 14:04:21 lpapp: you mean 'pkg_postinst'? Feb 03 14:05:04 yes, I think so. Feb 03 14:05:17 I hope that it is available in our old Yocto Feb 03 14:06:45 pkg_postinst has always existed Feb 03 14:07:17 I see. Feb 03 14:07:37 Thank; I am still unsure whether I understand my problem. Feb 03 14:07:39 +s Feb 03 14:08:00 I have two packages foo and bar that install files into /opt/baz Feb 03 14:08:07 if you want to run something at package install time, then pkg_postinst_${PN} is what you want to write Feb 03 14:08:27 and we currently do chmod in bar (which depends on foo), but apparently it does not chmod the whole /opt/baz Feb 03 14:08:50 what we want is that the permissions are right even when there is a package upgrade without flashing/. Feb 03 14:08:52 that's because you have a race in install order Feb 03 14:09:00 set the permissions right in the recipe in the first place? Feb 03 14:09:13 I thought do_install_append was helpful for that, but the problem is that if foo is installed, it comes with the "original" permissions Feb 03 14:09:28 therefore, it breaks what the origin installation (flashing) did with chmod Feb 03 14:09:32 original* Feb 03 14:10:00 but even reinstalling bar (which depends on foo that breaks stuff on update) does not solve it all as it seems to only chmod its own files. Feb 03 14:10:18 but since it does that, I do not know how if do_install(_append) does not run on package installation Feb 03 14:10:38 perhaps it is run in the Yocto environment and the package content is already chmodded, and opkg install just copies the files with the right permissions over. Feb 03 14:11:22 so I could probably chmod in both foo and bar, but is that the recommended way through do_install(_append)? Feb 03 14:11:30 or is it better to use pkg_postinst? Feb 03 14:11:41 I am a bit confused which one to use for package upgrades without complete image flashing. Feb 03 14:14:08 ultimately, the best way would probably be doing this chmoding in the software's target rather than in Yocto, but this is not how it is currently constructed. Feb 03 14:21:58 lpapp: pkg_postinst runs both on install and on upgrade Feb 03 14:30:49 diego_r: I thought do_install(_append) also runs in the sandbox? Feb 03 14:31:21 so if I have a chmod command in that function, the packaged files will be all coming with the right permissions? Feb 03 14:33:51 lpapp: yes, the do_install (append or not append) will act on 'image' folder. The chmod will act there and the mask changes should be reflected also on the package. owner and group generally are not preserved though. Feb 03 14:35:06 don't know if permission mask is updated on package upgrade, but I think it is Feb 03 14:35:29 yes, cause it is just copy, I guess Feb 03 14:35:29 is the file permission in you package correct or broken? Feb 03 14:35:51 inside the deb / rpm / ipk / whatever, I mean Feb 03 14:47:19 but strangely enough, it is ok for bar which depends on foo, but not for foo Feb 03 14:47:44 but since foo also gets into the same image directory in the Yocto sandbox before packaging, I wonder why installing foo puts the original permissions back for those files. Feb 03 14:47:51 I wonder if anyone can explain it to me. Feb 03 14:49:36 I mean bar does chmod foo:foo on /opt/baz Feb 03 14:49:43 both foo and bar install files into /opt/baz Feb 03 14:50:06 and what is happening is that when I do opkg install foo, the original permissions get back to the files installed by foo, so it will not be foo:foo Feb 03 14:50:14 I know it is kind of complex to imagine, so I am happy to clarify. Feb 03 14:50:32 and yes, we probably do the wrong thing by chmoding in a recipe, but that is not a discussion for today, I imagine. Feb 03 14:51:37 based on the what you wrote above, and assuming foo and bar install files into the same image directory in order (first the dependency foo and then bar), I though it should just work when I install foo manually with opkg Feb 03 14:52:01 because both packages install the files into this image directory, bar (which is done later than foo) does chmod for the whole $image/opt/baz Feb 03 14:52:20 so when the foo package is created from there, it is gonna have the right permissions... sorry for the too much details. Feb 03 14:53:15 lpapp: it should Feb 03 14:53:39 Hi Feb 03 14:54:07 What is the best way to change the gcc version used to create an image? Feb 03 14:54:21 Hi! I'm trying to get a busybox -based telnetd to start automatically with systemd... the binary is compiled, the latest test .bbappend creates a busybox-telnetd.service in /lib/systemd/system however i don't understand how or why it isn't symlinked into /etc/systemd/system/multi-user.target.wants as it should be normally. The bbappend looks like this http://pastebin.com/4mVCi9TY, the service file looks like this: http://pastebin.com/FBUy9qD6 Feb 03 14:54:29 is it enough to set PREFERRED_VERSION_gcc = 4.8 ? Feb 03 15:00:37 blotunga: i had the the same problem Feb 03 15:00:54 fl0v0: cool, any tips? Feb 03 15:01:30 i'm pretty unfamiliar yet with yocto's intricacies Feb 03 15:01:36 i looked in the systemd.bbclass and the postinstall routine didn't seem to do what i wanted Feb 03 15:01:50 so i just overwrote the routine Feb 03 15:01:58 but no warranty on this Feb 03 15:02:22 mom i post it on pastebin Feb 03 15:02:53 http://pastebin.com/8KfzdVPE Feb 03 15:02:56 i wonder why/how it works for other services Feb 03 15:04:12 so you changed restart into enable? Feb 03 15:04:21 yeah now i remeber in the original systemd.bbclass it only uses systemctl restart ${SYSTEMD_SERVICE} Feb 03 15:04:26 diego_r: is the image directory removed once the packages are created from it? Feb 03 15:04:33 anyone had trouble logging in into an image with systemd? the only thing I see is 'Cannot ex' and then it goes back to login prompt Feb 03 15:04:35 yeah Feb 03 15:05:04 ok, but why does it work with other services and not with the telnet Feb 03 15:05:13 i have no idea :) Feb 03 15:05:32 i didnt investigate further after it worked for me Feb 03 15:05:56 :) Feb 03 15:06:40 I wonder if the Type of the service has to do something with it Feb 03 15:06:43 sounds pragmatic Feb 03 15:08:27 diego_r: is the image directory removed once the packages are created from it? Feb 03 15:09:33 or is that the package directory before split which in turn means then that each recipe has its own sandbox? That would explain why chmoding in bar that depends on foo would not work for foo. Feb 03 15:09:38 if the image directory is not shared. Feb 03 15:09:51 (or wherever they go before packaging) Feb 03 15:10:53 I'm confused by MACHINE_FEATURES vs IMAGE_INSTALL, I wanted to install 'wifi' into my image so I added it to MACHINE_FEATURES to get iwconfig (etc) installed. bitbake choked when I added it to IMAGE_INSTALL_append. In my way of thinking, IMAGE_INSTALL would be what I'd want installed into my image? Feb 03 15:12:39 I think that I understand DISTRO_FEATURES_append as directing the build to place packages into the deb repository for the end-user to choose to install them later. Feb 03 15:13:04 T0mW: IMAGE_INSTALL is binary packages Feb 03 15:13:10 IMAGE_FEATURES is image features Feb 03 15:13:17 distro features and machine features have nothing to do with images Feb 03 15:13:24 they're global, and affect policy Feb 03 15:14:04 kergoth, so, if I wanted the wireless tools installed into my image, I should add 'wifi'to my IMAGE_FEATURES ? Feb 03 15:14:15 if your'e using packagegroup-base, then adding something to both machine and distro features will likely get the bits needed to support it added to your images by default Feb 03 15:14:41 in the case of wifi, adding the machine feature will get the packagegroup emitted for wireless support, but it won't get added to hte deps of packagegroup-base-extended unless it's also in distro features Feb 03 15:15:20 http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#ref-features-image -> I cannot see wifi there. Feb 03 15:15:23 generally speaking, distro, machine, and image are orthgonal axes that work with any combination of the others Feb 03 15:15:41 correct, it's not an image feature Feb 03 15:16:35 https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/packagegroups/packagegroup-base.bb#L35, https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/packagegroups/packagegroup-base.bb#L74 Feb 03 15:16:53 there's also added logic based on the distro feature and the availability of expandable buses -- https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/packagegroups/packagegroup-base.bb#L120-L121 Feb 03 15:17:10 it didn't, I included the packagegroup-base into my image, then added 'wifi' to DISTRO_FEATURES_append. Looking at package-group-base, it has a test for DISTRO_FEATURES against 'wifi'. I assumed that it would then place the 'wifi' group of packages into my image? Feb 03 15:17:48 It did add the packages into my pile of deb's Feb 03 15:18:15 kergoth, thanks Feb 03 15:18:16 don't know what to tell you, if wifi is in both machine and distro features, it'll eend up pulled in by packagegroup-base Feb 03 15:18:20 read the code yourself Feb 03 15:18:30 perhaps use bitbake -e to make sure *_FEATURES are set the way you think they are :) Feb 03 15:18:38 can also examine the deps in the packagegropu-base recipe to check sanity Feb 03 15:18:56 kergoth, missing, on my part, was adding it to machine_features. Feb 03 15:19:32 ah, 'bitbake -e'. that is something else I was looking for. Feb 03 15:20:55 how does the MACHINE_ differ from the IMAGE_ ? I would think that MACHINE_ would dictate really low level stuff like firmware. Feb 03 15:20:56 'bitbake -e' will show global metadata, bitgbake -e yourrecipe will show the metadata for that recipe. also shows what files were parsed, and the history of modifications to each variable Feb 03 15:21:03 it does Feb 03 15:21:12 adding wifi to MACHINE_FEATURES is stating your hardware supports wifi Feb 03 15:21:21 i.e has a wireless chip, or a bus that can use one Feb 03 15:21:28 than distro controls whether you want to acxtually support this Feb 03 15:22:04 then the image is package selection, normally separated from machine and distro, but packagegroup-base is special Feb 03 15:22:28 Then, the IMAGE_ is more a gross high level config, such as 'dev' or 'alsa', but IMAGE is not a package level control? Feb 03 15:22:50 shouldn't the "WantedBy=multi-user.target" "magically create the symlink for systemd? Feb 03 15:23:00 IMAGE_FEATURES by definition controls aspects of the image's construction Feb 03 15:23:04 it's not 'high level' in any form Feb 03 15:23:10 there are features which select groups of packages as a convenience Feb 03 15:23:34 aha, got it Feb 03 15:24:01 https://db.tt/F3bHEZRe might help, though it's probably a little out of date, and never got polished, wrote it up a long time ago Feb 03 15:24:10 IMAGE_xxx is for very specific features, not as flexible as the MACHINE_xxx Feb 03 15:24:47 LOL, yeah, I've got a new job and doing agile for the first time. I know about documentation (hates it) Feb 03 15:25:35 kergoth, thanks for clearing all that up. Feb 03 15:26:40 MACHINE affects the entire build. IMAGE affects the images only, and usually just the one where it's defined. Feb 03 15:26:47 it's less about flexibility than it is about scope Feb 03 15:26:55 np Feb 03 15:27:03 afk Feb 03 16:06:08 khem: there? Feb 03 16:14:22 fl0v0: your idea didn't worked for me Feb 03 16:14:50 hmmm Feb 03 16:14:56 mom Feb 03 16:15:26 can you paste the link to your recipe file again? Feb 03 16:19:26 http://pastebin.com/4mVCi9TY Feb 03 16:33:44 fl0v0: any ideas what I'm doing wrong? Feb 03 16:33:57 ah sry was away mom Feb 03 16:35:08 np Feb 03 16:38:33 blotunga: do you have SYSTEMD_AUTO_ENABLE_${PN}-telnetd = "enable" in your recipe? Feb 03 16:38:45 http://pastebin.com/4mVCi9TY Feb 03 16:38:46 nope Feb 03 16:38:50 only this Feb 03 16:39:11 yeah ok Feb 03 16:39:20 let me try Feb 03 16:39:56 did you change the postinstall function in systemd.bbclass itself? Feb 03 16:40:42 the difference to my recipe is that i have inherit systemd before all the SYSTEMD_* stuff Feb 03 16:41:43 and i overwrote the function in the recipe itsself so i dont change it for all other recipes which are using it Feb 03 16:45:00 i've tried inherting systemd everywhere Feb 03 16:45:40 and I tried overwriting in the recipe, but since it didn't worked I also tried it in the systemd.bbclass (which is only for testing)... i wouldn't leave it like that Feb 03 16:45:59 how could i add to my recipe something like do_configure_append(){ sed -e foo -i bar} if a distro feature "systemd" is enabled? Feb 03 16:46:01 I just want it see working Feb 03 16:46:36 fl0v0: still nothing in /etc Feb 03 16:46:44 I think I'll call it a day for today Feb 03 16:46:54 k :/ Feb 03 16:46:56 and tomorrow try with a fresh perspective :( Feb 03 18:07:15 H, anyone here knows how to change the gcc version used to create an image? Feb 03 18:07:59 Spulit: set GCCVERSION Feb 03 18:08:07 default is in meta/conf/distro/include/tcmode-default.inc:GCCVERSION ?= "5.%" Feb 03 18:09:18 JaMa: Thanks! This will change the version for the whole toolchain, right? Feb 03 18:09:53 depends on what you mean by whole toochain Feb 03 18:10:00 it changes only version of gcc Feb 03 18:10:48 JaMa: Yes, I noticed now that in the same file the rest of the variables (like PREFERRED_VERSION_gcc_*) are all set based on GCCVERSION Feb 03 18:33:44 rburton: I am able to reproduce the glibc issue Feb 03 18:34:13 [ Feb 03 18:41:05 rburton: can you try https://gist.github.com/a30319d758439f80e392 Feb 03 18:41:10 in your sandbox Feb 03 18:46:02 khem`: sure, will try now Feb 03 18:48:52 actually I am trying another fix where I am just remove -fstack-protector-strong from LDFLAGS for glibc and leaving in the rest Feb 03 18:48:56 its less intrusive Feb 03 18:54:30 rburton: I updated kraj/pu branch on contrib tree Feb 03 19:39:33 khem`: of course now i can't replicate the breakage Feb 03 19:50:13 rburton: cool Feb 03 19:50:44 there was need to remove ssp options from link step Feb 03 19:52:52 lates pu branch should be good Feb 03 19:53:04 I am doing musl and uclibc builds to see if it all gels well **** ENDING LOGGING AT Thu Feb 04 02:59:59 2016