**** BEGIN LOGGING AT Mon Jan 30 03:00:01 2017 Jan 30 07:06:59 RP: yeah, i saw the fix Jan 30 07:07:51 RP: when i had the chance to take a look at my git bicect results on saturday i noticed that you had already fixed the problem :) Jan 30 08:49:52 Hi There. I got a question on oe_runmake. if I configure EXTRA_OEMAKE = "'CC=${CC}' ... bitbake says "not found" cause ${CC} is the string "i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/..." and there is of course no file with this name Jan 30 08:50:39 what am I doing wrong? Jan 30 08:54:15 marquiz: sadly the times don't look much better for the changes :( Jan 30 09:04:53 Hi. is there anyone out there who could answer me a question? Jan 30 09:05:36 about oe_runmake and its configuration Jan 30 09:09:08 RP: yup :( Jan 30 09:12:09 could you tell me whats going wrong when i do CC=${CC} like it is stated in the documentation but bitbake means "not found" ? Jan 30 09:13:22 please Jan 30 09:14:04 Guest1016: there's something else going wrong. That same construct is used in many yocto recipes Jan 30 09:15:04 yeah i saw that and because of that i wonder Jan 30 09:16:29 it looks like oe_runmake tries to start "i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/..." Jan 30 09:17:29 and not i586-poky-linux-gcc with the parameters "-m32 -march=i586 --sysroot=/home/..." Jan 30 09:18:30 you think it is a fault inside the environment of bitbake? Jan 30 09:18:39 I doubt it Jan 30 09:19:18 are you sure that is what's happening? can you pastebin the recipe and the log? Jan 30 09:19:19 or the buildhost Jan 30 09:27:34 recipe: http://pastebin.com/MFjNYv0d Jan 30 09:30:21 Log: http://pastebin.com/ZLNqX3U0 Jan 30 09:42:35 what do you think about it? Jan 30 10:06:41 morning Jan 30 10:06:58 hi Jan 30 10:08:30 Guest63917: I believe CC value is 'correct' as in the makefile is expected to cope with that and normally they do... Jan 30 10:08:43 oops sorry, I mean Guest1016 Jan 30 10:09:23 ah ok. but why it fails then Jan 30 10:10:01 and what is not found Jan 30 10:11:08 if i say CC=i586-poky-linux-gcc it compiles but stoppes caust the headerfiles arnt found Jan 30 10:11:57 your Makefile probably does something that expects CC to be a filename. I don't see anything that points to headers not being found Jan 30 10:12:02 but that maybe another problem Jan 30 10:13:43 sorry I don't have great suggestions for a recipe workaround -- might be worth it to look in the Makefile, maybe it does something obviously weird with CC Jan 30 10:13:44 that happens if i just give i586-poky-linux-gcc to CC.... without the other parameters Jan 30 10:14:13 is the makefile ignoring CFLAGS? Jan 30 10:14:59 * rburton has only partial context, just realise its cutting the first word of CC and dropping the sysroot arg. Jan 30 10:15:03 the fix is to fix the makefile Jan 30 10:15:05 'cos its broken Jan 30 10:15:51 rburton yes exactly this was the issue http://pastebin.com/ZLNqX3U0 Jan 30 10:16:22 * rburton had zen like autoconf understanding this weekend, and i think i solved the aclocal/old macros problem for good Jan 30 10:16:46 and then you woke up? Jan 30 10:16:51 lol Jan 30 10:17:37 hmm ok that could be. i havnt wrote the make file so i have to debug it somehow Jan 30 10:20:19 ok i will contact the author of the makefile cause this isnt my home ;) Jan 30 10:20:33 many thanks for your help Jan 30 10:27:40 you think ignorring the CFLAGS could cause that "not found"-error? Jan 30 10:28:39 i am not that deep into makefiles Jan 30 10:31:33 RP: i think you mean ${datadir}/doc not /gtk-doc in your libxml2 patch Jan 30 10:31:35 rburton: are you going to take the UEFI patch series? I somehow managed to misuse "git series" in the latest revision and accidentally dropped the "[PATCH v4 02/12] acpica: work around flex 2.6.2 code generation issue" patch - it should still be needed. Jan 30 10:32:28 I can send another revision, if you want. Jan 30 10:35:11 rburton: not sure I did, it had gtkdocs here Jan 30 10:43:06 weird, my native build is dropping files into …./usr/share/doc/libxml2-2.9.4 Jan 30 10:46:34 rburton: I wonder if we have different tools installed? Jan 30 10:46:42 rburton: can we disable docs? Jan 30 10:47:14 RP: the docs are pregenerated so it just installs them Jan 30 10:47:16 rburton: sorry about the issues in mut btw, I think I solved things in my patches before I merged to master Jan 30 10:47:39 RP: yeah noticed it exploded but i've been feeling pretty dismal from saturday evening (and still do now) Jan 30 10:47:46 RP: have a look at ross/autoargh Jan 30 10:47:53 rburton: sorry to hear that :( Jan 30 10:49:58 rburton: "check that we have pkg-config in DEPENDS if pkgconfig is used" doesn't really match the description Jan 30 10:50:13 rburton: I like the idea Jan 30 10:50:15 damn i just squashed that and probably did it wrong Jan 30 10:50:29 ha, yeah, squashed too much away! Jan 30 10:50:35 whoopsie Jan 30 10:51:16 tl;dr: if when we patch a m4 file we bump the '#serial' in it, aclocal —install will install ours for us Jan 30 10:51:27 just need to test with gettext next Jan 30 10:53:17 rburton: I do like the idea although still wonder if we can get aclocal just to prefer our m4 files Jan 30 10:54:55 rburton: for some reason the gtk-doc in libxml2 was making it though the sysroot staging code but the others was getting removed without help. I therefore do think the patch was right... Jan 30 10:55:14 rburton: obviously not installing the stuff at all in the native case might be nicer again though Jan 30 11:11:29 rburton, ed2: Not sure where we're at with ed's patches? The ones in -next still trigger an oe-selftest failure. Have you a better set in -mut? Jan 30 11:12:59 mut has v3 Jan 30 11:13:39 looking at the ab it may have worked a bit better Jan 30 11:13:59 THIRTY SIX HOURS for selftest Jan 30 11:14:41 yeah the xml reporting stuff is broken Jan 30 11:19:50 RP: yes, he has all my patches in ross/mut as far as I can see. Jan 30 11:20:28 RP: they worked for me on Friday on mut, i.e. passed oe-selftest -r wic Jan 30 11:21:15 the ab wasn't happy thogh Jan 30 11:25:22 hello Jan 30 11:25:35 do_cleansstate() will call do_clean() also Jan 30 11:25:36 ? Jan 30 11:25:49 cornel: yes Jan 30 11:28:05 thank you RP Jan 30 11:39:16 rburton: please continue to ignore me ;-) My earlier comment about me having dropped a patch from the UEFI series was wrong, I merely compiled the recipe from meta-openembedded. I would never accidentally remove a patch, would I? Hmm... Jan 30 11:49:54 What happened to inclusion of shellcheck into OE-core? Some work was done on that, right? Jan 30 11:51:22 pohly1: sorry not ignoring you on purpose :) Jan 30 11:52:02 pohly1: verify-bashisms in scripts, realised over the weekend its broken with tinfoil2 Jan 30 11:53:59 rburton: no worries. If you agree, perhaps merge the UEFI patches. I'll look at verify-bashisms and might fix it, if no-one else is working on it. Jan 30 11:54:13 pohly1: that would be good thanks Jan 30 11:54:29 RP: just fired a mut selftest on the new builder to see what it does Jan 30 11:54:34 not convinced its in a happy place Jan 30 11:59:09 rburton: where did you get checkbashism.pl from? Google points to SF, which provides a "checkbashism" (no .pl suffix) file. Jan 30 12:00:21 hm Jan 30 12:01:44 good question Jan 30 12:03:29 it appears i ended up with a copy from debian's devscripts Jan 30 12:03:33 that's not very sensible Jan 30 12:03:41 (https://packages.debian.org/sid/devscripts) Jan 30 12:04:26 pohly1: https://anonscm.debian.org/cgit/collab-maint/devscripts.git/tree/scripts Jan 30 12:05:27 there's another tool i was going to switch to but i can't recall the name right now Jan 30 12:07:04 ah https://github.com/koalaman/shellcheck Jan 30 12:07:29 rburton: that's actually the one I was looking for, not checkbashism. Jan 30 12:07:53 Regarding checkbashism: the one from Debian seems to be better maintained. Jan 30 12:08:30 i must have copied the binary to my $HOME for testing and then forgot that i did that, sorry Jan 30 12:21:05 If I have RRECOMMENDS_${PN} = "foo" in recipe bar.bb, and foo.bb specifies COMPATIBLE_MACHINE = "armv7a" and I am building for MIPS, why does it fail with ERROR: Nothing RPROVIDES 'foo' (but bar.bb RDEPENDS on or otherwise requires it). The package foo is optional and I do not need it for the MIPS build. Jan 30 12:21:40 because bitbake wants to build all recommends so they're present in the feeds Jan 30 12:22:01 can you do RRECOMMENDS_${PN}_armv7a or similar? Jan 30 12:23:28 rburton: I can, but the point is I do not want bar.bb to care (it is a packagegroup). If the package is there, then fine use it, otherwise let it be... That is why I use the COMPATIBLE_MACHINE in foo.bb since it is the one that knows if it can be built or not. Jan 30 12:24:19 I do not see why RRECOMMENDS has to fail if the recipe does not exists. Jan 30 12:24:38 The whole point (to me) is that it marks an optional dependency... Jan 30 12:24:38 agreed, a patch seems like a good idea Jan 30 12:25:01 recommrends/suggests should not fail if they can't be built because they've been excluded Jan 30 12:26:59 rburton: Is there any difference if I RRECOMMEND something that does not exist at all? Typical example, if I RRECOMMEND something in a recipe in one layer that is provided by another layer, and that second layer is not included in my current build why does the build have to fail? Jan 30 12:37:19 RP: has the staging rework ended? Jan 30 12:41:27 haha, "cloud rot" Jan 30 12:41:42 https://lwn.net/Articles/712318/ Jan 30 12:42:17 also: "The new dependency hell [...] A "hello world" application based on one JavaScript framework has 759 JavaScript dependencies; this framework is described as "a lightweight alternative to Angular2". There is no way he is going to package all 759 dependencies for this thing; the current distribution package-management approach just isn't going to work here. " Jan 30 12:42:31 Yocto will probably hit this issue at some point as well :-/ Jan 30 12:44:23 RP: ah, again on deltask, I see you selectively drop do_populate_sysroot Jan 30 12:45:25 so this should simplify sstate, for any recipe I bet Jan 30 13:05:51 the openssl recipe does this during install: "ln -sf ${sysconfdir}/ssl/certs ${D}${libdir}/ssl/certs" Jan 30 13:07:36 this works on target (link points to /etc/ssl/certs), but is broken for native: in a native sysroot the link points to "./../../../../../../work/x86_64-linux/openssl-native/1.0.2j-r0/recipe-sysroot-native/etc/ssl/certs" ... Jan 30 13:10:12 that is from _wayland-native_ recipe-sysroot-native-directory. The linked file doesn't even exist but even if it did, that looks really wrong (it's a completely different sysroot) Jan 30 13:10:52 is there something wrong with how the link is created? Jan 30 13:16:26 jku: I wonder if we broken this with rss Jan 30 13:16:27 maxin, anyone: I'm having problem getting libtasn1-native built with OE-core master. First it failed because of "yacc: command not found", after addding DEPENDS = "byacc-native" it fails with a syntax error error in ASN1.y. Jan 30 13:18:08 RP: I think so Jan 30 13:18:34 jku: what is supposed to happen is the paths are meant to become relative in the relocation code Jan 30 13:19:38 RP: Maybe you can explain to me why an RRECOMMENDS on some non-existing recipe must lead to a build error? (And the non-existence can be caused by COMPATIBLE_MACHINE, BBMASK, the non-existing recipe being in another layer that is not part of the current build, or that it just does not exist yet). Jan 30 13:21:01 jku: if it's any consolation, after dnf I'm going to look at openssl 1.1, and the plan is to throw away existing recipe entirely :) Jan 30 13:21:05 pohly1: haven't tested it.. will check now Jan 30 13:21:07 RP not sure where that is, can you point me to right direction? Jan 30 13:21:46 maxin: that's with recipe specific sysroots. I'm currently checking whether libtasn1 for the target still builds. Jan 30 13:22:29 Saur: RRECOMMENDS are treated as a package management feature and real dependencies as far as the build process is concerned. Yes, we could ignore them but it would lead to non-deterministic builds Jan 30 13:23:28 pohly1: just did a libtasn1-native (4.10) with musl and it works as expected. Jan 30 13:23:51 jku: make_relative_symlink() in sstate.bbclass Jan 30 13:23:57 cheers Jan 30 13:24:40 RP: Hmm. In the specific case I have a RRECOMMENDS_${PN} = "foo" in recipe bar.bb, and foo.bb specifies COMPATIBLE_MACHINE = "armv7a" and I am building for MIPS and of course i get an error due to this. But it just seems wrong... Jan 30 13:25:35 Saur: I understand, however the alternative would be potentially large pieces of builds disappearing with no error/warning due to typos Jan 30 13:25:55 Saur: I prefer determinism Jan 30 13:26:18 maxin: which "yacc" implementation is called when building libtasn1-native? Is it perhaps the one from your host? Jan 30 13:27:18 DEPENDS = "bison-native" fixes the problem for me. byacc-native was something else. Jan 30 13:27:28 (byacc instead of just yacc). Jan 30 13:28:40 RP: Ok, in the general case I can understand your concern. But in the case of RRECOMMENDS on something that is excluded due to COMPATIBLE_MACHINE I think it is deterministic. Or am I missing something? Jan 30 13:29:32 RP: what is the difference between RRECOMMENDS and RDEPENDS then? Jan 30 13:30:16 pohly: I have bison in my host.. probably that explains it ( bison --version bison (GNU Bison) 3.0.2) Jan 30 13:30:36 Saur: people often complain about this and COMPATIBLE_HOST and the distro features code. I'm sure we could create something which recurses up the build system try, disabling anything that depends on these things automatically. The trouble is user visibility into the process and knowing when to stop. Jan 30 13:31:04 RP: ah right, NO_RECOMMENDATIONS Jan 30 13:31:12 Saur: If we implement it, I can guarantee that things you want in your build would silently disappear and then you'd be getting upset that these were silently removed Jan 30 13:31:12 RP: I fixed this myself the other day :-/ Jan 30 13:31:21 and already forgot :) Jan 30 13:31:43 kanavin: They are used by the package manager differently, for example installation of kernel modules verses builtin Jan 30 13:32:40 I wonder... should bitbake also sanitize "PATH", at least optionally? I.e. set up tmp/work/sysroot-native/bin etc. with symlinks to the assumed provided tools, then run with PATH containing only the "clean" directories? Jan 30 13:33:04 Saur: You might not like the current situation but its at least quite clear. The alternative would just be a nightmare to maintain. It would also be painful in bitbake's dependency code and I don't think we need more complexity there Jan 30 13:33:19 ASSUME_PROVIDED will make that a bit harder, though. Jan 30 13:34:02 pohly1: In one of my experiment patches, I created symlinks to speed up searching for binaries in PATH, reducing the number of stat calls needed Jan 30 13:34:24 pohly1: couldn't prove a speed increase though Jan 30 13:34:41 RP: Could an alternative solution to the RRECOMMENDS + COMPATIBLE_MACHINE be a new bbclass that lets th package build as normal for compatible machines, but just creates an empty package for others? Obviously one cannot set COMPATIBLE_MACHINE then, but instead would set some other similar variable. Jan 30 13:35:01 Saur: no. Really not going there. Jan 30 13:35:14 RP: just getting the build to be less dependent on the host already would be worthwhile, IMHO, even if there is no speed increase. Jan 30 13:35:29 RP: Well, the idea would be to inherit the class in the specific recipe, so that it is obvious what is happening. Jan 30 13:36:43 Saur: might as well just code the recommends in a common include/class file Jan 30 13:37:01 Saur: creating an empty package just to solve this is horrible Jan 30 13:39:14 rburton: continuing the python modules issue from last week, this is the dependency line I ended up with: python-core python-codecs python-netclient python-email python-threading python-distutils librepo python-shell python-subprocess libcomps libdnf python-sqlite3 python-compression python-pygpgme python-backports-lzma python-rpm python-iniparse python-json python-importlib python-curses python-argparse Jan 30 13:39:38 rburton: do you think that's a bit much, and just depending on python-modules is better? Jan 30 13:40:07 kanavin: not for target usage Jan 30 13:40:51 RP: yeah, this is in fact RDEPENDS_${PN}_class-target of dnf Jan 30 13:54:45 kanavin: I'd say its reasonable Jan 30 14:01:57 If I have an anonymous python function that calls bb.warn() it will produce a warning during recipe parsing that is prefixed with the recipe name, which is fine and what I want. However, it will also produce warnings later on during building, and they are not prefixed with anything. Is there some easy way to determine that it is the first case that is running and only produce the warning then? Jan 30 14:10:19 ed2: test_qemu fails here for me with ross/mut Jan 30 14:10:35 ed2: /dev/vda2 != /dev/root Jan 30 14:13:34 rburton: oh, again :( I'll look at it. Jan 30 14:14:35 rburton: i tested wic multiple times with my patches on top of ross/mut on Friday. all oe-selftest wic test cases were passed. Jan 30 14:19:16 ed2: should test_qemu expect a specific machine? i use intel-corei7-64 here. Jan 30 14:22:27 rburton: I usually run tests on qemu* machines. Jan 30 14:23:18 rburton: I'm not sure if intel-core7-64 images can be run on qemu. never tried Jan 30 14:23:26 the test should either set machine if it has to, or adapt to cope Jan 30 14:23:45 rburton: but it's not the case. that failure usually happens due to wrong WKS_FILE value. Jan 30 14:46:44 rburton: ed2: we recently added support for running meta-intel BSPs in QEMU Jan 30 14:58:38 Hello, Just wanted to build qtwebkit package with QtMultimedia backend instead of gstreamer , what should should it requires in qtwebkit_git.bb file ? Jan 30 15:01:45 Hello, how can I have a recipe depend on a user added through USERADD Jan 30 15:02:27 I'm getting some host contamination warnings and I think its because the recipe doesn't have the user required by the files for ownership Jan 30 15:13:01 hmm, why does building core-image-sato fail with "| configure: error: unable to find usable PCRE library" in rpm(?) Jan 30 15:13:24 does not seems to happen on all build hosts Jan 30 15:20:03 RP: I realized that creating an empty package was not needed at all, and rather defeated the purpose. However, here is the class that I did implement to solve my problem: http://pastebin.com/JSYfVjyc Jan 30 15:20:59 RP: It allows me to set SUPPORTED_MACHINE instead of COMPATIBLE_MACHINE and then produces a package for the supported machines. For any other machines it will not produce an image and instead produces a warning. Jan 30 15:21:52 RP: This makes RDEPENDS and RRECOMMENDS work with packages that inherits the class the way I want. :) Jan 30 15:24:53 Saur: Whilst I'm sure it works for you, I'm not convinced we want to encourage things like that Jan 30 15:25:33 RP: Well, it is a bit of a special case... :) Jan 30 15:29:47 Saur, conversations like that suggest an email to the architecture list would be nice to see if other peope have similar issues Jan 30 15:54:44 rburton: zeddii might have just found a long hidden native dependency of at-spi2-atk on glib-compile-schemas, I am working on a patch Jan 30 15:55:26 i wouldn't be surprised if some stealth deps on common host tools sneak out of the woodwork Jan 30 15:55:29 like glib-native Jan 30 15:56:11 rburton: yup glib-2.0-native to be exact in this case, patch forthcoming Jan 30 15:58:38 yeah thats the one Jan 30 16:49:05 I want to make some helper script available that wraps some commands in a native sysroot. I could make that a stand-alone recipe like "wic-tools" which then calls binaries installed in its recipe-sysroot-native. But how do I create the script itself, and where? Jan 30 16:50:57 The easiest solution would be to put it into $WORKDIR in do_compile, but then I must ensure that the tasks always runs (i.e. disable sstate). How can that be achieved? Jan 30 16:59:55 pohly1: why not just install from mytools-native into the native sysroot and depend on that where you need it? Jan 30 17:02:01 rburton: the path to the native sysroot into which mytools-native installs is very deep and user unfriendly. Jan 30 17:02:59 It's *not* mytools-native/1.0-r0/recipe-sysroot-native - that only has the tools mytools-native itself depends on. Jan 30 17:04:16 The file created in do_compile ends up in sysroot-destdir with a full absolute path beneath it. Jan 30 17:04:30 you shouldn't be manually calling anything in workdir, ever Jan 30 17:05:19 wic-tools is a special case for image construction, but that isn't run manually either, it's run from another recipe Jan 30 17:05:24 so the depth of the path is irrelevent Jan 30 17:05:30 i must be confused Jan 30 17:05:38 understandable because i'm feeling like death warmed up today Jan 30 17:06:11 so one downside of recipe sysroots is that deleting tmp/ takes FOREVER Jan 30 17:06:31 Before the recipe specific sysroot changes, it used to be kind of okay that one called binaries from tmp/sysroots/x86-64 directly on the build host. What's the right way of providing tools to the developer now? Jan 30 17:06:37 I guess that's my question... Jan 30 17:06:40 kergoth: ^^^ Jan 30 17:06:41 pohly1: are you using rm_work with rss? are you noticing some issues with it? Jan 30 17:07:13 I see all incremental builds failing in random places so I wonder if rm-work is cause of that Jan 30 17:07:26 JaMa: sorry, no idea. Jan 30 17:07:29 Haven't tried. Jan 30 17:07:41 ok Jan 30 17:07:46 Need to go now, back later... Jan 30 17:07:51 manually running files in the global sysroot was never a good idea. the fact that it happened to work was luck, not intention Jan 30 17:08:22 that said, writing wrapper scripts with accompanying recipes should be fairly straightforward.. Jan 30 17:08:40 i.e. a script in contrib that builds a corresponding recipe and adds its native sysroot to the PATH and runs the real underlying script Jan 30 17:08:41 * kergoth shrugs Jan 30 17:09:44 kergoth: yes, that's exactly what I try to achive, and it's currently not clear to me where that script should go and how to create it. Are there examples, besides runqemu (which isn't created)? Jan 30 17:09:53 Anyway, really need to go. Jan 30 17:10:04 today's wee python hack: http://pastebin.com/WdbevrYt Jan 30 17:10:05 runqemu isn't created, but it does depend on native recipes for its helpers, so is along similar lines Jan 30 17:10:32 rburton: cute :) Jan 30 17:11:18 kergoth: was writing save/restore environ code and realised with is perfect Jan 30 17:12:09 i'm never quite sure how to feel about context managers that technically affect the entire process, but it does work fine generally Jan 30 17:12:25 yeah environ is a bit evil Jan 30 17:12:41 tempted to fiddle the bits of OE that i'm calling so it doesn't have to touch it Jan 30 17:16:04 Hello - my initramfs has a copy of my kernel in it. Jan 30 17:16:39 I ran "bitbake -g -u depexp core-image-mysys-initramfs" and while linux-yocto shows up in the list, it has no reverse depends. Jan 30 17:42:01 rburton: I've noticed they take an age to delete too. So many hardlinks :( Jan 30 17:50:11 alimon: how do I get oeqa/runtime/_ptest.py to run? Jan 30 17:50:40 rburton, RP: wonder if rm_work should just become default at some point, at least then the removal is distributed over time Jan 30 17:50:40 heh Jan 30 17:50:44 alimon: it doesn't seem to be enabled anywhere in testimage.bbclass, and I don't know where else to look Jan 30 17:51:49 kergoth: If only rm_work wasn't a horrible hack :/. I keep trying to find a way to better integrate it but its hard :/ Jan 30 17:51:53 true Jan 30 17:52:27 kergoth: I'm a little disappointed at how much overhead rss is having :( Jan 30 17:52:45 kergoth: considering a patch to make the native .pc files relocateable and dropping .la files Jan 30 17:52:58 (less files that then need sed treatment) Jan 30 17:53:11 * kergoth nods Jan 30 17:53:21 Also, binutils link scripts are rather a mess with some odd paths we never use afaict Jan 30 17:53:52 do we have anything in the system that still -needs- .la files? Jan 30 17:54:02 fray: I doubt it on linux Jan 30 17:54:22 kanavin: atm is broke (previously too), it need to be fixed and enabled in the Autobuilder Jan 30 17:54:54 kanavin: i think mariano have the task and a bug... Jan 30 17:54:56 I think dropping .la files in general is a good thing Jan 30 17:55:15 .la files are an out dated concept to support broken systems (AIX/Solaris/etc) Jan 30 17:55:21 khem: we just run the risk of breaking by deviating from libtool's preferred way of working... Jan 30 17:55:21 so I'd hope we can safely drop them Jan 30 17:55:32 does anyone care about libtool's preferred way of working? :) Jan 30 17:55:48 * fray hates autoconf, but libtool is 100x worse.. Jan 30 17:55:51 almost has bad a perl Jan 30 17:56:00 only 100% worse? Jan 30 17:56:00 kergoth: well, there is that :) Jan 30 17:56:26 kanavin: for example the whole logic for install packages isn't needed, since we build the core-image-sato-sdk-ptest image Jan 30 17:56:29 * RP also wishes the gnupg people would start using pkgconfig Jan 30 17:56:50 kudos to anyone else who raises that on their mailing list btw ;-) Jan 30 17:57:34 RP: would be nice to stop needing the sed replacements at all. pkgconfig sysroot and wrapper scripts should be able to cover 90% of it, if the wrappers are tweaked to go by their own location rather than needing sed replacements themselves Jan 30 17:57:46 alimon: okay, the reason I'm asking is that I just ported runtime/smart.py to runtime/dnf.py :) and _ptest was next to be fixed :) Jan 30 17:57:51 RP: gentoo ditches libtool too, we cant be worse Jan 30 17:58:01 alimon: but I guess I can leave it alone then! Jan 30 17:58:19 kergoth: how do you relocate the wrapper scripts? :) Jan 30 17:58:20 kanavin: yep Jan 30 17:58:31 alimon: and it probably won't even need to use package installation with dnf at all Jan 30 17:58:40 RP: adjust them to go by $0 with relative paths, so they don't need it Jan 30 17:58:40 kergoth: seriously, the wrappers need to learn how to find their cwd to be able to solve that one Jan 30 17:58:49 alimon: what's mariano's nickname, I'd like him to see this conversation Jan 30 17:58:52 kergoth: right Jan 30 17:58:53 i have recieps that do so without even needing to modify create_wrapper Jan 30 17:59:36 would obviously be a fairly substantial effort, lots of breakage to fix.. i'll see if i care enough.. Jan 30 18:00:00 kergoth: if you want to feel sad about the enormity of it, "cat tmp/sysroots-components/x86_64/*/fixmepath" Jan 30 18:00:33 path relocation issues have always annoyed me. rather tempting to just wrap every binary that ends up in the sysroot bindir to use process namespaces to relocate via bind mount all a recipe's scripts to point at a path they're configured to run in Jan 30 18:00:48 wouldn't need per-recipe wrapper construction to do that, in theory Jan 30 18:01:58 i.e. —prefix=/oe, then mount the recipe's content there for the process Jan 30 18:02:48 bit messy with per-recipe sysroots for deps, though, unless you mount the deps in predictible paths too Jan 30 18:03:18 hrmph Jan 30 18:03:59 that would be a rather interesting possibility, actually. avoid all the hard linking in favor of predictable process namespace mounts and PATH adjustment Jan 30 18:04:03 hmm Jan 30 18:04:53 obviously only helps the native bits, still need the sysroot for linking Jan 30 18:04:58 * kergoth gets more coffee Jan 30 18:06:53 though if you adjusted the mounts in a way that affected the toolchain, you could handle linking deps the way nix does. i.e. —with-some-lib=/oe/that-other-thing/lib Jan 30 18:07:43 wonder how much overhead that would impose.. possibly not much, since the kernel / vfs would be doing most of the work Jan 30 18:12:15 kanavin: just a question, did you modified the smart test with current master, it did changed a lot Jan 30 18:13:09 justanotherboy: no, I'm currently basing my work on a version of master from December 20th Jan 30 18:13:26 justanotherboy: I will rebase it, but it's a task in itself, because of rss and oeqa rework Jan 30 18:13:35 justanotherboy: for now I have many other issues to solve still :) Jan 30 18:14:11 kanavin: Indeed, is not THAT hard, but the current branch won't work Jan 30 18:14:51 kanavin: dnf also needs createrepo to create the index, right? Jan 30 18:15:07 justanotherboy: createrepo_c :) Jan 30 18:15:16 rburton: I thought I saw this patchset http://lists.openembedded.org/pipermail/openembedded-core/2017-January/131679.html in ross/mut at some point. Now I don't see it there anymore. Jan 30 18:15:26 rburton: any problems with it? Jan 30 18:15:36 justanotherboy: I've removed old python implementation and replaced it with the current C implementation Jan 30 18:15:43 (of createrepo) Jan 30 18:18:18 kanavin: Nice that should speed index creation, just don't forget to add it to testimage class, I just discovered that we need for QA team. Jan 30 18:20:11 hmm, could even do read only bind mounts for everything we don't want it to be able to write to.. Jan 30 18:21:47 do we put the latest recipe report on wiki as well ? or just email Jan 30 18:22:12 justanotherboy: I think that should cover it https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/diff/meta/classes/testimage.bbclass?h=akanavin/dnf-rpm4&id=d1ad23e3e2cdc30dd0ea23d77c498c58d1d1d415 Jan 30 18:22:55 kanavin: indeed Jan 30 18:26:51 rburton: oe-selftest -r wic.Wic.test_qemu passed in my intel-corei7-64 target :( Jan 30 18:27:21 rburton: I'm using your branch Jan 30 18:40:23 rburton: all wic tests passed Jan 30 18:49:22 ed2: did the tests run in the same order? There is something not right :/ Jan 30 18:50:30 RP: i think unittest runs them in alphabetical order, so yes, the order should be the same. Jan 30 18:53:21 RP: I've noticed one nasty behaviour of oe-selftest: it restores backup configs when test is interrupted by Ctrl+C. So, if I edit config files when tests are running and then press Ctrl+C all my changes disappear. Jan 30 18:54:04 RP: I'm not saying this is the case here, but probably something similar, i.e. configuration issues. Jan 30 18:54:39 RP: I hope they'll pass on AB as it uses clean configs (hopefully). Jan 30 18:56:23 RP: I used clean new target for my experiment and all tests passed. Jan 30 19:10:10 /quit Jan 30 19:37:58 ed2: https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/168/steps/Running%20oe-selftest/logs/stdio <— worked for me ab too Jan 30 19:38:09 ed2: for, for the ab too Jan 30 19:38:14 so no idea why it broke here Jan 30 19:39:57 rburton: that's a great news. I thought I'll have to fix it again for the 3rd time :) Jan 30 19:40:28 rburton: did you see my question about http://lists.openembedded.org/pipermail/openembedded-core/2017-January/131679.html ? Jan 30 19:40:47 rburton: did it break something? Jan 30 19:51:30 RP: could it be that bb.event.RecipeTaskPreProcess doesn't fire for native recipes? Jan 30 19:53:43 I see in "bitbake -c listtasks my-native-recipe" that there is a do_rm_work tasks, but "bitbake -g my-native-recipe" does not list it and it also doesn't run, i.e. the actual dependencies never got added. Jan 30 19:53:56 my-native-recipe inherits native.bbclass. Jan 30 19:54:05 I just checked with qemu-native, there it works :-/ Jan 30 19:54:52 Hrmm. Need to dig deeper. Jan 30 21:00:37 What does _ exactly do to a variable? I have a custom image class, along with a IMAGE_CMD_test. Now I created a distro test, and somehow this seems to interfere Jan 30 21:01:40 NAME_foo replaces NAME whenever the special variable OVERRIDES contains foo Jan 30 21:01:47 falstaff: those are called "overrides" Jan 30 21:01:50 The distro name is one of the default overrides Jan 30 21:02:26 Oh ok... So naming a image class test and a distro is then not a good idea I guess? Jan 30 21:03:27 falstaff: well, the image class name here isn't important, the name of the IMAGE_FSTYPES item you're creating is Jan 30 21:05:36 Hm, afaik with IMAGE_CMD_test I created a name valid for IMAGE_FSTYPES? Jan 30 21:06:33 So I did IMAGE_CLASSES += "image_type_test", IMAGE_FSTYPES = "test", and defined in image_type_test.bbclass IMAGE_CMD_test... Jan 30 23:05:47 hi Jan 30 23:06:17 if one says "yocto BSP" does that typically include the kernel image, or just the SDK? Jan 30 23:07:25 robsta: BSP usually means the hardware support piece Jan 30 23:08:47 RP: now i'm even more confused, could you clarify? Jan 30 23:08:58 what is the HW support piece Jan 30 23:09:57 robsta: the kernel, the graphics support (kernel modules, GL library), definition of what the hardware looks like (pci tools, i2c tools), type of bootloader etc Jan 30 23:11:31 RP: so what's the correct name for image+bsp produced by a YP? Jan 30 23:12:03 er, bsp+sdk Jan 30 23:13:23 robsta: I'd class the input metadata as the bsp, the output would be a sdk Jan 30 23:13:41 robsta: not everything has a neat name :/ Jan 30 23:23:16 RP: i've heard PDK (platform development kit) being used and liked it Jan 30 23:24:06 robsta: that works Jan 30 23:28:34 cool Jan 30 23:41:42 khem: any thoughts on http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=b3ea1fa58756fa7762c9f93e1194f52831ea1e5f ? **** ENDING LOGGING AT Tue Jan 31 03:00:01 2017