**** BEGIN LOGGING AT Tue May 14 02:59:57 2019 May 14 09:18:53 morning yocto people, if i create an image recipe and add a bunch of packages to IMAGE_INSTALL, will only those packages and their dependencies be built? May 14 09:19:07 note not just installed but built May 14 09:22:38 milloni: those packages, their dependencies, and whatever else is needed to produce them is built May 14 09:23:08 LetoThe2nd: and nothing other than that? May 14 09:27:21 milloni: there might be non-obvious reasons, but generally thats the concept, yes. May 14 09:28:23 ok, what about installing, obviously not all packages needed to build those packages need to be installed (for example the compiler) May 14 09:28:40 how does yocto distinguish between build dependencies and runtime dependencies? May 14 09:29:56 milloni: DEPENDS: build time dependencies. RDEPENDS: runtime dependencies May 14 09:30:08 got you May 14 09:30:12 thanks May 14 11:34:04 are there any ways in distro config to remove layer, machine and bbclass additions? some BSP layers just plain broken, intrusive and messed up... May 14 11:34:52 using BBFILTER to disable recipes and bbappends, but that still leaves bbclasses, machine and layer configs to screw things up.. May 14 11:36:49 the classes I thought were added via the BBPATH.. so you'd have to filter that May 14 11:55:28 mcfrisk: what is BBFILTER? do you mean BBMASK? May 14 12:00:07 JaMa: yes, meant BBMASK. sorry May 14 12:03:29 what distro are you using? why don't you just stop including the layers which are plain broken for your needs? May 14 12:05:11 they are BSP layers but so some recipes are needed, like kernel etc. but they do more crap in their bbclasses and layer/distro/machine configs. broke useradd things now for me.. May 14 12:11:18 ok "some recipes are needed" was the part which I was missing in the original question, so I was wondering why not remove the whole layer from bblayers.conf when it's so broken May 14 12:23:18 BSP layers seem to have a habit of turning into complete SW stacks for proof of concept boards and devices with hacks and dependencies all the way up to GUI tools, webkit etc. May 14 12:26:07 Unfortunately the majority of them May 14 12:27:48 true, unfortunatelly it also means that things like webkit doesn't work well with majority of devices without device specific hacks (and sending those device specific hacks to e.g. oe-core webkit recipe won't be accepted as well) May 14 12:31:09 Is ${DATE} the only information that we could add to ${DISTRO_VERSION}? I would like to add something like `git describe --contains --tags --always` instead which seems a lot more useful that a simple date. May 14 12:32:31 alessioigor: that's what I do. we've removed DATE from everywhere and use git information instead. we also use git submodules for layers so for dirty builds we have a custom hash generator based on the actual git status and git diff. May 14 13:10:30 New news from stackoverflow: iptables command returns "No chain/target/match by that name." May 14 13:33:59 RP: Well, good news is I got the reproducibilty OE self test working... bad news is diffoscope took 1.5 hours to process sstate from core-image-minimal and produced gigabytes of logs. May 14 13:40:25 alimon: Are you here? I had a question about your notes on the reproducible build May 14 13:41:38 JPEW: yes May 14 13:43:29 alimon: I noticed that you recommend comparing the populate_sysroot sstate files... any reason why those and not the package files (e.g. .deb, .ipk?) May 14 13:46:03 JPEW: if i remember correctly is because not all package formats supports reproducible builds May 14 13:47:06 https://wiki.debian.org/ReproducibleBuilds/Howto May 14 13:49:51 alimon: Ah, so we'll probably need to generate sstate tarballs with the arguments to force the user and group to 0 May 14 13:51:27 JPEW: there is the PACKAGE_CLASSES = "package_tar ..." and could be used to test May 14 13:57:38 alimon: Ok, I'll give that a try.... I *think* the tar package files might be a better comparison since they should have the target owners and permissions encoded in them? May 14 13:59:36 JPEW: right, also there is --clamp-mtime and --mtime options May 14 13:59:50 to deal with timestamps May 14 14:00:06 alimon: Yes, I saw that... I also got a lot of timestamp differences when comparing sstate May 14 14:12:57 JPEW: that isn't so good. I should forward you some info Juro sent me May 14 14:23:00 RP, the ptest patches ran clean a-full: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/154 May 14 14:31:27 nm, ptest is still running May 14 14:41:15 armpit: it shouldn't be :/ May 14 14:42:13 seebs: around? I have more reliable UID/GID mismatch issue with pseudo May 14 14:43:22 ooh? May 14 14:44:01 seebs: http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/pseudo2 May 14 14:44:33 cherry-pick last 2 commits and just bitbake pseudo-test, should trigger that warning on ~10 files May 14 14:45:22 or I can give you qmake binary + generated Makefile which should in theory reproduce it as well May 14 14:46:34 huh. so qmake install seems to be doing it? May 14 14:47:08 only together with mv overwriting some of the files at the same time May 14 14:48:06 it's all in parallel, so there might be some race between the mv and qmake -install creating the file May 14 14:49:13 not sure if this has the same root cause as what we're seeing with glibc-locale (or luna-init which is just unpacking tar archive under pseudo) May 14 14:51:09 in general, pseudo should be robust to fairly arbitrary races between things moving files around and doing file ops, so if it's breaking, it's *almost* always because some call isn't being caught. May 14 14:54:13 in this case it's reproducible with the renameat2 explicitly disabled in qmake, now trying with it explicitly enabled May 14 14:55:31 and I'm running it on 2.27 glibc ATM, so it's not related with 2.28 glibc discussed in https://github.com/meta-qt5/meta-qt5/issues/187 May 14 14:56:46 RP, going to kill it May 14 14:57:09 hmm, need to switch to newer ubuntu with 2.28 before explicitly enabling renameat2 in qmake May 14 15:00:19 RP: fray: ndec: i'll start then :) May 14 15:15:14 seebs: with renameat2 explicitly enabled in qmake it doesn't trigger the issue May 14 15:17:31 * zeddii was watching the twitch stream and realized a meeting was on May 14 15:22:32 Hi, I'm searching a way to have a "develop" image on top of the stable, in which some of the recipes have AUTOREV when fetching. There is a standardized way of doing this? May 14 15:25:45 ektor-5: people usually create .inc file setting SRCREV_pn-foo = "${AUTOREV}" May 14 15:26:00 JaMa: That's interesting, because what pseudo does with renameat2 is explicitly fail it and not attempt to use it. So if qmake is explicitly calling renameat2, it should just be completely failing. May 14 15:26:20 Like, it should be trying the call, having it fail, and presumably giving up since renameat2 was explicitly configured...? Weird. May 14 15:26:30 I wonder if it's checking for a different errno than pseudo sets. May 14 15:26:44 i may have to actually bite the bullet and develop a protocol that allows renameat2 operations. May 14 15:27:04 seebs: or it might be that my reproducer fails to install anything, so it doesn't trigger the QA check at the end, let me check May 14 15:27:13 which, it turns out, is fairly hard, because it requires doing a pair of fancy update operations on the db atomically. May 14 15:27:21 JaMa: where pn-foo is the image name? May 14 15:28:03 i'm gonna have limited bandwidth for investigating for the next few days, i'm afraid. for various reasons, we ended up with a kid who is old enough to need housing and are getting a house. look. any *given* decision involved in this process was reasonable. May 14 15:28:47 seebs: looks like it failed as you said Error copying /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/pseudo-test/1.0-r0/pseudo-test-1.0/005.txt to /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/pseudo-test/1.0-r0/image/005.txt: Cannot create /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/pseudo-test/1.0-r0/image/005.txt for output May 14 15:29:11 seebs: will add something to the pseudo-test.bb to also report when the files weren't installed correctly May 14 15:29:21 okay. ugh. May 14 15:29:50 the basic problem: to implement renameat2, we have to be able to do two updates to the database in parallel which swap a bunch of path entries. May 14 15:29:53 or at least let make fail on any error detected May 14 15:29:55 make: [Makefile:49: R024] Error 3 (ignored) May 14 15:30:02 Basically, this is the 's/foo/bar/g; s/bar/foo/g' problem. May 14 15:30:41 hmm. so if it's *not* using renameat2, it's doing something else which is then failing. it might be that it's trying the renameat2 call and getting an unexpected errno back. dunno. May 14 15:30:49 seebs: but if the issue is reproducible with qmake not using renameat2, does it mean that it's actually the mv breaking the db? May 14 15:31:11 halstead: "Your message to yocto-ab awaits moderator approval" ;-) May 14 15:31:11 possibly. or it could mean that qmake is then doing something *else* which is breaking things. May 14 15:31:22 i'll look when i have time, but time may be limited for a bit May 14 15:33:08 seebs: this is the code https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfilesystemengine_unix.cpp#n1251 May 14 15:36:21 seebs: it used to do syscall before, but that was already removed in https://code.qt.io/cgit/qt/qtbase.git/commit/src/corelib/io/qfilesystemengine_unix.cpp?id=b7887f9b4faad2227691a2af589e9d7680d6ae08 May 14 15:42:00 tlwoerner, Approved. Along with some older messages that were missed. May 14 15:42:10 halstead: thanks :-) May 14 15:48:05 seebs: based on the error message, it looks like the qmake -install is actually failing in this function https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfile.cpp#n769 will debug a bit more to see if it e.g. tried to copy the file only after the initial call failed because of error code from pseudo May 14 15:48:32 ah-hah May 14 15:48:59 line 1256 is sort-of the culprit: it's assuming that the only valid response is EINVAL for indicating that renameat2 didn't work. But we used ENOSYS. May 14 15:49:31 It may be worth trying just changing pseudo to use EINVAL to fail renameat2 in the libc-wrapper variant. May 14 15:49:58 then i'd guess that qmake would "work" in the sense of installing things, but you might still see whatever race condition... May 14 15:50:45 ndec: so. sorry for the date hiccup... thanks for being around, and hopefully more viewers next time. i'll be on date, promised. May 14 15:51:10 seebs: but with the -no-feature-renameat2 (or schnitzeltony's patch this whole chunk 1251-1260 is disabled/removed and still triggers the QA issue May 14 15:51:11 LetoThe2nd: sorry I didn't make it over, I had the engineering call which conflicts :/ May 14 15:51:42 RP: all is well. was a small audience anyways due to me being off by one May 14 15:52:13 yeah. so i think something else is actually triggering the issue, and the reason that enabling renameat2 appears to untrigger the issue is actually just that it breaks qmake so badly nothing is installed to be installed incorrectly May 14 15:52:14 wheeee May 14 15:52:23 why did i ever think this was a good idea May 14 15:53:09 seebs: hehe May 14 15:53:53 I've updated the recipe to fail (just removed - before the qmake -install call) May 14 15:54:31 seebs: btw, I keep meaning to ask you, are you ok with changing to SPDX license headers in pseudo? We're trying to do this consistently across all of the Yocto Project components. If so, any preference on how we do it (someone sends patches, I can always merge if you don't want the hassle etc) May 14 15:54:59 I was also searching where it started to fail and it looks like qtbase started to use qmake -install relativaly recently (so it wasn't failing before, because qmake didn't generate qmake -install in the Makefiles at all) May 14 15:55:09 I don't know what SPDX license headers are. I don't think I'm authorized to change the licensing terms, but I have no opinion on how the license terms are presented. May 14 15:55:42 i do recall having been bitten at least once by forgetting to change the template used to create new guts files when a new function is wrapped. May 14 16:00:40 let's say I have as target an image-minimal-runtime and an image-minimal-sdk, any hint on how I can make the version override only for the sdk image? May 14 16:07:12 armpit: if that patch hangs, I'd really want that fixed before we consider merging it... May 14 16:11:29 RP, that is a concern of mine too. its going to be fun trying to debug it May 14 16:21:58 armpit: I'm unlikely to merge until we have answers on that May 14 16:24:41 I would not expect anything else. I just the current run again once I am in the office in a few hours. May 14 16:48:28 Thud's glib-extra-nss packages doesn't provide nis and nis+ library anymore. Is it a know issue? May 14 16:57:09 arm May 14 16:59:24 Crofton: leg May 14 17:12:59 any clues why the override DEFAULT_PREFERENCE_pn-foo = "1" in bb recipe is not working? May 14 17:18:42 seems to work for any other type of override though, but not for the image name May 14 17:38:51 seebs: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ffae400179fd0b64f8882cf79d78e1c0f2d74bee was what we did with OE-Core. Basically add SPDX-License-Identifier: lines to the source and cleanup. Its not changing the license terms at all, just the way its presented May 14 17:39:07 seebs: makes the license clear and machine readable May 14 17:41:02 fine by me. i think pseudo should all be LGPLv2. May 14 17:42:02 seebs: right, makes sense. I basically agreed we'd lead by example with YP's code. The kernel, uboot and others are also doing it May 14 17:42:08 my top commit is 3fa7c853, if you want to apply those changes and push a commit on top of that, feel free, i'll try to remember to fetch it before i make any other changes. May 14 17:42:41 seebs: I don't have a patch ready yet, I wanted to talk with you first and check you didn't have concerns May 14 17:46:14 yeah. i just meant "if you want to change it like that, go ahead, that seems like it'd be a friendly thing to do". May 14 17:46:25 seebs: ok, cool :) May 14 17:46:27 i have seen horrifying things trying to do license auditing. May 14 17:55:25 RP: How does uninative work? I thought it meant that building native tools would be linked with the libraries provided in the uninative-tarball. However, when I try to build cmake-native on a Fedora 30, it fails with /home/pkj/dists/poky-master/builds/qemux86-64/tmp/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./cmake) which is due to a newer version of libstdc++ being provided by May 14 17:55:25 Fedora than what is provided by the uninative tarball. May 14 17:56:19 But why is it using the libstdc++ from the host when it is present in the uninative tarball? May 14 17:57:14 Saur: uninative has to be newer or equal to what is on the host May 14 17:57:29 Saur: we build against the host then swap uninative in May 14 17:57:40 Saur: nothing else could be made to work is the short version May 14 17:58:09 RP: Ok, so we build against the host, but run against uninative? May 14 17:58:13 seebs: I've seen horror stories too. We probably have a few lurking even in yocto May 14 17:58:17 Saur: yes May 14 17:59:01 Saur: try a clean tmpdir and I think it should warn you May 14 17:59:22 Saur: if you upgrade a system and reuse a tmpdir it doesn't. A patch to fix that would be great May 14 18:00:38 RP: I think it is only checking the glibc version, which is the same (2.29), not the libstdc++ version, which is 6.0.25 in the uninative-tarball, but 6.0.26 in Fedora 30. May 14 18:00:50 Hi, what is the proper way to use the function `success`, `failure` of `/etc/init.d/functions`? I mean, how do I print "[ OK ] Script started". I tried `success "Script started"` but it only print the [ OK ] without the message. Is doing `success && echo "Script started"` a better way ? May 14 18:03:49 Saur: ah, could be May 14 18:05:01 RP: So I guess I would need to build a uninative-tarball with GCC 9 to get it working? May 14 18:08:35 Saur: yes May 14 21:42:39 * RP had a nice hammer which fixes several ptests and makes the results look way better May 14 23:15:08 hey all, first time Yocto user, I followed the install/setup instructions and when I get to the step to source toaster, it says Django is not installed, yet I just watched it install. I obviously missed something here? May 14 23:17:17 I do see where it installed "Django-1.11.20" and then when I source toaster it's saying "This program needs Django>1.8,<1.12" so something is obvious borked May 14 23:24:37 zeddii, awake? May 14 23:24:51 I don't think anyone is awake in here :D May 14 23:25:23 apparently May 14 23:26:03 I'm just trying to figure out why my fresh install went south, apparently the install process looks at least to me, to be borken May 14 23:36:44 sory I konw nothing about django May 14 23:36:53 Ok well, I'll just leave my info here hopefully when someone is around they might have some suggestions. Build OS is Ubuntu 18.04.02 LTS, Python version is 2.7.15rc1, and the install instructions were followed from the Yocto Docs site May 14 23:37:33 are you trying to run taoster? May 14 23:38:05 Maybe email yocto list, I'm not sure if dave Reyna is on here May 14 23:40:54 Crofton: I am, I'm trying to learn Yocto. I'll check back tomorrow and if not I'll try the mailing lists, thanks May 15 00:39:36 https://mdsattacks.com/ <-- this is sort of brilliant May 15 01:06:58 * armpit looks for his dunce cap to put on May 15 01:08:13 * armpit armpit go stand in the corner and think about it **** BEGIN LOGGING AT Wed May 15 01:32:39 2019 **** BEGIN LOGGING AT Wed May 15 01:42:14 2019 **** BEGIN LOGGING AT Wed May 15 01:52:50 2019 **** BEGIN LOGGING AT Wed May 15 02:02:22 2019 **** ENDING LOGGING AT Wed May 15 02:59:57 2019