**** BEGIN LOGGING AT Tue Jan 24 03:00:02 2017 Jan 24 05:32:55 http://arstechnica.com/security/2017/01/ciscos-webex-chrome-plugin-opens-20-million-users-to-drive-by-attacks/ Jan 24 08:13:01 good morning Jan 24 08:56:12 Connecting to rsync.samba.org|144.76.82.156|:80... failed: Connection refused. Jan 24 08:56:13 nice Jan 24 08:57:17 looks like download.samba.org is preferred these days Jan 24 08:57:19 at least, it works Jan 24 08:57:25 ooh, no more svn SRC_URIs on oe-core. Progress! Jan 24 09:59:32 jku: rpm5 is still using cvs, we mask it by creating snapshot tarballs :) Jan 24 10:00:03 * kanavin_home has overextended himself yesterday, and got a headache :( Jan 24 10:00:20 it's okay now, but I'll try to be extra careful today Jan 24 10:04:45 kanavin_home: I overdid things last night and ended up not sleeping well at all :( Jan 24 10:05:37 RP: but now that rss is in, you can take a break perhaps? Jan 24 10:06:06 kanavin_home: heh, now the bug reports start and the work begins! ;-) Jan 24 10:06:31 kanavin_home: but seriously, yes, particularly after I spent some of the weekend on triaging builds Jan 24 10:06:35 RP: but that's what bugzilla is for: it allows you to react later, or much later ;) Jan 24 10:07:27 kanavin_home: The current nasty one looks like go got broken Jan 24 10:25:53 yeah go is interesting is this really correct: Jan 24 10:26:00 GOROOT_FINAL_class-native="${STAGING_LIBDIR_NATIVE}/go" Jan 24 10:26:05 then in install: Jan 24 10:26:17 install -d "${D}${bindir}" "${D}${GOROOT_FINAL}" Jan 24 10:34:25 jku: I wouldn't have said so Jan 24 10:34:55 it seems just weird Jan 24 10:35:33 jku: well, hmm. Its "ok" but it won't ever end up running there, it would have to relocate to whichever sysroot its installed into Jan 24 10:36:56 yeah, and I guess it somehow is. It's just really hard to follow -- I guess this is true for all compiler-type recipes Jan 24 10:37:20 jku: I'm looking at a performance tweak to gcc and its a nightmare Jan 24 10:41:06 in fact I'm tempted to have another gcc code rationalisation attempt Jan 24 10:59:14 RP: i told you to not work all night! :) Jan 24 11:00:06 rburton: I didn't! Jan 24 11:00:33 oh good Jan 24 11:00:36 rburton: setting M2 away and the cycling just left me restless :/ Jan 24 11:01:25 rburton: I tested -next on the new cluster. My patches are buggy and there was a musl error but I forgot to bump the headers so not sure if that is a false positive or not Jan 24 11:04:43 RP: ah, cycling. yeah, late night cycling means i can't sleep too. Jan 24 11:04:54 rburton: well, this was 6-8pm Jan 24 11:05:04 rburton: it got a little competitive though Jan 24 11:30:52 Hello, I need to compile mpeg2enc package and for same enbale it in /meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc Jan 24 11:31:00 but it doesn't get compiled Jan 24 11:31:21 I have added it under PACKAGECONFIG ??= " \ Jan 24 11:34:35 maybe because its not enabled by default it broke Jan 24 11:34:46 i recommend reading the configure output to see why it didn't turn on Jan 24 11:42:36 bah, we were doing so well until what looks like an nfs glitch on the ab :/ Jan 24 11:42:47 again? :-( Jan 24 11:43:24 joshuagl: old cluster: https://autobuilder.yoctoproject.org/main/builders/nightly-mips-lsb/builds/1027 - we see this one now and again, no idea why :( Jan 24 11:43:42 damn it! Jan 24 11:43:45 rburton: RP: I just sent "[OE-core] [PATCH] toolchain-scripts: remove CCACHE_PATH from environment script" which should unblock the morty release once backported Jan 24 11:44:48 oo Jan 24 11:46:14 joshuagl: agreed with your diagnosis. awesome work \o/ Jan 24 11:46:59 joshuagl: seconded, thanks! Jan 24 11:49:26 thanks :-) Jan 24 11:49:34 now to figure out the second part of this… Jan 24 12:01:28 RP: rburton: we'd like to drop the ubuntu14.04 builder from the cluster, any objections? Jan 24 12:02:06 joshuagl: no Jan 24 12:02:34 its LTS release... Jan 24 12:02:38 it is Jan 24 12:03:03 but it's *old* and the only distro we have with that janky old kernel and no systemd Jan 24 12:03:51 it does raise a question about SANITY_TESTED_DISTROS in poky. We have a bunch of old distros in there, two of the Fedora's we list are no longer maintained Jan 24 12:03:57 and thus not tested on the AB Jan 24 12:04:03 joshuagl: needs pruning Jan 24 12:04:03 * joshuagl steps afk, bbs Jan 24 12:04:13 RP: ack, I'll write a patch Jan 24 12:20:16 hi! I versioned my conf/local.conf and am using git submodules to reference the layers. I'd like to put a note on the git revision of the local.conf into ${D}${sysconfdir}/os-release. Is it possible to set a variable value by executing a command line in local.conf? Jan 24 12:22:39 you want a rootfs hook to write the layer manifest into the image. Jan 24 12:23:24 (also its best not to version local.conf, instead have a distro configuration that does all your setup) Jan 24 12:23:25 rburton: okay Jan 24 12:24:38 rburton: I read about that. But it would require the user to edit the local.conf to use the right distro Jan 24 12:25:18 your distro can ship a local.conf.sample that sets that as the default Jan 24 12:25:51 rburton: sure, but I'd need to point bitbake (or whatever) to that distro first, woulnd't I? Jan 24 12:27:16 a custom oe-init-build-env in your distro layer would be sufficient to set the template directory Jan 24 12:28:31 ed: can I use wic on the target to install an OS on an entire disk? It would have to treat, say, /dev/sda as the "image file" and need have enough permissions to write to that. Jan 24 12:35:17 ed: looking at how wic is invoked by do_image_wic, one problem in current wic is that it creates an output directory hierarchy and creates the output file there. Can that be changed to use an existing file already, or does that have to be added? Jan 24 12:44:05 ed: another not-so-nice aspect is that wic will create temporary files for partitions before copying to the final whole-disk file. Jan 24 12:44:31 That's of course necessary when running as non-root on a build host, but can be done better on the target. Jan 24 12:44:39 Okay, let me drop the idea for now ;-} Jan 24 12:48:08 hello, I am getting mkfs.vfat: unable to open /dev/mmcblk0p3: Device or resource busy on an embedded linux system when I try to format the partition on a working board Jan 24 12:48:17 partition does not look to be mounted Jan 24 12:48:32 so the error message seems strange to me Jan 24 12:48:46 rburton: T_UNIX: you don't even need a custom oe-init-build-env, you can create a .templateconf file to tell it where to look for a local.conf.sample Jan 24 12:48:50 rburton: T_UNIX: http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#creating-a-custom-template-configuration-directory Jan 24 12:48:53 can anyone give me advice on how to properly clear a FAT32 partition on embedded linux? Jan 24 12:49:04 I use this partition as a backup for alternative kernel + device tree Jan 24 12:49:38 but currently the board is booted from other partitions so it is not supposed to be using it Jan 24 12:51:08 joshuagl: well that file relies in the top-level Source Directory (poky), which I source from git.yoctoproject.org Jan 24 12:51:52 rburton: I am trying to compile libav package but see this , libav was skipped: because it has a restricted license not whitelisted in LICENSE_FLAGS_WHITELIST Jan 24 12:52:09 ah, setting it as a env var overrides the default path? Jan 24 12:52:15 eduardas_m: have you checked "lsof /dev/mmcblk0p3" Jan 24 12:52:51 rburton : I tried adding LICENSE_FLAGS_WHITELIST = " commercial" this to libav.inc but it didn't work either Jan 24 12:52:57 jku, gives me nothing Jan 24 12:54:54 Ramose__: that goes in local.conf or your distro conf Jan 24 12:55:23 Ramose__: libav says "i have interesting terms", and then you or your distro says 'i understand these complex terms' Jan 24 12:55:53 eduardas_m: I'm really not familiar with mmc but maybe check the device file for whole disk as well if that was just the partition Jan 24 12:55:57 rburton: should I place it in local.conf ? Jan 24 12:56:52 Ramose__: or your distro conf, if you have one Jan 24 12:57:16 jku, the device of the SD card is actually being used because my rootfs in in mmcblk0p2 Jan 24 12:57:16 yeah under build dir, right ? Jan 24 12:57:33 yes Jan 24 12:58:10 but I don't seem to be using mmcblk0p3... does using mmcblk0p2 automatically prevents me from formatting mmcblk0p3? Jan 24 12:59:31 rburton: Still the same issue Jan 24 13:01:29 Ramose__: works here. all i can suggest is to check that you're writing to the right file. Jan 24 13:02:24 let me try again , LICENSE_FLAGS_WHITELIST = " commercial". Actually I put space after inverted commas, so fixing it Jan 24 13:03:41 whitespace shouldn't matter Jan 24 13:03:43 rburton: but for x264 I have got the same issue which I fixed by having LICENSE_FLAGS_WHITELIST = " commercial" in x264_git.bb file Jan 24 13:03:53 again, don't put it in the recipe Jan 24 13:04:32 rburton: yeah but other LICENSE strings are placed in local.conf file Jan 24 13:05:05 there's a distinction between the license of the recipe, and your understanding of the licenses Jan 24 13:05:19 LICENSE and LICENSE_FLAGS are statements about the recipe's licenses, so go in the recipe Jan 24 13:05:35 LICENSE_FLAGS_WHITELIST is *your* statement about what licenses you're willing to accept Jan 24 13:06:06 ok Jan 24 13:06:43 rburton : I just removed it from recipe and its started compiling :) Jan 24 13:15:29 rburton: Also, if I have to add it to my image, I need to put it in image recipe file under image_install ? Jan 24 13:15:46 Ramose__: the package names, not recipe name Jan 24 13:16:08 I mean for libav Jan 24 13:17:38 if you want to add libav packages to the image then yes extend IMAGE_INSTALL with the names of the *packages* (not recipe) that you want to add. Jan 24 13:18:29 ok, Thanks Jan 24 13:29:05 is there anything like a bbclassappend? :D Jan 24 13:43:51 Hi, I have a question Jan 24 13:44:24 I have my own layer - meta-mycompany - where I want to define an image which should be an extension of one of the images from meta-raspberrypi Jan 24 13:45:02 How do I do this? How do I include a bb file inside my layer from an external layer? Jan 24 13:45:09 Or should I look into bbappend? Jan 24 13:47:27 BaloneyGeek|work: i'd recommend just copying the contents, but if you really want to base off the image then your image recipe can just use require to pull in the other image Jan 24 13:48:18 rburton: what should the path to the require be? Jan 24 13:48:30 Relative using . and .. ? Jan 24 13:49:23 you might be able to just use the full path in the layer Jan 24 13:49:37 ie grep has this example Jan 24 13:49:38 meta/recipes-rt/images/core-image-rt-sdk.bb:require recipes-core/images/core-image-minimal.bb Jan 24 13:50:04 yeah, relative to BBPATH so meta-raspberrypi/blah/blah/image.bb Jan 24 13:50:45 So I've got poky/build/ which is my build dir Jan 24 13:50:59 And then poky/extra-metas/meta-raspberrypi Jan 24 13:51:11 And poky/extra-metas/meta-mycompany Jan 24 13:52:08 Awesome, it works :D Jan 24 13:52:22 Just specifying a relative path with ..'s Jan 24 13:52:46 no need to use .. Jan 24 13:53:29 hello everyone Jan 24 13:56:14 anyone have an idea how to build Qt5 in both static and shared libraries please ? Jan 24 13:56:28 i think that the default is shared libraries Jan 24 13:56:41 are you using poky? Jan 24 13:56:48 rburton: yes Jan 24 13:56:55 poky turns off static libraries Jan 24 13:57:13 rburton: i've just setup a complete env, and since it will take half of the day to build Qt i'd like to be sure Jan 24 13:57:38 rburton: isn't there any way to make an exception ? besides building qt manually Jan 24 13:58:11 i'd start by copy/pasting poky.conf and started to edit your new distro config to suit your needs. step one would be removing no-static-libs.inc. Jan 24 13:58:42 of course qt may be ignoring that, how are you sure its not building static libraries? they get packaged into a separate package to the shared libraries Jan 24 13:58:48 (-dev vs -staticdev) Jan 24 13:59:25 rburton: trying to trust my memory was using poky every day the past year Jan 24 13:59:52 rburton: but as i said, i'll build and see the result tomorrow Jan 24 14:02:04 rburton: thank you so much btw Jan 24 14:52:40 http://autobuilder.yoctoproject.org/pub/nightly/ is down Jan 24 14:52:58 rburton: Just now build gstreamer1.0-plugins-imx package but could not find its respected dir inside build/tmp/work Jan 24 15:40:31 something changed in the last day or two where dbus-native isn't putting a single file into the sysroot. Jan 24 15:41:38 shows up as an issue in building xfce4 bits as follows: Jan 24 15:41:43 | checking for dbus-binding-tool... no Jan 24 15:41:43 | *** The program "dbus-binding-tool" is required to build. Jan 24 15:42:10 and you're sure the recipes have a dependency on dbus-native? Jan 24 15:43:16 paul@yow-cube1:~/poky/build$ bitbake dbus-native > /dev/null Jan 24 15:43:16 paul@yow-cube1:~/poky/build$ echo $? Jan 24 15:43:16 0 Jan 24 15:43:16 paul@yow-cube1:~/poky/build$ find tmp/sysroots -name '*dbus*' Jan 24 15:43:16 paul@yow-cube1:~/poky/build$ Jan 24 15:43:34 per recipe sysrrots? Jan 24 15:43:37 that takes dependencies out of the picture, I think. Jan 24 15:44:25 in an "old" build (as in 3 days) there are about 300 files in the sysroot matching the above "find". Jan 24 15:44:38 is there anything in sysroots? Jan 24 15:45:08 interesting. it is empty. Jan 24 15:45:10 indeed Jan 24 15:45:14 welcome to per-recipe sysroots Jan 24 15:45:15 wtf... Jan 24 15:45:29 there's an epic commit message in the log if you want to read it Jan 24 15:45:42 was not aware of them. guess I've some reading to do Jan 24 15:45:43 tldr: missing dependencies are now fatal Jan 24 15:46:16 ok, that would explain why this recently appeared Jan 24 15:46:16 ie just because normally dbus-native would have been built on the way to build xfce-foo, unless its in DEPENDS xfce-foo won't have it in its own sysroot Jan 24 15:46:42 RP: why does tmp/sysroots exist? Jan 24 15:46:48 it appears during a build but is obviously empty Jan 24 15:47:17 will this stop rpm-native from fork bombing if which isn't on the build machine? Jan 24 15:47:20 yah, if it wasnt there at all, then I'd probably clued in something was up. :) Jan 24 15:48:38 Crofton|work: doubt it Jan 24 15:49:24 toobad Jan 24 15:49:31 pain in the ass to find Jan 24 15:49:45 the Fedora 23 docker container doesn't have which Jan 24 15:49:52 did you send a patch to add a DEPENDS, or make it bail obviously? Jan 24 15:49:54 this is how I know it is needed for a bui;d Jan 24 15:54:00 Crofton|work: openssl has a little py fragment to check that an essential perl module is on the host, as otherwise that fails to generate some C correctly and the errors are mysterious Jan 24 15:54:02 rpm should do that Jan 24 15:57:17 * kanavin has sorted the sdk *and* sdk_ext support with dnf... hopefully! Jan 24 15:57:45 that was the cause of yesterdays headache, and not a 'virtual' one at that Jan 24 16:00:41 rburton, clearly this is very very rare :) Jan 24 16:07:15 rburton, thanks for the clue ; it worked after I added dbus-glib-native to DEPENDS. Jan 24 16:08:05 paulg: you'll find a few more no doubt. basically now each build gets only the dependencies it actually asks for. Jan 24 16:09:06 yep, I've restarted and put off writing the commit log until all the other xfce4 chunks build successfully. :) Jan 24 16:14:53 rburton: I haven't really dared look for minor issues like that yet ;-) Jan 24 16:19:21 there's a reasonabe number of mentions to TMPDIR/sysroots/ in the classes still Jan 24 16:19:32 all of which look like they should be some other variable Jan 24 16:22:51 i take it back, the classes are mostly good apart from cross-canadian.bbclass Jan 24 17:56:18 so I am reading about the package management system of yocto. It looks like smart is expecting to use a repo for all packages. there is no provision for a local install of an rpm? Jan 24 18:09:09 mcudev: first, there is no 'package management system of yocto' -- you can decide whether you want rpm, ipk, or deb, whichever you prefer, but it installs packages that are built by recipes, not random packages you find from elsewhere, though there are options for that Jan 24 18:12:25 yeah, i know that Jan 24 18:12:53 I get that yocto isn't a distro, it makes a custom img Jan 24 18:13:06 but smart is part of the yocto project right? Jan 24 20:07:55 RP: the recipe-sysroot-native/usr/bin/../lib/libncursesw.so.5: file not recognized: File format not recognized issue is showing up in more than 1 recipes Jan 24 21:17:46 ok Jan 24 21:17:46 | Traceback (most recent call last): Jan 24 21:17:46 | File "setup.py", line 127, in Jan 24 21:17:46 | from setuptools import setup, Distribution, Extension Jan 24 21:17:46 | ImportError: No module named setuptools Jan 24 21:17:46 is this recipe sysroot thing? and suggested fixes? Jan 24 21:18:59 Crofton|work: does this recipe inherit setuptools? Jan 24 21:20:52 inherit pypi setuptools Jan 24 21:20:53 require python-cffi.inc Jan 24 21:28:49 RP: I was talking too early...rebuild from sstate for another machine gives Jan 24 21:28:51 | checking for arm-oe-linux-gnueabi-gcc... arm-oe-linux-gnueabi-klcc --sysroot=/tmp/build/tmp-glibc/work/akita-oe-linux-gnueabi/kexecboot-klibc/0.6-r0/recipe-sysroot Jan 24 21:28:51 | checking whether the C compiler works... no Jan 24 21:29:14 have to -c cleansstate and rebuild klcc-cross then it works Jan 24 21:29:37 let me do a build from scratch to confirm Jan 24 21:39:53 RP: it seems clang issue thats coming to front after rss, clang is adding paths relative to itself to -L during linking and libncursesw.so is a linker script so it will pick it up and hence the problem Jan 24 21:40:36 key is that it should not add self relative paths to -L and -I to find sysroot Jan 24 21:40:40 for target Jan 25 00:08:26 khem: ah, I can imagine relative paths getting a bit messed up with these changes :( Jan 25 01:06:08 I've seen twice today, that hostname.1 from inetutils doesn't properly use update-alternatives so it can co-exist with the hostname in coreutils. Once for x86-64, once for arm64. Jan 25 01:06:16 [log_check] update-alternatives: Error: not linking /home/paul/poky/build-arm64/tmp/work/qemuarm64-overc-linux/cube-graphical-builder/0.2-r0/rootfs/usr/share/man/man1/hostname.1 to /usr/share/man/man1/hostname.1.coreutils since /home/paul/poky/build-arm64/tmp/work/qemuarm64-overc-linux/cube-graphical-builder/0.2-r0/rootfs/usr/share/man/man1/hostname.1 exists and is not a link Jan 25 01:06:56 1st time I cleaned the pkg and it magically went away after that. Somewhat disconcerting. Jan 25 01:07:47 the recipe seems to treat hostname just the same as tcpdump or any other binary. **** ENDING LOGGING AT Wed Jan 25 03:00:01 2017