**** BEGIN LOGGING AT Thu Jan 07 03:00:55 2021 Jan 07 03:02:29 ant__: which recipe of which meta-rockchip? Jan 07 07:29:05 hi, any good hints for intro videos into yocto/openembedded Jan 07 07:51:42 https://www.google.com/search?hl=&site=&q=intro+videos+yocto+openembedded Jan 07 08:13:40 good morning Jan 07 08:15:44 hmw1: https://theyoctojester.info/ Jan 07 09:18:42 tlwoerner, hi, I found this series https://www.yoctoproject.org/pipermail/yocto/2017-January/034043.html Jan 07 09:18:57 did not bother to check the final commits... Jan 07 10:31:23 hmm, private email asking me why backporting a patch from master to sumo doesn't "just work" Jan 07 10:32:55 RP it's a hard life Jan 07 10:35:06 RP: got tired of the sumo backports that keeps coming on the ML, had to answer. Probably the same people I guess considering the timing Jan 07 10:35:31 qschulz: oddly enough its not, its a big company :/ Jan 07 10:35:59 I do think it would be useful for people to collect some of these things together if they are insisting on using obsolete versions Jan 07 10:36:20 I do understand why it can be necessary too Jan 07 10:36:34 not sure to follow what you mean by collecting some of these things? Jan 07 10:38:27 qschulz: putting the CVE fixes together on a branch would save each group reinventing them Jan 07 10:39:06 Hi, I'm trying to change the INITSCRIPT_PARAMS from the hostapd package in a bbappend in zeus but I keep getting "Postinstall scriptlets of ['hostapd'] have failed. If the intention is to defer them to first boot, Jan 07 10:39:06 then please place them into pkg_postinst_ontarget_${PN} ()" this does not occur if I use the default INITSCRIPT_PARAMS. I am not really sure on how to add the pkg_postinst_ontarget_${PN} () or fix the error. Has anyone encountered this? Jan 07 10:39:15 * RP wonders how depressed to be that master-next failed with three different failures, all not related to the changes in -next afaict Jan 07 10:39:49 RP: I'm afraid there'll be an expectation that the branches will stay up-to-date with the latest CVE fixes even on unmaintained (which technically wouldn't be unmaintained anymore... community-based effort buut still) branches Jan 07 10:40:27 RP: I don't think we want to make it less painful for people to stay on long outdated branches? Jan 07 10:40:48 qschulz: right, there are good reasons why we've not "done" it :( Jan 07 10:41:09 qschulz: the problem is testing of those patches. unmaintained branch as there's no maintainer to test. Jan 07 10:41:37 hey if someone is using sumo then they can step up and run the branch though the AB Jan 07 10:42:02 rburton: trouble is the older branches are breaking on the AB, as they're not being run regularly :/ Jan 07 10:42:16 we did just about make sumo work but I suspect it will be broken again Jan 07 10:42:29 qschulz: I always try to persuade manufacturers to migrate to newer versions but it is very difficult Jan 07 10:42:47 I can't even keep master working well, see comment above Jan 07 10:43:33 qschulz: after all they still manage to sell their cards :-D Jan 07 10:44:10 mckoan: sure, but then it's up to the user/company buying those cards to either complain or suffer the maintenance burden or upgrade path Jan 07 10:44:42 bash reproducibility issue, apt pseudo file handle issue and a checksum corruption issue with dnf Jan 07 10:44:45 qschulz: in a perfect world yes Jan 07 10:45:25 mckoan: what is there to earn for Yocto maintainers/contributors to maintain those branches from 5 years ago? Jan 07 10:45:56 qschulz: in fact. I totally agree. Sigh Jan 07 10:46:08 rburton: was autotools ready for wider testing? Jan 07 10:46:24 mckoan: I mean, you have to draw the line somewhere as a project and also as a user of some companies' products which are using long outdated software Jan 07 10:46:32 RP: yeah i need to rebase and clean up the branch. if the AB is idle though I can throw the messy branch at a-quick though Jan 07 10:46:58 mckoan: if they were paying it'd be a different story. See Microsoft with privately maintained XP now... Jan 07 10:47:54 rburton: might be interesting to. I'm just wondering if I need to save off any of these failures :/ Jan 07 10:47:58 Well, all of this from my perspective of small and occasional contributor and no maintainer of nothing :) Jan 07 11:33:19 Hello, quick question, according to https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-testing I'm supposed to test on target, does that mean that the only way to test is to run the image and test from inside the emulation? Jan 07 11:34:21 * mcfrisk still uses sumo, in decent shape CVE wise, maybe have something to do with the patches on mailing list.. Jan 07 11:35:02 RP: ok, I'll tell you a secret Jan 07 11:35:10 and can't update thanks to a big SOC vendor screwing us up big, big time Jan 07 11:35:25 lot of OE 'distros' did use sumo until last month Jan 07 11:36:04 lot of .bbappends and dubious patches, still they build images for DVB / STB Jan 07 11:36:11 mcfrisk: would you want to actually try and collect them up? Jan 07 11:36:26 mcfrisk: sad you're "stuck" :( Jan 07 11:37:36 RP: I have everything in a private tree, but can't publish that. would need to clean it up... and I do have backports for devel tools like python 2.7 Jan 07 11:37:43 just look in github for OpenPLi and OE-A Jan 07 11:38:28 mcfrisk: for a while recently we did have sumo building on the autobuilder. Not sure it would work now :( Jan 07 11:38:58 now people moved to zeus fwiw, so expect mainenance Jan 07 11:38:59 mcfrisk: I'd guess you have other priorities than cleaning it up :/ Jan 07 11:39:00 mcfrisk: can't you just make a BSP layer with this SoC vendor crap and update the rest? Jan 07 11:39:11 we do have CI with target tests and all Jan 07 11:39:19 ant__: which is funny considering dunfell is an LTS and not zeus :) Jan 07 11:39:34 I tried hardly..no way :) Jan 07 11:39:37 mcfrisk: and by BSP layer I mean bootloader and kernel? Jan 07 11:39:45 the issue is enigma2 and python 2.x Jan 07 11:39:48 qschulz: sadly not, some high level SW components from SoC vendor tie up openssl, icu etc versions Jan 07 11:39:48 mcfrisk: right, but your testing != the project's testing for our release quality :( Jan 07 11:39:58 I know, different kind of testing Jan 07 11:40:24 mcfrisk: vendors... smh Jan 07 11:40:45 ant__: py2 is why zeus and not LTS? Jan 07 11:40:53 iirc yes Jan 07 11:41:23 someone must rewrite enigma2 spaghetti code :) Jan 07 11:41:37 we made an effort to drop py2 from the LTS purely as it was dead then, let alone for the lifetime of the LTS :/ Jan 07 11:42:33 isn't there a (now unmaintained IIRC?) meta-python2 layer for dunfell? Jan 07 11:44:22 qschulz, my try https://forums.openpli.org/topic/76314-zeus-vs-dunfell/page-3#entry1212098 Jan 07 11:51:47 sorry to repeat my question, but the #new-recipe-testing entry in dev-manual isn't exactly exhaustive and I'm having no luck with SO/Reddit. Jan 07 11:52:05 Do I have to run the image to test whether all files are where they should be? Jan 07 11:53:04 To clarify, by "run the image" I mean "runqemu ..." Jan 07 11:53:12 Sponge5: you should be able to look at the WORKDIR/image directory or look at the generated packages Jan 07 11:53:12 ant__: hi, are you using OpenPLi ? Jan 07 11:54:12 Sponge5: oe-pkgdata-util list-pkgs ; oe-pkgdata-util list-pkg-files ; oe-pkgdata-util find-path /target/path/to/your/files Jan 07 11:54:23 rburton: diffoscope is off in the weeds again :( Jan 07 11:55:52 qschulz: thanks, I'll look into it! Jan 07 11:57:25 hmm, ppp and vulkan-samples-staticdev Jan 07 12:22:08 mckoan, ciao Jan 07 12:22:18 yes, I use it on vu+ vuduo2 Jan 07 12:22:39 I am fixing xbmc/kodi compilation on it Jan 07 12:23:02 problems where the mipsel fixes and now the private libs Jan 07 12:23:16 it is my new hobby after zaurus :) Jan 07 12:26:24 mckoan, btw I am A.A there Jan 07 14:39:35 Does anyone know how to force make to use a specific shell? Setting SHELL isn't helping :( Jan 07 14:40:01 that's the only hook I'm aware of Jan 07 14:41:01 The issue is https://github.com/paulusmack/ppp/issues/233 - reproducibility issue in ppp, dash vs bash. I can't stop it using /bin/sh Jan 07 14:43:13 yah. SHELL= in the Makefile has always done it for me in the past as well. Jan 07 14:44:34 SHELL = and then exporting it to any submakes, since IIRC it goes back to the environment variable otherwise. Jan 07 14:48:20 zeddii: I tried export SHELL = /bin/bash, I tried adding it to the commandline, I tried MAKESHELL, nothing seems to deter it Jan 07 14:49:06 bugger. and the problematic snippet, is in the first Make call ? i.e. not a submake, because, yah, that should 'just work' Jan 07 14:50:06 zeddii: no, its in a subdir Makefile with all kinds of parallel stuff flying around but nothing I can set seems to make it work Jan 07 14:50:33 yah. your export= should have handled that case. Jan 07 14:51:40 does a brute force patch of shell= in each and every makefile fix it, I wonder ? Jan 07 14:51:50 zeddii: tried that too :( Jan 07 14:51:59 daaaaang. Jan 07 14:52:34 if that doesn't work, then yah, there's no sense messing about with exporting SHELL, etc, since it is using something else. Jan 07 14:52:38 It's possible that a command inside the makefile sets the variable to /bin/sh Jan 07 15:06:53 can anyone suggest a way to do echo '#include ' in portable shell? :) Jan 07 15:07:41 quoting was screwed up in that report, oh the irony Jan 07 15:11:00 RP: here text? cat > file.c << EOF #include \nEOF\n ? Jan 07 15:11:21 mcfrisk: its the # character :/ Jan 07 15:11:41 mcfrisk: might work, not sure Jan 07 15:11:59 escape it with \? Jan 07 15:12:11 qschulz: works in some shells, not others Jan 07 15:12:24 I think this is actually a bug in bash, not a dash vs bash issue :( Jan 07 15:12:27 RP: dang... WHY SOME MANY DIFFERENT SHELLS Jan 07 15:12:36 s/SOME/SO/ Jan 07 15:16:24 RP: `echo -e '\x23'` ? Jan 07 15:16:31 RP: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02 it seems backslash or single or double quote escaping is POSIX compliant? Jan 07 15:16:36 Infact no, that may not work Jan 07 15:16:48 paulbarker: it uses \ so won't help :( Jan 07 15:16:50 Eugh, printf examples using `echo -e` instead of `printf` Jan 07 15:17:12 qschulz: I just updated that issue report, its a bug in some versions of bash afaict Jan 07 15:17:15 awk 'BEGIN { print "#include " }' Jan 07 15:17:16 :D Jan 07 15:18:49 Yep, looks like most of the best bets are awk or perl one-liners, choose your poison Jan 07 15:19:57 basically I need a command without # or \ in the command Jan 07 15:22:27 ah, but its a makefile so I can use make's variables Jan 07 15:23:22 yah, because any way I can think of to print # without using #, involves a code that uses \ Jan 07 15:23:24 HASH=$(echo 35 | awk '{ printf("%c", $0); }'); echo "${HASH}include " Jan 07 15:23:42 ooo! Jan 07 15:24:10 paulbarker: that should work :) Jan 07 15:24:24 omg Jan 07 15:24:37 It's only Jan 7th but I think that's a clear contender for the ugliest code I'll write all year Jan 07 15:24:45 UTMPHEADER = "\#include and then echo $(UTMPHEADER) also works Jan 07 15:24:55 paulbarker, call it "clever" Jan 07 15:24:57 but I do like paulbarker's version :) Jan 07 15:26:27 RP: I'm confused by your UTMPHEADER solution? where does the bug of unescaped # reside then? Jan 07 15:27:04 qschulz: it pushes the quoting handling from the shell to make Jan 07 15:39:10 How come there are no logs available for 2021?? Jan 07 15:45:26 or is this irc channel no longer active? Jan 07 15:45:29 halstead: ^^^ Jan 07 15:46:29 hithere: I guess the logging process drank too much at new year Jan 07 15:47:21 well someone responding means it is still active, one of the two mysteries seems to have cleared up, now the log "issue" Jan 07 15:47:30 (y) Jan 07 17:25:58 Just for completeness this issue isn't a shell issue. its a make incompatibility Jan 07 17:25:59 http://git.savannah.gnu.org/cgit/make.git/commit/?id=c6966b323811c37acedff05b576b907b06aea5f4 Jan 07 17:43:32 that spells it out pretty clearly!! Jan 07 17:44:08 RP: Am I right thinking this was the wic/pseudo bug we were talking about on Tues? https://bugzilla.yoctoproject.org/show_bug.cgi?id=14129 Jan 07 17:46:09 paulbarker: yes Jan 07 17:46:50 RP: Cool, I'll assign that to me. Will pick up up once I've finished fixing https://bugzilla.yoctoproject.org/show_bug.cgi?id=13994 Jan 07 17:47:58 paulbarker: thanks. I'm just struggling to get to things... Jan 07 17:57:23 Hi. Sorry if a bit off-topic, but can anyone tell me how to generate a sources folder such as the one found here: https://docs.projects.genivi.org/releases/gdp/13.0/raspberrypi3/sources/ Jan 07 18:00:31 Ollie456: Not off-topic at all. Look up the archiver bbclass in the docs Jan 07 18:02:40 perfect thank you Jan 07 18:05:06 Hey, why is the MLO and u-boot.img files part of the boot partition for beaglebone, since they should be written raw at the beginning of the SD card if I'm not mistaken Jan 07 18:06:04 v0n: Either option is supported by the AM335x boot rom. Jan 07 18:06:37 For the BeagleBone Enhanced (MACHINE = "bbe") in meta-sancloud we use the single partition layout with no vfat boot partition Jan 07 18:07:41 hum, interesting, I've just tested to put them all in the boot partition and it doesn't boot Jan 07 18:07:51 v0n: You could probably use same wic file with the original beaglebone: https://github.com/SanCloudLtd/meta-sancloud/blob/dunfell/wic/sancloud_bbe.wks Jan 07 18:08:50 v0n: Actually, just remembered some details Jan 07 18:09:13 You need either a u-boot patch (ugly) or a u-boot script in /boot in the rootfs (nicer) Jan 07 18:09:27 We use https://github.com/SanCloudLtd/meta-sancloud/blob/dunfell/recipes-bsp/u-boot/files/boot.cmd as the boot script Jan 07 18:22:58 paulbarker: I'll look into your wic file, thanks. If I want to protect the kernel and initramfs images I'm using, can u-boot for example pick these files from a encrypted partition? so that my SD card looks like: [MLO][u-boot.img][Part1(enc):zImage+dtb+intramfs][Part2:rootfs to switch to] Jan 07 18:23:36 v0n: I'm not sure off the top of my head. I'd be interested to see that working though Jan 07 18:24:49 paulbarker: or ideally having the MLO and u-boot.img unpartitioned and a single encrypted rootfs containing the kernel in /boot, but I'm not sure beaglebone supports that Jan 07 18:25:33 I've found patches to encrypt the rootfs with dm-verity but it seems like the secure location has to be in the kernel (signed fitImage) Jan 07 18:25:46 v0n: It would really be down to what u-boot supports when loading the kernel, dtb and (possible) initramfs Jan 07 18:26:00 I don't think it's hardware dependent Jan 07 19:07:10 v0n: I could be misremembering, but I have memories of something along the lines of needing to buy am355x parts from TI with the feature not disabled to be able to properly do secure boot Jan 07 20:31:23 smurray: the am335x parts with hardware root of trust are indeed on special order (and expensive) Jan 07 20:31:46 marex: heh, good to know my memory isn't completely shot ;) Jan 07 20:38:49 marex: smurray: what's the point of it? it you want an encrypted bootloader maybe? but if your bootloader is not encrypted, it can decrypt and thus you don't need this hardware component, right? Jan 07 20:43:35 v0n: the bootrom can authenticate signed bootloader blob, if the signature matches then bootloader is started, otherwise the system tries the next blob or hangs Jan 07 20:46:48 JPEW: any thoughts on qemu on mingw? I think that is the last piece of the qemu upgrade puzzle now Jan 07 20:48:09 RP: Only thing I can think of is to add a flag like "--mingw-flat=no" or something :( Jan 07 20:48:24 JPEW: should we just patch it out for now? Jan 07 20:48:44 Probably Jan 07 20:49:04 I'll try to propose a patch upstream to see how it goes over Jan 07 20:49:33 JPEW: I might try hacking something for now to see if we can move forward whilst that happens Jan 07 20:49:41 marex: ok then if you don't mind a non encrypted bootloader, you can let it decrypt and boot an encrypted kernel/rootfs without this hardware feature, right? Jan 07 20:49:44 RP: sounds good Jan 07 20:52:16 v0n: it's not about encryption, it's about chain of trust Jan 07 20:54:13 paulbarker: shouldn't it be --ondisk mmcblk in sandcloud_bbe.wks? Jan 07 20:56:04 v0n: Yes, `--ondisk mmcblk` is already used in each `part` line Jan 07 20:56:21 paulbarker: oops I meant --ondisk mmcblk0 Jan 07 20:56:44 I believe the index is handled automatically Jan 07 20:56:52 ho ok Jan 07 21:23:37 JPEW: confirmed that fixes it FWIW (hack in -next) Jan 07 21:25:28 RP: hey uh, if I want to override TOOLCHAIN_SHAR_REL_TMPL with a file in meta-foo , what do I set into that variable e.g. in local.conf ? Jan 07 21:26:02 I saw someone using ${LAYERDIR_meta-foo}/files/toolchain-shar-relocate.sh , but that seems to fail Jan 07 21:26:30 marex: you'd need something to be setting LAYERDIR_meta-foo Jan 07 21:26:34 RP: (yes, I am trying to backport the toolchain fixes to thud) Jan 07 21:27:01 RP: is there something which does that for me already ? Jan 07 21:27:11 RP: I was looking around wks, maybe that's what I want (? Jan 07 21:27:15 marex: not in master, a later might do it Jan 07 21:27:21 er, a layer Jan 07 21:27:47 not seeing the connection to wks Jan 07 21:28:01 RP: well WKS is also using the .wks file which is located in layer Jan 07 21:28:11 RP: so there should be some mechanism to find that file in a layer already Jan 07 21:28:18 RP: maybe it could be reused somehow Jan 07 21:28:36 ah, perhaps. I doubt the toolchain mechanism uses the logic though Jan 07 21:28:54 I suspect wks is done using BBPATH or similar Jan 07 21:28:59 RP: it is Jan 07 21:29:09 RP: I'll keep digging Jan 07 21:32:18 RP: ah, of course I can set it, thanks Jan 07 21:39:33 RP: Ok. I just sent a patch to QEMU, we'll see what they say Jan 07 21:40:20 JPEW: cool Jan 07 21:40:42 * RP somehow needs to unblock the patches in -next :/ Jan 07 21:44:54 My build server just filled it's disk with sstate.... time to buy a larger hard drive Jan 07 21:51:14 JPEW: probably faster than trying to delete it :) Jan 07 21:56:21 RP: Ya, it's only a 300GB disk, and it's shared with the OS, so it's time for a new one Jan 07 22:02:00 JPEW: I have a 2TB I keep filling! Jan 07 22:02:04 (just with sstate) Jan 07 22:03:20 JPEW: I setup a 1TB SSD drive.. a dream.. Jan 07 22:04:48 PaowZ: Ya. I just bought a 1.2 TB drive. It's for my build servers, so I'm not *as* worried about the speed. I have SSD for my desktop; it's nice :) Jan 07 22:05:02 Spindle driver for the server Jan 07 22:29:09 I got a mvme drive.. it just says I am out of space faster ; / Jan 07 22:34:39 JPEW: true that bottleneck is CPU first, but still.. considering the number of small files to read and, why not, rootfs writes of several GB :-) Jan 07 22:39:00 Ya. Decking out my servers with NVMe would be a little bit $$$ for my tastes... it would probably cost more than I paid for the servers in the first place :) Jan 07 22:42:37 Can't find the complete list of the web browsers in the recipes... Jan 07 23:19:39 does anybody know the recipe for Firefox/Chromium ? Jan 07 23:56:08 dv: https://github.com/OSSystems/meta-browser/tree/master ? **** ENDING LOGGING AT Fri Jan 08 02:59:57 2021