Tuesday, 2020-01-14

*** khem <khem!~khem@unaffiliated/khem> has joined #yocto00:07
JaMawhat might be adding "/dev/sda1       /boot   vfat    defaults        0       0" to the /etc/fstab after rootfs was created? I'm seeing it e.g. in core-image-sato-sdk-qemux86-64.rootfs.ext4, but it's not in WORKDIR/rootfs/etc/fstab for me it breaks the boot with systemd as there is no /dev/sda1 and boot waits forever for that (noticed when trying to debug -c testimage getting stuck until it timeouts waiting00:13
JaMafor login00:13
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC00:16
*** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has joined #yocto00:19
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC00:24
*** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto00:24
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC00:31
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto00:31
*** dev1990 <dev1990!~dev@asx191.neoplus.adsl.tpnet.pl> has quit IRC00:37
*** dev1990 <dev1990!~dev@asx191.neoplus.adsl.tpnet.pl> has joined #yocto00:39
khemJaMa: are you using wic ?00:49
JaMakhem: not really intentionally, but there was IMAGE_FSTYPES="wic.vmdk ext4 wic wic.bmap"00:50
JaMawasn't the issue with wic modifying it for other image types already fixed? let me find the commit00:51
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC00:53
JaMahttp://lists.openembedded.org/pipermail/openembedded-core/2019-October/288505.html00:53
JaMaah it looks like it never made it pass Ross00:54
khemyep00:54
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto00:55
JaMaso it's either openembedded-core/scripts/lib/wic/canned-wks/common.wks.inc expecting /boot partition which doesn't exist, or the /dev/vda image used by runqemu should actually use different disk which had separate /boot partition00:57
JaMait was happening only for -sdk images, so I was looking in wrong direction :/00:58
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC00:58
*** camus <camus!~Instantbi@222.67.188.168> has joined #yocto01:01
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC01:01
*** camus is now known as kaspter01:01
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto01:13
*** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC01:17
*** la_croix <la_croix!~la_croix@82.11.161.99> has joined #yocto01:23
*** camus <camus!~Instantbi@222.67.189.189> has joined #yocto01:24
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC01:25
*** camus is now known as kaspter01:25
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC01:37
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto01:41
*** mischief <mischief!~mischief@216.126.196.60> has joined #yocto01:43
mischiefis it normal that 'oe-pkgdata-util find-path' can't find directories?01:44
*** sgw <sgw!~sgw@134.134.137.77> has quit IRC01:50
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-phyargejysojxzap> has quit IRC01:53
khemmischief: whats your full cmd ?02:31
khemand have you built an image ?02:31
zeddiiRP: if all goes well, I'll have 5.4 ready by the end of this week + the new libc-headers. I fixed a few more issues today, but I have -rt, aufs, yaffs2, etc, all ported now and am running glibc tests. will do musl tomorrow and the AB after that.02:35
mischiefkhem: oe-pkgdata-util find-path /var02:44
mischiefor /var/tmp, or /var/log, so on02:44
mischiefif i inspect the built base-files package, of course it has /var, so thats what i expected this to print.02:45
mischiefand yes, i have an image.02:45
*** sgw <sgw!~sgw@192.55.54.42> has joined #yocto02:54
khemmischief: it works on filenames02:55
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC03:37
*** agust <agust!~agust@p508B64CC.dip0.t-ipconnect.de> has joined #yocto05:44
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC05:50
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC06:24
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto06:26
*** stuom1 <stuom1!3eecd81d@62.236.216.29> has joined #yocto06:28
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto06:28
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto06:37
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto06:44
yoctiNew news from stackoverflow: How to enter in root on sama5d27-som1-ek board <https://stackoverflow.com/questions/59728514/how-to-enter-in-root-on-sama5d27-som1-ek-board>06:49
*** pohly <pohly!~pohly@p5B05600C.dip0.t-ipconnect.de> has joined #yocto07:17
*** frsc <frsc!~frsc@2003:a:e7a:6200:29a6:db2c:eaaf:35ef> has joined #yocto07:27
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto07:32
LetoThe2ndangelo__: no, its the other way round. sumo is old, u-boot is new. so you you either need to roll back to an old u-boot, or forward to a new yocto release.07:34
*** meow <meow!~magnet@lfbn-mon-1-581-143.w2-4.abo.wanadoo.fr> has joined #yocto07:37
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto07:46
*** meow <meow!~magnet@lfbn-mon-1-581-143.w2-4.abo.wanadoo.fr> has quit IRC07:47
*** jww <jww!~magnet@lfbn-mon-1-581-143.w2-4.abo.wanadoo.fr> has joined #yocto07:49
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto07:52
angelo__LetoThe2nd, thanks07:53
*** mckoan|away is now known as mckoan08:01
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto08:02
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC08:07
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto08:08
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto08:09
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC08:11
stuom1how do I say to "devtool add" from what branch it should fetch?08:17
LetoThe2ndstuom1: devtool add --help :)08:18
stuom1I'm trying "--srcbranch" but it still complaind that unable to resolve master08:18
stuom1i dont have master branch and i dont want to fetch from master08:18
LetoThe2ndwell if master doesn't even exist, that might be a problem then.08:19
stuom1why master has to exist?08:19
yoctiNew news from stackoverflow: Yocto Linux for Banan Pi? <https://stackoverflow.com/questions/59729452/yocto-linux-for-banan-pi>08:19
stuom1My "master" branch is called develop, and "--scrbranch develop" says " Fetcher failure: Unable to resolve 'master' in upstream git repository"08:20
LetoThe2ndstuom1: its possible that the devtool code takes this as canonical state of a repo. if --srcbranch doesnt work for you, then you're probably either up to manual creation of the recipe or digging devtool source.08:20
LetoThe2ndor reporting a bug, or trying with recipetool08:21
stuom1if I would have branch called master, would it then fetch from correct srcbranch, or quietly fetch from master in that case?08:22
LetoThe2ndit would probably fetch master and then checkout.08:23
LetoThe2ndbut thats guessing, please check the sources if you need to know for sure.08:23
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto08:24
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC08:28
stuom1using srcrev instead works luckily08:29
LetoThe2ndstuom1: care to file a bug report, anyways? the worst thing that cna happen is a "won't fix because wroks like intented, reason is XYZ"08:30
stuom1i can look into it, if it doesnt take a workday to learn how to do it ;)08:31
LetoThe2ndstuom1: https://bugzilla.yoctoproject.org/enter_bug.cgi08:32
stuom1thanks, now where did i put by bugzilla credentials...08:33
*** likewise <likewise!~leon@145.130.96.189> has joined #yocto08:36
qschulzbluelightning: hello :) Asking you since you are one of the committers of meta/lib/oe/patch.py :)08:37
qschulzis patchdir *officially* supported for applying patches on top of files coming from FILEPATH? (e.g. meta-a/recipes-a/a/files/myfile and a patch meta-b/recipes-a/a/files/patch-for-myfile.patch)08:37
qschulzmore specifically, what I'm describing is supported but breaks devtool modify because the relative path to the files is then incorrect when running extract_files to prepare the workspace. I could try to dig into that but if we already know it's not gonna make it upstream, i'd rather not waste time :)08:38
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC08:40
khemRP: sato-sdk/mips issue is due to prelink, if we disable prelinking it works08:47
*** lfa <lfa!~lfa@217.19.35.51> has joined #yocto08:50
RPkhem: that sounds like fun to debug, good to nannow it down though!08:57
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto09:05
*** MeanEngi <MeanEngi!5fa87c99@95.168.124.153> has joined #yocto09:19
angelo__just updated "PREFERRED_VERSION_u-boot = "2016.03""   but bitbake still build the previous version. How can i refresh the version ?09:27
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto09:29
RPangelo__: did you change the u-boot recipe?09:29
paulbarkerangelo__: Do any of your layers have a recipe for that version of u-boot? it's a little old09:29
angelo__no, that above in in machine conf, u-boot recipe was always there09:30
angelo__yes i have09:30
paulbarkerYou might need to use "2016.03%" if there is anything appended to that version string in the recipe09:30
angelo__mm ihave  -rw-rw-r-- 1 ge ge   264 Jan 14 09:16 u-boot_2016.03.bb09:30
qschulzangelo__: bitbake-layers show-recipes u-boot?09:31
*** yann <yann!~yann@85.118.38.73> has joined #yocto09:31
qschulzyou'll see if your recipe is parsed by bitbake and thus available to you09:31
angelo__qschulz, thanks09:32
angelo__i see09:32
angelo__u-boot:09:32
angelo__  meta                 1:2018.0709:32
angelo__  meta-xxx-layer       v2016.03+gitAUTOINC+df61a74e6809:32
paulbarkerangelo__: PREFERRED_VERSION needs to match what's in PV in the recipe, in this case I'd guess to use "v2016.03%"09:33
angelo__paulbarker qschulz RP, thanks, it works now09:35
stuom1LetoThe2nd I think I found the bug in recipetool, I tried fix locally and it works. Is it easier to make a pull request somewhere or file a bug and write my findings there?09:37
LetoThe2ndstuom1: if you've already got a fix, then then best way is to send a patch to the ML09:38
*** sgw <sgw!~sgw@192.55.54.42> has quit IRC09:45
qschulzBTW, I was thinking, a good tool we could add to bitbake-layers or something would be something that parses SRC_URI and FILEPATHS and tells you which files in which paths could be a match and which one is used for that particular line in SRC_URI, making it way easier to help people debug weird defconfigs or so09:45
qschulzthe use-case is bbappends with same files but different layer priorities09:46
qschulzand/or OVERRIDES in paths09:46
qschulz(and the order in FILEPATHS)09:47
qschulz(i.e. PN-PV, then PN, then files)09:47
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto10:01
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC10:06
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto10:09
stuom1LetoThe2nd I did my best to send a patch, let's see how it went, heh10:56
stacktrustfor interactive dev/debug, when many changes are taking place (recipes, local patches, remote repos), it is sometimes necessary to issue "-c cleanall" for one or more recipes.  Question 1: can cleanall+build be combined in a single bitbake invocation?  Question 2: could bitbake theoretically be modified (may not be suitable for upstream) to retry failed tasks with cleanall?10:57
LetoThe2ndstuom1: thanks!10:57
LetoThe2ndstacktrust: 0) thou shalt use clean, not cleanall. 1) not my knowledge 2) anything is possible, its only software. but you're probably better off just using some wrapper then (also applies to 1)10:58
stuom1I also use cleanall when I want to clean something, is it bad?11:00
qschulzstuom1: the question is, what makes you use -c clean/cleanall/cleansstate? If it's just for cleaning purposes, then I'd say fine. But if it is because it's not behaving as it should or there is an error. NOT fine, you're "fixing" the consequence, not the cause. All of that = IMO11:02
LetoThe2ndit was explained lately why clean, not cleanall (by RP). it made sense, i just totally forgot again.11:03
LetoThe2ndanybody please dig up the logs, or poke him again :P11:03
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto11:05
stacktrustLetoThe2nd: thanks :) Wrapper works for target that has a few dependencies.  For a target with a large number of tasks, it would be too slow (hours) to rebuild after clean/all, hence it would be good if bb can internally re-queue the small subset of tasks which are failing (e.g. recipe edits have invalidated existing sysroots, causing FileExistsError for copy to sysroot-providers).11:05
paulbarkerLetoThe2nd: `cleanall` throws away downloads, sstate and the work dir. `clean` only throws away the work dir11:08
stacktrustEarlier in the logs it was mentioned that bb is only aware of recipe edits, not source changes.  It was also mentioned that PN/PV increments are the accepted way to force a rebuild. What do you do when PN/PV are already used by a recipe (e.g. dbus) and not suitable for modification in a bbappend? In that scenario, -c clean or -c force_rebuild (with warning message about tainted do_compile) can help.11:08
stacktrustSpeaking as a relatively new user of bb, the learning curve is so steep, and clean fixes so many indecipherable error messages, that -c clean is much closer to the default way of using bb.11:11
*** wooosaiiii <wooosaiiii!~prix@89-212-21-243.static.t-2.net> has joined #yocto11:16
stacktrustThe other issue with a wrapper is that each invocation of the wrapper loses time to reparse recipes. Memory-resident bitbake is good if recipes are not changing, e.g. only making changes to source code.11:18
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has quit IRC11:19
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto11:19
paulbarkerstacktrust: That doesn't sound like my experience with bitbake.11:20
paulbarkerWhat do you mean by "source changes"? Are you using the externalsrc bbclass or `SRCREV = "${AUTOREV}"`?11:21
stacktrustmostly autorev.11:21
paulbarkerOr are you placing source files in your layer and using `file://` URLs?11:21
paulbarkerautorev should pick up new commits to a recipe without you needing to mess with PN/PV11:22
paulbarkerIf it isn't doing then that's a bug not a feature11:22
paulbarker`-c cleanall` should only be needed if there's something wrong with your downloads directory, `-c cleansstate` only if there's an issue in sstate (which is almost always a bug to report upstream as sstate shouldn't ever be reused incorrectly), `-c clean` when you just need to re-build a recipe from scratch11:24
stacktrustthere are some patches in the layer with file:// URLs11:24
paulbarkerpatches in the layer and a few small source files are fine. Changes to these should be detected by bitbake and it will re-run the tasks from do_unpack for that recipe11:25
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto11:25
likewiseRunning into a devshell gives me this error: bash: /dev/fd/62: No such file or directory (which is the probable cause for subsequent problems). What could cause this?11:26
stacktrustpaulbarker: -c clean also needed when sysroot changes are caused by recipe edit, e.g. separating one package into two packages (e.g decoupling header file from library builds).  Before: 60 packages depended on P1.  After: 30 packages depend on P1a. The other 30 depend on P1b (which depends on P1a).11:30
*** likewise <likewise!~leon@145.130.96.189> has quit IRC11:31
paulbarkerThat shouldn't be needed, the dependency graph should rebuild the appropriate recipes. Which version of bitbake and the core layers are you using?11:32
stacktrustpyro11:32
stacktrust(migration to zeus in progress)11:33
paulbarkerpyro shouldn't be too bad.11:34
paulbarkerWhen you say you split P1 into P1a & P1b, are they separate recipes? Or packages in the same recipe?11:34
stacktrustSeparate recipes.  Packages in the same recipe would have a common dependency on P2, which we want to break by separating P1 into P1a/P1b.11:35
stacktrustAfter the split, only P1b depends on P2.11:36
paulbarkerSo then did you change DEPENDS in the 60 other recipes you mentioned?11:36
stuom1is it a bad idea to copy a recipe from newer branch of meta-oe than I use? I cannot update the whole meta-oe and I'm stuck with a very old nodejs :|11:37
rburtonfeel free to backport it11:37
rburtonjust be aware that some things might need changing11:38
rburtonRP:  so a-full does meta-intel builds now right11:38
* Crofton|road New Year resolution is to reduce the amount of work he does for old versions :)11:38
stacktrustpaulbarker: it was more like 30 packages depended on P3, which depended on P1.  After the split, DEPENDS on P3 was changed to P1a.  The other 30 packages remain dependent on P1==P1b.11:41
JaMarburton: was this dropped intentionally based on your review comment? It seems still needed http://lists.openembedded.org/pipermail/openembedded-core/2019-October/288505.html11:41
*** berton <berton!~berton@189.103.49.163> has joined #yocto11:41
rburtonJaMa: right, i was expecting a reply11:42
paulbarkerstacktrust: Dependency resolution in bitbake should figure out what to rebuild in that case, P3 will be rebuilt as DEPENDS changed then everything which DEPENDS on P3 will be rebuilt. If that's not happening it's a bug worth reporting11:42
JaMaI wanted to bump that thread, but no longer have it in the maildir11:42
stacktrustOk, should be easy (albeit slow) to repro.  Will do that after the refactoring is done.  With OpenXT moving to zeus, our bug reports will be more useful.11:45
stacktrustThanks for the analysis.11:45
stacktrustEverything which DEPENDS on P3 *was* rebuilt, but they each failed with FileExistsError in staging_copyfile os.link(c, dest), e.g. copying from /build/tmp-glibc/sysroots-components/all/P1a/sysroot-providers/P1a -> /build/tmp-glibc/work/core2-64-oe-linux/libgknome-keyring/2.32.0-r3/recipe-sysroot/sysroot-providers/P1a11:50
*** kovalevsky <kovalevsky!~kovalevsk@fedora/kovalevsky> has joined #yocto11:50
stacktrust(excuse typos from manual copy)11:51
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC11:53
*** likewise <likewise!~leon@145.130.96.189> has joined #yocto11:53
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto11:53
paulbarkerUnless you're manually copying things into weird recipe sysroots that sounds like a bug. If libgnome-keyring is rebuilt as one of its dependencies changed, the recipe sysroot should be rebuilt11:55
*** MeanEngi <MeanEngi!5fa87c99@95.168.124.153> has quit IRC12:03
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC12:03
LetoThe2ndlikewise: is this a real hw build host? running which distro?12:10
*** nacknick <nacknick!b9b8f483@185.184.244.131> has joined #yocto12:33
nacknickHi. I added the line * USERADD_PARAM_pn-systemd += "--system systemd-network" * to local.conf - and can't use root to login, why?12:35
LetoThe2ndnacknick: are you trying to replicate this? https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/systemd/systemd_243.2.bb#n35312:37
nacknickLetoThe2nd: no. It's just a local.conf someone passed to me and I don't know how to login12:37
LetoThe2ndnacknick: then what the line there for anyways? if you can't tell, get rid of it.12:38
nacknickI need to configure the environment as he did12:38
LetoThe2ndeven if its wrong?12:38
nacknickwhy wrong?12:39
*** stuom1 <stuom1!3eecd81d@62.236.216.29> has quit IRC12:39
nacknickIf there is no other choice, I will delete that line. Just wanted to make sure there is no way to login12:39
LetoThe2ndbecause let me rephrase your question. "i want to add this line to my local.conf. i have no idea why, just copying random stuff from somebody else. now something breaks. help me!"12:40
nacknickexactly12:40
*** stuom1 <stuom1!3eecd81d@62.236.216.29> has joined #yocto12:40
RPrburton: right12:43
*** blauskaerm <blauskaerm!Fever@gateway/vpn/mullvad/blauskaerm> has joined #yocto12:49
blauskaermI have a function in my image recipe like: do_myfuntion(). Is it possible to include if-statements like in bash?12:50
blauskaermI want to execute some commands if an environment variable is set12:50
LetoThe2ndblauskaerm: sure. lots of examples here: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/systemd/systemd_243.2.bb#n21812:51
qschulzblauskaerm: tasks and functions are running in a shell (I don't exactly how to turn that sentence so that might be *technically* wrong but whatever is inside should be shell valid12:51
qschulzblauskaerm: now the question is... what exactly are you trying to achieve12:52
LetoThe2ndblauskaerm: only remember the yocto chant: "recipe data is local, conf data is global". so if you want to set stuff in one recipe and use in another, then - nope, sorry. not a syntactical, but architectural problem that you have12:53
rburtonblauskaerm: environment variables get purged so you can't just do "FOO=bar bitbake recipe"12:53
LetoThe2ndrburton: was just about to add that12:53
rburtona shell function is literally ran by /bin/sh though so any sh works12:54
LetoThe2ndwhile that can be hacked with EXTRAWHITE12:54
rburtonshush12:54
qschulzLetoThe2nd: SHUSH12:55
rburtonproper solution is to just use a variable in local.conf etc :)12:55
*** PinkSnake <PinkSnake!51ff1123@81.255.17.35> has joined #yocto12:55
qschulzwell it depends what they want to achieve12:55
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC12:55
LetoThe2ndqschulz: i'm proud, you're getting the spirit.12:55
qschulzrburton: BTW, this is kinda weird to have /bin/sh because if I'm correct, the result of the task could be different depending on which shell is the one used on the building machine right?12:56
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto12:56
LetoThe2ndqschulz: (it ALWAYS depends :) )12:56
rburtonqschulz: docs say assume posix sh12:56
rburtonif you use bash code then yes expect breakage if you don't get bash12:56
qschulzLetoThe2nd: I was talking about the variables which shouldn't be named. But the local/global thing one day will be burnt in my brain12:56
*** tprrt <tprrt!~tprrt@139.28.219.86> has joined #yocto12:57
PinkSnakehello guys! Little trouble with this recipe : http://git.yoctoproject.org/cgit/cgit.cgi/meta-web-kiosk/tree/recipes-common/ssh-keys/ssh-keys_0.1.bb?h=master, I have simply added this recipe to my Yocto env (branch zeus) I got this error but I don't understand what's appened (log: https://pastebin.com/pm61RXzF) any idea ? Thanks12:57
qschulzrburton: yup. not great, no checks are enforced at review time I think here. Is there any magic thing one of you uses to detect non-posix instructions?12:57
qschulzhere = where I work eh12:58
rburtonqschulz: there's a tool to verify that you're not doing bashisms, scripts/verify-bashisms13:00
stacktrustshfmt claims to check posix shell validity: https://github.com/mvdan/sh13:00
qschulzrburton: that's nice! thanks!13:02
*** stuom1 <stuom1!3eecd81d@62.236.216.29> has quit IRC13:06
*** stuom1 <stuom1!3eecd81d@62.236.216.29> has joined #yocto13:09
blauskaermLetoThe2nd qschulz rburton: Thank you all for your replies :)13:12
blauskaermIm developing agenst a iMX6 board and want to controll when yocto hands over our kernel binaries to our crypto server for signing13:13
blauskaermAnd environment variable is not required, it just something I came up with13:13
blauskaermIf I could pass something else to bitbake and check if that is set in my function would be much better but I have not found anything like that?13:14
qschulzblauskaerm: I'm not entirely sure you want to automate that actually.13:14
qschulzI mean from security PoV13:14
qschulzsigning whatever is output by Yocto without human validation...13:14
blauskaermWe have two sets of boards. One for lab and one for production13:14
blauskaermProduction keys will be handled differently but we want to sign software for lab in yocto13:15
blauskaermBut regardless if it sound very dump, is it possible to pass "arbitrary" variables to bitbake what I can read in the function?13:17
qschulzblauskaerm: out of my head, maybe not ideal=> two recipes PROVIDES (that's the var name) the same "crypto-keys". One for lab, one for production. Then you pick the recipe with PREFERRED_PROVIDER_crypto-keys = "crypto-lab" in conf/local.conf for example?13:17
qschulzblauskaerm: sometimes when you want things to be controlled within a recipe from outside, what you want are different recipes, images, distros, machines or some lines in local.conf.13:18
blauskaermThat could work. Will discuss it with my colleague :)13:21
blauskaerm13:21
blauskaermThanks for your time13:21
*** kovalevsky <kovalevsky!~kovalevsk@fedora/kovalevsky> has quit IRC13:26
qschulzblauskaerm: we use some post script in the image recipe here. So you could have two different images (slightly, just one line changed or something) and build the correct image (lab/prod) when needed. It depends on how complex the signing process is and how late it should happen13:28
silviofI am involved in a single-source project, which also includes customization of several third party components. Now the sources are checked out x times. Is there a way around this and can the sources only be downloaded once? I assume that this is done via "work-shared", but I don't know how to do it. Does anyone have a manual for?13:47
qschulzsilviof: I do not really understand the "includes customization of several third party components" part13:48
silviofqschulz: We make changes in systemfiles, for example from "/etc/network/interfaces", but we do not track these changes in yocto but in another repository.13:50
Yatekiionto my first receipe!13:53
stuom1is it possible to skip sysroot_strip function?13:53
Yatekiihmm how would i source my sdk env from my receipe? should i just source the env file or is there a vetter way (does it do this by default?)?13:54
qschulzYatekii: no no, Yocto passes a few variables to the build system of your software. If the build system (make, cmake, autotools, meson...) does not use the variables correctly, you patch the sources. If it does not have the variables you're interested in, you add them to passed variables (CFLAGS, EXTRA_OEMAKE, EXTRA_OECONF, etc...)13:56
Yatekiiqschulz: ok, thx, i'll try13:59
*** florian_kc is now known as florian14:01
Yatekiihow hard can it be i mean xD14:02
qschulzYatekii: good luck. Try as much as you can but if it feels too hacky or you rely a bit too much on Google, maybe ask a question or two here :)14:02
qschulzYatekii: take this https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html. It's dangerous to go alone/14:02
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto14:03
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC14:03
Yatekii:D14:05
Yatekiiyeah I googled a lot butr most of it seems outdated (see conversationm yesterday) or just half-knowledge14:05
Yatekiimany irc channels are more like "google yourself, noob"14:06
Yatekii:D14:06
Yatekiiso thanks :)14:06
qschulzYatekii: well we know most YP stuff is very specific to one's case14:07
*** sgw <sgw!sgw@nat/intel/x-yxqwtcrfhrhidppp> has joined #yocto14:07
qschulzand the mega-manual being so mega is both a blessing and a curse. So much information. But... SO MUCH INFORMATION14:07
qschulzanyway, I should work some time :)14:08
Yatekiihave fun :)14:08
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto14:19
yoctiNew news from stackoverflow: Raspberry Pi 4 yocto, rpi-basic-image.bb: Unable to determine endianness for architecture 'INVALID' <https://stackoverflow.com/questions/59735965/raspberry-pi-4-yocto-rpi-basic-image-bb-unable-to-determine-endianness-for-arc>14:51
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:55
rburtonsilviof: downloads will be done once, cached in DL_DIR14:57
silviofrburton: Ah thanks. probably the unpacking will take ages, because this is what takes time then. Can I use an already unpacked source tree then?14:58
rburtonwork-shared isn't a built-in feature but rather something the kernel does itself14:58
rburtonits full of pain, you'll be best living with slow unpacks14:58
rburtonremember if you have two builds for different recipes inthe same source tree you *need* to be *sure* that they won't stamp on each other14:59
rburtonmaybe some tricks like only unpacking the bits you need15:00
rburtonif eg you have a 1gb tarball but only need one directory, just unpack those bits15:01
silviofrburton: Ah okay. Thanks you helped a lot.15:02
rburtoni'm presuming its a giant tarball as you said slow unpack15:02
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto15:05
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has quit IRC15:05
*** jonmason <jonmason!sid36602@gateway/web/irccloud.com/x-utkoeprpuhmnusyb> has quit IRC15:13
*** jonmason <jonmason!sid36602@gateway/web/irccloud.com/x-fkqexphgaprygwas> has joined #yocto15:18
kanavinRP: fix for gstreamer meson conversion on the way15:19
kanavin(just so you don't drop the patches from master-next)15:19
RPkanavin: thanks! :)15:19
RPkanavin: there is a -next build underway with your patches in15:19
kanavinRP: right :) btw, I will be employed by Daimler directly starting Feb 1st, which means changing equipment, setting up access, etc., so upstream work will be delayed until I'm settled15:21
LetoThe2ndkanavin: hooray!15:21
kanavinI will keep my build machine most likely, but making it work in Daimler environment may be tricky15:21
kanavinI will also try to convince them to buy me the 64 core threadripper :)15:22
RPkanavin: thanks for the headsup, I know what the disruption can be like!15:24
nacknickhow to reset root password of yocto? I tried raspberry pi technique (init=/bin/sh) with no success15:24
LetoThe2ndnacknick: rebuild image, with settings accordingly: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-extrausers15:29
LetoThe2ndnacknick: or IMAGE_FEATURES += "DEBUG_TWEAKS"15:29
mcfriskhi, want's the deal with nspr triggering compile of glibc on zeus. can't see the dependency..15:40
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC15:41
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto15:43
qschulzmcfrisk: bitbake-diffsigs on glibc might be helpful?15:45
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC15:46
*** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has quit IRC15:47
*** jonmason <jonmason!sid36602@gateway/web/irccloud.com/x-fkqexphgaprygwas> has quit IRC15:48
mcfriskqschulz: blah, I trigger fingered rm -rf tmp... I'll remember that if this reproduces15:48
angelo__is it possible to set a more recent gcc version to build all (and i.e. u-boot ?)15:49
LetoThe2ndangelo__: you can try and copypasta in recipes from a newer release, but be ready for some pain15:50
*** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto15:50
LetoThe2ndangelo__: (roughly the same amount as outright upgrading the release)15:50
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC15:50
angelo__aaaargh :(15:50
LetoThe2ndtheres a reason why there are releases which offer a consistent state :)15:51
*** jonmason <jonmason!sid36602@gateway/web/irccloud.com/x-xeugvhvbxzdauoez> has joined #yocto15:52
armpitYPTM: Armin in on15:55
*** PinkSnake <PinkSnake!51ff1123@81.255.17.35> has quit IRC15:56
qschulzmcfrisk: if you have your sstate-cache elsewhere it's still fine15:56
angelo__LetoThe2nd, have the following issue. I am in a sumo stuff, and cannot upgrade. If i build u-boot 2018, i get error that gcc must be > 6.0.0 (linaro-5.3 now), if i use an older 2016.03 u-boot i get the error "error: conflicting types for 'fdt64_t'"15:59
mcfriskqschulz: yea, I did hit the bug again. have a bbappend for nspr which adds a test and that seems to be triggering this, and recompile of gcc-cross. diffsigs didn't know how to display this though..16:00
LetoThe2ndangelo__: well then, either happy u-boot-patching, or happy upgrading.16:00
LetoThe2ndangelo__: hint: you can look at the u-boot logs to try and identify the commit that fixes your problem, then backport it.16:02
angelo__LetoThe2nd, well, will try. Thanks for now, i'll stay happy btw :)16:02
qschulzmcfrisk: interesting, it usually at least gives you one task which is the trigger16:03
kergothJPEW: what are the requirements pyrex has for the docker image? if i wanted to change the base image, what would i have to add to it to be able to use pyrex with it? Is everything in the dockerfile mandatory, or is there a specific list of requirements?16:05
tlwoerneryptm: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit16:06
Yatekiihmm I am trying to use the receipe in this example: https://github.com/rust-embedded/meta-rust-bin16:08
kergothJPEW: another quick question, when using non-standard oe setup scripts, can we manually set things lke BITBAKEDIR before sourcing pyrex-init-build-env?16:09
*** berton <berton!~berton@189.103.49.163> has quit IRC16:10
*** berton <berton!~berton@189.103.49.163> has joined #yocto16:11
LetoThe2ndYatekii: "and then...ยง16:14
Yatekii?16:15
LetoThe2ndYatekii: "i am trying to use this recipe". well if you got no further questions or remarks?16:15
Yatekiiwell it says it cannot copy the license etc16:17
Yatekiiand when I ignore it it complains about a missing manifest16:18
Yatekiiand when I check the git dir it is empty16:18
Yatekiiso I wonder how I get a populated git dir16:18
LetoThe2ndthe git dir?16:20
Yatekiimanifest path `/home/yatekii/repos/ecarup/build-openstlinuxtkrt-stm32mp1-raichu-cubemx/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_tkrt-linux-gnueabi/raichu-core/1.0-r0/git/Cargo.toml` does not exist16:20
Yatekiithe Cargo.toml is missing16:20
Yatekiibut the dir it is supposed to be in is the git dir the receipe should clone from16:20
Yatekii(the one in the readme)16:21
LetoThe2ndso you have a recipe that is called "raichu-core_git.bb, but which should build the gpio-utils? or what?16:22
YatekiiI have a receipe that is called raichu_core.bb16:23
Yatekiiraichu-core.bb16:23
Yatekiiyes it builds the gpio-utils16:23
LetoThe2ndsee, thats the problem.16:23
Yatekiihmm?16:23
LetoThe2nd${PN} and ${PV} are derived from your recipe name, unless tated otherwise. with that name, PV is unset, therefore the checkout braks.16:24
LetoThe2ndsuggestion: raichu-core_0.3.0.bb :)16:24
Yatekiiohhh thank you :)16:25
Yatekiihmm what do I have to do so it now checks out?16:26
Yatekiiit's still empty (I added the tag and the PV variable requirement all together16:26
LetoThe2nd(hint: next time you just post a pointless information without context or qeustion, i'll silently ignore instead of trying and pulling it all out of nose)16:26
LetoThe2nd?16:27
qschulzYatekii: what did you do exactly?16:27
LetoThe2ndcan't you just put the recipe as is in a pastebin? including the real file name?16:27
YatekiiLetoThe2nd: sorry, got distracted debugging ^^I actually intended to pose a quetsion ... :/16:27
YatekiiLetoThe2nd: https://gist.github.com/Yatekii/45cd029ca2f6690fddcbd00aa9a4120c16:30
Yatekiihere you gho :)16:30
Yatekiiqschulz: ^16:30
LetoThe2nd"i do not listen to what LetoThe2nd write: [X]"16:30
YatekiiLetoThe2nd: I thought when I remove the PV requiremet that works16:30
Yatekii?16:31
LetoThe2ndstop thinking. start reading. this might sound like an insult, which it is not. its just the truth.16:31
YatekiiLetoThe2nd: well I thought it's optional because my mate here in the office did his receipe without it16:32
Yatekiiso this was confusing16:32
Yatekiibut I now found some statements in his receipe16:32
LetoThe2ndSRC_URI[md5sum] on a git checkout is pointless too, imho16:32
LetoThe2nd-> SRCREV16:32
Yatekiiyes, this is what he did16:32
Yatekiialso added this: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"16:33
qschulzYatekii: basically, what you did there is asking yocto to checkout master16:33
LetoThe2ndtell your "mate" that PV belongs into the recipe name. and if its a moving target, then it shall be _git16:33
qschulzYatekii: stop stop stop. Start with small things :)16:33
LetoThe2nd*sighs*16:33
LetoThe2ndqschulz: have fun. i'm off.16:33
qschulzYatekii: you have an example, make the example work16:33
qschulzLetoThe2nd: o/16:33
qschulzYatekii: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#git-fetcher16:34
Yatekiiwell I have another example from a mate which works, so it's har dto tell which one is correct. especially since his seemed to work whilst the other didn't (not saying any of those means anything, but it's just confusing)16:34
Yatekiithx LetoThe2nd :)16:34
qschulzYatekii: your mate might not know what he's doing :)16:34
qschulz(and I say *might* because I don't know them and I haven't seen the code and I have no authority over who's doing something right or wrong :)16:35
Yatekiiqschulz: that's 100% the case :D16:35
qschulzYatekii: so have a look at the link16:35
qschulzthis gives all the default16:35
Yatekiiyup :)16:35
Yatekiithx16:35
qschulzfor the git fetcher16:35
qschulzmmmm16:36
qschulzit's actually not that good, it's missing the requirement on SRCREV16:36
qschulzanyway16:36
Yatekiiwell it tells the args I can put into the url16:36
Yatekiibut not much more :/16:36
qschulzTL;DR, either you use tag=mytag and you're good (except some network consequences as mentioned)16:37
qschulzor you need to pass a commit hash to SRCREV, because Yocto won't know which commit to take16:37
qschulzRemember, yocto is meant to build ina  reproducible manner16:37
Yatekiihmm what if I always want the newest hash?16:37
qschulzso, tag is ok because tag are meant to be fixed hashes16:37
Yatekiibecause I am developping and not in the mood to always change it16:37
qschulzYatekii: we'll see later16:37
qschulzlet me finish that first16:38
Yatekiikk :)16:38
qschulzso, either tag=something after the URL, or SRCREV16:38
qschulzthe thing is, the hash in SRCREV is a hash that has to be in master16:38
qschulzor, if you add branch=mybranch, in mybranch16:39
qschulz(add to the URL)16:39
qschulz(because branch=master by default)16:39
qschulzso that's one thing16:39
qschulzso when you remove tag=${PV}16:39
qschulzIt tries to get a undefined commit hash in master.. I'm actually surprised bitbake does not complain16:40
qschulzso you need either a tag or a branch + a commit hash16:40
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:40
qschulznow I hope the name of the recipe (${PN}) won't matter anywhere in the cargo class or elsewhere :)16:41
qschulzso, to answer your "but I want to develop and not update the SRCREV" => https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-AUTOREV16:42
qschulzand READ IT CAREFULLY, because the first line is not enough :) (bitbake will not complain but you'll have issues later on)16:42
kergothJPEW: nevermind, just used a wrapper script to set them16:43
qschulzFILESEXTRAPATHS_prepend is for bbappends, you don't need that in a recipe (moreover, what your mate did, if they did it in a bb recipe and not in a bbappend, is actually already done, in another way, but it's done already so it's a no-op)16:43
qschulzYatekii: also, best practice, always name your recipes my-recipe_version.bb16:44
qschulzNO underscores in my-recipe, NO uppercase letter or fancy character16:44
qschulzversion can be a number, have letters or be `git`16:44
qschulzwith that, PN in the recipe will be `my-recipe` and PV will be `version`16:45
qschulzok, afk til tmrw. You can write I'll answer tomorrow if nobody's answered til then16:45
qschulzYatekii: https://www.youtube.com/user/TheYoctoProject16:46
Yatekiiokii, thx :)16:46
Yatekiithx so much!16:46
YatekiiI will try some around, already read the sectioon you linked but not sure I fully understand16:47
Yatekiihave a nice evening!16:47
armpitYPTM: is over16:47
qschulzYatekii: i'm plugging my previous company's training (open access to materials) https://bootlin.com/training/yocto/ you can read the slides. It's a very wide introduction but not deep. Should be good for you.16:47
qschulzYatekii: don't blindly copy paste. If you think you need to add something to your recipe or someone tell you to do it, have a look at the mega-manual and try to see if ithe variable to be modified makes sense16:48
qschulzYatekii: btw, your personal website is returning 403 ;)16:49
JPEWkergoth: Ah, sorry missed your questions16:49
Yatekiiqschulz: I never blindly copy paste, I'll always try and understand the process behind it. but that does not mean it's the best way to do something ;)16:49
YatekiiWPF (thank god I don't have to use it anymore) is a good example. the entire internet suggests to use it like winforms. when in fact you are not supposed to.16:50
Yatekiiand even tho you can understand the code and it kinda makes sense, you can't know there's a better version ;)16:50
qschulzJPEW: sorry for vomitting on the channel :)16:50
JPEWkergoth: It should be possible to set BITBAKEDIR before sourcing the environment script. We just need to make sure that BITBAKEDIR is one of the variables passed during capture16:51
Yatekiiqschulz: yeah, I know :/ I cba to fix it ... only had my resume, my PGP key and my email :D should fix it ... thx for the hint :)16:51
qschulzYatekii: that was more meant for the FILESEXTRAPATH thing :)16:51
JPEWqschultz: no problem16:51
qschulzJPEW: you didn't use autocompletion for my nickname didn't you :p16:51
Yatekiiqschulz: yeah, that was just telling you guys what my mate used :) I didn't actually use that (lucky me :D)16:52
Yatekiiqschulz: https://github.com/yatekii this is more of a webpage for what I do :D16:52
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC16:52
JPEWqschulz: Hah, I didn't even know my client *had* autocomplete until I just tried it16:52
Yatekiiok imma catch the train and continue work tomorrorw. but i'l be online on the cell to chug in all that info you gave me!16:52
qschulzYatekii: invest your time in reading materials before coding otherwise you'll just be left with frustration. It is especially true with Yocto :) GL16:54
JPEWkergoth: I think adding "BITBAKEDIR" to run:envvars in pyrex.ini will do what you want16:55
JPEWkergoth: If you want to give that a try to make sure it works, I'll add it as the default16:56
JPEWkergoth: As far as the images are concerned, the absolute minimum requirement are the "*-base" images. From those, you could theoretically build up images for OE, Android, whatever16:58
khemJPEW: I think getting devtool to work would make pyrex useful for me16:58
khemand also running runqemu seemlessly16:58
JPEWI think those both work now16:59
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC16:59
JPEWkhem: On the "next" branch at least16:59
*** yann <yann!~yann@85.118.38.73> has quit IRC16:59
JPEWrunqemu works as long as you use uninative, since technically you are building qemu on a different system than you are running it :)17:00
JPEWkhem: I don't use devtool extensively, but when I have used it, it's worked17:01
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC17:04
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto17:06
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto17:08
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC17:10
Yatekiiqschulz: yeah :) I am reading through the material you gave me :) thx!17:15
*** frsc <frsc!~frsc@2003:a:e7a:6200:29a6:db2c:eaaf:35ef> has quit IRC17:19
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto17:23
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC17:25
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC17:43
*** tprrt <tprrt!~tprrt@139.28.219.86> has quit IRC17:48
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto17:53
*** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC17:53
*** sveinse <sveinse!~sveinse@7.92-221-150.customer.lyse.net> has joined #yocto17:59
sveinseI used to be able to run bitbake -c fetchall core-image-minimal, in zeus it complains Task do_fetchall does not exist for target core-image-minimal. How can I download the sources?18:01
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-yzjpehayamasiyzu> has quit IRC18:03
paulbarkersveinse: That was changed18:03
paulbarkerhttps://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#migration-2.5-bitbake-changes18:03
sveinsethanks18:04
khemRP: I have a potential patch for prelink18:04
khemi think it needs more work but hopefully can eke it out18:06
*** mckoan is now known as mckoan|away18:11
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC18:12
RPkhem: very cool :)18:19
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto18:23
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto18:25
Crofton|roadCan you linkedin people do me a favour and share this page ?18:29
Crofton|roadhttps://www.linkedin.com/posts/openembedded_fosdem-fosdem20-openembedded-activity-6622864179256705024-OTAJ18:29
tgamblinDone18:31
JaMaRP: I have one case of reproducible 'getpwuid(): uid not found: 1001' issue, but it happens only on one builder and works on other, anything you want me try there?18:36
JaMaRP: what I've found sofar is that it's triggered on all files which is unpacked from tarball in do_install() and it's not related to existing sstate-cache as I can still reproduce it on that builder after cleansstate and removing all SSTATE_MIRRORS18:38
RPJaMa: I was literally just looking at the python3 issue which also seems to only happen sometimes. I just replied on list about what I found there (not much) :/18:38
RPJaMa: Is the ownership of those files from the tarball ever set?18:39
JaMaRP: as chown in the do_install, then not, it's this recipe: https://github.com/webOS-ports/meta-webos-ports/blob/zeus/meta-luneos/recipes-webos/luna-init/luna-init.bb#L2418:41
RPJaMa: is pseudo up to date with master in that build?18:41
JaMayes, it's oe-core b6d4150f9c74f25a4022a3fa0bd489a8e85deb7718:41
RPJaMa: I think with that do_install you're at the mercy of tar and the ownership of the files is not consistent18:42
JaMaI'm logging the paths with bb.warn in "except KeyError as e" and it looks like every unpacked file triggers it (actually twice, once in package and once in packages-split directory)18:43
RPJaMa: there are basically two things that may happen here. Either tar never sets the ownership "correctly" or it makes a syscall pseudo doesn't capture18:43
JaMais it using tar from host?18:44
RPJaMa: yes18:44
RPJaMa: I guess a quick cheap test is to try a different older tar binary?18:44
JaMaok, can compare 2 builders, the failing one is tar-1.29 from Ubuntu 18.04, the other one tar-1.30 from Ubuntu 19.1018:45
RPJaMa: I'd have expected the older one to work and the newer one to fail :(18:46
RPJaMa: still worth comparing. Are the uids of the build user different or the same?18:47
JaMadifferent, 3001 on failing one, 1000 on the ok, one and the error is about 1001: WARNING: luna-init-2.0.1-10+gitAUTOINC+9f0d2b6e31-r0 do_package: Cannot update hash with getpwuid or getgrgid for path ./packages-split/luna-init-fonts/usr/share/fonts/Prelude-Bold.ttf: 'getpwuid(): uid not found: 1001'18:48
yoctiNew news from stackoverflow: My other imx7d pico android things start kit died, again <https://stackoverflow.com/questions/58982265/my-other-imx7d-pico-android-things-start-kit-died-again>18:52
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ciwnunpypgelrabk> has joined #yocto18:54
RPJaMa: in the tarball what is the ownership of the files?18:56
JaMaRP: "select * from files where path like '%Prelude-Bold.ttf%'"18:59
JaMaon both builders look the same (1001 uid and gid)18:59
RPJaMa: I guess that is good and it means the python lookup isn't deterministic :/19:00
khemRP: the gnu hash stuff is complicated, and musl does not support it either, so I think its best course for us to stay as it is19:00
RPJaMa: they'll be different python versions?19:01
RPhost python19:01
RPkhem: ok, fair enough19:01
RPkhem: its a good one to watch/consider19:01
khemRP: I want to do some measurements before enabling it19:01
RPkhem: sounds sensible19:01
khemsince it can cause some maintainence burden, and lets not take it if its not worth it19:01
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-qlwsyfyluamvfhzp> has joined #yocto19:02
*** thannoy_ <thannoy_!~anthony@134-48-190-109.dsl.ovh.fr> has joined #yocto19:04
JaMaRP: 3.6.9 on failing, 3.7.5 working fine19:07
JaMaRP: roger/roger in the tarball which is 1001/1001 with --numeric-owner19:08
RPJaMa: Both should error, I don't know why they behave differently :/19:09
JaMatrying with explicit chown on the failing one now19:10
RPJaMa: could you add debug to sstatesig.py to see that the return values of the pwd.getpwuid() call are and the input values19:11
RPbeing py it shouldn't change sigs and rebuild19:11
*** armpit <armpit!~armpit@2601:202:4180:a5c0:3849:7200:d754:59fc> has quit IRC19:12
RPpython docs say it shouldn't be version specific19:12
JaMawith chown -R root:root.. it works fine, pseudo db showing 0:0 now19:13
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-dgnptywhtlmzxvek> has joined #yocto19:20
*** beratiks <beratiks!b0283dda@176.40.61.218> has joined #yocto19:20
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-hgypzpqdskxhcmqe> has joined #yocto19:28
Crofton|roadhttps://twitter.com/YoctoThe/status/1217166071519744000?s=2019:31
JaMaRP: is it possible that it doesn't have include_owners set on the working one? I've added bunch of bb.warns (like I did on the failing builder) and nothing is shown, let me add it before the include_owners case19:34
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto19:36
JaMadamn, sorry, it might be that this build directory on the failing one doesn't have hashserv enabled at all :/19:36
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-xvsuireibjifcxbx> has joined #yocto19:44
JaMaRP: now it's failing the same on both builders, I'm sorry for wasting your time19:46
RPJaMa: no problem, I know who hard these things can be to figure out19:48
JaMaRP: we might still improve the error message in these cases19:48
RPJaMa: yes, I quite like what I managed locally to improve the python 3.8 error failure19:49
JaMaI've checked last zeus build and the .ipk file really contains the files owned 1001:1001 and package-qa was fine with it (because it wasn't the same as builder's UID to trigger user-host-contamination)19:49
RPtry: <xxx> except Exception:             bb.warn(str(path))           raise19:49
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC19:50
RPJaMa: we really need to improve the package-qa check to check "all unknown users"19:50
JaMaI was using https://paste.ubuntu.com/p/t2hMCZH977/19:50
RPJaMa: might be worth a bug19:50
RPJaMa: With mine the benefit is it doesn't change behaviour, just shows more warning19:51
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-icfmwaskxccctbov> has joined #yocto19:51
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto19:51
LetoThe2ndRP: https://twitter.com/YoctoThe/status/121716851184551936119:51
yoctiNew news from stackoverflow: Trouble building u-boot for gumstix overo on yocto "thud" release <https://stackoverflow.com/questions/59093849/trouble-building-u-boot-for-gumstix-overo-on-yocto-thud-release>19:52
JaMaYes, that would be good, because now this error is triggered only with OEOuthashBasic and it might lead people to assume it's related to that19:52
JaMaI'll check the code in package-qa as I obviously have good test case for that19:53
RPJaMa: the hard part would be knowing which user ids are "bad". Current build user is easy, anything else is harder19:56
RPJaMa: I guess "exists in passwd in sysroot" is the right test?19:57
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-sezuirtplpeidujr> has joined #yocto19:58
JPEW`getent passwd | cut -f1 -d: | grep -q $USER` ?19:59
RPJPEW: sounds like a performance nightmare19:59
JPEWRP: Ya, I could see that19:59
* RP is only half joking19:59
*** berton_ <berton_!~berton@189.103.49.163> has joined #yocto20:01
*** davisr <davisr!~davisr@cpe-184-58-235-7.wi.res.rr.com> has joined #yocto20:02
JPEWrburton, RP: regarding YOCTO #13733, I've noticed that sometimes the non-reproducbility is in parts of ELF files that get discarded, but this changes (only) the NT_GNU_BUILD_ID.20:03
JPEWBest solution I've found is to disable stripping of ELF files in the reproducible build test so that you ca debug it20:04
*** berton <berton!~berton@189.103.49.163> has quit IRC20:04
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-hwzrmewrnprffogp> has joined #yocto20:05
khemRP: interestingly, GNU_HASH/without-prelink boots faster than sysv_has/with-prelink almost 15%20:06
frayHey we just ran into an sstate failure (zeus) where the filename was too long.  I know this has been seen before.. has zeus been patched for this (and my zeus is just too old?)20:08
frayGNU_HASH w/ prelink is what I test.  I'm not even sure sysv_hash + prelink actually works20:08
khemit works on mips20:10
khemfilename too long is host system problem20:11
khemare you using something like ecryptfs20:11
frayno..  the sstate filename is -really- long..20:11
frayit's the arch part that seems to have made it too long..20:12
frayI was looking in the oe-core archives, and I see some recent patches to address it, but havn't seen if they went in (yet)20:12
khemlonger than 255 ?20:12
frayyes20:12
fray25720:13
*** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto20:13
*** fullstop <fullstop!~fullstop@162.243.42.48> has quit IRC20:13
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC20:14
*** aidanh_ is now known as aidanh20:14
khemperhaps we should check for NAME_MAX and bail out20:14
frayRP's patch fro 1/5 looks like it will fix it..20:15
fray[OE-core] [PATCH 4/4] sstate: Handle sstate filenames longer than 255 characters20:15
dev1990if project have custom license, is it ok to use it like this LICENSE="${PN}" ?20:15
frayNo, you need to define the license with a specific name. 'proprietary' is one such name you can use20:16
*** fullstop <fullstop!~fullstop@162.243.42.48> has joined #yocto20:16
dev1990I have bunch of projects with custom licenses to deal with, they have custom licenses but they are all non-commercial20:17
dev1990example: https://github.com/libretro/fmsx-libretro/blob/master/LICENSE20:18
LetoThe2nddev1990: proprietary != commercial20:18
LetoThe2ndso fray++20:18
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-eehyaiqdtllqgykl> has joined #yocto20:19
*** berton__ <berton__!~berton@189.103.49.163> has joined #yocto20:20
khemfray: perhaps that patch could try to deduce the limits at runtime using getconf NAME_MAX $SSTATE_DIR20:22
frayThere is a section in the manual on settin the license field and including the license in your layer(s)20:23
*** berton_ <berton_!~berton@189.103.49.163> has quit IRC20:23
frayhttp://lists.openembedded.org/pipermail/openembedded-core/2020-January/290956.html20:23
fray+        limit = 25420:23
fray+    fn = spec + hash + "_" + taskname + extension20:24
fray+    if len(fn) > limit:20:24
fray+        avail = (254 - len(hash + "_" + taskname + extension) - len(components[0]) - len(components[1]) - len(components[5]) - len(components[6]) - 7) / 320:24
fraythen max for fields 2/3/4 are 'avail'20:24
fraythat should ensure it stays comfortably at or under 25420:24
frayI'll spend some time to check that on Zeus in a bit20:27
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-bcxdpfmjetkixgcz> has joined #yocto20:27
denixis there a bash-completion script available for opkg?20:31
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC20:31
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-wubjxxexfucabpjv> has joined #yocto20:34
sveinsebitbake is evaluating the entire dependency tree up front right? Are there any options to alter the behaviour of the sequencing of tasks, such as early as possible vs late as possible?20:34
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-phahabciwrimlarg> has joined #yocto20:41
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC20:42
*** fullstop <fullstop!~fullstop@162.243.42.48> has quit IRC20:44
angelo__need to produce u-boot.bin and u-boot-spl , on deploy images i find only the main u-boot, how can i produce also the spl ?20:44
LetoThe2ndangelo__: adjust u-boot configuration accordingly20:45
*** pohly <pohly!~pohly@p5B05600C.dip0.t-ipconnect.de> has quit IRC20:45
LetoThe2ndu-boot will build whatever its config it says.20:45
*** fullstop <fullstop!~fullstop@162.243.42.48> has joined #yocto20:45
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-bfhjxmoikdotohzz> has joined #yocto20:47
*** vmeson <vmeson!~rmacleod@128.224.252.2> has quit IRC20:47
angelo__LetoThe2nd, mm i have CONFIG_SPL in my config, but seems only one binary is generated20:51
LetoThe2ndangelo__: and if you build the config manually then it gets built?20:51
angelo__i build out of the tree with same config, it get built20:52
angelo__but i see now that the single u-boot produced is u-boot.imx20:53
angelo__so, there seems to b an issue with the make target20:53
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ucewoupobbwzjuha> has joined #yocto20:53
LetoThe2ndangelo__: time to inspect the logs, then.20:53
angelo__maybe is this20:54
angelo__UBOOT_MAKE_TARGET ?= "u-boot.imx"20:54
LetoThe2ndmaybe.20:56
angelo__LetoThe2nd, there will be any Yocto stand at fosdem ?20:57
LetoThe2ndangelo__: OpenEmbedded is there20:57
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC20:57
LetoThe2ndsee also https://www.linkedin.com/posts/openembedded_fosdem-fosdem20-openembedded-activity-6622864179256705024-OTAJ20:57
denixangelo__: define SPL_BINARY20:58
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC21:05
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ehqcuwmwprmosvww> has joined #yocto21:08
angelo__LetoThe2nd, cool, will probably buy a ticket21:08
angelo__LetoThe2nd, you will be there ?21:08
angelo__denix, thanks, trying21:08
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC21:10
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto21:10
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-wclsdrbxoybmzxyy> has joined #yocto21:14
*** Linus_SWE <Linus_SWE!d58e1c30@h213-142-28-48.cust.a3fiber.se> has joined #yocto21:14
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC21:16
Linus_SWEHi! Im trying to find out how to remove busybox and replace it with coreutils on my build but Im failing miserably. Any hints? :)21:22
yoctiNew news from stackoverflow: How do you properly build gpiod applications from Yocto? <https://stackoverflow.com/questions/59741817/how-do-you-properly-build-gpiod-applications-from-yocto>21:22
RPsveinse: you can change bitbake's scheduler, its plugable21:25
RPsveinse: rmwork enabled a different one for example21:25
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-tjdgaayaqxcuiqla> has joined #yocto21:26
*** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto21:29
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto21:30
roussinmautoconf-archive fails to the configuration step, because it finds python through my pyenv configuration... that is weird.21:33
*** armpit <armpit!~armpit@45.19.219.178> has joined #yocto21:36
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has joined #yocto21:37
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-tsirfhsgmggpzryt> has joined #yocto21:40
*** Linus_SWE <Linus_SWE!d58e1c30@h213-142-28-48.cust.a3fiber.se> has quit IRC21:44
*** dqx <dqx!~dqx@unaffiliated/dqx> has joined #yocto21:49
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-pbzajjfrcufmwqdj> has joined #yocto21:51
RPJPEW: Are your slides from the San Diego devday somewhere I can link to?21:52
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto21:53
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-detceyyvfyvbmjto> has joined #yocto22:03
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC22:07
JPEWRp: https://docs.google.com/presentation/d/1IzFlI8n8B49HkHiQClO6OoE_mugvK52Zoarx9BRimiY/edit?usp=sharing22:08
RPJPEW: can I put that on the wiki?22:09
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-irxmlnasxcrvazze> has joined #yocto22:09
JPEWPlease do22:09
RPJPEW: thanks22:09
dev1990I found funny thing, please look at this22:09
dev1990https://github.com/RetroPie/RetroPie-Setup/tree/master/scriptmodules/libretrocores22:09
dev1990seems familiar?22:10
RPdev1990: not to me...22:12
*** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has quit IRC22:13
dev1990I don't get it, they are working so hard on something that could be a Yocto from the beginning22:14
dev1990Yocto layer I mean22:15
RPdev1990: oh, I see. I've seen that happen before :/22:16
khemRP: is there space for running another glibc run ?22:16
RPkhem: its busy doing a build from scratch but there probably is overnight22:17
khemI have a fix for prelink, which I want to see if is working22:17
RPkhem: does it only affect mips?22:17
RPkhem: I could just run the failing mips builds if so22:18
khemRP: the fix is mips specific but applies to common srcs22:18
khemof prelink22:18
RPkhem: so we should build everything? or just need to test mips atm ?22:18
khemGNU hash is pretty fast22:18
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC22:18
khemI think mips will benefit from it, I will disable it for musl/mips and enable it for glibc/mips22:19
RPkhem: ok22:19
RPkhem: do you have a poky branch with the change in? If so we can just run it on the AB and queue after the current build22:19
RPI can point it at your branch22:19
khemmusl will eventually get it done too but they are not happy with glib's approach, so it might be a while22:19
khemRP: I will push this into kraj/glibc-2.3122:20
khemlet me do that22:20
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-hslhzdxojcsvanej> has joined #yocto22:22
*** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto22:25
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ttcvsxuvvbplpwks> has joined #yocto22:28
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC22:33
*** beratiks <beratiks!b0283dda@176.40.61.218> has quit IRC22:33
khemRP: try https://git.yoctoproject.org/clean/cgit.cgi/poky-contrib/log/?h=kraj/glibc-2.3122:34
khemRP: perhaps just run mips/core-image-sato-sdk for starts22:35
* zeddii calls it a day of boot testing on 5.4. sato and kernel-dev tomorrow. then I'm pretty well covered22:35
RPzeddii: btw, I think there are fixes for meta-intel which will stop the autobuilder throwing warnings22:36
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-gvivtrrjkdhvwhwq> has joined #yocto22:36
*** hpsy <hpsy!~hpsy@85.203.15.14> has joined #yocto22:37
RPkhem: https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/1447  https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/206 https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/144522:37
zeddiiyah. I have most of them queued here, but they are on top of other 5.4 changes that I have, so I need to test a bit more.22:37
RPzeddii: ok, cool. Just keen to get rid of one of the last warnings on the AB22:38
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC22:40
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto22:42
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ulkfftatrolnmkxp> has joined #yocto22:43
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC22:46
khemRP: cool, I opened them in browser lets hope for green22:47
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ozodbkxluzjtcxnr> has joined #yocto22:48
khemRP: I think we need https://patchwork.openembedded.org/patch/168929/ along with rest gst/meson conversion patch22:49
khemthere are several layers which have to adopt to meson changes for gst as well22:49
RPkhem: right, will add in the next round of testing22:49
khemok22:49
*** JaMa <JaMa!~martin@109.238.218.228> has quit IRC22:52
khemRP: nfsroot with qemu is quite helpful in debugging the  low level stuff like ldso22:52
RPkhem: needs better documentation! :)22:52
khemRP: I think when you have prelinked rootfs and want to unprelink just one file and rootfs is not booting22:54
khemsuch situations while not common are very hard to debug otherwise22:54
RPkhem: yes, early init can be fun...22:55
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ujpqfwlzmxzzypnl> has joined #yocto22:55
khemespecially a borked ldso :)22:55
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC23:02
frayya, broken ldso sucks.. REALLY a pain to debug23:02
fraywhat bugs me is the error is usually "No such file or directory".. but it doesn't tell you it's the ldso (or what the ldso was trying to load).. just a completely nebulous error.23:03
*** agust <agust!~agust@p508B64CC.dip0.t-ipconnect.de> has quit IRC23:06
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-jmqgtmuxquautynt> has joined #yocto23:07
*** nacknick <nacknick!b9b8f483@185.184.244.131> has quit IRC23:14
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto23:16
*** florian_kc is now known as florian23:19
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-kuyuzongdxqgjvkt> has joined #yocto23:20
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto23:20
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-fueusutovoluxukr> has joined #yocto23:27
khemKernighan law rightly states - debugging is twice as hard as writing the code in the first place23:32
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-yklffwjnzdicmdqg> has joined #yocto23:32
RPkhem: unless its bitbake hashequiv :)23:38
khemhmm heh23:38
khemRP: core-image-sato-sdk is booting here fine on qemumips now23:39
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC23:39
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto23:40
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-lakuidaajunudyzu> has joined #yocto23:46
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC23:52
*** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-azwphkpsqiemruhy> has joined #yocto23:59

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!