**** BEGIN LOGGING AT Tue Jan 31 03:00:02 2017 Jan 31 08:31:03 Hi, how can I specify, that my newly created layer shall provide an .bbappend and not an identical named .bbappend file in one of the layers below? Jan 31 08:36:14 m4ho: just in the normal way, they should get stacked on top of each other. You can check with the bitbake-layers command Jan 31 08:38:51 RP: is my understanding correct, that xyz.bbappend will only selected once in the whole stack? Which is the one with the highest priority? Jan 31 08:40:49 m4ho: no, all bbappends that match are applied Jan 31 08:46:51 RP: Do you have an idea how to disable some bbappends? In my case, each of those bbappends includes the same file but only mine should be there in the end, which is not happening even with highest and lowest priority Jan 31 08:56:03 bluelightning: is it necessary to call tinfoil.shutdown()? verify-bashisms currently doesn't do that and hangs during exit. Aborting shows: Jan 31 08:56:04 ^CError in atexit._run_exitfuncs: Jan 31 08:56:04 Traceback (most recent call last): Jan 31 08:56:04 File "/usr/lib/python3.4/multiprocessing/popen_fork.py", line 30, in poll Jan 31 08:56:04 pid, sts = os.waitpid(self.pid, flag) Jan 31 08:56:04 KeyboardInterrupt Jan 31 08:56:39 Adding tinfoil.shutdown() at the end leads to a different error: Jan 31 08:56:39 ERROR: UI received SIGTERM Jan 31 08:56:39 Process ForkPoolWorker-2: Jan 31 08:56:39 Traceback (most recent call last): Jan 31 08:56:39 File "/usr/lib/python3.4/multiprocessing/process.py", line 257, in _bootstrap Jan 31 08:56:39 util._exit_function() Jan 31 08:56:40 ... Jan 31 08:57:17 That's probably two errors: first, "ERROR: UI received SIGTERM" looks like something that shouldn't be printed in this case. Jan 31 08:57:48 Second, tinfoil interacts poorly with multiprocessing. Jan 31 08:59:24 pohly: it is, yes... but I'm hoping to fix it so it's not required Jan 31 08:59:28 Looks like initializing the multiprocess pool before connecting to the bitbake server works without errors. Jan 31 08:59:32 on my ever-grwoing todo list Jan 31 08:59:44 hmm, ok - wasn't aware of the multiprocessing issue Jan 31 09:00:08 though bitbake (and by extension tinfoil) uses multiprocessing itself, I wonder if that has something to do with it Jan 31 09:00:53 I've not looked into it in detail, but it looks like the forked processes inherit some information about the connection to the server, but can't actually do anything with it because it isn't one of their children. Jan 31 09:36:14 bluelightning: when extracting a shell script via tinfoil ("script = data.getVar(key, False)" where "key" refers to a function), is it possible to get line number information relative to the file in which the script was defined? Probably not in the general case (for example, a function created with setVar()), but at least for normal function definitions? Jan 31 09:52:43 pohly: getting the filename varflag for the variable might work Jan 31 09:52:58 pohly: er, lineno even Jan 31 10:06:26 marquiz: would you be able to point one of your performance testers against the master-next branch and get a number for the performance of that? Jan 31 10:09:52 RP: sure Jan 31 10:18:20 marquiz: thanks, hoping the patches there help performance of rss a bit Jan 31 10:26:08 RP: ok, i set the ubuntu14 machine to test master-next Jan 31 10:41:05 marquiz: thanks Jan 31 10:53:31 bluelightning: verify-bashisms found a bashism in populate_sdk_ext.bbclass: if [ "${SDK_INCLUDE_TOOLCHAIN}" == "1" -a ! -e $unfsd_path ] Jan 31 10:53:37 I'll send a fix... Jan 31 11:02:00 pohly: I wonder how many more of these host tool type problems we're going to find. That symlink idea may be necessary at least to validate where we stand and root out any remaining gremlins... Jan 31 12:01:40 hmm, i'm still seeing this strange rpm build failure in some environments Jan 31 12:01:50 looking at config.log: Jan 31 12:01:56 i586-poky-linux-gcc: error: unrecognized command line option '--should-not-have-used-/usr/bin/pcre-config Jan 31 12:02:01 wtf is that?? Jan 31 12:04:42 CPPFLAGS=' -DRPM_OS_LINUX=040400 --should-not-have-used-/usr/bin/pcre-config' Jan 31 12:09:10 marquiz: something is trying to run pcre-config, it should probably be fixed to use pkg-config Jan 31 12:09:14 marquiz: sounds like something used a -config script which it shouldn't Jan 31 12:09:56 why does this only happen on some build hosts Jan 31 12:10:33 ah, pkg-config is missing on the host Jan 31 12:12:31 it worked before, though (before rss, i think) Jan 31 12:12:46 pkg-config would have been pulled into the sysroot Jan 31 12:12:55 not anymore Jan 31 12:13:27 Good afternoon, Jan 31 12:13:27 Has anybody used meta-toolchain with Linux (lx-*) scripts Jan 31 12:13:46 The default morty setup (poky-morty) lacks support for python on the GDB Jan 31 12:15:05 poky-morty/meta/recipes-devtools/gdb/gdb-cross.inc Jan 31 12:15:05 PACKAGECONFIG[python] = "--with-python=${PYTHON},--without-python,python3-native" Jan 31 12:15:18 have anybody had similar issue? Jan 31 12:15:34 marquiz: we need to catch and fix these kinds of issues :/ Jan 31 12:16:55 RP: playing now with noexec/deltask. I'm looking at task.order and listtasks to evaluate the changes. Jan 31 12:17:11 How can I easily spot task dependencies? Jan 31 12:19:50 for kernels i.e. deltask do_install is a no-go because you then loose strip, sizecheck, staging Jan 31 12:19:56 RP: what would be the proper fix, "inherit pkgconfig" in rpm recipe, or something else Jan 31 12:20:27 marquiz: yes Jan 31 12:21:07 thanks, i'll submit a patch, then Jan 31 12:21:39 there might be other similar issues so i'll make sure that core-image-sato builds fine before posting Jan 31 12:25:21 marquiz: yes Jan 31 12:26:44 the error was just so strange at first sight it confused me Jan 31 12:27:02 ah, wpa-supplicant fails, too... Jan 31 12:27:19 i added a few more inherits in mut for this problem, after adding a sanity check that configure.ac using pkgconfig pulls in pkgconfig Jan 31 12:35:24 rburton: would it be possible to throw the dnf branch on the AB sometime soon (not yet)? Jan 31 12:36:10 rburton: I'll soon run out of ways to test things locally, so need a more serious approach in breaking my code :) Jan 31 12:36:16 yeah sure Jan 31 12:39:56 RP: update on recipe sysroot symlink breakage: I've got a possible patch but I'll spend a moment checking what other broken symlinks we still have in sysroots (and making sure I'm not breaking something else) Jan 31 12:56:19 pohly: thanks for fixing bashisms! Jan 31 13:00:03 * kanavin tries out rss for the very first time Jan 31 13:09:02 jku: is the branch somewhere I can look at out of interest? Jan 31 13:16:06 RP: poky-contrib "jku/make_relative_symlink" -- it seemed to me I didn't really need the state[2] based dstpath but as said, I'm still looking at the results Jan 31 13:17:09 I wanted to pass some arguments to qmake from qtwebkit_git.bb, what is the way to do it ? Jan 31 13:18:26 jku: ah, you need that for things like do_deploy which have have symlinks in the image deploy directory Jan 31 13:19:42 ok, I'll take a look Jan 31 13:19:52 jku: can't we just use the output from os.path.relpath and bin that while depth: bit? Jan 31 13:25:36 we might with a little massaging, I can try again Jan 31 13:28:23 rburton: around ? Jan 31 14:15:09 Hi, I'm using meta-qt5 layer (fido branch) from https://github.com/meta-qt5/meta-qt5 Jan 31 14:15:18 It has qtsvg_git.bb recipe Jan 31 14:16:29 when I `bitbake -C fetch qtsvg`, it (re-)creates libqt5svg5_....ipk Jan 31 14:16:38 ...aaand looks like I just noticed what the problem may be Jan 31 14:16:56 the problem is, I can't get this .ipk installed on image Jan 31 14:17:10 I have to scp it over to target and do opkg install libqt5svg...ipk Jan 31 14:17:38 hmm Jan 31 14:18:22 so anyway, to continue explanation: it creates these two ipk files, which i want on my image: Jan 31 14:18:43 libqt5svg5_5.4.2+git0+ccae23961e-r0_cortexa9hf-vfp-neon.ipk Jan 31 14:18:58 libqt5svg-plugins_5.4.2+git0+ccae23961e-r0_cortexa9hf-vfp-neon.ipk Jan 31 14:19:21 and that latter one, plugins, is the one I can't get included on image Jan 31 14:19:39 but now I see, there is a name difference there too, maybe that has something to do with it Jan 31 14:21:37 hyde: sometime you should use "source" package names and sometime "binaries" package names Jan 31 14:22:17 like DEPENDS="curl" RDEPENDS="libcurl" Jan 31 14:22:30 I guess the core of the problem is, what should I write to image recipe, to have that libqt5svg-plugins...ipk installed Jan 31 14:23:07 libqt5svg-plugins I would say :-) Jan 31 14:23:37 I already have IMAGE_INSTALL_append+=qtsvg Jan 31 14:23:48 yeah, that's the name of a source package. that's wrong Jan 31 14:23:52 which takes care of the libqt5svg5_5.4....ipk Jan 31 14:24:04 ...or at least doesn't produce error Jan 31 14:24:21 I'll try a bit more Jan 31 14:25:06 hyde: IMAGE_INSTALL wants package names, not recipe names Jan 31 14:25:56 ah, maybe it also has a binary package called that way that pulls in some dependencies Jan 31 14:26:06 yeah, it does something Jan 31 14:26:08 just not enough Jan 31 14:26:38 RDEPENDS_${PN} = "libqt5svg-plugins" Jan 31 14:26:38 gives error Jan 31 14:26:46 I guess because that isn't a recipe name Jan 31 14:27:42 hyde: RDEPENDS isn't right here, it was just an example about package names, sorry Jan 31 14:28:19 IMAGE_INSTALL_append+=libqt5svg-plugins doesn't work? Jan 31 14:29:19 ERROR: Nothing RPROVIDES 'libqt5svg-plugins' Jan 31 14:29:27 same with RDEPENDS and IMAGE_INSTALL_append Jan 31 14:30:32 it may well be bug in meta-qt5 (fido is old branch), but I currently have no idea how to go about fixing it Jan 31 14:30:55 ...or using DEPENDS instead of RDEPENDS may actually help Jan 31 14:31:16 at least it is building now :-p Jan 31 14:32:10 no no... that's just compile time depends Jan 31 14:32:43 you can find the package names in the packagesplit directory in the workdir Jan 31 14:35:58 yeah, I found 'em Jan 31 14:37:32 libqt5svg5_...ipk is there and included in mage Jan 31 14:37:52 corresponding libqt5svg-plugins_....ipk is in the the same dir, but not included in the image Jan 31 14:39:28 manyally copying and installing that makes my app work (it uses svg images) Jan 31 14:42:21 ah, there seems to be qtsvg-plugins Jan 31 14:42:37 I don't know what it is, exactly, but it can be added to IMAGE_INSTALL_append Jan 31 14:44:44 all I can say is, thank $DEITY for SSD disks. working with this stuff must have been very painful before Jan 31 14:45:19 now building a new image and installing it is a matter of like 3 minutes (on my not-new dev laptop) Jan 31 14:45:39 it must have been something... a lot more, 5 years ago Jan 31 14:49:20 ...still no svg plugin :( Jan 31 14:51:26 Hmm, build-appliance is the one recipe which uses SRC_URI in an image recipe. Probably should change that Jan 31 14:52:56 hyde: how much speedup do you see with SSD disks - we benchmarked rootfs builds years ago on SSDs vs spinning and found a greater correlation with RAM than disk Jan 31 14:53:15 might also be RAM Jan 31 14:53:27 rburton: known issue? Jan 31 14:53:27 WARNING: core-image-sato-1.0-r0 do_sdk_depends: Manifest /home/ak/development/poky/build/tmp/sstate-control/manifest-allarch-meta-environment-extsdk-qemux86.populate_sysroot not found? Jan 31 14:53:27 WARNING: core-image-sato-1.0-r0 do_populate_sdk_ext: Manifest /home/ak/development/poky/build/tmp/sstate-control/manifest-allarch-meta-environment-extsdk-qemux86.populate_sysroot not found? Jan 31 14:53:54 just curious, always looking for an excuse to play with some new hardware at work Jan 31 14:54:41 kanavin: was that with master? Jan 31 14:55:18 RP: no, with my dnf branch on top of master - I'll try with pristine master in a bit Jan 31 14:55:48 ...actually, messed up flashing, including that qtsvg-plugins might have fixed it (flashed old image) Jan 31 14:56:18 kanavin: actually, I didn't do what I thought I'd done which would fix that Jan 31 14:58:30 guys, I have created a kernel module recipe. The module install correctly but it doesn't auto load Jan 31 14:58:48 I did KERNEL_MODULE_AUTOLOAD += "mymodule" Jan 31 15:02:23 there is no .conf on /etc/modules-load.d/ Jan 31 15:07:28 I'm attempting to compile yocto for a digi connectcore 6 sbc. Jan 31 15:08:01 there're a bunch of things enabled that I don't want Jan 31 15:08:05 like QT5 Jan 31 15:08:40 but when I tried disabling those lines, I'm getting an error in bitbake where it complains about "nothing provides dey-image-qt" Jan 31 15:09:23 what's the correct method to go about removing any graphical manager from compiling Jan 31 15:13:10 figure out what you're trying to build that depends on dey-image-qt, and remove it, either via bbappend or local.conf Jan 31 15:13:15 grep is your friend :) Jan 31 15:19:42 ernstp: thanks for pointing me to the right direction, would have taken me a lot longer to find out qtsvg-plugins without your suggestions Jan 31 15:23:13 kergoth: ah, so there's no ncurses type method of enabling/disabling stuff? Jan 31 15:30:20 any clue on why KERNEL_MODULE_AUTOLOAD doesn't work with my module? Jan 31 16:09:40 Looks like we're going for an M2-rc2 so nominate patches to get merged if they're not in already ASAP... Jan 31 16:40:17 I'm experiencing a problem installing the eSDK - ext-sdk-prepare.py is failing with "Unexpected tasks or setscene left over". All the tasks that are listed (do_fetch through do_bundle_initramfs) are coming from my kernel recipe Jan 31 16:40:44 so it looks like its trying to rebuild the kernel when preparing the SDK, not sure where to start with troubleshooting this Jan 31 16:59:22 RP: rebasing dnf branch on top of master (that is, rss) went quite smoothly, other than an odd missing dependency :) Jan 31 16:59:31 it is nice when things just work Jan 31 17:02:48 kanavin_home: that is nice. I did try not break the world with rss :) Jan 31 17:07:42 they are so many raspberrypi meta... what is the best in town? Jan 31 17:10:26 honestly i still just use the debian fork for the pi Jan 31 17:10:41 i don't have any particular reason to need a fancy build system for it, in general. Jan 31 17:12:20 raspbian...I believe. but what about this lovely testing/qemu setup in poky? how can you reuse that? Jan 31 17:14:46 marquiz: hmm, 31.1GB down to 30.8GB so better but still not ideal :/ Jan 31 17:14:55 but it is faster at least Jan 31 17:19:40 i haven't really bothered with the qemu stuff, because the actual machine is usually fine for my purposes. Jan 31 17:19:57 also i can't hook wires up from qemu to a little board i soldered up and then to an arduino. Jan 31 17:39:40 hey seebs: have you blogged your receipe !? Jan 31 17:47:13 any suggestions for troubleshooting that issue I mentioned earlier? I saw in the mailing list someone experienced this and they used bitbake-diffsigs to uncover some recipe issues? Jan 31 17:55:15 no, because i don't have a recipe. i never even thought to try yocto on the pi, since i already had a working distro Jan 31 18:04:53 themikenicholson: I just read the scrollback Jan 31 18:05:13 themikenicholson: so the kernel is kind of special in that it can't be fully restored from sstate, but the eSDK doesn't treat it specially Jan 31 18:06:45 I'm not sure if there is additionally something in your dependency chain that means that it has to fully rebuild the kernel rather than restoring the bits that it can Jan 31 18:07:33 bitbake -g and looking at task-depends.dot (manually, it's way too large to produce a visual graph from) may shed some light Jan 31 18:38:22 bluelightning: thanks for the starting point. eSDK is a lot of black magic, trying to understand the recipes for it Jan 31 19:18:03 themikenicholson: let me know if you have any questions - I wrote a large portion of it (not proudly, in some parts...) Jan 31 19:42:53 RP: yes, a little bit better, looks slightly faster Jan 31 19:43:20 RP: something strange has happened in the "rm_work" test of the other machine, though Jan 31 19:43:27 but more results in the morning Jan 31 20:12:30 huh Jan 31 20:12:31 | configure: error: Either a previously installed pkg-config or "glib-2.0 >= 2.16" could not be found. Please set GLIB_CFLAGS and GLIB_LIBS to the correct values or pass --with-internal-glib to configure to use the bundled copy. Jan 31 20:12:41 from pkg-config-native on JaMa's builders Jan 31 20:13:11 as, | checking if internal glib should be used... no Jan 31 20:13:14 but mine says yes Jan 31 20:13:33 oh this is target pkgconfig Jan 31 20:13:35 strange, you'd think use of the internal glib would have nothing to do with the host or external dependencies Jan 31 20:13:35 so maybe a missing dep Jan 31 20:13:44 ah Jan 31 20:14:02 * rburton1 still feels like death warmed up so should just go eat and ignore this Jan 31 20:15:02 yeah target pkgconfig needs pkgconfig-native Jan 31 20:15:44 * kergoth chuckles Jan 31 20:26:34 bluelightning: I'm seeing a lot of lines like this : "linux-mts.do_build" -> "openssl.do_package_write_rpm" Jan 31 20:27:36 themikenicholson: right - it's the ones that end with "-> linux-mts." that are of interest Jan 31 20:28:28 ah, so that is read as openssl.do_package_write_rpm depends on linux-mts.do_build Jan 31 20:28:49 I saw "python-pydispatcher.do_unpack" -> "python-pydispatcher.do_fetch" as an example and assumed it was the opposed way around Jan 31 20:29:00 *opposite Jan 31 21:26:45 Hm, do we have anything in place to add timing info about postinst executions on first boot, to debug slow first boot issues? Jan 31 21:27:02 'opkg configure' obviously is too monolithic, i doubt opkg provides such information, unless we inject it into the postinsts Jan 31 21:28:28 suppose it'd be easiest to enable by using rpm and modifying run-postinsts to add times to the log file Jan 31 21:44:44 can someone explain why we have both opkg-configure and run-postinsts, and both get installed and systemd services enabled? Jan 31 21:44:52 afaict they're both running on first boot, and both slow Jan 31 21:45:03 i don't get it Jan 31 21:46:51 there are postinsts in ipk-postinsts, which run-postinsts will run, yet opkg-configure runs 'opkg configure', which runs the unconfigured postinsts from the opkg metadata, and both are running on first boot Jan 31 21:46:53 what? Jan 31 21:49:02 adelcast: ^^ Jan 31 21:49:08 i must be missing something.. Jan 31 21:51:09 presumably originally run-postinsts was in place to fix images without package-management, but then it gained the ability to call out to the package managers, so it seems like opkg-configure is now superceded and pointless Jan 31 21:51:15 * kergoth tries disabling it to see what happens Jan 31 21:53:27 I thought it was the other way around, but I haven't been close to that stuff for a while Jan 31 21:54:12 * kergoth shrugs Jan 31 21:54:43 rpm, dpkg, and opkg all rdep on run-postinsts Jan 31 21:56:27 the post install stuff is not unique to one package format or another.. Jan 31 21:56:31 the implemention though is different Jan 31 21:57:29 For deb/ipk the system will collect failed post install scripts and put them into a run-postinsts step... (does this in the rootfs.py) Jan 31 21:57:33 run-postinsts calls out to dpkg or opkg, but runs them itself for rpm, and then opkg-configure also calls out to opkg. i don't see an equivalent to dpkg, so it seems like we just forgot to remove opkg-configure when run-postinsts took over for it, but that's having no real knowledge of the changes Jan 31 21:57:52 for RPM, we have a wrapper script that checks if the scriptlet failed, and we do the same thing, then the rootfs.py moves it to the final place Jan 31 21:57:55 kergoth: yeah, that sounds wrong, if we are running the postinst externally, I believe opkg configure will re-run all the postinst again Jan 31 21:57:59 my system is starving for entropy on first boot due to running everything twice Jan 31 21:58:01 :) Jan 31 21:58:28 admittedly it's way worse on this than on most systems, since qemu user mode doesn't seem to support x32, so *everything* is postponed, just about Jan 31 21:59:05 from the implemnetation (I was reading it this morning) it -should- be collecting the post install scripts and running them once.. Jan 31 21:59:21 the first boot -should- be the same for both RPM, Opkg and Deb style.. since the collection happens at the rootfs.py time.. Jan 31 21:59:43 if it's running BOTH the postinstall and re-filtering through the deb/opkg control files.. that is a bug.. it shouldn't be loading those directly at boot.. Jan 31 22:00:50 ...and for most of the systems I seem to deal with, qemu usermode doesn't work.. :P Jan 31 22:01:06 various ARM variants, MIPS variants and 64-bit PPC variants.. :P Jan 31 22:01:06 i think it's working as intended, once the upstream runj-postinst fix to call out to opkg/dpkg is applied, if i remove opkg-configure Jan 31 22:01:10 ahh indeed Jan 31 22:01:22 ya, opkg-configure sounds like it's wrong in those cases.. Jan 31 22:01:42 first boot on this board is completely stalling until i hit enter on my attached bt keyboard, think i might have to make run-postinsts run after rngd, worst case Jan 31 22:01:44 it should be run the single postinstall stuff.. that is intended to be universal to all package formats (including when there is no package manager on the target) Jan 31 22:01:50 * kergoth nods Jan 31 22:02:15 s/bt/usb/ Jan 31 22:02:19 ya.. rngd -- or get the virtio-rng stuff in place to increase entropy Jan 31 22:02:26 * kergoth nods Jan 31 22:03:19 kergoth, any plans for ELC in Portland this year? Jan 31 22:04:20 so, opkg-configure not only runs the postinst's, but it also changes the state of the the package from Unpacked to Install, if we drop the opkg configure call, we'll need to do that too Jan 31 22:04:32 (not sure if it's already being done) Jan 31 22:04:49 the rootfs.py collection of the scripts to the run-postinst collects them an also changes the status.. Jan 31 22:05:11 it does this in a way that should work for all three package types equally.. (and of course then the package managers and DBs can be erased as well in rootfs.py) Jan 31 22:05:16 adelcast: yeah, run-postinsts runs opkg configure too, at least with 17ad91ac applied, so should be fine Jan 31 22:05:48 fray: ah, good to hear, then it is effectively implementing opkg configure, but in a package manager agnostic way Jan 31 22:05:52 fray: ugh, i always forget to request approval until it's too close, i'll have to check :) Jan 31 22:06:06 haven't been to elc in *years*, would be nice Jan 31 22:06:53 sheesh, last time i went was shortly after parallel parsing went in, and we were discussing how to cover all the needed use cases for archiver.bbclass :) that's a while ago now.. Jan 31 22:09:01 well, the recipe specific sysroot will likely be a big topic Jan 31 22:09:25 indeed Jan 31 22:09:40 i'm impressed with how smoothly the transition to rss has been, considering how high impact it is. RP did good :) Jan 31 22:09:51 we've not always had the best track record on the invasive changes Jan 31 22:09:57 (course most projects don't, really.. :) Jan 31 23:16:37 If I want to file a bug with the intel meta layer do I do that on bugzilla.yoctoproject.org or on OE? Jan 31 23:23:29 nvm: If you're relatively certain Jan 31 23:23:29 that it's a bug against the BSP itself, please use the 'Yocto Project Jan 31 23:23:29 Components: BSPs | meta-intel' category for the bug Jan 31 23:23:53 via gitweb about Jan 31 23:23:57 for meta-intel **** ENDING LOGGING AT Wed Feb 01 03:00:01 2017