**** BEGIN LOGGING AT Fri Feb 05 02:59:57 2021 Feb 05 07:38:56 Hello guys ! In my kernel recipe folder I have two subfolders: files (with patches) and configs (with .cfg), how can I add both of them to FILESEXTRAPATHS_prepend ? Feb 05 07:50:56 yo dudX Feb 05 07:56:30 hi LetoThe2nd Feb 05 07:56:54 howdy mckoan Feb 05 08:17:30 thekappe: add each one separated by a ":" ? Feb 05 08:18:42 RP, thanks ! Feb 05 08:21:40 is there -native recipe example? can't find the good one. Feb 05 08:26:45 dvorkindmitry: one that is explicitly -native, or one that is native enabled? Feb 05 08:28:18 LetoThe2nd, I don't really know. I need the script from recipe A to be used while building recipe B binary. Feb 05 08:29:00 dvorkindmitry: if A is technically also buildable for the target, then its probably enough to jsut add BBCLASSEXTEND = "native". Feb 05 08:29:08 dvorkindmitry: look at bc, for example. Feb 05 08:31:15 LetoThe2nd, I added BBCLASSEXTEND = "native" to recipe A. But I can't find the script installed into {D} from recipe A do_install() in the work directories of recipe B. Feb 05 08:31:53 dvorkindmitry: well did you add DEPENDS = "A-native"? Feb 05 08:32:04 LetoThe2nd, I did Feb 05 08:33:31 I have no FILES... section in recipe A, but it doesn't give me any error messages and looks like it doesn't do packaging! Feb 05 08:35:16 it does ... install and deploy (used in DEPLOYdir too). no packaging. I suspect, I forgot to add some property to the A recipe Feb 05 08:35:43 i would try cleaning A-native, rebuild B and see what happens. if nothing shows up then you have to dig deeper, yes. Feb 05 08:36:05 I already did. No effect Feb 05 08:36:48 recipe B rally depends on A, A looks instaled. But no files from it in B recipe dirs Feb 05 08:36:58 rally->really Feb 05 08:37:49 dvorkindmitry: ah. they should not show up in the recipe dir, but in the sysroots that B uses. you hopefully looked in the right places? Feb 05 08:40:43 I did find -name "filenamefromB" - nothing Feb 05 08:41:34 sorry, vise-versa... :) Feb 05 08:42:55 what looks suspitious for me is that I have do_install() { install myscript } and have image/...myscript, but no packaging dir for this A recipe Feb 05 08:43:40 without seeing the recipe i personally can't guess more, sorry. others probably can, but its beyond my knowledge. Feb 05 08:47:30 dvorkindmitry: you can see what the recipe installed to the sysroot by looking in tmp/sysroot-components/(host arch)/A-native/ Feb 05 09:09:27 khem: do you plan on merging my meta-py fixes? our CI is broken. Feb 05 09:09:54 hm i forgot to [meta-python] tag them Feb 05 09:27:03 dvorkindmitry: not sure there's packaging for native recipes? Feb 05 09:54:25 Hi, there is one thing I am curious about Feb 05 09:54:37 if I track kernel patches in a metalayer Feb 05 09:55:21 assume I have foo-patches.scc which lists the patchset and then matching patches in the same directory, 000*-whatever.patch Feb 05 09:55:37 now, a new kernel version is rolled out, I generate those patches with git format-patch Feb 05 09:56:20 I end up with a diff full of +- lines for From with a different hash, possibly Subject where [PATCH nn/mm] is modified, and also some index ... entries Feb 05 09:56:39 I wonder, is there a tool to scrub those useless changes to clean up the sync diff ? Feb 05 09:57:50 marex: hard part is deciding which bits are useless Feb 05 09:58:24 RP: the patch context is generally useless, since its text unrelated to the patch content Feb 05 09:58:28 right ? Feb 05 09:59:41 marex: it has a use in that it helps the system understand where the patch content needs to go. Its noise in that it obscures what you happen to want in this case. Feb 05 10:00:08 RP: I mean things like 'From b7cefab79b977ec289a3254b1f5135af6e98d4da Mon Sep 17 00:00:00 2001' Feb 05 10:00:21 that is just noise and doesnt help anything, really Feb 05 10:00:46 marex: is there something in diffutills which would strip things down to bare patches? Feb 05 10:01:10 marex: git adds these things as it can help it apply the patches under some circumstances Feb 05 10:01:52 RP: I was looking for such a thing for a while, I can't seem to find anything Feb 05 10:02:19 I guess I can somehow tweak git config to generate patches without some of that stuff, or filter it manually with sed Feb 05 11:22:50 is there a way to get a sysroot of one recipe with all debug symbols (basically all -dbg packages of everything in DEPENDS of said recipe)? Feb 05 11:26:45 qschulz: the debug info is only packaged, not put into sysroots so you'd need an image recipe with debug image enabled installing that one recipe Feb 05 11:31:59 you can turn off stripping of the sysroot if you really need it though Feb 05 11:32:17 when i was digging at pseudo I had INHIBIT_SYSROOT_STRIP_pn-pseudo-native = "1" Feb 05 11:33:01 sounds like what you want is a debug image though, generated like an image but with all symbols for gdb to ues Feb 05 11:33:16 or, the debuginfod stuff dorinda is working on :) Feb 05 11:34:36 the debug image is the fastest way I know of to get it with the existing code Feb 05 11:38:50 rburton: this INHIBIT_SYSROOT_STRIP_pn-pseudo-native applies to sysroot-destdir dir of pseudo-native right? Feb 05 11:41:55 qschulz: yes Feb 05 11:46:57 ok so that's not really what I wanted but that is interesting to know. (in the end we went for a debug image enabled "rootfs") Feb 05 11:47:41 oh new uboot Feb 05 11:49:57 marex: any plans to upgrade uboot in oe-core? Feb 05 11:55:44 how to specify a dependency to a native compiler? DEPENDS = "gcc-native"? Feb 05 11:57:55 the native compiler is assumed to exist Feb 05 11:58:25 (on the host) Feb 05 11:59:59 hmm, one ltp run on the arm server 3.75 hours, the other was nearly 7 :/ Feb 05 12:00:17 * RP is going to merge glibc 2.33, looks like it builds cleanly Feb 05 12:03:12 jonmason: I reran the failing ltps and they went green FWIW Feb 05 12:04:31 Cool, so it's not occuring every time Feb 05 12:04:51 rburton: doesnt AUH do that ? Feb 05 12:05:21 marex: uboot is on my list of things that should likely be tested before pushing :) Feb 05 12:05:40 rburton: tested in what way ? :) Feb 05 12:05:53 rburton: I am running it on the boards I care about already Feb 05 12:06:12 rburton: switching the SRC_URI is enough Feb 05 12:06:26 marex: can you send the patch :) Feb 05 12:06:40 rburton: doesnt AUH do that ? Feb 05 12:06:49 I was hoping this automation should do it Feb 05 12:07:34 marex: the AUH can prepare the patches but we do ask that a human does check and confirm its a good idea Feb 05 12:07:56 marex: you can replicate the work of the AUH by using devtool upgrade locally iirc Feb 05 12:08:00 RP: ah, was the patch posted ? Feb 05 12:08:11 oh Feb 05 12:20:48 RP: rburton: btw Im tracking a local layer with linux 5.10.y and mesa 20.3.y for dunfell here, is there some better place to put it, so its useful for others that want LTS version of core, but more up to date kernel and graphics stack ? Feb 05 12:24:15 anyone noticed icu build failing in dunfell like this? Feb 05 12:24:17 ../data/rules.mk:744: recipe for target 'out/build/icudt66l/windowsZones.res' failed Feb 05 12:24:21 make[1]: *** [out/build/icudt66l/windowsZones.res] Segmentation fault Feb 05 12:24:32 sometimes there is "Bus error" instead of segmentation fault Feb 05 12:31:04 JaMa: I am just building it, in previous builds I didnt see it Feb 05 12:31:23 JaMa: could it be HW error on the build box ? Feb 05 12:32:53 it might, but I'm seeing it only in icu (3 times since last dunfell update yesterday) Feb 05 12:33:32 JaMa: is that native or target build ? Feb 05 12:33:42 target Feb 05 12:33:58 seen it for qemuarm and rpi4 Feb 05 12:34:11 marex: poky-contrib under stable/ ? Feb 05 12:34:13 JaMa: I'm just building arm32, so lets see Feb 05 12:34:36 JaMa: not seen that Feb 05 12:34:49 but it's relatively rare as it failed 3 times in 100+ builds here and I haven't reproduced it locally yet (only on jenkins) Feb 05 12:35:07 RP: meta-stable ? :) Feb 05 12:35:34 marex: absolutely not Feb 05 12:38:33 hehehe :-) Feb 05 12:39:39 RP: in fact, I have to wonder, is there still any need for linux-yocto ? wouldn't it make more sense to just pull plain linux-stable ? Feb 05 12:42:33 marex: that somewhat undervalues the work that goes into testing and maintaining the config data and patches in linux-yocto Feb 05 12:44:51 RP: looks like posix format will be the default in newer tar versions, but the docs also say "This format is quite recent, so not all tar implementations are able to handle it properly." so maybe the centos7 might still handle it differently :/ Feb 05 12:45:19 RP: cant those extras be applied on linux-stable all the same ? Feb 05 12:45:30 marex: https://gitlab.com/openembedded/community/meta-linux-mainline Feb 05 12:46:14 paulbarker: thanks Feb 05 12:47:00 marex: linux-yocto is better tested but if you want a vanilla kernel and are happy to do any necessary testing yourself then that layer may save you the time of maintaining the recipes Feb 05 12:47:10 paulbarker: https://gitlab.denx.de/denx/meta-mainline-common Feb 05 12:48:21 marex: Let's chat after FOSDEM, perhaps we can consolidate those layers Feb 05 12:49:24 I'm a bit too busy today and this weekend but after that will have a look around that layer Feb 05 12:49:29 paulbarker: ideally into something which gets updated often Feb 05 12:49:34 and automatically Feb 05 12:49:45 marex: https://gitlab.com/openembedded/community/meta-linux-mainline/-/blob/master/scripts/update-layer Feb 05 12:49:55 paulbarker: I have my own update script too Feb 05 12:50:33 I have talked about getting linux-yocto-dev running on the autobuilder fwiw Feb 05 12:51:05 JaMa: that sounds problematic :( Feb 05 12:51:29 RP: Unless we want to carry linux-yocto recipes for everything as far back as 4.4.y then I don't think it'll address what I need Feb 05 12:51:59 Definitely helpful to have that tested on the AB though, don't get me wrong Feb 05 12:52:18 JaMa: I guess we need to establish if centos7 tar supports posix archives Feb 05 12:52:21 paulbarker: if we can put some linux-stable into poky-contrib and keep it updated as soon as new version is out, great Feb 05 12:52:39 that should be possible to automate with auh Feb 05 12:52:48 paulbarker: right, it won't solve every need but for cutting edge it might help some cases Feb 05 12:52:51 marex: poky-contrib is absolutely not the place to put this, it needs to be a layer we can add Feb 05 12:52:57 Is anyone building with yocto on Alpine Linux? Feb 05 12:53:02 paulbarker: I want to get better about handling upstream changes more quickly Feb 05 12:53:25 manuel_: I tried building on Alpine once but had various issues with musl incompatibilities Feb 05 12:53:47 RP: dont we already have devupstream bbclass for that ? Feb 05 12:54:14 paulbarker: I see, thanks. Would love to see Crops be based on Alpine instead ?Ubuntu?. :) Feb 05 12:54:57 manuel_: I don't understand your question there sorry. CROPS needs to use a distro which we know can handle Yocto Project builds Feb 05 12:55:11 paulbarker: if we can keep in maintained, separate layer is fine Feb 05 12:55:56 marex: My limiting factor is a machine to do CI builds on. I should have that addressed within a month or so and then will be able to fully automate updating & test building the layer Feb 05 12:57:25 paulbarker: Yes, having Yocto projects build successfully on Alpine would of course be a requirement for basing CROPS on Alpine. Feb 05 12:58:01 paulbarker: lets revisit that later Feb 05 12:58:15 marex: Sounds like a good plan Feb 05 13:01:11 marex: that only works to a point but yes, it could be part of it Feb 05 13:19:32 when I run devtool I get the following; Feb 05 13:19:32 Exception: ModuleNotFoundError: No module named '_sysconfigdata' Feb 05 13:48:40 lxc: it's known issue already fixed in newer oe, I assume you used dunfell, see the patches on ML Feb 05 13:49:12 RP: I'll try with some container/VM with centos7 Feb 05 14:25:16 Hi, i recently installed the avahi-daemon on my yocto package. It is not starting automatically via systemd (startup fails) if i try it manually i get fcntl(F_SETLKW) failed: Permission denied Feb 05 14:36:33 I gave up trying to understand why this recipe A required for build recipe B does not install anything into B's root: https://pastebin.com/GeiVNFWm Feb 05 14:37:42 paulbarker: The patches all look good except for the logging one which breaks the standalone bitbake server Feb 05 14:39:55 JaMa yes running dunfell. Feb 05 14:40:15 JPEW: I get backtraces without that patch so something is wrong Feb 05 14:40:49 dvorkindmitry: why are you manually deploying? Feb 05 14:41:18 rburton, what you mean "manually" ? Feb 05 14:42:45 is there are something that could be ommited? Feb 05 14:42:46 why do you have a do_deploy at all Feb 05 14:43:34 rburton, case I need exact directory structure. some installed cripts rely on relative paths Feb 05 14:44:06 paulbarker, JPEW: sounds like in one case we get the python logger, in the other its a bitbake logger where debug is different Feb 05 14:50:22 RP: Ya... it's a bit unfortunate that bitbake overrides logging.debug with a different signature :/ Feb 05 14:50:28 can bitbake deploy a recipe on target with scp? or am I required to use devtool? Feb 05 14:54:04 rburton, so... do you have any ideas? I have rA/image/sp_tools/add_uhdr.sh file, but this file is not installed into rB/* during the recipe B build process. Although I have DEPENDS += "A-native" in recipe B Feb 05 14:54:10 lxc: you usually flash that image, e.g. you could use rauc for update Feb 05 14:55:36 RP: marex: the icu failure seems to be related to https://unicode-org.atlassian.net/browse/ICU-21175 from rburton :) Feb 05 14:55:39 In devtool I can do this; Feb 05 14:55:40 devtool deploy-target Feb 05 14:55:40 Is there something similar in bitbake? Or I need to use devtool as frontend to bitbake? Feb 05 15:01:03 lxc: you can create a custom image via bitbake recipe. One which is predefined (i guess?) is core-image-basic Feb 05 15:01:55 I know how to create image. I am running an image on target, and during development want to upgrade a certain package. Feb 05 15:02:43 lxc: ah i see. afaik you could create an rpm file of that application Feb 05 15:03:18 ok, but that require me to have the package manager as well then Feb 05 15:03:25 i compile the application(s) with the generated SDK and use scp. But i deploy images on my jenkins after merging Feb 05 15:03:48 lxc: exactly... I want that... But i want to get other stuff working first :) Feb 05 15:05:19 lxc: iam planning to put FPGA bitstreams in a package, to be able to upgrade it simply via rpm... But i dont have a connection for it right now... Feb 05 15:09:09 dvorkindmitry: your script is not part of SYSROOTDIRS Feb 05 15:10:11 and I'm guessing you want this script to be run at build time and not runtime, then you need a native recipe which is installing this script and in recipe B have DEPENDS = "A-native" Feb 05 15:10:42 dvorkindmitry: https://docs.yoctoproject.org/ref-manual/variables.html#term-SYSROOT_DIRS Feb 05 15:11:09 well, technically on your case it'll be SYSROOT_DIRS_NATIVE but still your script won't be part of it Feb 05 15:11:32 (ah, forgot to read your message to rburton, so you got the native part right already) Feb 05 15:12:24 dvorkindmitry: your justification for using do_deploy is still dubiuous, care to explain a bit more why you need so many files in your deploydir? Feb 05 15:12:26 qschulz, so you mean I just have to install add_uhdr.sh into traditional dir, like /usr/... or something? Feb 05 15:12:41 dvorkindmitry: that, or add your path to SYSROOT_DIRS_NATIVE Feb 05 15:14:21 qschulz, the scripts are written by another company, they are using it in they projects. some of them are Too much related to relative pathes. Instead of making patches for all this scripts (that is updated from time to time) I prefer to keep directory structure Feb 05 15:20:15 Do i have to take another avahi-deamon package if i use systemd? Feb 05 15:29:00 qschulz, may I add my special dir into SYSROOT_DIRS_NATIVE directly in the recipe? Feb 05 15:30:43 anyone else seeing the latest binutils bump in master inexplicably not find bison during the binutils-cross build ? Feb 05 15:30:54 * zeddii tries to hack it Feb 05 15:51:33 zeddii: I did not see that Feb 05 15:53:06 RP: yah, it has to be my re-used tmp/build somehow, since obviously it wouldn't be in master if it was triggering everywhere. Feb 05 15:53:20 but I've now cleanalled on everything I can think of, and just keep hitting Feb 05 15:53:21 https://pastebin.com/u6HPGPSW Feb 05 15:54:11 bison-native is in the depends, but when I search the recipe sysroot, it isn't in the native dirs, so something is off the rails. I'll rm -rf and see if that helps Feb 05 15:54:48 zeddii: you could have tried a bitbake bison-native binutils-cross-XXX -c clean Feb 05 15:55:29 did that, but actually, I didn't do the binutils-cross-x86_64 clean in my case, so I just tried that before the rm -rf Feb 05 15:55:44 will see what bison-cross thinks of that! Feb 05 15:56:16 (I just did the cleanall on binutils-cross, didn't realize the variant) Feb 05 15:57:52 zeddii: binutils-cross would just error wouldn't it? Feb 05 15:59:04 yah, according to my history, was just binutils I did the cleanall. must be monday. Feb 05 15:59:06 heh Feb 05 15:59:58 RP, paulbarker: We probably need to do a global find-and-replace to change all the places using the bitbake style logger.debug to logger.bbdebug (or similar)? Feb 05 16:02:57 dvorkindmitry: yes, in the recipe Feb 05 16:03:51 GeneralStupid: work out the permission issue first, it's probably just that that is the issue Feb 05 16:05:24 JPEW: that is going to be a lot of sites I suspect :( Feb 05 16:06:52 JPEW: also, probably better to add a debug2 and then change all the debug(1, to debug( Feb 05 16:08:48 RP: Ya, that works Feb 05 16:20:03 Looks like about 244 locations Feb 05 16:23:13 JPEW: have you a second to sanity check my logic with something in bitbake? Feb 05 16:27:41 Sure Feb 05 16:27:46 JPEW: I'm trying to understand https://autobuilder.yoctoproject.org/typhoon/#/builders/95/builds/1595/steps/12/logs/stdio - it shows two events being printed at once to a pipe partial datamore full data Feb 05 16:28:00 JPEW: code is in bit/bitbake-worker Feb 05 16:28:27 JPEW: its hard to read as there are two queues, the one where the worker passes to the server and the one where the worker children pass to the worker Feb 05 16:29:27 worker_fire() and worker_child_fire() ? Feb 05 16:29:38 JPEW: right Feb 05 16:29:52 JPEW: I'm struggling to spot where the race is happening though Feb 05 16:31:01 * JPEW reads Feb 05 16:33:58 Rp: So, if I read correctly, the default behavior is to push data to a queue and a background thread will write it to the pipe Feb 05 16:34:14 JPEW: in the worker parent, yes Feb 05 16:34:58 And when a task is forked off, it changes to directly write to the pipe from the child process? Feb 05 16:35:24 Ah, a new pipe setup between the parent and the child Feb 05 16:36:19 JPEW: yes, a new pipe is setup between the child and the parent Feb 05 16:36:57 JPEW: I am noticing that the parent pipes to other children are not closed in new children Feb 05 16:38:50 Ok, an the the parent(?) selects() on all the child pipes and forwards the events through it's pipe? Feb 05 16:39:02 JPEW: yes Feb 05 16:39:47 So is the un-pickling error in the the child, the worker process, or the worker's parent? Feb 05 16:43:13 JPEW: the error message matches the line in runqueue so in the server Feb 05 16:43:26 bb.msg.fatal("RunQueue", "failed load pickle '%s': '%s'" % (e, self.queue[7:index])) Feb 05 16:44:23 JPEW: i.e. worker's parent Feb 05 16:50:24 Hmm, the parent uses stdout as the pipe? Feb 05 16:50:39 Err, sorry the *worker* uses stdout as the pipe Feb 05 16:51:53 JPEW: yes :/ Feb 05 16:52:51 JPEW: whilst that has its risks, the logs look like multiple colliding :/ Feb 05 16:53:29 RP: Ya, for sure. Is there any indication in where those events would be originating from (e.g. child or worker?) Feb 05 16:53:39 Hello everybody Feb 05 16:54:05 JPEW: they look child to me but they could be being sent on from the worker's queue or the child Feb 05 16:54:24 Is there an easy way, given a package name, to know where the corresponding package is (i.e the .rpm/.deb/.ipk file ? Feb 05 16:54:34 extending PV etc for me Feb 05 16:54:53 (I want to use it in image-recipe context, so it can be a python call) Feb 05 16:55:04 RP: How reproducible is this? Feb 05 16:55:21 JPEW: not very but has happened on several ltp builds recently Feb 05 16:55:40 JPEW: I don't understand what is happening :( Feb 05 16:55:57 I don't either but we can probably narrow it down a little Feb 05 16:56:53 If we put some sanity code in the runQueueWorkerPipe() to make sure the "prepickled" message from the child has one and only one "" at the beginning of the string it would narrow it down Feb 05 16:57:38 lxc: yes use devtool deploy-target Feb 05 16:58:04 JPEW: that sounds reasonable Feb 05 16:59:31 lxc: devtool deploy-target pushes whatever it finds in $TMPDIR/work////image to the target for a given recipe Feb 05 17:00:09 and it's smart enough to keep track of what was pushed "the last time" so it can know what to unload before the next "devtool deploy-target" or "devtool undeploy-target" Feb 05 17:00:15 RP: something like: assert msg.startswith("") and msg.count("") == 1 Feb 05 17:01:32 lxc: so it's like building a package, scp'ing the package to the target, and installing the package… but without having to go through the package mgmt system (and it's smart enough to know how to uninstall too) Feb 05 17:02:20 lxc: see https://twoerner.blogspot.com/2020/10/writing-software-for-your-embedded.html perhaps? Feb 05 17:03:12 lxc: the only downside with "devtool deploy-target" is that it installs *everything* in /…/image, including documentation etc Feb 05 17:03:58 JPEW: right, that makes sense Feb 05 17:04:53 JPEW: fwiw one of the call sites triggering this is meta/lib/oeqa/core/target/ssh.py:SSHCall:run(), the logger.debug('Partial data from SSH call...) Feb 05 17:09:34 Hmm, could be a CLOEXEC error Feb 05 17:12:44 JPEW: I just found the other message is coming from make_logger_bitbake_compatible in lib/oeqa/utils/__init__ which seems apt given the discussion earlier Feb 05 17:13:58 Err, ya... how fun! Feb 05 17:16:03 JPEW: the other message it was colliding with is logger.debug('time: %s, endtime: %s' % (time.time(), endtime)) from a few lines above the Partial data line Feb 05 17:17:44 RP: Would that be in the child process>? Feb 05 17:18:27 JPEW: Yes, these would be in the child. Given they're in the same function and logically follow each other it probably rules out a few things too Feb 05 17:20:54 RP: I'm testing the tar in centos7 and I think autobuilder is already using different tar implementation, isn't it? Because with the default tar 1.26 (included in centos:centos7 docker image) it fails with tar: unrecognized option '--sort=name' Feb 05 17:22:55 JaMa: ah. Then what did I test with? :/ Feb 05 17:23:02 * JPEW gets some food Feb 05 17:24:20 RP: I wonder if the InterruptedError is interrupting the write to the pipe Feb 05 17:28:51 JPEW: https://www.python.org/dev/peps/pep-0475/ Feb 05 17:29:33 JPEW: would having an exception handler there change the behaviour of a write call. Surely the write() calls autoretry? Feb 05 17:31:45 https://git.openembedded.org/openembedded-core/commit/?id=f19e43dec63a86c200e04ba14393583588550380 from rburton also says "We now depend on tar 1.28, so talking about older tar versions is just confusing." so maybe it's already upgraded on centos7 builder somehow Feb 05 17:32:57 RP: Ah, but it *can't* if it's already partially written Feb 05 17:33:05 *written some of the data Feb 05 17:33:05 JaMa: centos7 uses buildtools Feb 05 17:33:16 It has to just return with how much has been written Feb 05 17:33:26 JaMa: I'm now very puzzled as to how I came across the issue though Feb 05 17:33:44 worker_child_fire() needs to loop to make sure all the data gets written, even though it's non -blocking Feb 05 17:33:49 Err, blocking Feb 05 17:34:19 Because you can get a short write on a pipe even with a blocking FD, if you had a partial write and then a signal occurred Feb 05 17:34:20 JPEW: ah, right. If it can make short writes, that would explain it Feb 05 17:34:38 JPEW: well deduced :) Feb 05 17:35:04 RP: me too :) Feb 05 17:35:12 Which, is a lot more likely to happen when running the LTP test on QEMU and the system because of a lot of output CPU load making the pipe more likely to fill(?) Feb 05 17:36:30 JaMa: do you know which version of tar changed the default format? Feb 05 17:38:33 JaMa: is there a way to see which format tar is using by default? I just checked and I did also test what I was working on with a tumbleweed autobuilder worker Feb 05 17:38:41 which has tar 1.32 Feb 05 17:39:03 JPEW: the ltp tests do seem to chuck more data around Feb 05 17:39:26 RP: Cool, I bet that's it. Probably still worth having the sanity check Feb 05 17:41:03 JPEW: you never see python .write() calls checking length or a retry write() loop or helper Feb 05 17:46:53 JPEW: I guess you don't see fdopen used much Feb 05 17:47:44 RP: Ya. I don't think signal come up much either... most are fatal by default anyway Feb 05 17:48:51 I'll write a little PoC after lunch Feb 05 17:50:17 RP: the default is still gnu (since long time), the default wasn't changed to posix even in 20.10 ubuntu yet, the build-time configured default is shown at the end of tar --help Feb 05 17:51:40 20.10 ubuntu is still on 1.30, so 1.32 in tumbleweed might already have posix Feb 05 17:54:16 JaMa: that might be how we got here Feb 05 17:54:47 JaMa: sorry for the misinformation, I could have sworn I used centos7 Feb 05 17:58:17 JPEW: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=992d15973ce13cad80730b51645c4748ff91ef1c :) Feb 05 18:02:16 RP: so can I try to submit change from gnu to posix? I already have a patch Feb 05 18:02:56 I'm checking the default in tumbeweed docker Feb 05 18:03:41 JaMa: which version of tar added posix support? Feb 05 18:04:08 it was already in 1.26 in centos7, only the --sort=name was missing Feb 05 18:04:41 JaMa: ok, in that case we're good Feb 05 18:04:50 JaMa: we should be able to change it Feb 05 18:14:21 jonmason: need to get ross to fix that esdk2 error that happened again on meta-arm ;-) Feb 05 18:20:49 edk2 is such a PITA Feb 05 18:21:34 even worse, we never see issues when compiling in our CI Feb 05 18:23:25 Anyone here a devtools user/guru? Feb 05 18:43:16 don't know if this is the best place to ask or if i should find a freescale-specific place, but i'm trying to change my UBOOT_CONFIG to "nand" as seen in https://github.com/Freescale/meta-freescale/blob/master/conf/machine/imx7dsabresd.conf#L36 and u-boot is failing to build because it can't find "mx7dsabresd_nand_config" - which seems understandable, because i can't find it or anything that appears to generate it in the Feb 05 18:43:16 tree either Feb 05 18:43:41 neither in that nor in the sources it pulls Feb 05 18:44:19 any clues on where that file is supposed to be coming from would be appreciated; i can't find many of the other variants it seems to reference there either Feb 05 19:00:53 RP: Ah ok. It is a problem with short writes, but only when you make big writes. It's a combination of the kernel and python collaborating in a strange way: https://gist.github.com/JPEWdev/c9206cf531a38ee71476ca3c94af3386 Feb 05 19:10:35 Hey there, I need to toggle a flag in linux in gpio.h `GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME`. See this line: Feb 05 19:10:48 https://github.com/torvalds/linux/blob/a409ed156a90093a03fe6a93721ddf4c591eac87/include/uapi/linux/gpio.h#L287 Feb 05 19:11:40 I already have a bbappend where I configure linux kernel configs. Thus, I guess this also belongs in there. Feb 05 19:12:32 Do I need to set some env variable such as `LINUX_KERNEL_EXTRA_ARGS` or so? I remember something similar to that but can't seem to find the exact point where to toggle that flag. Feb 05 19:12:55 `KERNEL_EXTRA_ARGS` Feb 05 19:13:26 That's the one I meant. Is that the right place to put that? I guess there should rather be a CC compiler extra args variable or so Feb 05 20:03:36 okay this is weird. if i set DEBUG_PREFIX_MAP_class-target to -fdebug-prefix-map=${B}=/foo, the work-shared path to a gcc binary gets truncated.. or rather, gets TMPDIR removed Feb 05 20:03:46 i.e. /work-shared/gcc-9.3.0-r0/gcc-9.3.0/libatomic/gload.c rather than /mel/kergoth/mel/cb-toolchain/its-790/build/tmp-glibc/work-shared/gcc-9.3.0-r0/gcc-9.3.0/libatomic/gload.c Feb 05 20:03:53 even though that path doesn't include ${B} at all. Feb 05 20:04:09 and the replacement string, /foo, isn't in the result. yet still the path changes Feb 05 20:04:19 Anyone have any ideas? Feb 05 20:37:54 I have been looking at nix a little. Any thoughts about adding nixpkg support along side ipk/deb/rpm? Feb 05 20:56:37 rabbit9911: I think someone was recently looking at making the packaging system more pluggable so that you could maintain such a thing on your own more easily Feb 05 20:56:43 I think their goal was APK Feb 05 20:57:30 I suspect the core project necessarily needs to keep the number of package formats it support to a minimum.... we have a hard enough time with deb as it is Feb 05 20:57:35 Hello everybody Feb 05 20:57:53 Is there an easy way, given a package name, to know where the corresponding package is (i.e the .rpm/.deb/.ipk file ? Feb 05 20:57:53 extending PV etc for me Feb 05 20:58:03 (I want to use it in image-recipe context, so it can be a python call) Feb 05 20:58:26 boucman: Maybe.... why? Feb 05 20:58:45 I want to add partial update to meta-swupdate Feb 05 20:59:01 swupdate itself has already what I need, so i'm adding the yocto part Feb 05 20:59:14 JPEW: That makes sense. I will dwell on it. I was thinking of using it similar to what the yocto SDK is used for. Feb 05 20:59:21 basically, I want to embedd a package in a .swu image then deploy on the target Feb 05 20:59:40 (most of the time it will be a .tar package, since that's what makes most sense in this case) Feb 05 21:00:36 boucman: If you dig through package.bbclass you might find something useful Feb 05 21:01:26 I have been trying to dig through the do_rootfs logic to try to figure out how packages are found (in particular wrt PREFERRED_VERSION) but no luck Feb 05 21:01:36 i'll look into package.bbclass Feb 05 21:02:02 boucman: The package manager handle that (e.g. opkg, dnf, apt) Feb 05 21:02:23 Basically, OE just creates a package repository Feb 05 21:02:44 (e.g. a feed) and tells the underlying tool to install a bunch of packages Feb 05 21:02:47 yes and no... at some point oe needs to "force" version, so PREFERRED_VERSION is obeyed, right ? Feb 05 21:03:12 but yeah, unfortunately you might be right... so no where to look for that Feb 05 21:03:19 boucman: Ya... I don't exactly know were that happens Feb 05 21:03:47 maybe I'll dig in the package_tar logic... since there is no package manager, I might have more luck Feb 05 21:04:22 boucman: Right, I think the problem you are likely to run into is that you'll always be second guessing what the package file names are Feb 05 21:04:42 i'm a bit afraid of that, yes Feb 05 21:05:22 boucman: But... perhaps there is a way to get that information from the package manager itself when you build the swu file? Feb 05 21:05:40 e.g. "give me the exact file name of the 'busybox' package" Feb 05 21:06:24 maybe, I havn't looked into using the PM itself yet... and that would be different for each PM Feb 05 21:06:43 (unless there is a generic wrapper, but I would have stumbled onto it at this point, I think...) Feb 05 21:06:46 I have an issue, that is that systemd-sysusers is telling me during startup that he cant lock /etc/passwd . Does anyone have a suggestion for me? Is it ok to use yocto useradd class with systemd? Feb 05 21:20:42 GeneralStupid: Should be fine. I'm doing it and it works OK Feb 05 21:20:46 rburton: should be in today Feb 05 21:22:12 JPEW: it is a rather odd combination of things. hopefully the patch I've added will help Feb 05 21:22:35 kergoth: what issue do you run into with DEBUG_PREFIX_MAP Feb 05 21:23:22 khem: if you were in this channel earlier i elaborated. its' really strange behavior. Feb 05 21:23:25 heh https://lists.gnu.org/archive/html/info-gnu/2021-02/msg00001.html Feb 05 21:23:30 khem: if i set DEBUG_PREFIX_MAP_class-target to -fdebug-prefix-map=${B}=/foo, the work-shared path to a gcc binary gets truncated.. or rather, gets TMPDIR removed Feb 05 21:23:31 i.e. /work-shared/gcc-9.3.0-r0/gcc-9.3.0/libatomic/gload.c rather than /mel/kergoth/mel/cb-toolchain/its-790/build/tmp-glibc/work-shared/gcc-9.3.0-r0/gcc-9.3.0/libatomic/gload.c Feb 05 21:23:31 even though that path doesn't include ${B} at all. Feb 05 21:23:35 a release after perhaps 10 years ? Feb 05 21:23:46 and the replacement string doesn't show up in those entries at all Feb 05 21:23:58 now, that replacement *does* correctly apply to other source files Feb 05 21:24:08 just not these.. which it shouldn't, but why are they affected at all? Feb 05 21:24:54 kergoth: I think it operates on WORKDIR Feb 05 21:25:06 khem: i'm directly printing the paths coming out of dwarfsrcfiles Feb 05 21:25:12 not looking at the resulting installed files Feb 05 21:25:37 so why would the stored source file paths in the binary be altered like that? it's weird Feb 05 21:26:03 unless package.bbclass is doing something else funky that i'm missing, but the parsing of the output of that tool is straightforward.. Feb 05 21:26:11 see meta/recipes-devtools/gcc/gcc-runtime.inc Feb 05 21:26:25 i know, that's what i'm working on Feb 05 21:26:40 i overrode DEBUG_PREFIX_MAP to only include that one entry, yet paths that don't contain the specified path are being altered somehow Feb 05 21:27:12 i'm working on fixing the issue where gcc sources are not being included in the debug packages, but i can't fix the gcc paths from work-shared because they end up "/work-shared/gcc...." Feb 05 21:27:19 even though none of the mapping specify that Feb 05 21:27:36 I dunno, I might have to call it a day and try again tomorrow Feb 05 21:27:47 figured out my u-boot thing, i was using the wrong u-boot sources Feb 05 21:27:49 but now this is driving me insane https://gist.github.com/jordemort/b8b322522053cd7d0553d788c40cb746 Feb 05 21:28:28 i am getting a KeyError from sstate_report_unihash for my build user's UID, for a package i have not touched Feb 05 21:28:41 every once in a while this happens and the only answer i've found is "blow away your sstate" but i would really really like to figure out how to prevent it from happening Feb 05 21:29:28 again, this an untouched unmodified recipe, i haven't screwed up in do_install or anything, my build has just decided to randomly start choking on it for no discernible reason Feb 05 21:30:22 jordemort: what release/branch? Feb 05 21:30:42 kergoth: dunfell Feb 05 21:32:12 i have a theory that it's related to RPM signing? because sometimes GPG dies in the middle of signing a package, also for unknown reasons; perhaps if that happens it leaves behind something with a bad UID maybe? Feb 05 21:34:34 kergoth: I think I dont yet fully grasp the problem Feb 05 21:37:12 I'll post a gist. I'm building gcc-runtime with package.bbclass adjusted to dump the source paths referenced by the binaries the build produces, and these paths are being modified in ways inconsistent with the specified debug-prefix-map Feb 05 21:37:13 to sum up Feb 05 21:42:08 khem: https://gist.github.com/kergoth/d2f4057717daf8794ac8a54055c944df Feb 05 21:42:42 khem: there you can see the changed paths resulting from setting the map this way, but the first two entries shouldn't have changed at all, as they didn't contain the paths specified in the prefix map! Feb 05 21:58:10 is it bad to define WKS_FILE in the image recipe? Feb 05 22:05:09 vdl: generally yes, as it makes the image machine specific, whereas any combination of distro/machine/image are supposed to work Feb 05 22:06:16 kergoth: I see. but it seems weird to me to defined different machines for my board's SD card, flash, and e.g. usb stick. isn't it? Feb 06 00:00:24 kergoth: I've been a bit too distracted to make sense of that, I do remember being surprised by some of the remapping code though :/ Feb 06 00:00:51 kergoth: I wish I remembered the details Feb 06 02:42:10 really at my wit's end with this file permission weirdness in the container Feb 06 02:42:22 now i'm getting a pseudo abort https://gist.github.com/jordemort/4cf3876cbb8d0353c5b5d321ba3356f1 Feb 06 02:42:34 literally NOTHING has touched the volume Feb 06 02:42:56 did a successful build, then brought in a commit that updates my poky submodule, bang, psuedo abort Feb 06 02:43:06 is there any way just to run the whole thing as root and dispense with all of this? Feb 06 02:43:31 RP: no worries, just strange, might have to delve into gcc to make sense of it :) Feb 06 02:44:18 i guess i will dump my entire build directory and sstate for the fifth time today Feb 06 02:44:42 there has got to be something extremely stupid that i am doing that is bringing all this down on me Feb 06 02:44:49 i just wish i knew what it was **** ENDING LOGGING AT Sat Feb 06 02:59:57 2021