**** BEGIN LOGGING AT Fri Apr 13 03:00:03 2018 Apr 13 06:19:20 I want to install gobject-introspection-native into the sdk, but add it into TOOLCHAIN_HOST_TASK doesn't take effect(the other thing I added it works) Apr 13 06:20:24 And I check the gobject-introspection-native build directory, I didn't see any packages split directory nor ipk files Apr 13 06:32:23 I have enabled the buildhistory in my local.conf file, but can't find the build history folder. When compiling the project it even says. "Writing build history". Does anyone have any idea why it isn't there ? Apr 13 08:05:25 osten: it should be /buildhistory directory unless you have overridden the BUILDHISTORY_DIR variable. Apr 13 08:39:39 anujm: Thanks, hmm somehow after a couple of builds it came to exist. Maby it's my ssh mount which is just a bit slow to sync the files. Apr 13 08:41:32 Another question, not sure this is the right place to put it tough. I'm trying to add rauc as an update system to my image, i followed their guide, but when i'm trying to generate a rauc bundle, then it fails where there is no .live image of my image. Do any one have any idea why i get this error ? and where to find information to solve the problem ? Apr 13 09:14:53 When/After running a build how can I see how much was found in the sstate ? Apr 13 09:23:42 osse: inheritting buildstats-summary gives you nice summary at the end of the build Apr 13 09:27:00 JaMa: Thanks, I'll try that Apr 13 10:29:13 New news from stackoverflow: U-Boot How to run a standalone binary program? || PCIE not detecting on IMX7 with kintex fpga Apr 13 11:44:13 I have a simple Makefile based project that adheres to CC/DESTDIR/PREFIX conventions and supports `make install`. It seems that if I inherit `autotools` it tries to build using the (empty, since no `configure`) `build/`-subdirectory Apr 13 11:44:22 which obviously fails Apr 13 11:44:43 if I implicitly inherit `base`, it does not run `make install` Apr 13 11:44:58 so what's the intended way to solve this Apr 13 11:46:38 setting `B=${S}` might mess with rebuilds, right? Apr 13 11:53:53 That's what autotools-brokensep does Apr 13 11:54:12 But why don't you just override do_install and call oe_runmake install yourself? Apr 13 11:59:13 @neverpanic I assumed that it would be a common case and that I'm just Doing-It-Wrong(TM) ;-) Apr 13 12:00:39 neverpanic: also: doesn't just equalizing build and source dir interfere with e.g. source fetching vs. reconfiguration? Apr 13 12:01:50 I added something like `do_compile_prepend() { cp -aR ${S} . }` Apr 13 12:05:16 No, since autotools-brokensep already does that Apr 13 12:07:31 neverpanic: but the `configure` routine conditionally deletes `${B}`. I mean I thought `B` was there for a reason (e.g. not having to rerun do-unpack). Apr 13 12:10:18 what configure routine? Apr 13 12:10:54 I don't see anybody deleting ${B} in base.bbclass Apr 13 12:11:21 Of course if you're using autotools.bbclass with a non-autotools project, you probably shouldn't. Apr 13 14:08:39 hello guys, does anybody know how to add a console login message on yocto ? Apr 13 14:14:22 /etc/issue is sent before login... /etc/motd after Apr 13 14:16:56 fray: thanks ! Apr 13 15:48:44 hi all. I need a native tool to build a custom image type. This tool needs some config file, so, in my recipe i installed config file using install -m 644 ${D}/${sysconfdir} (BBCLASSEXTEND="native", etc...). My problem is how to access this config file in a image_type_custom.bbclass ? Apr 13 15:50:52 using directly ../../${sysconfdir}/ is a bit ugly, isn't it ? Apr 13 17:06:29 halstead: A sumo-next when the AB is free would be cool :) Apr 13 17:07:23 RP, Will do. I'm taking my father in law to the doctor so I'll be a little slow to respond for the next little bit. Apr 13 17:09:02 halstead: no problem, I'm finished for the day Apr 13 17:10:00 RP, Thanks! I'll complete updates and get sumo-next queued up in the next couple hours. Apr 13 17:41:21 i'm curious, does anyone know why deleted files in DEPLOY_DIR cannot be automatically detected and rebuilt? Apr 13 17:41:21 https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#structure-build-tmp-deploy-images Apr 13 17:41:21 "If you do accidentally delete files here, you will need to force them to be re-created. In order to do that, you will need to know the target that produced them." Apr 13 17:41:21 I'm not a bitbake expert but am wondering why packages deploying to DEPLOY_DIR don't effectively take a dependency on the files they create (or be allowed to voluntarily declare those dependencies) so that when files are deleted, they get rebuilt when you rebuild the image. Apr 13 17:56:12 quit Apr 13 17:56:15 oops Apr 13 17:56:23 :) Apr 13 18:00:44 New news from stackoverflow: How is /dev/block/bootdevic/by-name created? Apr 13 18:26:14 martinkelly: bitbake doesn't track every file by design. tasks are run based on stamps, those stamps happen to include metadata and file checksums in very specific cases only Apr 13 18:26:52 is that for performance reasons? Apr 13 18:39:56 * armpit network to work is down.. time for beer Apr 13 18:50:06 Is there any way to use a MultiStageProgressReporter with a task's 'progress' varflag? Apr 13 18:54:44 suppose I need to modify exec_func_shell in bitbake/lib/bb/build.py Apr 13 19:20:21 ... Okay this is one of those things I probably should have checked. At one point, on most filesystems I'd checked, symlinks persistently had their own distinct inode numbers. Apr 13 19:20:37 Do we ever run on filesystems where that's not the case? I don't think it's actually strictly required by POSIX. Apr 13 19:45:30 fwiw, I have some free time and I'm looking at 12434 again. I'm gonna clean up some of the spammy log messages and see if I can track down the actual problem, because I'm pretty sure there is an actual problem in the logs I'm seeing. Apr 13 19:55:52 seebs: awesome Apr 13 19:56:37 it has been far too long since i used this stuff Apr 13 19:57:06 imagine that i want a specific package to be built, and I want the environment variable PSEUDO_DEBUG set while it builds. Apr 13 19:57:21 It appears that just adding PSEUDO_DEBUG to BB_ENV_EXTRAWHITE and setting it as an environment variable is not enough. Apr 13 19:57:51 throw export PSEUDO_DEBUG='1' into the recipe and use bitbake -C unpack recipename? Apr 13 19:57:59 much easier than messing with the env whitelist Apr 13 19:58:34 oh, that'd work. Apr 13 19:58:48 The interesting thing, to me, is that pseudo appears to be getting in some way screwed up before the recipe is even really involved. Apr 13 19:59:04 Like, I'm getting weird complaints about the suspicious similarity of log.do_install.pid and log.do_install. Apr 13 19:59:30 So I may actually need to be able to set pseudo_debug outside the stuff that's nominally "in" the recipe to catch that. Apr 13 20:00:45 in that case the whitelist thing should work :/ Apr 13 20:01:15 I'd think, yes. Apr 13 20:01:49 huh. i may have been looking in wrong log file, though. heh. Apr 13 20:05:48 ... Nope. There's an initial setup of the server happening, which is outside the stuff done within the recipe, so it doesn't get PSEUDO_DEBUG. Apr 13 20:15:59 heh. i can fix that by adding it to bitbake.conf, but that means everything has to be rebuilt very slowly with debugging on. whoops. Apr 13 20:17:52 ... i am apparently missing something, because I'm still not seeing expected logging output on the server side. Apr 13 20:18:33 *and* i found a path-resolution bug. man, this is just not my day. Apr 13 20:23:07 seebs: what rburton said, hack the specific recipe in question Apr 13 20:23:20 sorry, scrollback stalled :) Apr 13 20:24:31 so the problem i'm currently looking at, which is actually one of a couple probably-related ones, is: Apr 13 20:24:38 inode mismatch: '/home/seebs/src/poky/build/tmp/work/all-poky-linux/pseudo-test/1.0-r0/temp/log.do_install' ino 41689229 in db, 41690343 in request. Apr 13 20:24:43 seebs: you can force something out of the variable hashing with XXX[vardepvalue] XXX[vardepexclude] and friends Apr 13 20:24:47 the problem is, this isn't *inside* the recipe. Apr 13 20:25:12 this is happening during the setup around the recipe when the recipe's not actually in play yet, so far as i can tell. so i'm not actually getting a PSEUDO_DEBUG setting in to the pseudo server at that point. Apr 13 20:25:43 seebs: pseudo is started disabled and then only enabled per recipe Apr 13 20:25:46 My goal would be to turn on debug info enough that, when I get that message, I can figure out what client program was even running. Apr 13 20:26:20 seebs: so it sounds like you want it when pseudo starts which is bitbake.conf Apr 13 20:26:23 So I'm looking for the point at which a specific server is started. Apr 13 20:26:32 Because each recipe is getting its own distinct server. Apr 13 20:26:51 seebs: that should be the point the logging applies. The code itself is from bitbake-worker Apr 13 20:26:54 Huh. I wonder whether I should add a thing to check the pseudo directory for a .rc file. Apr 13 20:27:36 So, *something* is being done that causes a pseudo server, with PSEUDO_PREFIX pointed to this specific recipe's recipe/version/pseudo directory, to emit a diagnostic about log.do_install. Apr 13 20:29:08 But that server isn't running with any debug flags, even though I just went ahead and set PSEUDO_DEBUG globally in bitbake.conf, and it's working for the clients. Apr 13 20:29:11 That is really weird. Apr 13 20:29:11 seebs: the code runs two versions of bitbake/bin/bitbake-worker, one under pseudo, one not. When a task is marked as fakeroot, its passed to the bb-worker script running under pseudo and that enables pseudo in that context for that recipe Apr 13 20:29:46 seebs: you can see the code that applies the flags in bitbake-worker. It sounds odd hat something wouldn't get PSEUDO_DEBUG Apr 13 20:29:58 Does it ever actually directly start the server, or is that being done only by the client? Apr 13 20:30:12 seebs: only server start is from the clients Apr 13 20:30:15 afaik Apr 13 20:30:35 huh. So if the client has PSEUDO_DEBUG set (which it does, since it's producing the diagnostics)... Apr 13 20:30:50 That's really odd. Apr 13 20:30:58 summary, yes Apr 13 20:31:52 seebs: how late is this in the recipe execution and is this glibc-locale? Apr 13 20:32:09 sounds like its any do_install from your logs? Apr 13 20:32:28 if so no matter, my theory is irrelevant Apr 13 20:32:55 it's not glibc-locale, it's the dummy pseudo-test package. Apr 13 20:33:12 seebs: note that /home/seebs/src/poky/build/tmp/work/all-poky-linux/pseudo-test/1.0-r0/temp/log.do_install is a symlink which gets updated at the end of a task's execution out of pseudo context Apr 13 20:33:16 And *something* seems to be sending the wrong path or inode data to the server, causing errors. Apr 13 20:33:32 So the problem is, it's being seen inside pseudo. Apr 13 20:33:39 And that's causing at the very least weird diagnostics. Apr 13 20:33:50 inode mismatch: '/home/seebs/src/poky/build/tmp/work/all-poky-linux/pseudo-test/1.0-r0/temp/log.do_install' ino 41689233 in db, 41690345 in request. Apr 13 20:33:51 symlink mismatch: '/home/seebs/src/poky/build/tmp/work/all-poky-linux/pseudo-test/1.0-r0/temp/log.do_install' [41689233] db mode 0120777, header mode 0100644 (unlinking db) Apr 13 20:34:26 which means that *some* client code, actually talking to pseudo, interacted with that name, but had the file header data from the thing it links to, rather than from the symlink. Apr 13 20:34:56 So that's clearly a bug, and it may not be related to the other problems, but I feel like it should get figured out and fixed. But to do that, I have to be able to figure out what's *doing* it. Apr 13 20:35:11 seebs: I can tell you the code that changes that file Apr 13 20:35:22 And to do that, I have to make the server log more information -- but it won't, because it's not getting any debug flags, which is itself really weird. Apr 13 20:35:30 lib/bb/build.py:_exec_task() Apr 13 20:35:56 seebs: # Setup the courtesy link to the logfn Apr 13 20:36:45 seebs: _exec_task is called from exec_task() which is only called from bitbake-worker Apr 13 20:37:12 seebs: which should only ever be in the right pseudo context... Apr 13 20:37:34 side note: if i wanted to use a local git repo, how would I spell that in SRC_URI? git:///home/seebs/...? Apr 13 20:38:08 seebs: git:///home/seebs/...;protocol=file Apr 13 20:38:20 thx. Apr 13 20:38:30 * RP needs to be elsewhere but I'll check in later Apr 13 20:38:32 I want to do some crazy things and not upload them. Apr 13 20:38:33 Thanks! Apr 13 20:43:38 hah. Apr 13 20:43:41 message from client 4 [15791:grep - ] fd 11 Apr 13 20:43:41 inode mismatch: '/home/seebs/src/poky/build/tmp/work/all-poky-linux/pseudo-test/1.0-r0/temp/log.do_install' ino 41688885 in db, 41688996 in request. Apr 13 20:44:03 that's... interesting. so that's probably from package_qa or something, calling grep on log.do_install. Apr 13 20:45:00 So the failure there is that there is a real symlink, inode *5, and grep is being invoked on that path, but getting the data for *6, but the message sent to the server uses the wrong path. Apr 13 20:47:44 yay. i have a trivial reproducer for that, now i just need to figure out why it happens. Apr 13 20:50:13 .... d'oh. Apr 13 20:51:26 wow that's been broken forever. Apr 13 20:51:42 Like, over three years. Apr 13 20:52:13 So, there's a pseudo_root_path() which tries to resolve a path. Its last argument is called leave_last, and is supposed to be nonzero if and only if we should not be following symlinks. Apr 13 20:52:24 openat() calls that, just passing in flags. Apr 13 20:52:55 Which means anything like O_CLOEXEC, etcetera, causes it not to try to follow symlinks. This is completely wrong, and I can't find any relevant changes since 2015. Apr 13 20:54:23 I'm not even sure how to fix it, since the right answer varies between functions. Apr 13 20:59:24 what a beautifully weird bug, and I'm stunned we never apparently got hit by it. That's just really *weird*. Apr 13 21:02:49 no relation to 12434, I don't think, and I still haven't been able to get that to actually trigger, but still. Apr 13 21:27:04 Hmm, anyone try doing bitbake builds under WSL? Apr 13 21:30:14 seebs: thanks a lot for looking into it again, if you need more testers let me know I'll trigger a lot of builds with any weird pseudo revision you gave me :) Apr 13 21:30:39 So right now, my problem is basically that I can't get the pseudo-test recipe from 12434 to fail. Apr 13 21:30:51 kergoth: few people try, nobody was able to finish I believe, next version is supposed to make the filesystem better (I don't belive it at all) Apr 13 21:31:12 I fixed an unrelated (I think) bug that was creating spurious reports, and I also fixed it so you no longer get all the "path mismatch [N links]" for N > 1 by default. Apr 13 21:31:22 Because that's incredibly spammy with heavily-hardlinked trees, and useless. Apr 13 21:31:51 So current master... *I* can't get it to fail, anyway. Both trying with that pseudo-test recipe under poky, and just running that makefile under pseudo directly. Apr 13 21:32:28 And I don't know whether this is the same issue as the glibc-locale one or a different one. My intuition says "probably different", because I have a vague recollection of glibc-locale doing a thing where it tries to access files stashed from another recipe's work directory or something. Apr 13 21:34:26 kergoth: one of last threads I remember about WSL http://forum.webosose.org/t/failed-at-55-glibc-locale-building-in-wsl-win10/208 Apr 13 21:35:04 kergoth: there was tread on oe-core or yocto ML as well long time ago, IIRC with similar conclussion Apr 13 21:35:16 ah, thanks Apr 13 21:35:43 kergoth: this is with 2.2 Morty, but I don't think it matters to WSL Apr 13 21:36:29 seebs: ok, I'll give latest master a try in case it's not reproducible at all anymore Apr 13 21:38:07 I suspect it might just require more cores than my laptop has? But it's also really hard to be sure. I'm particularly interested in pseudo-test failures, because the glibc-locale thing *could* be a completely different problem. Apr 13 21:38:19 And honestly I bet the symlink fix will catch all sorts of weird stuff. Apr 13 21:38:29 Because there were absolutely ways that could result in dropping database entries. Apr 13 21:38:42 glibc-locale seems to be most common from "public" reproducers Apr 13 21:39:04 but I get these issues from quite a few other components as well Apr 13 21:39:32 yeah. glibc-locale in particular is a really weird package, and i seem to recall having concerns about it back in the day, because it had some non-obvious implication about its interactions with glibc builds or something. Apr 13 21:39:35 e.g. various .qml files generated with meta-qt5, sometimes CONTROL file inside .ipk packaging Apr 13 21:39:39 it's been too long and i've forgotten. Apr 13 21:40:53 with less spammy log I might be able to spot what makes some components to be more error-prone for this then others Apr 13 21:41:46 shame that my pseudo-test didn't work reliably in the end Apr 13 21:42:34 i dunno, maybe it does, and i actually fixed that specific error. :) Apr 13 21:43:00 anyway, the "path mismatch" stuff should now be gone except in the case where a file only has one link, which should dramatically reduce spam about things that have dozens of links. Apr 13 21:43:08 and the symlink mismatches caused by the weird openat bug should be gone now. Apr 13 21:43:33 yeah, thanks for the pointers. will likely just use docker or a vm for the time being, good to know there's progress though.. the filesystem issues do seem troublesome Apr 13 21:43:40 "I think this stems from the NTFS limitation that prevents renaming directories which have a handle open to anything below" interesting Apr 13 21:50:28 Is there a way to tell a bitbake build to output a debian package only and nothing else? E.g. I would like to build curl as a debian package and output that debian package in the DEPLOY_DIR but not build anything else. Apr 13 21:50:54 switch PACKAGE_CLASSES to package_deb, run bitbake curl Apr 13 21:55:29 EXTERNAL_TOOLCHAIN variable worth documenting? Any opinions? Apr 13 21:55:58 that depends on whether we want to cover meta-external-toolchain or not. the variable has no meaning without a layer that obeys it, oe-core does not Apr 13 21:57:17 OK - we do not document meta-external-toolchain Apr 13 21:58:26 Although I do have the https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#dev-optionally-using-an-external-toolchain section that mentions a bit about external toolchains. The link to EXTERNAL_TOOLCHAIN is broke as I don't have a glossary definition for that variable. Apr 13 21:59:55 seebs: glibc-locale does weird stuff, but it's interesting that whatever happens there is "preserved" in sstate archive and even different host which just reuses this tar archive ends with the same issue (in my testing every time). Whatever bad happens in particular build can be stored in tarball. Apr 13 22:00:59 seebs: unfortunatelly I wasn't able to find out the significant difference between "good" and "bad" glibc-locale sstate archive Apr 13 22:08:31 kergoth: Oh sweet, that does end up putting the .debs in the deploy dir. Should have just tested instead of asking the question. Thanks! Apr 13 22:16:51 Huh, that's interesting. Apr 13 22:17:06 One thing I'm curious about, is the intent that locale files be 0644, or should they actually be 0444? **** ENDING LOGGING AT Sat Apr 14 03:00:00 2018