Friday, 2021-11-19

paulgarmpit, Does that make 'merika a cargo cult?
*** florian <florian!> has quit IRC (Ping timeout: 268 seconds)00:09
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)00:12
*** chep <chep!~chep@> has quit IRC (Ping timeout: 256 seconds)00:22
*** chep <chep!~chep@> has joined #yocto00:25
bqJPEW, but this means if I set00:28
bqJPEW, but this means if I set the reprod rimestamp it'll rebuild even with kernel from git00:30
JPEWbq: Correct... I guess you could try to second guess what the command will do, but that seems brittle00:30
JPEWOk, I used `cargo bitbake` to generate a list of crates to put in SRC_URI... and it's a parse error :/00:31
JPEW`Could not find a fetcher which supports the URL: 'crate:`00:32
JPEW... but only when I also have a git:// repo in SRC_URI?00:36
*** troth <troth!> has quit IRC (Ping timeout: 264 seconds)00:38
RPJPEW: the crate fetcher can't cope with AUTOREV I think00:42
RPJPEW: I have an open bug for this. It is due to the fetcher module not being imported at the right point as the fetcher is in an external layer and not in bitbake itself00:42
*** xmn <xmn!> has joined #yocto00:46
JPEWOk. I'll see if I can make it do the same as our custom fetcher00:46
*** vd <vd!> has quit IRC (Quit: Client closed)00:47
*** rsalveti <rsalveti!> has quit IRC (Quit: Connection closed for inactivity)00:47
*** vd <vd!> has joined #yocto00:47
*** troth <troth!> has joined #yocto00:52
*** troth <troth!> has quit IRC (Ping timeout: 256 seconds)01:03
*** mckoan|away <mckoan|away!> has quit IRC (Ping timeout: 265 seconds)01:14
*** troth <troth!> has joined #yocto01:18
*** bluelightning <bluelightning!~paul@2406:e003:151f:d701:810f:5dba:6440:52c7> has joined #yocto01:30
*** sakoman <sakoman!> has joined #yocto02:03
*** mckoan|away <mckoan|away!> has joined #yocto02:07
*** troth <troth!> has quit IRC (Ping timeout: 268 seconds)02:13
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)02:13
*** troth <troth!> has joined #yocto02:27
*** mckoan|away <mckoan|away!> has quit IRC (Ping timeout: 240 seconds)02:30
*** chep <chep!~chep@> has quit IRC (Ping timeout: 268 seconds)02:58
*** mckoan|away <mckoan|away!> has joined #yocto03:02
*** chep <chep!~chep@> has joined #yocto03:05
*** pgowda_ <pgowda_!> has joined #yocto03:50
*** mckoan|away <mckoan|away!> has quit IRC (Ping timeout: 268 seconds)04:01
*** jmiehe1 <jmiehe1!~Thunderbi@user/jmiehe> has joined #yocto04:13
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 265 seconds)04:15
*** jmiehe1 is now known as jmiehe04:15
*** mckoan|away <mckoan|away!> has joined #yocto04:18
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:43
*** FredO2 <FredO2!> has quit IRC (Quit: Leaving)05:00
*** troth <troth!> has quit IRC (Ping timeout: 256 seconds)05:25
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 268 seconds)05:37
*** davidinux <davidinux!> has joined #yocto05:37
*** troth <troth!> has joined #yocto05:41
*** kroon <kroon!> has joined #yocto05:56
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:06
*** paulg <paulg!> has quit IRC (Ping timeout: 265 seconds)06:10
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)06:17
*** xmn <xmn!> has quit IRC (Ping timeout: 260 seconds)06:27
*** adrian__ <adrian__!~F_Adrian@> has joined #yocto07:06
*** adrian_ <adrian_!~F_Adrian@> has joined #yocto07:11
*** adrian__ <adrian__!~F_Adrian@> has quit IRC (Ping timeout: 268 seconds)07:14
JosefHolzmayrTheyo dudX07:34
*** mckoan|away is now known as mckoan07:39
mckoangood morning07:39
*** tre <tre!> has joined #yocto07:53
*** rfuentess <rfuentess!> has joined #yocto07:54
*** davidinux <davidinux!> has quit IRC (Ping timeout: 268 seconds)07:56
*** davidinux <davidinux!~davidinux@> has joined #yocto07:56
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: Textual IRC Client:
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto08:01
*** chep <chep!~chep@> has quit IRC (Ping timeout: 260 seconds)08:06
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:07
*** chep <chep!~chep@> has joined #yocto08:09
*** dev1990 <dev1990!> has quit IRC (Quit: Konversation terminated!)08:24
qschulzmornin' :)09:01
*** _whitelogger <_whitelogger!> has quit IRC (Ping timeout: 264 seconds)09:17
*** _whitelogger <_whitelogger!> has joined #yocto09:18
ad__smurray: thanks still for the help of yesterday. What works is LAYERSERIES_COMPAT_your-layer_append = " dunfell" in bsp layer layer.conf09:20
JosefHolzmayrTheis there a nice way to find symlinks via oe-pkgdata-util?09:41
*** florian <florian!> has joined #yocto09:46
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: Textual IRC Client:
*** michalkotyla <michalkotyla!> has joined #yocto10:23
*** zyga <zyga!~zyga@> has joined #yocto10:25
*** zyga <zyga!~zyga@> has quit IRC (Quit: Leaving)10:32
michalkotylaHi, which hash function is used as default to password inside the /etc/shadow in poky honister? I need to use usermod in my recipe, in the old version of my layer (thud) I do this like: -P cleanpassword user, but I see that now patch for using clean passwords is dropped. It is SHA256, 512, or something else?10:33
*** zyga <zyga!~zyga@> has joined #yocto10:35
qschulzsha256 AFAICT?10:41
*** nad <nad!> has joined #yocto10:47
*** xmn <xmn!> has joined #yocto10:48
*** zyga <zyga!~zyga@> has quit IRC (Quit: Leaving)10:49
michalkotylaqschulz: thans, i will try with 25610:50
qschulzmichalkotyla: the docs explain how to create the password and pass it to useradd so just follow the instructions :)10:57
kanavinRP: I think more patches with malformed upstream-status may have made it to master while I was writing and testing the test for that10:59
kanavinRP: so you or me may have to do fixups10:59
kanavinand there'll be a bit of red as it is10:59
RPkanavin: the script is showing master-next as ok11:00
RPkanavin:  Patches missing CVE: 3 I guess11:00
RPkanavin: we'll get them fixed one way or another though11:01
RPkanavin: I appreciate the work you're doing on them11:01
* RP will try and loop around through the todo list and do a few more11:01
kanavinRP: this
kanavinthe test will complain about Upstream-Status: Backport[;h=3929bca9ca95de9d35e82ae8828b188029e3eb70]11:02
kanavin(for once, I am being pedantic about whitespace :) and insist on having spaces there11:02
RPkanavin: ah, ok. I can tweak that. The other script doesn't pick that up :)11:02
RPkanavin: patch queued11:04
kanavinRP: unfortunately I couldn't force mandatory [reason] or [submitted where], there's too much to fix then11:04
RPkanavin: one step at a time11:04
kanavinso there's still plenty of inappropriates without reason, or submitteds without reference11:04
RPkanavin: we used to have no data at all11:05
kanavinRP: fedora/rhel still doesn't11:05
kanavinRP: I wonder if it's a part of their 'vendor lock in' strategy11:05
kanavinhave hundres of patches with no metadata ---> profit11:05
RPkanavin: perhaps. it is also so much easier not to send upstream11:07
RPkanavin: As you're finding, there are a surprising number of patches we can simply drop11:07
RPeven in gcc :)11:07
*** goliath <goliath!~goliath@user/goliath> has joined #yocto11:10
kanavinRP: yes. Where I am now is: I reviewed all of the pending patches size 4000 bytes or more (except the toolchain stuff). Next I'll be sending my own remaining pending patches, so I can claim the moral high ground! :D11:11
kanavinthere was only a dozen of 4K-5K sized patches, but significantly more 3-4K sized ones, so that's where I stopped for now :)11:11
RPkanavin: I did audit libtool and a first pass over the gcc ones11:12
kanavinand a maaaaassive long tail of even smaller ones11:12
RPkanavin: right, but you're right the bigger ones are more likely to be painful at upgrade11:13
kanavinRP: yes, the small ones tend to change only a single line, or a single chunk, or several single lines. We should weed out the ones that change several multiline chunks.11:14
*** prabhakarlad <prabhakarlad!> has joined #yocto11:17
*** florian_kc <florian_kc!> has joined #yocto11:23
kroonRP, I suppose tweaking the "Upstream-Status" tags in the gcc patches should not cause a rebuild of glibc/kernel etc ?11:23
kanavinkroon, if hashequiv works correctly then it should not11:25
kanavinthat's exactly what was in mind when implementing it11:25
kroonbut that seems to be the case on my setup 8-/11:26
ernstpIs there a good Yocto way to debug/trace python functions? Following what a do_package in python does for example11:36
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:1973:4823:d0a6:d227> has joined #yocto11:44
kanavinI have been wondering the same. I guess it comes down to how to you trace python script execution in general.12:00
kanavinI guess "insert more debug prints into the script" is not the answer you seek :)12:00
qschulzernstp: ${WORKDIR}/temp/run.do_package12:01
kanavinthe question is, do_package tends to be silent about what it's doing and can go on for minutes and minutes and minutes12:02
kanavinhow do you make it more chatty, e.g. printing what is being executed (like shells can do)12:02
qschulzah like set -x but for python scripts12:03
ernstpqschulz: yeah it's quite empty for do_package since it's all python12:08
qschulzernstp: the run isn't but the log yes, I didn't read kanavin 's answer, thought it was about a different topic. I unfortunately don't have any idea how to do that kind of tracing12:09
ernstpcould have more bb.debug()12:10
ernstpbut maybe they have a slightly different purpose..12:11
qschulzernstp: yeah but you can't force layers to do that with their own recipes/classes so the question remains :)12:11
*** xmn <xmn!> has quit IRC (Ping timeout: 256 seconds)12:20
RPkroon: it will rebuild gcc itself but then things depending on gcc shouldn't rebuild12:27
RPkanavin: the logs are a lot more verbose12:28
RPkanavin: I suspect to bitbake XXX -v -c package would work12:28
*** pgowda_ <pgowda_!> has quit IRC (Quit: Connection closed for inactivity)12:53
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)13:00
*** prabhakarlad <prabhakarlad!> has joined #yocto13:01
nadHi. What could be the "proper" way to get rid of a pkg_postinst_ontarget task from recipes I inherited ?13:05
nadRemoving the script from ${sysconfdir}/rpm-postinst leads to such output "The following packages could not be configured offline and rootfs is read-only: []"13:05
nadof course, importing the recipe do temporarily the job13:06
qschulznad:  pkg_postinst_ontarget() {:} in a recipe appends13:09
*** tnovotny <tnovotny!> has joined #yocto13:17
*** tnovotny <tnovotny!> has quit IRC (Client Quit)13:18
*** tnovotny <tnovotny!> has joined #yocto13:20
*** dvorkindmitry <dvorkindmitry!~dv@> has joined #yocto13:24
dvorkindmitryin what branch ":append" and ":remove" ops has been introduced?13:26
*** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has joined #yocto13:29
qschulzdvorkindmitry: and it was backported to dunfell and hardknott13:36
dvorkindmitryqschulz, good news! so I can just pull "dunfell", update my recipes and I will be compatible?13:38
qschulzdvorkindmitry: technically both syntax will work up to honister13:41
qschulzso you can have mix and match in layers13:41
*** chep <chep!~chep@> has quit IRC (Ping timeout: 268 seconds)13:42
dvorkindmitryqschulz, in hardknott old syntax gives unnoying errors13:43
dvorkindmitryin honister, sorry\13:44
*** chep <chep!~chep@> has joined #yocto13:46
qschulzdvorkindmitry: "up to honister" :)13:50
qschulzmy bad, can't read, what is wrong with me13:51
qschulzloooong friday.. you corrected yourself just after13:52
qschulzbut yeah, honister does not support both syntax13:52
dvorkindmitryyea. sorry and thank you13:52
qschulzit's alright, I expect we're going to have lots of questions aorund this new syntax :)13:53
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:f8:68c4:4327:6ca7> has quit IRC (Remote host closed the connection)13:53
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:f8:68c4:4327:6ca7> has joined #yocto13:53
kroonRP, JPEW, I do "bitbake strace", then change the cover-letter in one of the gcc patches, then run "bitbake strace" again, and gcc -> glibc -> strace is rebuilt. Any of you got any tip on how to debug hashserv and see why this is happening ?13:56
*** codavi <codavi!~akiCA@user/akica> has joined #yocto13:57
JPEWkroon: if you capture the depsig files in ${T} between each build, you can diff them13:58
kroonJPEW, ok, ${T}, you mean TMPDIR ?13:59
JPEWNo, $WORKDIR/temp iirc13:59
JPEWAfk, so not exactly sure :)13:59
kroonJPEW, and you mean the "depsig" files for strace ?13:59
JPEWGCC and glib are the more interesting ones14:00
JPEWHashequiv uses the hash of the depsig files to determine if two sstate outputs are equivalent, so if they differ between the two runs, that would explain it14:01
kroonJPEW, ah ok14:02
JPEWIdeally for trivial changes, they would be the same, but things happen :)14:03
kroonJPEW, so looking at the diff between gcc's is the interesting one ?14:05
JPEWYa, probably. I'd diff them all just to make sure14:06
krooncause if im reading those correct cc1 and cc1plus binaries dont have identical checksums14:06
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 260 seconds)14:06
kroonJPEW, ok14:06
JPEWThat would do it14:06
JPEWIf you can figure out why they are different, you can probably fix it14:07
JPEWA lot of hashequiv problems like this are reproducible build problems in disguise14:08
kroonJPEW, yeah, I guess I'd need to extract the binaries from sstate and compare them then14:09
kroonor just keep a copy after doing the first build14:09
kroonand we should replace buildhistory with versioning those depsig files!14:10
JPEWkroon: I recommend diffoscope for diffs. You can probably directly diff the two sstate archives14:12
JPEWYa, the depsig files could have a lot more uses14:13
kroonJPEW, ok ill try14:13
*** sakoman <sakoman!> has joined #yocto14:17
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto14:18
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 264 seconds)14:18
*** davidinux <davidinux!> has joined #yocto14:20
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 260 seconds)14:22
kroonsigh. vanilla diffoscope in fedora 35 is not working for me14:47
*** paulg <paulg!> has joined #yocto14:50
kroonbut yeah, cc1 and cc1plus differ14:52
kroonand looks like its binary data that is differing14:56
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 268 seconds)15:03
kroonComparing output of "readelf -a" for both binaries states that Build ID is differing, which would explain one of the two diff chunks I see15:03
*** amitk <amitk!~amit@> has joined #yocto15:04
manuel1985Is there a canonical place to put docker compose files on the filesystem?15:09
manuel1985libvirt puts VM images to  /var/lib/libvirt/images, so would choose /var/lib as well15:13
*** davidinux <davidinux!> has quit IRC (Ping timeout: 268 seconds)15:14
*** davidinux <davidinux!~davidinux@> has joined #yocto15:14
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 264 seconds)15:15
*** amitk <amitk!~amit@> has joined #yocto15:15
JPEWkroon: If it's only the build ID thats different, it usually means the difference is in the stripped debug data15:15
kroonJPEW, its not only the build id though, there is 16bytes that differ15:16
JPEWkroon: Ah, taht would do it15:16
kroonIm trying to compare the stash_build_dir sstate tasks15:16
JPEWtimestamp maybe?15:16
kroonIve got no clue what those 16 bytes are..15:17
sgwMorning all15:19
tgamblinIs there a way to force a LICENSE override for a recipe that won't generate more warnings? I am looking specifically at hdparm, which has LICENSE, LICENSE_${PN}, and LICENSE_${PN}-dbg lines. The latter two lines are still resulting in warnings during build even if I do e.g. LICENSE_forcevariable_hdparm = "..."15:19
tgamblinsgw: ^15:19
qschulztgamblin: LICENSE_hdparm_forcevariable instead?15:20
sgwRP: around, not sure if you say my comment about the kernel spdx status yesterday?15:20
*** paulg_ <paulg_!> has joined #yocto15:21
sgwqschulz: yeah, was not exactly sure which order it was, but when done as hdparm_forcevariable we get: WARNING: Variable key LICENSE_${PN} (BSD) replaces original key LICENSE_hdparm (BSD-2-Clause & GPLv2 & hdparm).15:21
qschulzsgw: LICENSE_${PN}_forcevariable_pn-hdparm from a local.conf or LICENSE_${PN}_forcevariable from a bbappend then15:25
qschulznot tested, just an idea15:25
sgwOh that's a good on, I will give it a try15:26
kroonJPEW, ok diffoscope is working after installing apt15:28
JPEWkroon: I think you can install it though pip alos?15:28
kroonJPEW, but it is taking a long time15:28
JPEWYa, it might15:29
kroonJPEW, yeah but its only show the same hex diff15:29
kroonJPEW, should I run it on the stash build dir perhaps15:30
JPEWkroon: Probably not helpful then15:32
JPEWSorry :/15:32
tgamblinqschulz: sgw: that seems to work15:33
*** dev1990 <dev1990!> has joined #yocto15:37
kroonIm hoping some object file will show up15:37
qschulztgamblin: :muscle:15:37
qschulzeh, no emoji for you then :)15:37
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:dfc4:6584:f65f:a643> has joined #yocto15:46
sgwJPEW:  ross: did you see any issues with vim LICENSE?15:48
tgamblinqschulz: thanks!15:50
JPEWsgw: I seem to have missed the email15:51
qschulztgamblin: my pleasure!15:51
kroonJPEW, is it a good idea to tell diffoscope to ignore modified timestamps when diffing (if possible) ? or do you just run "diffoscope a b" ?15:56
nadqschulz: thank for reply. It does not work unfortunately. Even if the task is rewritten as empty, file is created and QA Issue pop up15:56
JPEWkroon: It depends15:56
sgwJPEW no email, just some findings we are discovering running the SPDX verify over many packages.  tzdata has issues also PD is not a vaild SPDX License identifier.  I have to analzye the rest of the issues, I will send email.15:59
sgwJPEW: I am still looking the issue of how to deal with the kernel source package from work-shared and getting the "generated" source16:04
kroonRP, JPEW, any of you familiar with build/gcc/cc1plus-checksum.c ? I think the unsigned char executable_checksum[16] in there is the culprit16:08
JPEWkroon: Ah, I wonder if that includes the debug data?16:09
JPEWkroon: Maybe the difference is in the debug data (this is pretty common, which is why I keep mentioning it)16:09
kroonJPEW, hmm how would I check that ?16:10
JPEWkroon: Fine the debug symbols for the executable? I don't remember exactly where they are16:10
RPsgw: I saw you said it was roughly working?16:15
RPsgw: but fun with shared-work16:15
*** tre <tre!> has quit IRC (Remote host closed the connection)16:15
RPkroon: That brings back some memory fragment, maybe worth looking at the mailing list as I think it was mentioned16:16
RPkroon: look for "[OE-core] [PATCH] gcc: Improve reproducibility" from October. Patch needed rework but was never resubmitted16:18
RPkroon: it may or may not be related16:18
kroonRP, ok, thanks ill check16:18
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 265 seconds)16:19
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)16:19
kroonRP, yeah its definetly in that area. ill see what i can find16:20
sgwRP: very roughly, I have the debug info getting parsed and the split/strip working, it did require changes to package.bbclass.  Yes loads of fun now with shared-work and finding "generated" files.  I know there is a kernelsrc.bbclass that's used by perf, is there a way to generate the kernel-src/linux-yocto-src package that I am missing?  And then there is still the modules!16:20
* sgw afk for a bit16:20
RPsgw: kernel source is done through kernel-devsrc, a separate recipe and is not the complete source16:22
RPzeddii: here we go again :)16:22
kroonRP, well, that proposed patch removed the file "checksum-options" from being included in the checksum, but in my build both of those are identical in the two builds. so it must be something else in here16:30
RPkroon: ok, I did wonder since you are likely rebuilding in the same path16:31
RPkroon: might give some hint as to another issue, I don't know.16:31
kroonRP, yeah. oh yes, there are more things included in that checksum, ill see what differs16:32
kroonand checksum-options is already being filtered out in gcc-cross.inc16:38
*** kaitsh <kaitsh!~kaitsh@user/kaitsh> has joined #yocto16:41
kroonIt is all the .a files that are included in the checksum that differ: libcommon.a, libcpp.a, libiberty.a, etc16:42
kroonprobably .o added in nondeterministic way16:42
kroonwell, the timestamps of the .o files is different16:45
kroonorder looks to be the same according to diffoscope16:46
kroonRP, JPEW, any suggestion how/if we want to solve this ?16:46
* kroon is afk for a while16:48
kaitshHey guys, what is the best way to configure a fallback url. I want to fetch a file from a server, but if this fails, I'd like to use a local file as fallback.16:51
qschulzkaitsh: not sure for local files, but you can setup a MIRROR16:54
qschulzyou can use file:// for local files I checked in PREMIRRORS which is the same syntax16:55
qschulzif you don't want to mirror git repos, just use the DL_DIR of a succesful Yocto fetch/build. Otherwise run the BB_GENERATE_MIRROR_TARBALL and use this output16:56
qschulzbut it's documented :)16:56
kaitshqschulz: Good idea, thanks! Somehow I thought MIRRORS only work with ftp://, http://, or https:// calls16:56
JPEWmoto-timo: I got squeekboard to compile. What a mess!16:56
*** florian <florian!> has quit IRC (Remote host closed the connection)16:56
moto-timoJPEW: \o/ HAZAAH16:58
moto-timokaitsh: it will work with any fetcher16:58
JPEWI seriously hope that using meson to invoke cargo is not a normal practice16:58
moto-timoJPEW: meson to invoke cargo to invoke bazel to invoke autotools to invoke cmake16:59
paulbarkerIt's build systems all the way down16:59
JPEW... to invoke ninja to invoke meson!16:59
moto-timocircle of life17:00
moto-timoI honestly don't know what these folks are thinking, but I'm sure they have reasons17:00
JPEWbuildsystem quine17:00
*** ecdhe <ecdhe!> has quit IRC (Ping timeout: 268 seconds)17:01
moto-timoJPEW: was it the fetcher fixes you sent to the ml?17:02
*** troth <troth!> has quit IRC (Ping timeout: 264 seconds)17:04
JPEWPart of it17:04
moto-timoand you got it to cross-compile? that has been awkward with some cargo stuff (python3-cryptography)17:05
JPEWI haven't tried cross compile yet.... doing that now17:05
*** bps <bps!> has joined #yocto17:07
moto-timoJPEW: that's a lot of work. nicely done17:07
moto-timoJPEW: doesn't inherit cargo already inherit rust?17:07
JPEWIt doesn't? It include rust_common17:07
JPEWI may not need that anymore17:08
moto-timowe will eventually have enough minds thinking about rust that we will streamline this toolchain17:09
khemninja uses many make systems as build generators e.g. CMake, make, and meson just falls in same line I guess17:14
khemJPEW:  I guess meson is delegating the rust build+packaging+dependency tracking to cargo17:17
*** troth <troth!> has joined #yocto17:20
RPJPEW: the fetcher "fix" is quite neat but I think we need to do better than this with some kind of proper API17:21
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)17:22
JPEWkhem: ya, and annoyingly in this case it is dynamicly generating Cargo.toml in meson17:22
JPEWRP: fair. That's just the "hack" we've been using for years on our custom fetcher so we didn't have to modify bitbake17:25
kroonRP, JPEW, do you have any comment on the diffing timestamps in .a files above ?17:26
kroonI know there is a -D flag one can pass to 'ar', but its not used in my build17:26
RPkroon: we should probably stop it using timestamps17:28
*** mckoan is now known as mckoan|away17:30
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Read error: Connection reset by peer)17:30
khemJPEW: Do you have plans for using phosh for some stuff at work or just fun stuff ?17:30
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 264 seconds)17:30
* zeddii reads17:31
zeddiisorry. I've been buried (and failing) to get the actual technical work done for my presentations at the summit, much less working on the slides.17:31
zeddiiso I've been ignoring IRC for the most part17:31
* zeddii curses networking between his test machines17:32
* paulg hands zeddii two new soup cans and some string17:32
paulgand a  300 baud modem for each end17:33
zeddiiseriously though. I still haven't made it to testing the actual software17:33
zeddiiI just needed fully routable networking between the VMs, and had to fixup all the OverC macvtap crap to get it just working some now17:33
zeddiiI can ssh between the VMs, so next is CNI networking.17:34
zeddiigood times17:34
paulgsounds keyboard smashingly fun times.17:34
zeddiione almost died, yes.17:34
zeddiilets just say the slides won't be done much before my talks ;)17:34
kroonRP, ok17:34
khemI have clang-native rust-native and llvm-native and linux-taspberrypi compiling all in parallel wow, should I call fire deptt soon 🙂17:34
khemhave llvm compiled for three different big tools is something to solve17:35
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto17:35
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)17:36
*** bps <bps!> has joined #yocto17:42
kroonRP, i suppose binutils-native isnt used when building gcc-cross ?17:45
kroonRP, cause I think we pass "--enable-determistic-archivers" when compiling binutils-native17:46
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 256 seconds)17:49
khemkroon: right. its primarily use is uninative17:49
kroonkhem, ok17:49
khemand binutils testsuites too17:49
JPEWkhem: no, not for work. Looking for sato a replacements17:50
khemOK, I wondered if there were UIs which were viable in commercial settings that could be useful, right now I think there are not many good options17:54
khembrowser based UIs are quite popular17:54
khemflutter is  interesting, I see canonical/ubuntu working on it quite a bit,17:57
sgwRP: back, Ok, I will dig into kernel-devsrc (clearly I forgot about that one), zeddii, I am trying to build SPDX data for the kernel as you know and I need to deal with the combo of upstream source and "generated" files!17:57
zeddiithey can be regenerated from devsrc.17:57
zeddiibut can't you just look at ${S} ?17:57
*** nad <nad!> has quit IRC (Quit: Client closed)17:58
zeddiithe generated files in in ${B}, but everything else in ${S}17:58
zeddiis/in in/are in/17:58
sgwzeddii: Ok, I will dig, I have to see exactly where create_spdx is looking, I used the cfg/debug/debug_info fragment and have the debug_info being generated, split and striped (not booted), just making sure the basic packaging is working so far.17:59
sgwNo resource (time/size) data yet17:59
*** eloi1 <eloi1!> has joined #yocto18:00
zeddiilooks like ${S}, which is work-shared.18:01
zeddiibut with the build split, generated bits are in ${B}18:01
sgw${S} might point to the source, but create_spdx is not finding the source on disk, it is getting the debug_info file data correctly, which is the first step.18:02
sgwI am digging, in my normal slow plodding pace!18:02
kroonRP, JPEW, but I don't understand this. Has gcc never been reproducible in OE ?18:08
JPEWkroon: it might be triggered by untested conditions, such as rebuilding without a clean sandbox18:10
JPEWThere are other known cases where that can cause non reproducible builds18:10
*** eloi1 <eloi1!> has quit IRC (Ping timeout: 264 seconds)18:14
kroonJPEW, what the heck does this mean... diffoscope when comparing the two .a: the .o files have zero timestamps now when passing -D, but the timestmap for folder "/" differs according to diffoscope18:25
kanavinAlex's pending patches today 42 -> 3818:26
kanavinmoral high ground is getting closer \0/18:26
kroonJPEW, and so the sha256sum's of the two .a therefore differ. but what is "/" in a .a-ardchive..18:27
kroonoh, maybe its ranlib doing stuff..18:32
kroonyeah probably need a D there too :-/18:32
JPEWkroon: not sure, sorry18:35
JPEWRP: that meson rust patch in master-next doesn't work for cross-compiling. Would you rather remove it and I'll send a V2, or make a new patch to fix it18:37
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 240 seconds)18:37
kroonJPEW, yeah that was it. both "ar" and "ranlib" needs D18:42
RPJPEW: I can drop it and go for a v218:43
kroonstill im surprised, because I cant find anything in the history, so it looks like gcc has never been reproducible18:44
RPkroon: we test target reproducibility, not so much cross/native binaries since they depend on host gcc18:44
RPkroon: the on target gcc binary *is* reproducible18:44
kroonRP, yeah, i guess that because binutils is built with --enable-deterministic archives18:45
RPkroon: sadly if gcc-cross doesn't reproduce, that affects hash equivalence effectiveness18:45
RPkroon: so we need that in the cross case? or the issue is binutils from the host?18:46
kroonRP, i started looking into this because of the gcc patch upstream status tag cleanups. it forced all my target packages to rebuild, which seems unnecessary18:47
kroonso yeah gcc-cross didnt reproduce18:47
RPkroon: you're right, it shouldn't do that. Sadly I've only been able to push things so far with the reproducibility work and so on :/18:47
RPkroon: it sounds like a new test case we should add too once we get that working18:48
RPkroon: I get a little frustrated everyone just wants everything to work so I appreciate you digging into it18:49
kroonRP, yeah of course, well fix it.18:49
kroonRP, no problem, I hope upstream gcc would also want to be reproducible18:49
vdcan you control the bitbake output during a build? In an interactive environment, there's nicely redrawn progress bars, but in a non-interactive environment (CI/CD), lines are printed every X seconds, which generates unnecessary long logs18:51
kroonRP, s/well/we will/18:51
RPkroon: :)18:52
RPvd: There is code in knotty (the terminal UI) which calls istty() and reacts accordingly. Sounds like your CI is trying to be too clever about pretending to be an interactive terminal. Do "bitbake XXX | cat" ;-)18:53
*** davidinux <davidinux!~davidinux@> has quit IRC (Quit: WeeChat 2.8)18:56
vdRP: is there a bitbake variable I can set to avoid such terminal trickery?18:57
*** bps <bps!~bps@user/bps> has joined #yocto19:00
vdRP: the | cat trick won't do it I think, because it stills erase/reprint percentages e.g. "Parsing recipes:  57% || ETA:  0:00:39", which prints a new line for each update19:00
vdstill erases/reprints*19:03
RPvd: no variable to do it19:05
*** chep <chep!~chep@> has quit IRC (Ping timeout: 260 seconds)19:06
RPvd: the progress bars shouldn't be displayed in the non-interactive mode19:07
*** chep <chep!~chep@> has joined #yocto19:09
vdRP: you still have clear/reprint in non-interactive mode19:13
RPvd: that sounds like a bug then :/19:15
vdRP: I think so. My CI/CD logs have hundreds of lines like "Initialising tasks:  87% || ETA:  0:00:00"19:31
moto-timomichaelo: is there a way to use variables in Sphinx, e.g. for the linux version that is repeated multiple places in my docs? I know we did things with entities in the old docbook worfklow19:32
moto-timomichaelo: my google fu is not being useful yet19:32
*** florian <florian!> has joined #yocto19:36
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Read error: Connection reset by peer)19:40
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto19:45
*** chep <chep!~chep@> has quit IRC (Ping timeout: 268 seconds)19:53
*** chep <chep!~chep@> has joined #yocto19:56
RPvd: It is strange that our autobuilder doesn't have those20:05
RPmoto-timo: isn't that what poky.yaml is for?20:06
moto-timoRP: Right! I totally forgot! THANK YOU20:07
moto-timovd: RP: I see that sometimes locally too. My hunch is something about the console/tty settings?20:08
* moto-timo completely forgot what we did in Jenkins 4 years ago20:09
JPEWRP: So, how would we make the crate fetcher have a better API? My first thought is that the SRCPV stuff could be made better (since right now only one "custom" fetcher will work)20:09
moto-timoJPEW: I suspect RP means a general fetcher API in bitbake itself?20:09
JPEWAh, like move the crate fetcher into bitbake?20:10
moto-timoJPEW: that was my interpretation/hunch20:10
*** aleblanc <aleblanc!> has quit IRC (Remote host closed the connection)20:15
*** aleblanc <aleblanc!> has joined #yocto20:15
*** aleblanc <aleblanc!> has quit IRC (Ping timeout: 256 seconds)20:25
RPJPEW: that would be one way, the other would be some sort of bitbake API to add other fetcher modules20:30
JPEWRP: Right. getting the registration early enough would be the tricky part20:31
*** ecdhe <ecdhe!> has joined #yocto20:32
RPJPEW: and in all the different contexts20:32
JPEWIs there a reason the cargo fetcher wasn't put in bitbake in the first place?20:33
moto-timoJPEW: hold over from meta-rust porting20:34
paulgyay! moar rustz!20:35
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)20:35
moto-timoNo rust emoji lol20:35
moto-timoAhhh yes!20:36
JPEWGiven the current implementation has some short comings, moving the crate fetcher to bitbake seems the cleanest solution?20:37
* JPEW didn't follow the history of rust integration... not trying to rehash any old stories20:37
JPEWmoto-timo: Is there a reason to have core-image-phosh and core-image-phosh-gnome?20:43
*** florian <florian!> has quit IRC (Ping timeout: 264 seconds)20:45
*** florian <florian!> has joined #yocto20:46
moto-timoJPEW: yes, core-image-phosh is a "core-image-sato" clone. core-image-phosh-gnome is pure GNOME apps20:48
JPEWmoto-timo: K20:49
moto-timoJPEW: different goals. one is attempting to replicate sato as is. the other is trying to replicate what Purism/Librem5 might have from GNOME20:51
JPEWmoto-timo: Makes sense20:51
JPEWmoto-timo: Should we include squeekboard and gnome-control-center in core-image-phosh? The latter is required for the wifi/networking bar at the top of phosh to function20:53
moto-timoJPEW: that was my original intent, as long as squeekboard isn't a bad citizen... I never tried it since I failed to get it to compile lol20:55
moto-timoJPEW: probably some kind of packagegroup-phosh-essential or similar?20:55
JPEWSounds good20:55
* moto-timo overengineers things again20:55
JPEWI'll be testing squeekboard as soon as this image finishes flashing to the rapsberry pi20:56
moto-timoI'll probably get to it on the weekend. kernel-lab is still needing some love20:56
RPJPEW: the fetcher was phase two of the rust merge, nobody has looked at it yet20:57
moto-timoalso, I had some wonky issues on QEMU. Like apps would be off the screen20:57
JPEWYa, it seems better on hardware20:57
moto-timoand the PIN screen was not complete... like the canvas is not scaling properly on QEMU20:57
JPEWYa, I wonder if that's some virtgpu problem20:58
moto-timo(part of the list of TODO items)20:58
moto-timoyeah, probably20:58
moto-timoit was working so well on rpi4 that I kind of ignored it for now20:58
moto-timoI only recently got gl working on my qemu host anyway, so I might be having <cough> NVIDIA </cough> drivers issues etc. or just configuration20:59
RPJPEW: I think the issue is the crate fetcher may not meet all our fetcher requirements :(21:00
RPJPEW: I don;t remember exactly though21:00
moto-timothese "language fetchers" are begging for some love21:01
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds)21:01
moto-timoand don't get me started about python wheels21:01
alex88how can I check why a file isn't installed? I have uboot enabled and should add /etc/fw_env.config... I see the file fw_env.config in ./build/tmp/deploy/images/raspberrypi4/fw_env.config but not in the rootfs... any idea?21:06
*** florian <florian!> has quit IRC (Ping timeout: 268 seconds)21:10
*** chep <chep!~chep@> has quit IRC (Ping timeout: 268 seconds)21:10
*** bps <bps!> has joined #yocto21:11
*** chep <chep!~chep@> has joined #yocto21:12
alex88`bitbake-layers show-appends` includes that file btw21:13
moto-timoalex88: it's in FILES-${PN}-env so you need to install the u-boot-env package to your image21:13
alex88moto-timo, wait, why u-booot-env? shouldn't u-boot be enough?21:14
moto-timoalex88: no, for embedded systems we split things into smaller packages so you only get what you asked for21:15
moto-timono cruft21:15
moto-timo(less cruft)21:15
alex88I see, did something change regarding that from hardknott and honister?21:15
moto-timodo a git blame on that file21:15
moto-timo(teach a man to fish)21:15
alex88oh yeah sure you're right, no I thought for a moment that maybe the previous version included it anyway.. didn't think about changed21:16
alex88(previous version of yocto included it anyway even if not in FILES-${PN})21:16
alex88hardknott had the same condition, gatesgarth too... not sure then.. maybe some other recipe was including the env package then21:18
alex88thanks a lot moto-timo!21:18
moto-timoyou're welcome21:18
moto-timomight have been a change in meta-raspberrypi too? don't know21:18
moto-timowe do tend to make things more explicit over time21:19
moto-timoas the cruft gets caught by more eyeballs21:19
alex88totally in favor of that, I just need to get better at finding the why things happen21:20
moto-timobitbake -e <foo> , bitbake-getvar, oe-pkgdata-util are your friends21:21
moto-timoand sometimes bitbake -DDDD21:23
alex88got it, very helpful!21:24
*** kaitsh <kaitsh!~kaitsh@user/kaitsh> has quit IRC (Quit: WeeChat 3.1)21:24
*** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)21:30
*** chep <chep!~chep@> has quit IRC (Ping timeout: 268 seconds)21:36
*** chep <chep!~chep@> has joined #yocto21:39
kroonJPEW, depsig.* arent generated when building from sstate ?21:55
JPEWkroon: No21:55
JPEWRP and I have discussed doing something like that, since it would open some interesting options21:56
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)21:59
*** camus <camus!~Instantbi@> has joined #yocto21:59
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 256 seconds)22:01
JPEWmoto-timo: squeekboard seems find... looks like by default it only appears when the user presses the keyboard icon in the lower left of the screen?22:10
JPEWThere might be some support for applications to make it pop up on their own, but either none of the ones I've tried are doing that or there is some flag that prevents it when the do22:10
moto-timoJPEW: that’s great news and expected behavior.22:10
moto-timoJPEW: I think kanavin said the keyboard was coming up any time a user input field got focus?22:12
moto-timoI can’t wait to try it this weekend!22:12
JPEWmoto-timo: It doesn't appear to popup unrequested?22:16
JPEWBut... that could just be the applications I'm try22:16
JPEWI know the wayland protocol they are using supports that sort of thing22:16
moto-timoMaybe they fixed something!22:16
moto-timoOne thing I am wondering about is the mobile adapted or whatever tab vs. the other apps. Like epiphany is in the top tier and everything else below the line22:18
moto-timoMy Google fu didn’t come up with anything yet22:19
*** xmn <xmn!> has joined #yocto22:19
moto-timoProbably some API or interface requirements22:20
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto22:20
JPEWOne would hope GTK dealt with that mostly transparently22:20
moto-timoOne would indeed22:20
*** Gaffel <Gaffel!> has quit IRC (Quit: What's that?)22:23
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds)22:24
*** florian <florian!> has joined #yocto22:33
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:dfc4:6584:f65f:a643> has quit IRC (Ping timeout: 240 seconds)22:34
*** chep <chep!~chep@> has quit IRC (Ping timeout: 256 seconds)22:35
*** chep <chep!~chep@> has joined #yocto22:39
*** sakoman <sakoman!> has joined #yocto22:39
*** Gaffel <Gaffel!> has joined #yocto22:54
*** adrian__ <adrian__!~F_Adrian@> has joined #yocto23:12
*** adrian_ <adrian_!~F_Adrian@> has quit IRC (Ping timeout: 256 seconds)23:14
*** adrian__ <adrian__!~F_Adrian@> has quit IRC (Ping timeout: 264 seconds)23:27
*** Gaffel <Gaffel!> has quit IRC (Quit: What's that?)23:37
kanavinJPEW, that's the behavior I got in Fedora, so maybe it's just wrongly built or packaged there, or many other reasons23:48
kanavinbut I did have to deinstall it to get rid of it23:48
*** manuel <manuel!~manuel@2a02:1748:dd5c:f290:c553:9012:6082:a89a> has quit IRC (Remote host closed the connection)23:58
*** manuel_ <manuel_!~manuel@2a02:1748:dd5c:f290:c553:9012:6082:a89a> has joined #yocto23:59

Generated by 2.17.2 by Marius Gedminas - find it at!