**** BEGIN LOGGING AT Wed May 13 02:59:58 2020 May 13 03:14:07 jonmason: if you miss a meeting, you could always consult the notes/minutes ;-) May 13 05:00:30 tlwoerner: how much do you pay for "consulting"? May 13 05:38:44 RP: I see you staged Revert using __getauxval in libgcc patch its no longer needed after the v5 so please drop it May 13 07:34:19 Good day, trying to make a full read-only root filesystem. I have an overlay FS that is catching pretty much all reads to the filesystem, but I have some questionmarks about some files. May 13 07:35:11 Anyone out there with a couple of minutes to spare on obscure files in the /etc/ folder? :) May 13 07:36:14 i'm no expert there, but.. why would an overlay catch the *reads*? May 13 07:36:28 ... Writes May 13 07:36:37 i mean, we usually just go for IMAGE_FEATURE read-only-rootfs and are mostly set. May 13 07:36:51 Yeah, I did that May 13 07:37:07 And it's a handful of files I need to determine what to do with May 13 07:37:11 Also, systemd :P May 13 07:38:05 Anyway, booting from a fresh image, systemd seems to update group and gshadow files by removing four groups May 13 07:38:22 set .updated and machine-id May 13 07:38:36 and then udev/hwdb.bin and ld.so.cache May 13 07:39:14 Hi, i want to link against dbus with the SDK. How do i do that? It only uses --sysroot=/opt/fslc-framebuffer/2.6.4/sysroots/armv7at2hf-neon-fslc-linux-gnueabi May 13 07:39:19 link / compile. right now the compiler does not find dbus.h May 13 07:42:13 PatrickE: as usual, check the include paths given to your build. your build system should be checked to be cross compilation aware. May 13 07:42:38 wertigon: hum but that is no standard behaviour as far as i know. May 13 07:43:24 Letothe2nd: Yeah, I know, that's what puzzles me too :/ May 13 07:43:52 wertigon: remove your $SPECIALSAUCE until you understand it :) May 13 07:43:54 Letothe2nd: Sorry I was wrong, it adds four groups to group/gshadow: wheel, kvm, render and nobody May 13 07:45:17 But this should be easily fixed by adding them manually in say, the systemd .bbappend May 13 07:45:31 Letothe2nd if i use the SDK i dont have an include path. But i just saw that there is an sdk pkg-config May 13 07:46:07 PatrickE: Did you run the SDK setup script? May 13 07:46:10 PatrickE: why shouldn't you have an include path in the sysroot? May 13 07:46:45 wertigon yes i did. I see the XCC and other env variables May 13 07:47:08 PatrickE: Ok, just checking the basics :) May 13 07:47:26 PatrickE: sounds like you are ignoring the environment setup script. essentially, if you did your stuff right, it should build in the sdk seamlessly. if it doesn't, its pretty much an indication that you hardcoded things into your build instead of properly configuring them. May 13 07:50:42 Letothe2nd: The overlayfs will be moved to a RAM disk btw (currently it's a separate partition), so I want to make sure it's as small as possible. Then logs are stored on a separate partition. May 13 07:51:38 wertigon: don't get me wrong, i totally understand the objective. just can't help you with it. May 13 07:51:48 Hello All, May 13 07:51:52 Letothe2nd: Ok :) May 13 07:52:11 Letothe2nd: thank you for your time atleast May 13 07:52:59 Ok wait... I added dbus for rauc support and then i created the SDK (not extended SDK). I see the dbus.h in /opt/..../usr/lib/dbus-1.0/include/dbus. And i sourced the environment script as mentioned in the documentation May 13 07:54:11 PatrickE: see, then make your build system find it through pkg-config or whatever applies, and use the resulting path flags. May 13 07:55:35 I am using sja1000 can , I have configured device tree for interrupt and all..the problem is i am facing in "irq.c" driver. even though I configured #interrupt-cells = <2>; the property read by driver gives interrupt size as 4( its default value) May 13 07:57:19 manoj: sprinkle printks everywhere :) May 13 08:00:21 thats what i did ....And value is coming out to be 4....th function is pretty simple /* Get size of interrupt specifier */ May 13 08:01:49 manoj: while understanding your possible frustration, i have to point out that debugging some driver stuff is somewhat out of the scope of this channel. we rather care about building the kernel and drivers, instead of their inner workings and problems. May 13 08:03:15 okay... i get it...thanks for your time and sorry for inconvenience:] May 13 08:03:39 manoj: no problem :) May 13 08:06:06 Letothe2nd thanks that works :) May 13 08:07:55 PatrickE: :) May 13 09:01:56 Hmm, what is the best way to add a new group to Yocto? May 13 09:02:20 Googling describes a lot of packagegroups, but almost nothing how to actually add a user/group May 13 09:03:30 wertigon: theres a example for useradd, this should include group. May 13 09:03:46 wertigon: if you can't find it, ping me again in a few moments then i'll dig it up. May 13 09:23:08 Letothe2nd: Ok, so if I understand it correctly I should inherit the useradd package class May 13 09:23:21 And then simply use GROUPADD += May 13 09:23:40 wertigon: sounds basically correct, yes. May 13 09:24:03 Sorry, GROUPADD_PARAM May 13 09:24:33 Ok, I'll give it a whirl after I've built this round :) May 13 09:26:40 Does this work for multiple groups? May 13 09:28:07 Hmm, appears to work if I separate it with semicolons May 13 09:28:16 i think you can add multiple in a single recipe, not sure about the exact syntax though. May 13 09:28:27 e.g. "-g 2000 group1; -g 2001 group2" May 13 09:28:31 Letothe2nd yes you can, theres an example ... May 13 09:28:52 https://git.yoctoproject.org/cgit.cgi/poky/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb May 13 09:28:53 according to the example :) May 13 09:29:30 PatrickE: Thanks, exactly what I was looking for May 13 09:30:36 like i said :) 09:03 < Letothe2nd> wertigon: theres a example for useradd, this should include group. May 13 09:36:57 Letothe2nd: Found a different example on the intarwebz May 13 09:37:10 Google is vast :) May 13 09:38:14 wertigon: i should have added "in poky", granted :) May 13 09:42:13 Letothe2nd: good thing we are engineers and used to searching for information :) May 13 12:23:54 Letothe2nd: adding useradd package worked like a charm May 13 12:24:18 wertigon: throw money! THROW MONEY! May 13 12:25:13 Yocto project looking for donations? May 13 12:26:02 * wertigon throws a quarter up in the air May 13 12:27:56 Now I just gotta figure out how to make /etc/ld.so.cache and /etc/udev/hwdb.bin pre-rendered May 13 12:28:53 The rest (machine-id, .updated, .pwd.lock) can easily fit in a 128k RAMdisk May 13 12:39:50 hmmm. my reproducibility test is still running on the AB that I started last night late. I wonder if it hung. May 13 13:15:16 wertigon: hwdb.bin is generated at rootfs time May 13 14:08:29 khem: I did drop it and things broke without it May 13 14:14:42 khem: https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/694 May 13 14:33:08 RP: for the series I just sent, I of course noticed an issue when re-reading the patches on the list. What’s the best way to do that tweak to the patch ? another incremental ? ammend it on my branch and re-push ? May 13 14:34:51 zeddii: an incremental patch please May 13 14:35:19 ok, will send it as standalone. easy to squash in as required. May 13 14:59:15 zeddii: thanks May 13 15:38:26 RP: thats strange since I build for aarch64/odroid-c2 target here and I do not see valgrind failing this way May 13 15:38:39 whereas I was able to see it before May 13 15:38:47 let me try qemurm64 May 13 15:41:58 RP: did you have glibc patch staged when it failed ? since that is essential for fixing it May 13 15:43:26 Hi, could someone fix downloads.yoctoproject.org? The website is not available. I have the issue with icu and opkg downloads. May 13 15:47:37 halstead: hello :) This one's for you I think :) ^ May 13 15:48:07 qschulz, Yes. I'm on it already. May 13 15:48:30 tema, Working on it! May 13 15:49:00 halstead, thank you May 13 15:49:53 tema, There is some availability now but there will be intermittent timeouts until I can find the problem. May 13 15:52:58 Ok, I think I realised what I need to do with the /etc/udev/hwdb.bin - if I create a permanent one supposedly in /usr/lib/udev/hwdb.bin then systemd will not create a dynamic one. May 13 15:53:34 So that's the good news May 13 15:53:54 RP: dumb question but could we not use the downloads.yoctoproject.org for recipes but only for mirror? e.g. opkg maybe could use: https://git.yoctoproject.org/cgit/cgit.cgi/opkg/snapshot/opkg-0.4.2.tar.gz? In which case, you have two ways of downloading the sources and you increase the overall availability? May 13 15:53:58 But, question: is it /usr/lib/udev/hwdb.bin or /lib/udev/hwdb.bin in Yocto? May 13 15:56:04 rburton: it does not seem to be generated correctly in my case, either that or it is excluded in the distro for now May 13 15:56:05 wertigon: If you use ${nonarch_base_libdir}/udev then it will be correct also if usrmeger is enabled in DISTRO_FEATURES. May 13 15:56:26 Saur: Ok, good to know :) May 13 15:56:44 And that should of course be "usrmerge". May 13 15:57:04 My plan is pretty much, run a dev image once on each hw revision and save a local copy of the file, then use that coupled with machine id May 13 15:57:25 e.g. MACHINE=... set when using bitbake May 13 15:57:47 So generate it once for a new machine and then keep it static May 13 15:58:46 BTW, still stuck on thud for now, Zeus migration will happen this summer I think May 13 15:58:55 qschulz: I thought downloads was a mirror? May 13 15:59:38 RP: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/opkg/opkg_0.4.2.bb?h=master#n14 May 13 15:59:48 yes but it's used in SRC_URI for a few recipes as well May 13 16:01:06 from a quick grep in poky: xrestop, yocto-uninative and opkg use downloads.yoctoproject.org/releases (and not /mirror) May 13 16:02:07 so what I was suggesting is not using downloads.yoctoproject.org/releases (nor mirror) in SRC_URI so if downloads.yoctoproject.org is down, there is still a chance to have the sources from the one in SRC_URI May 13 16:02:08 qschulz: right, I see what you mean. The git snapshots are notoriously unreliable (checksum/date changes) May 13 16:02:35 RP: and using commit hashes isn't really a good option either... or? May 13 16:04:22 (because I'm pretty sure we don't want tags for the same reason (changeable and need a "network" check? Just throwing ideas :) ) May 13 16:05:28 qschulz: we're not really had this amount of problems with the hosting before :( May 13 16:07:17 Worktime over, have a nice day everyone! Or night ;) May 13 16:08:44 qschulz: some recipes uses downloads directly because there *is no other location* May 13 16:10:19 rburton: or we host the project May 13 16:12:40 khem: any idea on why https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/1892 would suddenly show up? :/ May 13 16:13:25 ah, http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=f6a210aaafaab8393e7371b75f309bbb302c6039 maybe May 13 16:13:56 jonmason: I got armqemu64 booting with TF-A and optee May 13 16:14:18 s/armqemu64/qemuarm64/ May 13 16:14:29 nice, working testbed of optee is great May 13 16:14:33 Ya May 13 16:15:06 jonmason: I really don't know what any of that is actually used for, so I don't know if theres some runtime tests that can be done? May 13 16:15:34 IIRC, there are tests built in. It's been forever since I even looked at it. May 13 16:16:30 Fair enough. Building is a good start... at least that way there is at least one stock COMPATIBLE_MACHINE to build with May 13 16:35:56 ooo. gmail is smart, it classified the patchtest email as spam! May 13 16:36:27 lol May 13 16:36:39 * zeddii doesn’t correct its opinion. May 13 16:37:43 Why is this message in spam? Lots of messages from patchwork.openembedded.org were identified as spam in the past. May 13 16:38:00 ok, who’s the gmail users classifying oe as spam :D May 13 17:25:27 RP: I think one has to have LSE enabled in gcc to have that arm64 bit error, for odroid I use a different defaulttune and it works fine May 13 17:26:54 jonmason: don't you have any real platform using optee? May 13 17:29:02 zeddii, not like we've not seen that with lkml mail b4 as well. May 13 17:33:47 true. I fish a few out of there from time to time. May 13 17:52:01 simple question but i'm having some trouble modifying the users in my build process. I created a new layer, and wrote a recipe to be used. Edited bblayers.conf to include the layer and built the image. I flash the image, and there's no extra users (just the default root). I checked bitbake-layers and it shows my layer as included...not sure what May 13 17:52:01 might be the problem. Also tried adding sudo but there's no file at /etc/sudoers May 13 17:53:39 I was attempting to use EXTRA_USERS_PARAMS May 13 17:56:46 perhaps show the relevant code changes might help someone answer it May 13 17:58:24 Will do, does kiwi support code formatting or should i use pastebin May 13 18:02:20 pastebin is better May 13 18:06:42 what a surprise, systemd doing dumb shit again. May 13 18:06:48 http://lkml.iu.edu/hypermail/linux/kernel/2005.1/07241.html May 13 18:07:38 zeddii, not sure if we'd want to put an un-stoopid bbappend in overc or probably better in yocto as a whole. May 13 18:09:55 * zeddii reads May 13 18:10:51 basically they did the equivalent of NFS root-squash on /tmp (or any other dir with sticky set) May 13 18:46:03 May 13 18:52:56 Update: the usermod works if I put the EXTRA_USERS_PARAMS in local.conf, but not in its own layer. Heres the layer recipe, layer conf, bblayers.conf, and output of bitbake-layers show-layers: https://gist.github.com/bsmerbeck/025b809cac13a76872b31c0715b6bf82 May 13 18:55:10 Could it be because the the .bb was in [meta-name]/recipes/usermod.bb and not like [meta-name]/recipes/usermod/usermod.bb? May 13 19:00:01 bsmerbeck: What are you adding to BBFILES in your layer.conf? May 13 19:02:17 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ ${LAYERDIR}/recipes-*/*/*.bbappend" May 13 19:02:23 So yes, i needed the extra subdirectory May 13 19:02:54 Tried the build though and still no extra user accounts unless I add the extra_user_params into local.conf. weird May 13 19:03:36 bsmerbeck: What target are you bitbaking? May 13 19:03:50 core-image-minimal May 13 19:05:02 bsmerbeck: When `core-image-minimal` builds it won't see any variables you've set in `usermod.bb` May 13 19:05:42 paulbarker: okay, any idea how I might include this? Sorry, the book i'm referencing just has code samples of this operation and is pretty outdated May 13 19:05:49 You possibly need to define your own image recipe and build that, I've not used `EXTRA_USERS_PARAMS` though so I'm not sure on the exact usage May 13 19:06:02 Okay, yeah that makes sense May 13 19:16:23 bsmerbeck: The docs say that extrausers should be applied at the image level - ie. in an image recipe or in a conf file, not in a package recipe May 13 19:16:24 https://www.yoctoproject.org/docs/3.1/mega-manual/mega-manual.html#ref-classes-extrausers May 13 21:40:10 is there a way to bbappend a recipe in such a way that it will produce separate packages (perhaps with a suffix) so that the not-bbappended packages are also built? May 13 21:40:49 or alternatively is there some way to include/require the combined output of a recipe and all its bbappends? May 13 21:41:36 is this for one recipe ? May 13 21:42:26 not necessarily, but if there is a solution that works for one then presumably it could be applied multiple times May 13 22:12:33 jonmason: Booting qemu with ATF + OPTEE was quite the rabbit hole! Kinda fun though :) May 13 22:15:18 JPEW, jonmason: expect more ATF patches from me shortly, now that I rebased my past work on top of your recent changes... :) May 13 22:15:24 JPEW: cool, can you do some instructions then? I'd like to have it handy as a test May 13 22:15:51 denix: sure. do you have much more coming? May 13 22:17:24 JPEW: btw, are you using OE and RK chips for your day job, if no secret? May 13 22:17:43 jonmason: well, not too much May 13 22:18:40 no worries, I just want to cut the release on Friday. So, please try to get them out as soon as possible May 13 22:19:31 jonmason: understood, will do asap May 13 22:19:55 thanks May 13 22:20:14 I'll be better about announcing it next time May 13 22:23:14 sh_: you can write do_install_append() where you make needed copies of files you need to package differently then add PACKAGES += foo-mine" and FILES_foo-mine += "/path/to/new/files" May 13 23:05:37 JPEW: anyway, was just wondering if that was your day job or not and where you get energy... :) May 13 23:09:35 JPEW: I started making those TFA changes for our platforms, which should have taken 20-30 minutes tops. And I've been interrupted and distracted for calls, meetings and other fire-fighting activities so many times, 20-30 minutes became several hours... :) May 13 23:14:14 JPEW: I see you hacked together qemuarm support - I'm adding more generic SPD support as well (albeit simplistic w/o dependencies). and I have concerns the way you got it together... we can discuss with jonmason on the list May 13 23:33:04 jonmason, JPEW: sent out my patches. decided to send out what I already have working and not sit on the rest of my WIP any longer. May 13 23:35:20 Thanks May 14 00:06:04 jonmason: 2 more :) May 14 01:17:50 khem: unfortunately I need to do a complete rebuild since I want to do one build with a source patch applied and one build without May 14 01:28:56 denix: It's related to my day job. I end up being involved in a lot of SoC evals, so we try to find these cheap boards to eval and I try to get upstream support for them to be better while I'm at it :) May 14 01:29:36 denix: Ya, the qemuarm ATF parts are a bit messy, your patches will make it much cleaner May 14 01:54:39 JPEW: nice job! May 14 02:14:36 denix / JPEW: I see meta-ti and meta-rockchip have recipes for some variant of gcc-arm-none-eabi. Is it safe to assume that you would be happy to kill this in favor of something in meta-arm-toolchain that performs the same function? May 14 02:15:07 As I have something internal that is doing similar that I want to kill also. One recipe to rule them all! May 14 02:17:37 jonmason: that would be the first step in unification, sure. but the proper solution would be a multiconfig with TCLIBC=baremetal... :) May 14 02:18:51 baby steps May 14 02:27:45 denix / JPEW: I'm going to use https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/recipes-devtools/gcc-arm-none-eabi/gcc-arm-none-eabi-native_9-2019-q4-major.bb as it is the version now. Are there needs for any older versions? May 14 02:28:28 I see 2018 releases in meta-ti, but not sure if that is just there because it's already done May 14 02:32:52 jonmason: Works for me May 14 02:33:07 cool May 14 02:33:26 I'm writing an email for the IRC deficient May 14 02:33:55 JPEW: I assume that is fine for me to add your S-O-B in the patch that rips it from meta-rockchip May 14 02:34:23 Yep May 14 02:34:44 cool, I'll send that out to the mailing list shortly **** ENDING LOGGING AT Thu May 14 02:59:57 2020