**** BEGIN LOGGING AT Thu Jan 26 03:00:02 2017 Jan 26 04:46:29 hi all, if I build Yocto e-sdk (based on Morty) on a RHEL7.x version, can I use it on older RHEL version? Jan 26 04:46:47 i am planning to use locked-sigs for native packages Jan 26 07:14:57 Greetings, I am trying to build an Image using Yocto Poky version that contains the tomcat-8. I have tried couple of recipes from openembedded repo but its not working as its only having servlet and its also old version. Can anyone suggest me a working recipes that can build tomcat-8? A quick help or a hint will be very helpful. Thank you. Jan 26 07:19:05 Robbin: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=tomcat suggests that there is nothing noteworthy out in the wild Jan 26 07:22:30 LetoThe2nd: Thank you very much for quick reply. Really appreciate it. Yes thats correct the default servlet comes from the tomcat-5.5 and its not the full tomcat web server. I am assuming there should be a way to have/include the full tomcat as a web server. Jan 26 07:23:54 Robbin: there obviously is a way, as its only software. its just that nobody paved that way yet for you (e.g. published a recipe) Jan 26 07:24:14 Robbin: so you'll probably have to take one of those and modify/extend until it fits your needs. Jan 26 07:24:47 LetoThe2nd: Yes thats right. Its thing of putting all things in the recipe. Jan 26 07:25:52 LetoThe2nd: The way i was assuming that If i can get a hint to include the full blown server its doesnt matter if its old release. Jan 26 07:26:48 LetoThe2nd: At the end as you suggest I am also gonna do it as I am playing around it ...but was thinking can get a help from the Gurus like you :) Jan 26 07:27:36 Robbin: um, what do you expect? looking at the recipe, its rather small anyways: http://git.yoctoproject.org/cgit/cgit.cgi/meta-java/tree/recipes-core/servlet-api/servlet2.4_5.5.26.bb?h=master Jan 26 07:28:17 Robbin: but as there is java involved, things might be complicated. Jan 26 07:28:29 * LetoThe2nd cannot help there much, for a reason Jan 26 07:29:49 LetoThe2nd: Yeah thats fine ... and for the JAVA it was just matter of compiling with the correct JVM and I have done it.. Jan 26 07:30:46 LetoThe2nd: I already have a working JAVA platform in the Yocto recipes and Now was trying to include the tomcat. Jan 26 07:35:07 Robbin: like i said, i really can't help you there. Jan 26 07:38:00 LetoThe2nd: No problem. I really appreciate it. Jan 26 07:38:33 LetoThe2nd: will see if i can get a help from here and will continue to my test with it. Jan 26 07:39:04 LetoThe2nd: Thankyou. Jan 26 07:40:10 Robbin: have fun Jan 26 07:40:57 LetoThe2nd: yeah compiling this kind of stuffs alwyas being a fun! Jan 26 09:25:11 hi! What's the recommended way to specify the rootfs image I want packaged with the meta-toolchain-qt5 recipe? Jan 26 09:25:21 bbappend? Jan 26 09:46:40 i *still* have no idea why meta-toolchain-qt exists as a thing Jan 26 09:50:12 why would gnulib decide to write ITS OWN STDINT.H Jan 26 09:52:03 you know, all those users demanding C90 support :) Jan 26 09:52:20 Jan 26 09:54:48 Hi! Is there any known "limitation" to what an unpdated eSDK could deliver? More precisely: should I assume any particular "change" in the eSDK content/setup not being suitable to be applied through eSDK updates? Adding recipes through new dependencies seems the most frequent/expected use-case, but I'm wandering what I should expect i.e. by removing recipes from the target image's dependencies list or even Jan 26 09:54:55 high-impact configuration changes like enabling systemd after delivering a initsysv-based eSDK. Of course I can do test any of these patterns (and I'm building some eSDKs right now), but I'm hoping for community wisdom to forsee any potential wrong assumption here... Jan 26 09:55:11 is there a clever way to debug changes to e.g. package.bbclass? I'd just like to re-package a specific recipe after a change but of course bitbake starts packaging the whole world before it... Jan 26 09:57:07 jku: sadly not. do a build in a tmpfs for a little bit more speed? Jan 26 09:57:34 i believe you can use bitbake -b to tell it to run just a specific bb file, but i wouldn't be surprised if a fair bit breaks Jan 26 09:59:47 ed2: any ideas on https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/164 ? Jan 26 10:00:01 RP: looking at the musl #if thing now Jan 26 10:00:12 rburton: thanks Jan 26 10:00:30 rburton: I have a fix for multilib Jan 26 10:08:01 rburton: is there a channel dedicated to meta-qt5 stuff? :) Jan 26 10:08:09 nope Jan 26 10:09:54 gizero: If it works in a normal build directory, it should work in the eSDK, they use the same approach Jan 26 10:10:16 gizero: We've gotten a lot better about cleaning things out these days Jan 26 10:15:02 RP: ok, in one of my initial tests (maybe from a quite dirty build setup) the sdk-update thing went wrong complaining for missing initsysv stuff while updating a default conf eSDK with a systemd-only one... Trying to reproduce on a simpler setup and see if it happens again. Will report back asap Jan 26 10:15:44 gizero: does that work in a normal build directory? Jan 26 10:16:29 rburton: can you merge my 2 yesterday patches? Jan 26 10:17:19 ed2: check ross/mut, i think they're both in Jan 26 10:17:28 oh helps if i push first Jan 26 10:17:32 now check :) Jan 26 10:21:14 RP: I don't understand what you mean for "work in a normal build directory". The eSDK builds fine, then I guess that's not a problem of just building with the updated configuration (with systemd enabled). It was fails while updating the SDK, but let see if I can reproduce on master with a core-image-minimal based eSDK... Jan 26 10:22:33 gizero: If you take a normal TMPDIR, build configuration A, then change to configuration B, does the build work as expected? Jan 26 10:22:51 (without wiping TMPDIR) Jan 26 10:23:14 uhmm... collateral problem here... Jan 26 10:23:29 ERROR: core-image-minimal-1.0-r0 do_sdk_depends: Error executing a python function in exec_python_func() autogenerated: Jan 26 10:23:32 The stack trace of python calls that resulted in this exception/failure was: Jan 26 10:23:34 File: 'exec_python_func() autogenerated', lineno: 2, function: Jan 26 10:23:37 0001: Jan 26 10:23:38 is mingw by now integrated as host machine? Or is there an up-to-date layer to provide a mingw sdk? Jan 26 10:23:39 rburton: thank you! Jan 26 10:23:39 *** 0002:extend_recipe_sysroot(d) Jan 26 10:23:42 0003: Jan 26 10:23:44 File: '/home/gizero/work/upstreaming/poky/meta/classes/staging.bbclass', lineno: 551, function: extend_recipe_sysroot Jan 26 10:23:47 0547: continue Jan 26 10:23:50 0548: if native: Jan 26 10:23:53 0549: dest = staging_copyfile(l, recipesysrootnative, fixme['native'], postinsts, stagingdir) Jan 26 10:23:56 0550: else: Jan 26 10:23:58 *** 0551: dest = staging_copyfile(l, destsysroot, fixme[''], postinsts, stagingdir) Jan 26 10:24:01 0552: if dest: Jan 26 10:24:04 0553: m.write(dest + "\n") Jan 26 10:24:06 0554: Jan 26 10:24:09 0555: for f in fixme: Jan 26 10:24:10 0266: os.symlink(linkto, dest) Jan 26 10:24:10 0267: #bb.warn(c) Jan 26 10:24:10 0268: else: Jan 26 10:24:13 File: '/home/gizero/work/upstreaming/poky/meta/classes/staging.bbclass', lineno: 270, function Jan 26 10:24:16 0269: try: Jan 26 10:24:18 *** 0270: os.link(c, dest) Jan 26 10:24:21 0271: except OSError as err: Jan 26 10:24:23 0272: if err.errno == errno.EXDEV: Jan 26 10:24:26 0273: bb.utils.copyfile(c, dest) Jan 26 10:24:28 0274: else: Jan 26 10:24:30 gizero: use a no-paste service, please :) Jan 26 10:24:31 Exception: FileExistsError: [Errno 17] File exists: '/scratch/gizero/poky-master-build/tmp/sysroots-components/i586/systemd/usr/include/libudev.h' -> '/scratch/gizero/poky-master-build/tmp/work/qemux86- Jan 26 10:24:35 poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/include/libudev.h' Jan 26 10:24:37 ERROR: core-image-minimal-1.0-r0 do_sdk_depends: Function failed: extend_recipe_sysroot Jan 26 10:25:08 T_UNIX: sorry for that... ;-) Jan 26 10:25:58 RP: this is when rebuilding the eSDK with changed config (systemd enabled) Jan 26 10:26:16 Does meta-raspberrypi no longer include a working recipe to use binary broadcom hardfloat drivers? Jan 26 10:26:48 RP: didn't happen before... Jan 26 10:27:33 With the default userland providing egl, this happens when I build eglinfo-fb Jan 26 10:27:35 poky/build/tmp/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/6.2.0/ld: src/platform_fb_raspberrypi.cpp.1.o: undefined reference to symbol 'vc_dispmanx_element_add' Jan 26 10:28:11 And libbcm_host.so doesn't actually include the string vc_dispmanx_element_add Jan 26 10:28:17 gizero: we recommend wiping tmp when changing DISTRO_FEATURES Jan 26 10:32:50 gizero: I can see why that would break :/ Jan 26 10:32:50 RP: here is build config and log after enabling systemd (not backfilling sysinitv yet). Previous build of eSDK went fine. http://pastebin.com/TjztfycQ Jan 26 10:33:09 gizero: I'd bet this would break in a normal builddir without eSDK Jan 26 10:42:28 created an esdk and found a second deployedable script ending in buildtools-nativesdk-standalone. what is this meant for? or is it just an intermediate artifact? Jan 26 10:42:33 RP: do you mean master as is is broken when enabling systemd on core-image-minimal? Jan 26 10:44:00 gizero: I mean if you switch sysvinit/sytemd settings like that on a normal TMPDIR, I suspect we'll see the same failure Jan 26 10:44:13 gizero: its from recipe specific sysroots :( Jan 26 10:46:35 RP: ok, got your point... I see 2 options here... going back in time on a pre rss commit and get back to my initial issue (upgrading eSDK from sysinitv to systemd) or maybe help somewhat with this one... I'll get back to this later anyway Jan 26 10:48:26 gizero: btw, can you tweak that sdk patch you sent to remove the path to pyshtables.py ? then it matches how poky does it and isn't distro specific (which the eSDK isn't) ? Jan 26 11:52:30 rburton: can you merge this one also? http://lists.openembedded.org/pipermail/openembedded-core/2017-January/131805.html Jan 26 11:53:17 rburton: it fixes wic occational test failure. Jan 26 12:02:17 ed2: done Jan 26 12:02:48 rburton: thanks Jan 26 12:09:46 is there a reason why the (e)sdk env does set path to sysroot/usr/bin, but not the toolchain subdirectory? resulting in the tools not being found OOTB Jan 26 12:30:05 >>> os.path.join('a','/b','c') Jan 26 12:30:05 '/b/c' Jan 26 12:30:23 anyone has an idea of how to make python not do this? Jan 26 12:31:34 kanavin: lstrip(os.path.sep) on all arguments to os.path.join Jan 26 12:31:42 kanavin: it's documented and expected behavior Jan 26 12:32:07 neverpanic: documented yes, expected, no :) Jan 26 12:32:18 ka6sox: this is why we have oe.path.join Jan 26 12:32:19 Depends on whether you've read the documentation, I'd say? Jan 26 12:32:26 damnit Jan 26 12:32:34 kanavin: this is why we have oe.path.join Jan 26 12:32:51 rburton: I guess I have to convert all of my newly written dnf code to use it then Jan 26 12:32:56 yes Jan 26 12:33:42 neverpanic: what I mean is that it's counter-intuitive - if I want to join paths, I don't want components to be thrown away like that Jan 26 12:35:17 kanavin: its widely known as an example of where python got the API wrong :( Jan 26 12:48:02 kanavin: are you debugging wic rawcopy plugin by any chance? Jan 26 12:48:51 mborzecki: no, I'm replacing smartpm and rpm5 with dnf and rpm4 Jan 26 12:49:12 aah, ok, looked similar to what I found in wic :) Jan 26 12:59:25 ed2: If I add your patch on the list, the wic pieces in master-next should be ok to merge to master? Jan 26 13:02:08 RP: I've just successfully run wic tests on ross/mut, so probably yes Jan 26 13:05:25 RP: ross: I rebased my hddimg patchset on top of ross/mut: http://lists.openembedded.org/pipermail/openembedded-core/2017-January/131813.html Jan 26 13:06:04 RP: rburton: I'm sure it conflicts with master and probably with master-next too. Jan 26 13:09:41 my python-fu is quite rusty Jan 26 13:10:47 how does one search in lists with a key function? Jan 26 13:11:19 i.e. I need to find something in a list of strings that begins with "#!" Jan 26 13:13:16 kanavin: >>> y = ['a', 'b', '#!c', '#!d'] Jan 26 13:13:17 >>> [x for x in y if x.startswith("#!")] Jan 26 13:13:17 ['#!c', '#!d'] Jan 26 13:13:53 RP: I need only the index of the first occurence Jan 26 13:14:33 RP: actually this is the issue: I have a script that begins with Jan 26 13:14:33 # libgdk-pixbuf-2.0-loader-gif - postinst Jan 26 13:14:33 #!/bin/sh Jan 26 13:14:43 I need to strip away everything that comes before #! Jan 26 13:15:46 kanavin: x.split("#!")[1] ? Jan 26 13:16:22 kanavin: although I guess that swallows the #! Jan 26 13:16:31 RP: what if #! occurs later in file? Jan 26 13:16:51 (I mean, more than once) Jan 26 13:17:00 kanavin: x.split("#!", 1) Jan 26 13:18:24 RP: yeah, that should work :) although I still wonder how I could get the list index without resorting to an ugly for loop Jan 26 13:21:32 kanavin: [i for i,x in enumerate(y) if x.startswith("#!")][0] is the best I can come up with Jan 26 13:23:06 RP: I'm surprised [0,1,2,3].index() only takes a value to match exactly, and not a function... not very powerful facility Jan 26 14:22:37 I'm trying to get multipath-tools to build. Something in the parameters after "-shared" causes gcc to switch back to linking an executable, leading to undefined references to main: -shared -Wl,-soname=libmultipath.so.0 -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=.../multipath-tools/0.5.0+git770e6d0da0-r0=/usr/src/debug/multipath-tools/0.5.0+git770e6d0da0-r0 -fdebug-prefix-map=.../multipath-tools/0.5.0+git770e6d0da0-r0/recipe-sy Jan 26 14:23:11 Repeating -shared directly before -o fixes it. Jan 26 14:23:25 Does anyone see what the reason could be? Jan 26 14:41:53 pohly: your line truncates at "git770e6d0da0-r0/recipe-sy", there is no -o in it Jan 26 14:42:55 kanavin: here's the complete line again: http://zerobin.org/?acf010b984aeaefa#yDaASn9KKIGfiQHJzBqvOlMrppNOpoQ4KzI89HEMfnU= Jan 26 14:43:27 I'm now patching the Makefile to work around the issue, so I'm not blocked. Still would prefer to understand it, though ;-} Jan 26 14:44:18 pohly: -pie Jan 26 14:44:50 Yep, "man gcc" agrees. Jan 26 14:45:35 I guess one can argue that multipath-tools.bb shouldn't put that into CFLAGS. Jan 26 14:49:04 RP: OK, going to send a V2 of the sdk patch Jan 26 14:50:35 gizero: thanks! Jan 26 14:54:08 interestingly, saving out all the datastores as we parse means a 770MB cache file. "compressing" with intern() to reduce string duplication, 754MB Jan 26 15:00:38 RP: surprisingly lack of reduction tbh Jan 26 15:01:29 rburton: python3 got better at string handling Jan 26 15:59:05 and if I just save the task dependency data its 409MB Jan 26 15:59:22 so still an order of magnitude too big :( Jan 26 16:37:49 alimon: i see a pile of qa patches have landed but the bugs are still open: you can get the glory if you close them before i run my script ;) Jan 26 16:38:21 rburton: i don't have assigned bugs about oeqa Jan 26 16:38:26 rburton: give me the numbers Jan 26 16:38:29 :) Jan 26 16:40:01 alimon: http://pastebin.com/GhuHZEZA Jan 26 16:41:01 rburton: good, let me review it Jan 26 16:46:34 rburton: yes those are pending minus oeqa tests are incompatible with python's unittest runner Jan 26 16:46:57 rburton: that's the reason i said first set of patches... there are a lot of work on qa if you want some :D Jan 26 16:50:38 rburton: certainly selftest is a monster... Jan 26 16:55:11 alimon: are you an expert in testimage.bbclass? Jan 26 16:56:12 kanavin: i don't say expert, but i known testimage well and mariano too Jan 26 16:56:44 alimon: how do I handle this failure? Jan 26 16:56:49 | Couldn't get ip from qemu process arguments! Here is the qemu command line used: Jan 26 16:56:49 | /home/ak/development/poky/build/tmp/sysroots/x86_64-linux/usr/bin/qemu-system-i386-serialtcp:127.0.0.1:54709-cpuqemu32-m256-serialtcp:127.0.0.1:39329-drivefile=/home/ak/development/poky/build/tmp/deploy/images/qemux86/core-image-sato-qemux86.ext4,if=virtio,format=raw-vgavmware-show-cursor-usb-usbdevicetablet-devicevirtio-rng-pci-snapshot-kernel/home/ak/development/poky/build/tmp/deploy/images/qemux86/bzImage--4.8.12+git0+926c93ae07_021b4aef55-r0-qemux86-201701 Jan 26 16:56:49 | and output from runqemu: Jan 26 16:56:49 | runqemu - INFO - MACHINE: qemux86 Jan 26 16:56:49 | runqemu - INFO - DEPLOY_DIR_IMAGE: /home/ak/development/poky/build/tmp/deploy/images/qemux86 Jan 26 16:56:49 | runqemu - INFO - CONFFILE: /home/ak/development/poky/build/tmp/deploy/images/qemux86/core-image-sato-qemux86.qemuboot.conf Jan 26 16:56:49 | runqemu - INFO - Continuing with the following parameters: Jan 26 16:56:50 | Jan 26 16:56:50 | stty: 'standard input': Inappropriate ioctl for device Jan 26 16:56:51 | runqemu - INFO - Running /bin/ip link... Jan 26 16:56:51 | runqemu - INFO - Setting up tap interface under sudo Jan 26 16:56:52 | sudo: no tty present and no askpass program specified Jan 26 16:56:52 | runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/.lock... Jan 26 16:56:53 | runqemu - INFO - Created tap: Jan 26 16:56:59 please use a pastebin Jan 26 16:57:02 don't spam the channel Jan 26 16:57:40 kanavin: seems that runqemu tries to up a tap device without permissions Jan 26 16:58:01 kanavin: did you add NOPASSWD to sudo? Jan 26 16:58:12 kergoth: sorry Jan 26 16:58:27 alimon: nope, I'd like to be prompted when random binaries call it :) Jan 26 16:58:50 *random binaries I downloaded from random websites :D Jan 26 16:58:53 specify an askpass program? Jan 26 16:59:09 that's the best way to deal with out of band authentication in general Jan 26 16:59:55 ed2: wic just blew up Jan 26 17:00:07 | File "/home/ross/Yocto/poky/scripts/lib/wic/plugins/source/bootimg-efi.py", line 170, in do_prepare_partition Jan 26 17:00:07 | bootimg_dir = os.path.join(get_bitbake_var("WORKDIR"), "efi") Jan 26 17:00:07 | File "/usr/lib/python3.4/posixpath.py", line 82, in join Jan 26 17:00:07 | path += b Jan 26 17:00:07 | TypeError: unsupported operand type(s) for +=: 'NoneType' and 'str' Jan 26 17:00:52 kergoth: runqemu doesn't support providing an askpass argument to sudo as far as I can see Jan 26 17:01:11 kanavin: read `man sudo` Jan 26 17:01:18 you can use an env var or sudoers as well Jan 26 17:01:21 afaict anyway Jan 26 17:04:13 kanavin: you can use runqemu-gen-tapdevs, I don't have sudo installed on my desktop Jan 26 17:06:46 good suggestion Jan 26 17:07:41 kergoth: justanotherboy: thanks, solved via sudo.conf Jan 26 17:29:53 anyone happen to know what YP release WRL 9 is going to be based off of? Jan 26 17:41:43 hmm, I can get the task dependency data to around 290MB but its still way too large to save our for debugging :( Jan 26 17:42:17 tried different formats, rather than pickle? what's the goal you're working on, anyway ? Jan 26 17:44:10 kergoth: these hash mismatch errors. If we could save out more data into the cache during parsing it would help debugging Jan 26 17:44:19 ah Jan 26 17:47:02 kergoth: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=97a3ef495e6db2e7a49dbdbd2f8de542dec6a024 - taking the data that would usually go into sigdata files and trying to "compress" it before saving into the cache Jan 26 17:47:15 kergoth: horrible code but had to be worth a try Jan 26 17:47:18 is -f accident when force pushing to bitbake repo? Jan 26 17:47:19 * [new branch] master-next-f -> origin/master-next-f Jan 26 17:47:42 JaMa: that doesn't look good Jan 26 17:48:18 JaMa: 7 months ago Jan 26 17:48:51 yes, noticed when updating some very old build directory :) Jan 26 17:49:00 JaMa: gone, thanks Jan 26 17:49:05 thanks Jan 26 17:49:24 openssl might be having issues with the recipe specific sysroots Jan 26 17:49:40 the symlinks in /usr/lib/ssl/ seems to be broken Jan 26 17:49:49 * RP removes noupdatedata too Jan 26 18:00:08 is someone already working on improving rm_work to remove more with recipe specific sysroots? With recipe-sysroot recipe-sysroot-native now in WORKDIR I need to buy a lot more RAM or stop doing builds in tmpfs Jan 26 18:00:43 JaMa: space usage should be similar as its all hardlinks Jan 26 18:01:52 then it's something else eating my tmpfs much faster than before Jan 26 18:01:53 36G tmp-glibc/work Jan 26 18:02:24 maybe hardlinks don't work as this is tmpfs (separate partition) from the sysroots in BUILDDIR? Jan 26 18:02:44 JaMa: ah, yes you need sysroots-components in the same disk Jan 26 18:03:39 ok, that might help 1.8G tmp-glibc/sysroots-components/ Jan 26 18:04:58 now just to find out why do_patch doesn't find quilt binary on jenkins builder Jan 26 18:07:20 Is Jefro around? Jan 26 18:24:37 Stupid question - what is the solution for a recipe where the package has no license file whatsover, the package is a single gzipped font file? I know I can set the license to closed but the projects cite states that it is GPL. Jan 26 18:25:26 Can i disable the QA check for LIC_FILES_CHKSUM and keep LICENSE = "GPL" since that is more correct than LICENSE = "CLOSED" Jan 26 18:30:06 themikenicholson: Use the common license files in meta, LIC_FILES_CHKSUM ?= "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6" or whatever GPL version it is. Assuming it is indeed standard GPL Jan 26 19:03:09 <_Ben> I'm trying to compile a driver for a system I built with Yocto... where can I find the kernel source that Yocto used? is there something local created or do I need to look through the recipes and find where the kernel was pulled from Jan 26 19:11:03 nrossi: Thanks! Jan 26 19:34:41 hi all, is my assumption correct: I can use an Morty based esdk built on RHEL7.2 on an RHEL6.8 version? Am I on a valid path? Jan 26 19:35:26 we have a requirement to support our customers on RHEL68....hence the query Jan 26 20:00:50 manju: tbh it would be a lot safer to build on 6.8 Jan 26 20:01:15 (you'll discover that binary software vendors build on ancient redhat releases to get the most compatibility out of the binaries) Jan 26 20:01:50 rburton: ok, i am facing quite some issues on 6.8 especially qemu-native breaking due to older gcc version Jan 26 20:02:26 hence was looking around for feasible solutions Jan 26 20:03:07 you could try - it depends on the versions of the toolchain on both and whether incompatible changes were made to libgcc/glibc/etc. Jan 26 20:07:09 rburton: thanks Jan 26 20:29:45 rburton: I have a fix in my contrib branch ed/wic/wip Jan 26 20:30:49 rburton: it's rebased on top of your ross/mut. Should I send the whole thing to the mailing list or your can merge my branch into yours? Jan 26 20:32:21 RP: rburton: do you plan to bump minimal required bitbake version for oe-core (after bumping the version in bitbake) with older revision recipe-specific-sysroots fail to find quilt (and everything else if they don't fail in do_patch already), see https://bugzilla.yoctoproject.org/show_bug.cgi?id=10977 Jan 26 20:32:22 Bug 10977: normal, Undecided, ---, ross.burton, NEW , quilt missing in recipe-sysroot-native for build with slightly older bitbake revision Jan 26 20:45:15 JaMa: just reading that now. bumping seems the best thing just to ensure the versions are right Jan 26 20:46:14 rburton: does yocto support live updates of target devices between YP releases using package feeds? (desktop distro - style) Jan 26 20:46:35 rburton: or is 'make an image and reflash' the official way? Jan 26 20:46:56 JaMa: can't really see anything relevant in the git log. do you use rm_work? Jan 26 20:47:40 kanavin_home: it should work, yes. we've some qa checks to ensure versions don't go backwards, but it's not as well tested as it should be. Jan 26 20:47:52 ed2: sent patches please Jan 26 20:48:24 rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9724 seems to indicate it's not actually officially recommended Jan 26 20:48:25 Bug 9724: normal, Medium, 2.4, jair.de.jesus.gonzalez.plascencia, ACCEPTED , Create a YP 2.2 test plan for package upgrades Jan 26 20:49:29 rburton: which is a good thing I guess, because I don't see a sane way to do a live update from rpm5 based distro to an rpm4 one Jan 26 20:49:45 ha, i knew there was a subtext :) Jan 26 20:50:06 maintaining package upgradability is non-trivial. it's a serious amount of maintenance load that we aren't putting enough effort into. of course, there are a number of other update mechanisms and projects around nowadays Jan 26 20:50:16 i think only angstrom has ever prioritized it Jan 26 20:52:05 i think we'd be okay with a big entry in the release notes, if a feed from either side of rpm5/rpm4 was impossible to migrate. Jan 26 20:52:17 the act of installing rpm4 and removing rpm5 would be "non trivial" to start Jan 26 20:52:18 kergoth: yeah, but at some point desktop-style updates via remote repos should be supported officially, also from one YP release to next YP release Jan 26 20:52:33 rburton: exactly, and if something breaks in that transaction, you are seriously SOL Jan 26 20:52:34 kanavin_home: are you offering to own that bug? Jan 26 20:52:36 we'd have to have sufficient resources to do so Jan 26 20:52:42 we barely have enough to cover what we need as it is Jan 26 20:52:49 * kergoth shrugs Jan 26 20:53:10 it shouldn't be *that* much effort to at least automate verifying a poky feed works from day to day Jan 26 20:53:49 that's assuming you only test from version M to version N. what about M to O, or N to Q, or..? Jan 26 20:54:01 and even then there's the work involved in actually fixing and maintaining such issues, beyond the testing Jan 26 20:54:47 yeah it's totally non-trivial Jan 26 20:56:05 rburton: is 'maybe later' an acceptable answer for the owning a bug question? Jan 26 20:56:06 so, any objections to adding 'acl' to default DISTRO_FEATURES? Jan 26 20:56:09 if you only ever support upgrades from one release to the next release, and not master or jumps beyond one release, that'd help pare it down, but there's still hte upgrades along the stable branch track Jan 26 20:56:29 for a core-image-sato it's just adding libacl dependencies to three packages, but adds a reasonable amount of functionality that modern systems might expect. Jan 26 20:56:37 kanavin_home: absolutely Jan 26 20:57:23 rburton: the question got stuck in my head because I just wrote an epic response to Mark in 9675 Jan 26 20:57:52 a side note, i haven't been actually looking closely at pseudo bugs, I think all the stuff I know of is probably in reasonable states, but I haven't had time to actually go check. Jan 26 20:58:13 If there's specific issues that people think are broken, feel free to ping me. Jan 26 20:58:24 (... and on a side note, I will totally get around to some reliability improvements Any Week Now.) Jan 26 21:02:00 rburton: yes I'm using rm_work Jan 26 21:02:15 rburton: but not sure how rm_work would affect do_patch dependencies Jan 26 21:02:47 or rather not executing extend_recipe_sysroot inside do_patch Jan 26 21:02:59 JaMa: me neither but i'd be curious if that would make a different. :) can you try disabling it? Jan 26 21:05:00 fails the same without rm_work Jan 26 21:05:13 seebs: not an issue as such, but for tracking pseudo releases, we'd need either git tags or tarballs Jan 26 21:05:52 (i.e. being notified when there's a new release, or checking what is the latest release right now) Jan 26 21:09:54 rburton: you can remove hddimg patchset from your branch. I'll send v3 at some point, but not today. It's still under testing. Jan 26 21:14:14 rburton: The required bitbake commit is: Jan 26 21:14:15 4dcd0e5 event/ast: Add RecipeTaskPreProcess event before task finalisation Jan 26 21:15:19 I don't think I've done any git tags or tarballs for a while. But I will likely do a tag and tarball after any proposed reliability fixes. Jan 26 22:21:09 what changed recently that all of my images (except -minimal) now require sudo? Jan 26 23:22:09 skrawn: bitbake -g can probably tell you Jan 26 23:22:18 (nothing that i'm aware of in oe-core at least) Jan 26 23:30:25 ok, I thought it would be something obvious because I do have to include "empty-root-password" explicitly now or I can't log into any images Jan 26 23:30:50 last big update to the morty branch was 1/11 and I just started building new images Jan 26 23:31:53 but now I can't even restart because I need to be super user :P Jan 26 23:32:53 well if you don't set empty-root-password then you need to set the root password yourself, as otherwise root won't have a password Jan 27 00:04:01 how do i log the output of a command in a recipe for debugging? i want to do something like bb.plain(`ls -l`) Jan 27 00:20:22 i'm inheriting from bin_package, and it looks like it unpacked my stuff into ${WORKDIR} instead of ${WORKDIR}/image, which is the default location of ${D}. but reading through the bin_package.bbclass looks like it untars it to ${D}. did ${D} change somehow beteween the time bin_package did it's install and my recipe is run? Jan 27 00:23:23 miceopede: it's using tar to copy from ${S} to ${D} Jan 27 00:24:25 miceopede: you may wish to set subdir= and then if necessary set S accordingly Jan 27 00:24:39 subdir= being a parameter in the URL in SRC_URI Jan 27 00:24:47 that's covered in the comments at the top of bin_package.bbclass Jan 27 00:25:30 miceopede: re logging - anything that produces output is going into the task log - you will find that under ${T} i.e. ${WORKDIR}/temp Jan 27 00:25:55 so you don't necessarily need to run it through bb.plain() Jan 27 00:26:05 thanks Jan 27 00:28:24 still don't quite understand what's going on though. bin_package_do_install() is run. it appears it untarred it to ${WORKDIR} instead of ${D} Jan 27 00:31:52 oh Jan 27 00:32:04 do_install_append() comes before bin_package_do_install()? Jan 27 00:33:43 nope Jan 27 00:34:03 the bin_package_do_install becomes the implementation of do_install (via EXPORT_FUNCTIONS) Jan 27 00:34:16 then any do_install_append()s will be appended to the end of that Jan 27 00:34:31 there are two tar operations going on here Jan 27 00:34:36 one that happens in do_unpack Jan 27 00:35:08 that's going into ${WORKDIR} - you need to add ;subdir=something to the entry in SRC_URI to put that in a subdirectory if you need that Jan 27 00:35:50 and then if necessary set the S variable so it points to "${WORKDIR}/something" Jan 27 00:36:21 (I say if necessary, because you could always set subdir= such that it matched the default value of S) Jan 27 00:36:46 then there's the second tar that happens during do_install, that's what's defined by bin_package Jan 27 00:37:20 so ;subdir=${S}, then bin_package will pick it up in do_install? Jan 27 00:37:43 what is the first unpack for, then? Jan 27 00:37:57 the first unpack is the only way source actually gets unpacked Jan 27 00:38:36 the tar operation in do_install is just copying... don't be confused by the fact that tar is being used, that's just to preserve permissions, hardlinks etc. Jan 27 00:39:02 i see Jan 27 00:39:08 (I say source, I mean the contents of what you've put in SRC_URI) Jan 27 00:40:07 ok, makes sense now Jan 27 00:40:09 thanks so much Jan 27 00:40:12 no worries Jan 27 00:40:26 I wonder if we need a new bin_package class that sets up some of these things by default Jan 27 00:41:20 right now it is a bit awkward Jan 27 00:44:47 it's a bit confusing. i was expecting that it would be fetched to ${S}, then bin_package would extract it to ${D} Jan 27 00:44:58 maybe that was the wrong mental model Jan 27 00:48:05 I guess underlying is that it is often assumed that S controls where the source gets unpacked Jan 27 00:48:35 it doesn't - it merely specifies where the system should expect the natural root of the source to have been unpacked Jan 27 00:49:06 (since most source tarballs contain a subdirectory at the root and have everything underneath that) Jan 27 00:49:14 isn't that the most obvious way of interpreting ${S}? i specify a source tarball in SRC_URI. i expect it to be in ${S} Jan 27 00:49:59 right, and a lot of the time the default value of S and the subdirectory name used in a source tarball will match up Jan 27 00:50:40 but whether or not it does depends on what name was used when that tarball was created upstream, which we usually don't control Jan 27 00:52:04 of course this is for general recipes - for bin_package recipes where you're bringing in an rpm or a tarball or similar that's laid out in the same way you want it to appear on the target, then you don't have such a subdirectory Jan 27 00:52:32 so our default of unpacking into ${WORKDIR} isn't ideal Jan 27 00:52:45 for the bin_package scenario, I mean Jan 27 00:59:27 yeah. i'll just repackage my tarball to match ${S} Jan 27 01:00:06 or just use subdir=${BP} - there's nothing wrong with doing that Jan 27 01:00:58 at least then you don't have to remember to put the subdirectory in if you regenerate it later Jan 27 01:51:11 do i need to put all my *.a files into FILES_${PN}-staticdev? or can i just add them to FILES_${PN}-dev? Jan 27 01:51:21 they're only needed at buildtime Jan 27 02:01:11 miceopede: typically they would go into ${PN}-staticdev so that ${PN}-dev doesn't fill up with them, but I don't think there's actually a QA check to prevent them going into ${PN}-dev Jan 27 02:07:03 @bluelightning what's the difference? if i put them in -staticdev, they won't get staged to the target, but if i put them in -dev, they will? Jan 27 02:08:11 miceopede: if by "staged" you mean installed on the target device, it depends Jan 27 02:08:20 miceopede: by default, neither will... if you explicitly install the -dev package, or you have dev-pkgs in IMAGE_FEATURES, then files in the -dev package will be installed Jan 27 02:09:33 FWIW when it comes to the SDK, there -dev packages are installed by default, but not -staticdev Jan 27 02:09:51 (by virtue of the default value of SDKIMAGE_FEATURES) Jan 27 02:09:53 how does that make sense? Jan 27 02:10:13 miceopede: which, sorry? Jan 27 02:10:36 presumably if i'm bulding the sdk, i'd want .a's in there to link against, no? Jan 27 02:10:59 only if you're statically linking your executable, if you aren't (and we assume most people aren't) then they are of no use at all Jan 27 02:11:49 hm... i see Jan 27 02:12:05 in any case it's just a default, you can change SDKIMAGE_FEATURES to include "staticdev-pkgs" if you are expecting to link thing statically Jan 27 02:12:26 s/thing/executables/ Jan 27 02:13:39 i see, ok Jan 27 02:15:20 so now i added a bunch of .so's to -dev, and it complains "-dev package contains non-symlink .so: Jan 27 02:15:34 all i have are the raw .so's Jan 27 02:15:44 these are supposed to be symlinks..? Jan 27 02:18:25 i guess i put these into FILES_${PN} instead? Jan 27 02:22:24 miceopede: .so is supposed to be symlinks Jan 27 02:24:44 if you really want to have .so in -dev you can override it with INSANE_SKIP_${PN} ="dev-so" Jan 27 02:28:20 miceopede: the .so files are needed at runtime - so typically they go into the main package Jan 27 02:28:37 except for a .so symlink without a version, that goes into the dev package Jan 27 02:29:10 (we assume if you put libraries into the standard library paths, that you are using standard library versioning) **** ENDING LOGGING AT Fri Jan 27 03:00:01 2017