**** BEGIN LOGGING AT Mon Jan 04 02:59:57 2021 Jan 04 05:22:21 0;10;1c Jan 04 06:45:03 Hello, I'm integrating on some Go packages and I would submit recipes, is it okay if I submit them to meta-oe? Jan 04 08:32:08 good morning Jan 04 09:00:33 tprrt: try and people will let you know :) Jan 04 09:00:36 mckoan: o/ Jan 04 09:00:42 Happy New Year all Jan 04 09:02:52 qschulz: Copy that and Happy New Year! Jan 04 09:23:40 qschulz: happy new year Jan 04 10:22:27 Happy new year to all (and less #dumpsterfire) Jan 04 10:32:54 HNY :) Jan 04 10:33:07 RobertBerger: I suspect its going to take a while to dampen down Jan 04 10:34:23 @RP: I am afraid so as well - my frequent flyer card just got extended for another year - without flying Jan 04 10:48:40 ndec: morning! are we ready to merge the sphinx docs back to dunfell? Jan 04 10:48:58 If anyone has any issues with doing that, now is the time to say :) Jan 04 10:49:10 * RP did defer it until the holidays were over Jan 04 10:51:14 hey RP, I have been ready for a long time now ;) so looks good to me. We will need to keep an eye for breakage/issues of course. Jan 04 10:51:32 ndec: right, it was the latter I though I'd better wait over... Jan 04 10:51:51 as I said in the email, we will need to merge what we have first, then update the AB scripts to publish them, then update yp-docs conf.py to update the bitbake extlink. Jan 04 10:52:18 e.g. the first time we publish the cross links from yp-docs to bitbake will be wrong. Jan 04 10:52:29 ndec: right, I think I may as well go ahead and merge things and get this started? Jan 04 10:52:51 sure. i am back now.. and I can help with testing/monitoring! Jan 04 10:55:26 ndec: first set is in, is there a patch for the AB script? Jan 04 10:55:37 nope.. Jan 04 10:55:52 ok, I can have a guess then :) Jan 04 10:58:16 ndec: ok, patch for helper in Jan 04 11:01:11 RP: looks good. will you start a build? Jan 04 11:03:24 ndec: yes, done Jan 04 11:08:43 hello guys ! I'm struggling to create a .img file like the one generated for the raspberry Jan 04 11:08:52 in particular I saw that Jan 04 11:09:31 here there is the class that generates the sdimg file: https://github.com/agherzan/meta-raspberrypi/blob/master/classes/sdcard_image-rpi.bbclass Jan 04 11:09:48 thekappe: IIRC, they switched to wic images now Jan 04 11:10:26 ndec: seems to have gone green Jan 04 11:10:39 yes.. https://docs.yoctoproject.org/dunfell/ Jan 04 11:10:56 here there is the variable that enable the dsimg file generation (at least it was I suppose) https://github.com/agherzan/meta-raspberrypi/blob/e13d6a218863beaebef7a2cbb85764330343338a/conf/machine/include/rpi-default-settings.inc Jan 04 11:11:14 RP: let me check a few things, and i will share a patch for the bitbake extlinks. Jan 04 11:11:19 qschulz, what is a wic image ? Jan 04 11:12:47 thekappe: wic is a tool to create multiple partitions file that you can dd directly to a medium, such as an SD card, which is often the case for RPis Jan 04 11:13:41 https://docs.yoctoproject.org/ref-manual/kickstart.html Jan 04 11:14:35 qschulz, thanks. I'll look into that. I can't verify it now because I'm waiting the final board but what I wnat to do (if it's possible) is to create a .img file with all the files/partitions to boot a Linux Os on a zynq Jan 04 11:15:08 I'm planning to write this .img file from u-boot to the emmc on the board Jan 04 11:15:42 as the board needs to be flashed the first time Jan 04 11:16:02 do you know if it's possible ? Jan 04 11:17:19 BTW, thanks for the link Jan 04 11:25:22 ndec: merged and build triggered. I've added a patch to autorun docs builds for the new branches but its not applied to the running autobuilde ryet Jan 04 11:39:44 thekappe: SD card, emmc, same shit different name :) I'm not using a GPT table on our emmc (we use blkdevparts with hardcoded offsets in the emmc for "partitions") so can't say for sure but fairly confident it should work Jan 04 11:45:19 qschulz, thanks for the hint. Can you be more specific about 'blkdevparts with hardcoded offsets in the emmc in the emmc for "partitions"'. I'm new to the world so I am really interested in any better approach Jan 04 11:50:46 Once I get a fully blank board (no sd, blank emmc), I planned to boot the board via jtag until u-boot. Hence I thought I'll have two options, boot a linux image from tftp and hence write the emmc from the running OS, or alternatively, write a .img file (with the partition table and its related partitions) directly from uboot to the emmc, in order Jan 04 11:50:46 to populate it correctly Jan 04 11:57:59 qschulz, sorry i got disconnected Jan 04 12:05:00 thekappe: either should work just fine. I would honestly test both cases if you're interested in performance Jan 04 12:05:21 I remember U-Boot had subpar write/read performance for NAND controllers for a long time Jan 04 12:05:41 so maybe booting a very minimal kernel and initramfs and flashing from there would be faster Jan 04 12:06:17 (might also not have highest possible bandwidth on network too in U-Boot, so the smallest the image to load from network the better?) Jan 04 12:19:05 @RP: I am playing around with sourcestats.bbclass vs your hacked package.bbclass and there seem to be inconsistencies ;) Jan 04 12:19:48 RobertBerger: not surprised ;-) Jan 04 12:19:56 qschulz: did you consider enabling icache/dcache ? Jan 04 12:20:12 qschulz: that should help with your performance problems considerably Jan 04 12:20:12 @RP what I mean is, that hacked package.bbclass detects inconsistencies while sourcestats does not even realize that there is SPDX info ;) Jan 04 12:23:16 marex: it was years ago in my previous company and we just fixed the NAND controller driver ;) Jan 04 12:23:57 but thx for the suggestion! Jan 04 12:25:32 sure Jan 04 12:25:50 there is also this BLOCK_CACHE which makes a huge difference with ext4 Jan 04 12:26:33 @qschulz, thanks. How do you think https://www.kernel.org/doc/Documentation/block/cmdline-partition.txt would help in that ? Jan 04 12:32:54 RobertBerger: that is explained by package.bbclass seeing into headers which sourcestats would not Jan 04 12:33:41 thekappe: then you don't use the GPT table but hardcoded offsets, that's what we have. Honestly don't remember why hardcoded partitions were preferred, might be historical because we always used NAND before and wrote to raw partitions :shrug: Jan 04 12:35:41 @RP: OK - yep that would explain it - thanks! Jan 04 12:36:18 RP, kanavin: looks like upstream autoconf might have fixed the breakage, will test shortly Jan 04 12:36:28 rburton: ah, cool :) Jan 04 12:36:56 rburton: lwn also has coverage of this recent autoconf flurry of activity Jan 04 12:37:28 rburton, RP: https://lwn.net/Articles/834682/ Jan 04 12:38:06 yes Jan 04 12:44:00 rburton, kanavin: Nice to have a YP mention! :) Jan 04 12:44:52 just doing my job :) Jan 04 12:55:35 hi guys... I have a custom .bbclass in which I need to import some custom python module (named svn)... this works only if beforehand I install custom python module on build machine with e.g. "pip3 install svn" Jan 04 12:55:57 is it possible to somehow define this svn module as dependency :) Jan 04 12:56:47 cant you depend on python-something-native and let OE build it ? Jan 04 12:57:51 python3-svn-native in that case but it does not exist in "official" layers... might need to create a recipe for it ;) Jan 04 12:58:02 good idea :D Jan 04 12:58:26 basically in my custom layer I provide recipe for python3-svn-native Jan 04 12:58:37 and then do depends in my custom bbclass? Jan 04 12:58:56 yup Jan 04 12:59:05 ok, thanks... let me try to implement this :D Jan 04 12:59:06 but do you REALLY need this svn module? Jan 04 12:59:13 because we have svn support in SRC_URI Jan 04 12:59:23 (don't know what this python3-svn is for) Jan 04 12:59:37 qschulz: I need to parse SVN revision, etc to set PV, etc accordingly Jan 04 13:00:10 isnt that what the fetcher does already ? Jan 04 13:00:12 wooosaiii: what are you trying to achieve exactly? (why do you need to get SVN revision, etc...) Jan 04 13:01:14 my company has a ton of SVN modules... and I want to reduce recipe complexity... thus anyone that tries to add new recipe just sets COMPANY_SVNPKG_MODULE = "app/some-app" and inherits my custom class Jan 04 13:01:32 PV, SRC_URI, SRCREV, etc are then set automatically Jan 04 13:02:10 but I need to somehow fetch / parse those... and here I need this python3-svn module Jan 04 13:02:47 is this sound explanation? :D Jan 04 13:03:48 isnt that something like AUTOREV ? Jan 04 13:04:18 marex: well not really... AUTOREV doesn't set PV for example Jan 04 13:04:34 marex: all pkgs will have version 1.0 Jan 04 13:05:44 wooosaiii: doesnt it set SRCPV ? Jan 04 13:06:04 meta/recipes-core/psplash/psplash_git.bb:PV = "0.1+git${SRCPV}" Jan 04 13:07:59 marex: have to look into this... thanks Jan 04 13:08:15 wooosaiii: I think qschulz is right, you should be able to achieve most of it using the fetcher and the variables it extracts from the repo on its own Jan 04 13:08:39 wooosaiii: and then maybe what you want is some .inc file instead of bbclass Jan 04 13:09:32 wooosaiii: it seems svn supports AUTOREV mechanism, you indeed should use SRCPV in PV Jan 04 13:09:55 then bbclass or inc file would do, though bbclass works better if you have your recipes in different directories Jan 04 13:10:23 qschulz: .inc file works better if you need to override it Jan 04 13:10:44 qschulz: you cant easily override bbclass Jan 04 13:12:13 marex: indeed, if they're the final user and not a vendor, it'd be nicer (well... anyway AUTOREV shouldn't be used at all in that case) Jan 04 13:12:53 (AUTOREV is ok probably only during heavy development phase.. but no AUTOREV for production ;) Jan 04 13:12:54 qschulz: ack on AUTOREV, it should only be used during active development, and even then its often source of problems Jan 04 13:13:05 marex: you read my mind :D Jan 04 13:13:07 qschulz: heh Jan 04 13:36:57 RP: just going to do a test build for autoconf270 on the AB Jan 04 13:47:31 rburton: cool, I have some kernel and other patches I was going to run tests for too Jan 04 13:47:49 I've just fired a solo qemuarm64 run, not a-* Jan 04 13:50:47 rburton: ok, I assume its not ready for an a-* ? Jan 04 13:51:41 well, lets see if this passes first :) Jan 04 13:52:09 rburton: right, just wondering about my bigger build I'm queuing Jan 04 13:52:25 zeddii: I'm pulling in the 5.10 kernel bits Jan 04 13:52:39 ok. cool. was just writing you an email! Jan 04 13:52:42 mine will be done fairly quickly and if against all expectations it is green i'll schedule a full later tonight Jan 04 13:53:11 My last build was mid last week, and I'll spin up some more. I'm here, and will be the rat on the wheel to get anyting fixed. Jan 04 13:53:58 zeddii: I'm catching up on my queue, finally replied to your 5.10 one :) Jan 04 13:54:41 heh. I get it. No worries here. I did almost nothing for the past week, so I'm catching up on suspended things as well. Jan 04 13:59:15 zeddii: I didn't want to get pulled into opening up files an things, or trying to split patch series to the different trees ;-) Jan 04 14:15:19 RP: Sorry for the delay, I took some vacation. The action to invalidate an hash-equiv entry is pretty simple (either delete the row, or change the hash). We can manually do that if there are equivalences that you need to remove. Otherwise, we need some mechanism for the code to be able to detect it itself Jan 04 14:15:55 Hi, does anyone know if libpam-otpw recipes exist? Can't find any :( Jan 04 14:16:42 JPEW: No problem, vacation is good. I was looking for a way to do it from a recipe but I think I found a rather horrible one... Jan 04 14:18:53 RP: Hmm, should we add something like: `bitbake -c invalidate-hashequiv ` ? Jan 04 14:19:48 JPEW: I don't think it makes sense since I needed to "ship" the invalidation to anyone using the code Jan 04 14:21:14 JPEW: basically when we have a reproducibility issue we need to invalidate the outhash since in these cases we have multiple inputs matching that outhash, some correct and some not. Jan 04 14:22:29 RP: Ah, make sense.... perhaps we need to add a variable that factors into the outhash ("OUTREV"?) for that purpose? Jan 04 14:22:55 JPEW: we kind of have one. Its probably a case of deciding if this is the way to promote doing this Jan 04 14:23:41 JPEW: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=290dccc6e236d66f26da9332a87e4fb7b95e2c58 Jan 04 14:25:49 RP: OK. I think something like that is fine. It makes sense to me at least Jan 04 14:26:57 JPEW: it seemed right to me but I wasn't 100% sure, its slightly abusing the variable Jan 04 14:27:43 RP: Ya, we could make it the contentation of 2 variable (which I think would make it a little more clear) Jan 04 14:30:45 Having both a the "global" version and a "recipe specific" version Jan 04 14:31:23 JPEW: I guess it depends how common we think this will become... Jan 04 14:36:19 I have a anonymous python function in .bbclass... It wants to import custom python module named 'svn'. Module should be built by the custom recipe named python3-svn.bb that does BBCLASSEXTEND = "native" and in .bbclass I do DEPENDS += "python3-svn-native". Jan 04 14:37:04 I can see python3-svn-native getting built... but then anonymous function fails with "failed to import module svn"... Jan 04 14:37:10 wooosaiii: I don't think you can import a python module provided by a recipe in anon python Jan 04 14:37:10 what am I doing wrong Jan 04 14:38:03 JPEW: I also fear this is true for anonymous functions Jan 04 14:38:25 wooosaiii: What are you trying to do? Jan 04 14:39:01 JPEW: I did some explanations at 14:01:14 :) Jan 04 14:39:49 wooosaiii: you can't import external modules from inside anon py as you need to be running on the python3-native python3 binary, which you are not Jan 04 14:40:49 rburton: so the only solution is to provide external module on the host machine via apt-get or pip3 or something right? Jan 04 14:41:11 or write a script and run it in the right python3 instead of using anon poy Jan 04 14:41:53 wooosaiii: You could also build in a container, or roll your own buildtools-tarball that your developers must use Jan 04 14:42:11 ^^ which would make sure python3 svn is installed on the host Jan 04 14:42:49 JPEW: I already do use docker container... but I didn't want to add additional dependencies there :D Jan 04 14:43:02 guess this will be the easiest solution Jan 04 14:43:32 wooosaiii: Ya, that's probably the easiest Jan 04 14:49:07 tlwoerner: I've added mkfifo to HOSTTOOLS in -next for testing, thanks to rburton for reminding me of the real pseudo issues Jan 04 14:54:28 definitely too many mesons around :) Jan 04 14:54:37 RP: okay nice Jan 04 14:55:05 tlwoerner: I'll retest and see how we look Jan 04 14:56:44 RP: thanks, fingers crossed :-) Jan 04 15:51:03 * kergoth yawns Jan 04 15:57:14 Hi guys, i have successfuly built dunfell-22.0.4 on my machine and now would like to do zeus-22.0.4, is it as easy as checking out the correct branch and running "source oe-init-build-env" + "bitbake core-image-sato" again? Jan 04 15:58:57 I'm trying to avoid compiling everything from scratch Jan 04 16:02:56 Sponge5: zeus and dunfell are different enough it won't reuse much and its safer to use a separate build directory Jan 04 16:04:42 RP: Already ran it, oops. Separate directory would mean I'd build both from scratch, right? Jan 04 16:05:20 thanks anyway! Jan 04 16:05:25 Sponge5: yes, but as I said, it will effectively do that Jan 04 17:29:24 Can I unsubscribe from main but still being subscribed from poky mailing list? Jan 04 17:30:41 v0n: there has never been a message sent to main according to the "archives" Jan 04 17:31:21 v0n: "Please note that unsubscribing from main@lists.yoctoproject.org will remove you from all Yocto Project mailing lists. " Jan 04 17:31:21 mmh ok. I asked because I subscribe to poky@ and I also get a subscription notice for main@ Jan 04 17:31:37 https://lists.yoctoproject.org/g/main Jan 04 17:32:04 okay, I'll keep it then and filter both poky@ and main@ I guess ;-) Jan 04 17:40:45 there are no messages on main@ Jan 04 17:42:11 I hope so :P Jan 04 17:45:55 v0n: main is an implementation detail, no mail from it Jan 04 17:49:15 moreover: "Only moderators can post to the group." so you'll be fine really ;) Jan 04 17:50:53 he he, perfect then ;-) Jan 04 17:51:24 subscribing to a mailing lists to send a few typo fixes is always a barrier Jan 04 17:56:36 v0n: the patches look good, thanks! :) Jan 04 17:57:22 RP: how do you know it was me!? :-P Jan 04 17:57:47 v0n: I'm making an educated guess :) Jan 04 17:58:10 v0n: I process the patches so I pay more attention than most Jan 04 18:01:54 these are silly patches, but there's no bad contribution to start from IMHO. I hope you don't mind Jan 04 18:02:59 v0n: not silly at all, the patches are very welcome! Jan 04 18:57:04 oh perf. why do you hate us so ?!? Jan 04 19:08:06 haha Jan 04 19:08:31 zeddii: imagine how much time you could save if you just had a CI bot building perf in all the combinations we care about so you could spam the lists when it breaks Jan 04 19:08:42 basically, why can't kernelci do that? Jan 04 19:09:03 perf for 32bit arm is busted in 5.11 in our env. I could spam ARM folks about that! ;) :P Jan 04 19:09:34 "could" Jan 04 19:10:02 and "our" env means oe-core, not my employers ENV Jan 04 19:10:18 that's even more busted I'm sure :D Jan 04 19:11:38 * zeddii wades into Makefile hell. Jan 04 19:19:08 * moto-timo back from sabbatical Jan 04 19:20:29 moto-timo my condolences Jan 04 19:20:34 man, pseudo is *really* slow under asan Jan 04 19:20:49 zeddii: you know we don't care about obsolete architectures anymore Jan 04 19:21:03 I'm sure 64 bit is busted too. Jan 04 19:21:08 I just haven't gotten there yet :D Jan 04 19:21:10 zeddii: honestly, why isn't kernelci catching these? Jan 04 19:21:19 fray: thank you Jan 04 19:21:24 x86 on x86 would pass Jan 04 19:21:35 so I'm not sure if kernelci is doing cross stuff. Jan 04 19:31:59 zeddii: I can make it an agenda topic in tomorrow's kernelci technical meeting... what would you like me to ask ? Jan 04 19:32:30 Is perf being built in kernel-ci, and if so, is it cross built ? Jan 04 19:32:40 because I'm always seeing it detect things on the host, and getting it wrong. Jan 04 19:32:40 gotcha Jan 04 19:32:47 and there's no way for me to easily override them. Jan 04 19:33:02 in this case, its picking a x86-64 libcap from sysroot native for a 32 bit ARM build Jan 04 19:33:07 so clearly, it is off the rails. Jan 04 19:33:19 ugh Jan 04 19:34:36 Are the image recipes designed only for complete rootfs image? Or can I use one to create a squashfs containing a single file? Jan 04 19:36:12 v0n: They pull in packages from package feeds (primarily) Jan 04 19:36:31 I'm trying to figure out a simple way to provide a configuration override to a prebuilt system from an (e)SDK. Jan 04 19:37:03 so a squashfs image containing only /etc/myapp.conf with a built-in logic to overlay it on boot might be neat Jan 04 19:54:04 so long ago, one of the reasons pseudo ended up with horrible fsync workaround hackery was that some (but possibly not all) filesystems did not actually have the ability to flush *just one* file descriptor, so fsync() meant "wait until ALL writes prior to this moment have been flushed", which was Painfully Slow. Jan 04 19:54:24 does anyone happen to remember this madness and/or have hints on which filesystems are or aren't affected, before i go doing science to experiment with it? Jan 04 20:00:24 I don't remember which ones, but the ones at the time it was added were btrfs, xfs, zfs, nfs, and the whole ext* line Jan 04 20:00:32 so it could have been any or all of those Jan 04 20:01:55 fray: oh hey, any news on meta-xilinx-standalone release of matching embeddedsw sources ? Jan 04 20:30:40 marex I keep asking, nothing to report at this time.. sorry Jan 04 20:31:26 fray: how hard can a simple 'git push' be ? Jan 04 20:31:38 it's a completely different set of sources that what has been previously released Jan 04 20:31:39 fray: surely someone does have the matching sources Jan 04 20:32:10 So there are a lot of issues with code review, legal review, etc etc.. I'm not in the group that has the code, only one of the people requesting they make it available Jan 04 20:32:11 fray: which btw is also totally baffling, how did Xilinx keep releasing this meta-xilinx-standalone for over two years without noticing that it doesn't even compile Jan 04 20:32:13 is there no CI ? Jan 04 20:32:45 there are parts of the standalone that do NOT use the embedded software that we're talking about.. specifically the baremetal toolchain components work fine with the exisitng.. Jan 04 20:32:55 it's the ability to rebuild the pmufw and other stuff that requires the unreleased code Jan 04 21:45:00 rburton: it's a good thing "cp" is one of those rare commands that most users never use (lol) ;-) Jan 04 22:04:42 tlwoerner: :) Jan 04 22:40:43 fray: isn't pmufw one of the most basic boot components on zynqmp ? Jan 04 22:41:14 fray: note that that one can be compiled, it is all the other cr5 stuff which is completely broken Jan 04 23:09:34 zeddii: FWIW the 5.10 patches in master-next seem to test out ok Jan 04 23:09:44 zeddii: should I merge? Jan 04 23:41:06 RP: yep. I have no other changes that weren't in that branch. Jan 04 23:41:31 I have some more -stable bumps for 5.10, but they'll flow through the normal process. Jan 05 00:14:35 zeddii: cool, will think about it tomorrow :) **** ENDING LOGGING AT Tue Jan 05 03:01:24 2021