Wednesday, 2021-02-24

RPJPEW: np. I just don't know why diffoscope continues to take so long :/00:06
*** aleblanc <aleblanc!> has quit IRC00:07
*** Guest16229 <Guest16229!> has quit IRC00:18
*** richbridger <richbridger!> has quit IRC00:39
*** kiwi_29 <kiwi_29!> has quit IRC00:40
*** linums <linums!> has quit IRC00:40
*** kiwi_29 <kiwi_29!> has joined #yocto00:41
*** alicef is now known as AliceBot00:47
*** AliceBot is now known as AlicefBot00:48
*** bluelightning_ is now known as bluelightning00:49
*** AlicefBot is now known as alicef00:49
*** paulg <paulg!> has quit IRC00:51
*** tlwoerner_ <tlwoerner_!> has joined #yocto00:51
*** paulg <paulg!> has joined #yocto00:51
*** tlwoerner <tlwoerner!~tlwoerner@unaffiliated/tlwoerner> has quit IRC00:52
*** manuel1985 <manuel1985!> has quit IRC00:53
kiwi_29Hello ... I am using package_deb, packge_feed_uris and package-management in my conf file as I am hosting a deb repo on remote server.  This generates a sources.list. with.  deb http://<URL>/all  ./       How do I generate. sources.list with deb http://<URL>/all yocto main    where yocto is the name of distribution and main is name of component01:12
*** dev1990 <dev1990!> has quit IRC01:14
*** goliath <goliath!> has quit IRC01:15
*** linums <linums!> has joined #yocto01:20
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:47c4:89ec:8e68:7431> has quit IRC01:23
*** linums <linums!> has quit IRC01:24
*** vineela <vineela!~vtummala@> has quit IRC01:33
*** kpo <kpo!> has quit IRC01:33
*** kpo <kpo!> has joined #yocto01:34
*** linums <linums!> has joined #yocto01:56
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has quit IRC02:16
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has joined #yocto02:17
*** vmeson <vmeson!> has quit IRC02:27
*** beneth` <beneth`!> has left #yocto02:40
*** tlwoerner_ <tlwoerner_!> has quit IRC02:52
*** tlwoerner <tlwoerner!~tlwoerner@unaffiliated/tlwoerner> has joined #yocto02:52
*** behanw <behanw!uid110099@gateway/web/> has quit IRC02:52
*** ahadi <ahadi!~ahadi@> has quit IRC03:03
*** ahadi <ahadi!> has joined #yocto03:05
yatesvdl: i understand. it just sounded like you were saying you didn't need any bootloader for the x86. you do, just not one you compile within the bsp (as you stated).03:10
yatesirc is not always the best way to communicate... :)03:10
yatesvdl et al.: thank you for the information03:10
yatespardon me if i've asked this recently, and this is not necessarily a yocto question, but which component of a linux build provides the cross toolchain?03:20
yatesmore specifically, as i understand it, the binutils has to be ported to the processor architecture for which the build is constructed. how is this provided?03:21
*** beneth` <beneth`!> has joined #yocto03:23
*** mranostaj <mranostaj!~mranostaj@pdpc/supporter/active/mranostay> has quit IRC03:26
*** sakoman <sakoman!> has quit IRC03:28
*** sbach <sbach!~sbachmatr@> has quit IRC03:57
*** sbach <sbach!~sbachmatr@> has joined #yocto03:57
*** kiwi_29 <kiwi_29!> has quit IRC03:59
*** kiwi_29 <kiwi_29!> has joined #yocto04:01
*** ahadi <ahadi!> has quit IRC04:01
*** ahadi <ahadi!~ahadi@> has joined #yocto04:04
khemyates:  cross toolchain consists of several components but you need a cross-gcc and cross-binutils at the least to bootstrap04:08
khemyou will see binutils-cross and gcc-cross recipes in metadata those will be of interest04:09
khembut since bootstrapping cross toolchains is a bit of voodoo there are some intermediate steps to achieve a fully functional cross toolchain, if you want to learn more look at gcc/ binutils/ linux-libc-headers/ glibc related recipes04:10
*** pankaj347 <pankaj347!7aa678a8@> has joined #yocto04:52
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto04:52
*** f3ddischson <f3ddischson!> has joined #yocto04:58
*** plntyk <plntyk!> has left #yocto04:59
*** plntyk <plntyk!> has joined #yocto05:00
*** linums <linums!> has quit IRC05:07
*** linums <linums!> has joined #yocto05:10
*** linums <linums!> has quit IRC05:20
*** linums <linums!~linums@> has joined #yocto05:20
*** linums <linums!~linums@> has quit IRC05:25
*** linums <linums!~linums@> has joined #yocto05:25
*** pankaj347 <pankaj347!7aa678a8@> has quit IRC05:33
*** alessioigor <alessioigor!> has joined #yocto05:33
*** linums <linums!~linums@> has quit IRC05:36
*** linums <linums!~linums@> has joined #yocto05:37
*** pankaj347 <pankaj347!7aa678a8@> has joined #yocto05:49
*** ctlnwr__ <ctlnwr__!~catalin@> has left #yocto06:10
*** pankaj347 <pankaj347!7aa678a8@> has quit IRC06:14
*** pankaj347 <pankaj347!7aa678a8@> has joined #yocto06:27
*** AndersD <AndersD!> has joined #yocto06:33
*** camus <camus!~Instantbi@> has joined #yocto06:36
*** kaspter <kaspter!~Instantbi@> has quit IRC06:36
*** camus is now known as kaspter06:36
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC06:38
*** beneth` <beneth`!> has left #yocto06:38
*** jobroe <jobroe!> has joined #yocto06:38
*** minimaxwell <minimaxwell!> has joined #yocto06:43
*** pankaj347 <pankaj347!7aa678a8@> has quit IRC06:44
*** w00die_ <w00die_!~w00die@> has quit IRC06:48
*** w00die_ <w00die_!~w00die@> has joined #yocto06:50
*** risca <risca!~quassel@> has quit IRC06:53
*** pankaj347 <pankaj347!7aa678a8@> has joined #yocto06:58
*** risca <risca!~quassel@> has joined #yocto06:58
*** rcoote <rcoote!> has joined #yocto07:01
*** kiwi_29 <kiwi_29!> has quit IRC07:06
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:13
*** goliath <goliath!> has joined #yocto07:19
*** agust <agust!> has joined #yocto07:22
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:cc0b:cf31:a49c:b4df> has quit IRC07:28
*** frsc <frsc!> has joined #yocto07:41
*** xtron <xtron!~xtron@> has joined #yocto07:47
*** pankaj347 <pankaj347!7aa678a8@> has quit IRC07:48
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto07:54
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:54
*** xtron <xtron!~xtron@> has quit IRC07:57
*** fl0v0 <fl0v0!> has joined #yocto07:57
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC07:58
*** pcglue <pcglue!> has quit IRC08:01
*** pankaj347 <pankaj347!0e62b3fe@> has joined #yocto08:01
*** mckoan|away is now known as mckoan08:02
mckoangood morning08:02
LetoThe2ndyo mckoan and rest of dudX08:02
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:b7bd:1d78:9a4c:6909> has joined #yocto08:05
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto08:06
*** kpo__ <kpo__!> has quit IRC08:10
*** beneth` <beneth`!> has joined #yocto08:11
*** minimaxwell <minimaxwell!> has quit IRC08:20
*** manuel1985 <manuel1985!> has joined #yocto08:28
*** dev1990 <dev1990!> has joined #yocto08:28
*** minimaxwell <minimaxwell!> has joined #yocto08:47
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:47
*** kiwi_29 <kiwi_29!> has joined #yocto08:56
*** kiwi_29 <kiwi_29!> has quit IRC09:01
*** Ad0 <Ad0!~Ad0@> has quit IRC09:21
*** Ad0 <Ad0!~Ad0@> has joined #yocto09:26
*** grma <grma!~gruberm@> has quit IRC09:28
*** gillesm <gillesm!> has quit IRC09:32
*** gillesm <gillesm!> has joined #yocto09:33
*** oberstet <oberstet!~oberstet@> has joined #yocto09:43
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC09:49
pankaj347i want to add mkisofs with image how i can add this into image ?09:54
*** pankaj34756 <pankaj34756!0e62b3fe@> has joined #yocto10:01
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto10:02
*** pankaj347 <pankaj347!0e62b3fe@> has quit IRC10:05
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC10:05
qschulzpankaj34756: IIUC, it's [part of cdrtools, but we only have a native recipe available10:05
qschulzso you probably need to create one yourself10:06
qschulzdon't know if cross-compilation is supported, but you'll discover by yourself :)10:06
pankaj34756qschulz ok..thanks10:06
*** grma <grma!~gruberm@> has joined #yocto10:07
*** yannholo <yannholo!> has joined #yocto10:09
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto10:16
*** risca <risca!~quassel@> has quit IRC10:35
*** risca <risca!~quassel@> has joined #yocto10:35
*** risca <risca!~quassel@> has quit IRC10:38
*** risca <risca!~quassel@> has joined #yocto10:40
*** kiwi_29 <kiwi_29!> has joined #yocto11:01
*** darknighte <darknighte!sid214177@pdpc/supporter/professional/darknighte> has quit IRC11:03
*** kiwi_29 <kiwi_29!> has quit IRC11:05
rburtonRP: diffoscope is *so slow*.  I had to diff two 1gb trees and after six hours I gave up11:26
RPrburton: with master? its hanging for me atm11:26
rburtonoh, outside of OE11:27
RPI was able to reproduce the hangs quite quickly by adding to meta/lib/oeqa/selftest/cases/diffoscope/A and it's counterpart to B, then oe-selftest -r reproducible.DiffoscopeTests.test_diffoscope11:27
LetoThe2ndrburton: you need moar power11:27
rburtonLetoThe2nd: its not multithreaded so adding more power doesn't really help11:27
RPrburton: did you see that arm worker build hang? I had to stop it to unblock all the jobs :/11:27
rburtonLetoThe2nd: there must be some bad algorithms as these two 1gb trees were identical apart from ~10 files11:28
*** mseeber <mseeber!~mseeber@2a02:2450:1159:680:464d:d23b:600a:b6a3> has joined #yocto11:28
LetoThe2ndrburton: more is always more:
RPrburton: I ended up separating the packages I wanted to diff and running it in parallel11:28
rburtonRP: the doomed worker or the other worker?11:28
RPrburton: other one11:29
RPrburton: jon delegated to you last night11:30
rburtonthanks jonmason!11:32
rburtonwe need to get the AB an Altra so the arm builders stop hitting all the timeouts due to being slow11:32
RPrburton: that would be nice11:33
RPrburton: were you using html output or not? That is what seems to hang diffoscope11:33
rburtonAh, really11:33
rburtonYes, I was11:33
RPrburton: which version out of interest?11:33
rburtonSome O(N^N) stupidity in the html output?11:33
rburtonerm, latest a few weeks ago11:33
rburtonso that hanging job actually finished all the bitbake work11:34
rburtonbut bitbake didn't actually quit11:35
RPrburton: how did you determine that?11:38
rburtonNOTE: recipe core-image-sato-1.0-r0: task do_testsdkext: Succeeded11:39
rburtonBitbake still alive (5000s)11:39
rburtonhm hang on no11:40
RPrburton: NOTE: recipe core-image-minimal-1.0-r0: task do_testsdkext: Started never finishes11:42
RPrburton: stop blaming poor bitbake11:42
rburtonstill blaming bitbake :)11:42
rburtonbit annoying that the logs are just merged11:43
rburtonwhen do we get per-task logs in the buildbot11:43
*** iokill <iokill!> has quit IRC11:44
RPrburton: when you implement it. I was happy just to get per invocation with nice naming ;-)11:49
*** iokill <iokill!> has joined #yocto11:50
*** rubdos <rubdos!~rubdos@> has quit IRC11:51
RPstrace: [ Process PID=15408 runs in x32 mode. ] - should diffoscope-native/python3-native really be doing that11:52
rburtonwait what11:54
rburtonthats terrifying if true11:54
RPrburton: I don't believe it but that is what it says11:55
rburtonsurely file on the binary can tell you11:56
RPpython3-native/python3.9: ELF 64-bit LSB shared object11:56
RPso what is strace on about?11:56
rburtonso googles suggests that x32 detection is a heuristic and can be wrong11:57
RPrburton: ah. its a weird world. gdb is now spewing warnings due to a glibc version it doesn't understand11:59
yateslast night i was asking: more specifically, as i understand it, the binutils has to be ported to the processor architecture for which the build is constructed. how is this provided?12:03
yateskhem: i saw your response last night but i'm still confused (a common situation)12:04
yatesthe question above was preceded by this question: pardon me if i've asked this recently, and this is not necessarily a yocto question, but which component of a linux build provides the cross toolchain?12:04
yatesso khem the basic question is this: does the cross-binutils first have to be created (copied/stolen from other projects), then provided to yocto, or is there a way somehow for  yocto to build it?12:05
yatesthe problem is that we won't have a prebuilt cross-toolchain for our processor arch. it is custom12:07
*** Crofton|cloud <Crofton|cloud!sid401373@gateway/web/> has quit IRC12:10
*** Crofton|cloud <Crofton|cloud!sid401373@gateway/web/> has joined #yocto12:10
paulbarkeryates: When you say "custom", is that a fully custom ISA or built around an existing common ISA?12:11
yatesfully custom ISA12:18
paulbarkeryates: You'll need to port binutils, gcc, etc. Expect to put a couple of person-years of work in if the ISA customisations are non-trivial12:21
*** xroumegue <xroumegue!~roumegue@2a01:cb1d:3f5:3900:fd88:2eb2:8463:8658> has quit IRC12:21
paulbarkerTypically in Yocto Project we build cross-binutils from source but obviously the binutils source needs to include support for the ISA you're targetting12:23
yatespaulbarker: exceellent info. thank you.12:24
RPtouch usr/lib/rpm/rpmrc "fixes" the diffoscope hang12:28
*** berton <berton!> has joined #yocto12:29
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto12:31
*** mckoan is now known as mckoan|away12:32
*** minimaxwell <minimaxwell!> has quit IRC12:41
*** minimaxwell <minimaxwell!> has joined #yocto12:41
*** minimaxwell <minimaxwell!> has joined #yocto12:42
RPdl9pf: retesting master-next, hopefully the hang is partly addressed and we have the font issue. I've opened an upstream bug for the diffoscope html hang12:49
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto12:52
fl0v0Hi, i want to create a extra image for the boot partition of a a raspberrypi. The files are packed by wic and wic creates the FAT image in "${WORKDIR}/build-wic" (of the image recipe), but i need to have an extra image recipe, that deploys the files as a tar.xz12:57
fl0v0Is there any clever way to do this?  I tried to strip an image created by image.bbclass but it feels like its too complicated.12:57
*** Konsgn <Konsgn!> has joined #yocto13:10
*** Konsgn <Konsgn!~Konsgnx3@unafiliated/joyseph> has joined #yocto13:10
*** bradfa <bradfa!sid297668@gateway/web/> has quit IRC13:16
*** bradfa <bradfa!sid297668@gateway/web/> has joined #yocto13:16
qschulzfl0v0: you don't need an extra image recipe, you need an extra image type (IMAGE_FSTYPES IIRC)13:18
fl0v0qschulz: thanks will look more into the image_types.bbclass then?13:19
SaurI'm getting a bunch of "WARNING: SOURCE_DATE_EPOCH value from sstate '0' is deprecated/invalid. Reverting to SOURCE_DATE_EPOCH_FALLBACK '1302044400'" when I build with current master, but there is no indication what recipe are causing them. Will they go away by themselves, or is there something I can do to get rid of them?13:35
KonsgnIs there a means to have multiple seperate layers in a single repository? I see the combo-layer feature, but what I want to do is have a repository that has direct folders of repo/meta-foo, repo/meta-bar and so on.13:38
SaurKonsgn: meta-openembedded does this.13:43
Konsgnthanks for that! looks like it's really simple to do13:45
JPEWRP: huh... interesting. Should that file be packaged by
*** mbulut <mbulut!> has joined #yocto13:48
*** sakoman <sakoman!> has joined #yocto13:59
*** creich <creich!> has quit IRC14:04
JPEWRP: Ok, finally looking at the SDE stuff14:14
kayterinawhat kind of recipe I put in build/workspace with devtool add and when in a meta-layer/recipes-kati/
*** falk0n <falk0n!> has joined #yocto14:28
*** vmeson <vmeson!> has joined #yocto14:33
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:42
dl9pfSaur: this is in master/master-next. it is expected, but no action should be required.15:01
Saurdl9pf: Ok, so I guess those messages will go away after things are rebuilt?15:02
qschulzkayterina: I'm sorry but I do not understand your question, can you rephrase?15:03
dl9pfSaur: should go away over time.15:05
kayterinaa,yes.I have my bash scripts and systemd services to put in an image. I did devtool add <my-local-git> and it adds a recipe inside build/workspace. Alternatively, I can make a meta-mylayer and put in there the recipe by hand15:08
kayterina * a,yes.I have my bash scripts and systemd services I want to put in an image. I did devtool add <my-local-git> and it adds a recipe inside build/workspace. Alternatively, I can make a meta-mylayer and put in there the recipe by hand15:08
qschulzkayterina: devtool is a development tool, ultimately, you want your recipes in your layer and not devtool workspace15:11
qschulzdevtool finish does that for you IIRC15:11
*** dleppich <dleppich!~Thunderbi@> has quit IRC15:12
*** dleppich <dleppich!~Thunderbi@> has joined #yocto15:14
RPJPEW: it is packaged, it wasn't relocating correctly. I've adjusted the wrapper and that is fixed. With SDE I concluded we had to bump the hashequiv version15:36
JPEWRP: Ok15:43
RPSaur: using hashequiv or not? We should have forced everything to rebuild15:43
JPEWRP: I have a sort of cleanup patch we can try (or at least discuss)15:43
JPEWWill post it in a minutes15:43
SaurRP: Hashequiv is on, using the server started by bitbake automatically.15:43
RPJPEW: ok, thanks15:44
RPSaur: do you set your own hashequiv_version ?15:44
SaurRP: No, not that I know.15:44
RPSaur: then I don't quite understand what happened and why you'd see it. I suppose they might self heal as tasks run15:45
RP(it may need to run do_fetch/unpack on an existing build with SDE=0 before it resets it15:45
JPEWYa, that's part of the reason the SDE is exlcuded from task hashes... it's not stable before do_unpack15:47
dl9pfand we might not want to invalidate all existing ... just for the fix away from SDE=0 ...15:48
RPdl9pf: well, I gave in and did15:49
JPEWRP, dl9pf: Sent an RFC patch for discussion15:51
*** armpit <armpit!~armpit@2601:202:4180:a5c0:8cb5:e0e1:ba5f:6619> has quit IRC15:51
JPEWI think we could also add something like: do_configure[vardeps] += "SOURCE_DATE_EPOCH_DEP" which would make all do_configure and beyond re-run when SDE changes15:52
RPJPEW: at a quick glance, I don't think that buys us anything at this point.15:52
RPJPEW: I also really do want the disk SDE to match the variable, its confusing otherwise15:52
*** armpit <armpit!~armpit@2601:202:4180:a5c0:ec25:e174:9590:a68b> has joined #yocto15:52
RPJPEW: and you can't make SOURCE_DATE_EPOCH_DEP work that like as you can't calculate that in advance15:53
JPEWErr, which part?15:54
RPdl9pf, JPEW: How about we unset SOURCE_DATE_EPOCH for fetch/unpack/patch tasks?15:54
JPEWRP: Ya.... I was trying to avoid having to list "all the tasks that might run before do_unpack" :/15:55
RPJPEW: when bitbake parses the metadata we compute the task hashes. You can't know at that point the value SDE will take15:55
SaurHmm, where does that tarball created by uninative-tarball end up?15:56
RPJPEW: well, it is cosmetic and avoids warnings15:56
RPSaur: TMPDIR/sysroots-uninative15:56
JPEW^^ which is cosmetic?15:56
RPJPEW: clearing SDE for fetch/unpack/patch15:56
*** AndersD <AndersD!> has quit IRC15:58
JPEWHmm, do we need the warning anymore?15:58
SaurRP: I don't seem to have that dir. Is it enough to run `bitbake uninative-tarball` or is there some more magic involved?15:58
*** rcoote <rcoote!> has quit IRC15:59
RPSaur: that definitely won't help. The build either inserts it up front or does not15:59
SaurRP: Huh?16:00
RPJPEW: it is useful to have when things go wrong16:00
RPSaur: uninative is downloaded at the start of a build and extracted/installed before tasks run16:00
SaurRP: I know. I'm trying to rebuild the tarball since I want to add to it.16:01
RPSaur: oh, right, then yes you just build it16:02
RPSaur: sorry, I though you meant "where does it end up when installed", not "where does it end up when built"16:02
SaurRP: Right, it's the latter I'm looking for...16:03
RPSaur: deploy/sdk16:03
SaurAh, thank you. :)16:03
RPJPEW: I think if you try your patch with the sstatesig tests it will fail if you want an example of how it would break16:17
* RP notes the last reproducibility tests didn't hang but failed properly :)16:17
RPdl9pf: if we can figure out the font issue we should be good to enable16:17
vdlRP: do you expect both the committer and author to sign the patch off, or the committer alone suffices?16:19
*** sakoman1 <sakoman1!> has joined #yocto16:20
*** sakoman <sakoman!> has quit IRC16:20
RPvdl: how are you defining committer ?16:20
*** sakoman1 <sakoman1!> has quit IRC16:20
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC16:20
*** sakoman <sakoman!> has joined #yocto16:20
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto16:21
vdlRP: I tried to be smart but keeping my personal address to submit the patch (hence the committer) but still use my company email for the author. Then I ask myself should my committer address, author address, or both sign off the patch.16:22
RPvdl: usually the signoff would match the author for this case16:23
vdlIt looks like a grey area, especially when both committer and author point to the same person16:23
vdlRP: ok.16:23
fraydepending on circumstance, I do one or both myself.. depends on where I'm working on the patch and in what context..16:24
vdlRP: you're correct in fact because the committer is dropped anyway when sending a patch via email, only the author and the project maintainer applying the patch (you) remain.16:25
frayif it's in my 100% open source role, I do it on my personal.  If it's my 100% work role.. work..  if it's a mix, sometimes I end up signing off with both..16:25
fray(the both is when I'm playing author [work] and maintainer [open source])16:25
vdlfrom an history point of view, only the author address matters. From the submitted step point of view, that's a different topic but the information will be lost anyway (which is kinda bad).16:26
vdlfray: that's my case indeed, authored from work, but submitted on my own, not a company task.16:27
vdlgit commit --signoff's documentation only states the committer, but it might not be accurate depending on the project.16:28
*** pankaj34756 <pankaj34756!0e62b3fe@> has quit IRC16:33
frayvdl ya, usually when I do that I sign off on both accounts.. since the first is the authorship and I had permissiont o release this.. the second is I have permission to submit this for inclusion..16:34
frayit's a very gray area, but I try to be consistent for my own commits16:34
vdlfray: what you just describe is specific to the agreement terms, but I get the idea.16:35
vdlproblem is there's no clear distinction in Git yet for the downstream integrator/submitter, who might be different from the author. This guy is lost in the process and replaced with the upstream integrator/committer.16:36
tlwoernerfriendly reminder: OEHH is today in 4h 20min (
vdlfray: The only downside is having to commit --amend --author=<other address> --signoff every times, but we like well done patches, don't we ;)16:43
RPvdl: if you want the information preserved, you can add both signed-off-by lines16:43
RPvdl: if someone handles the patch in some meaningful way, the practise is to add that signed-off-by16:43
RPvdl: the signed-off-by has a very specific meaning about what you're saying about the patch contents and its origin/license16:44
vdlthus hardly bound to the author rather than the submitter I presume16:45
vdlso having the author SoB is usually the default16:46
frayYa.. I consider handing it to myself (as an external participant) as meaningful in many cases.. so thats when I do it16:48
RPvdl: right16:50
vdltrue. If the company explicitly agreed to submit patches upstream, adding your personal address as the committer isn't necessary anymore I'd say16:50
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto16:53
*** wooloomooloo <wooloomooloo!> has joined #yocto17:00
wooloomoolooGood afternoon everyone. I have a question regarding the use of ALTERNATIVE_PRIORITY.17:02
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto17:02
wooloomoolooCan I specify the priority in an image recipe? I have two psplash packages and would like to set the priority for either of them depending on the image.17:03
wooloomoolooThey way it is now, both packages are already installed, but the priority is the same.17:04
qschulzwooloomooloo: recipe data is local so no, you can't from another recipe (image recipe) change another recipe's data (psplash)17:06
qschulzyou can do logic on your final rootfs in your image recipe though17:06
smurrayone perhaps messy approach would be a rootfs or image postprocess command to tweak the alternative file17:07
smurrayanother approach would be a firstboot script to call update-alternatives to flip it17:09
wooloomooloosmurray the prostprocessing is what I had in mind at first, but I was looking for a clearer way.17:10
smurraywooloomooloo: another approach that is a bit more complicated would be to use multiconfig, with one config for each target image, overriding the package's ALTERNATIVE_PRIORITY as required17:13
*** falk0n <falk0n!> has quit IRC17:13
smurraywooloomooloo: it's perhaps overkill for this, but it'd work.  In theory, just that one package would get rebuilt for the second multiconfig17:14
*** falk0n <falk0n!> has joined #yocto17:14
wooloomoolooFor psplash specifically, where would the priorities be set? If I have two or more splash screen packages, is the only place to set the priorities the bbappend itself?17:14
RPlsg: I've dropped khem's go patches and the ffmpeg ptest patch from -next17:15
RPlsg: the cancelled reproducible failures are handled by changes in -next17:15
smurraywooloomooloo: or in local.conf with ALTERNATIVE_PRIORITY_pn-splash = "X"17:15
*** fl0v0 <fl0v0!> has quit IRC17:16
wooloomoolooAh. I was hoping to avoid using local.conf, since that's not under version control.17:17
lsgRP ok thanks for the info.17:19
smurraywooloomooloo: there are options there, you could have your own local.conf.template in your product layer17:22
*** falk0n <falk0n!> has quit IRC17:22
smurraywooloomooloo: or if you use a tool like kas, add the variable to the yaml definition for the build17:22
*** falk0n <falk0n!> has joined #yocto17:23
wooloomooloosmurray thanks for the pointers. I'll try using the rootfs postprocessing feature.17:28
smurraywooloomooloo: okay, good luck17:29
*** vdehors <vdehors!> has quit IRC17:32
*** jobroe <jobroe!> has quit IRC17:37
vdlAre recommended packages intended to be installed from an image recipe with IMAGE_INSTALL_append = " ${RRECOMMENDS_systemd}"?17:38
vdl(systemd being an example)17:38
khemRP:  what issues are you seeing with go patches ?17:39
*** vineela <vineela!vtummala@nat/intel/x-cglrwhhheqxfitgq> has joined #yocto17:39
*** jobroe <jobroe!> has joined #yocto17:40
RPkhem: I was trying to defer this to Leo ;-). oe-selftest fails: lib32 world fails:
*** kpo <kpo!> has quit IRC17:43
*** linums <linums!~linums@> has quit IRC17:44
*** kpo <kpo!> has joined #yocto17:44
*** linums <linums!~linums@> has joined #yocto17:44
khemRP: is being built as part of gotoolchain.oeGoToolchainSelfTest.test_go_dep_build. and that repo is deprecated and archived perhaps we should build something else instead. Ironically go-dep was replaced with go mod so I am expecting it to not build17:47
smurrayvdl: RRECOMENDS packages will be pulled into images automatically unless that's disabled by setting NO_RECOMMENDATIONS, or a package is listed in BAD_RECOMMENDATIONS17:47
vdlsmurray: is it the default behavior even for poky-less distros?17:48
RPkhem: I'm open to patches to update it to whatever makes sense with the new approach17:49
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC17:50
smurrayvdl: AFAIK, yes.  See
smurrayvdl: I tend to not use deb packaging, so I'm not sure if the caveat there means that recommended packages will just always be installed with deb, but that would be my guess17:53
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto17:56
jordemortanybody else seeing what looks like weird base64 spam over in #poky or has matrix gone off the wagon for me?17:57
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC17:57
*** frsc <frsc!> has quit IRC17:58
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto17:58
vdlsmurray: thank you. Unrelated question, would you append systemd-container in the distro conf or the image recipe?17:58
khemRP:  I see that we can perhaps fix the test case itself to not use old way of building and still keep building dep as module17:58
khemwhats the cmd to reproduce it17:59
*** yannholo <yannholo!> has quit IRC17:59
khemoe-selftest -r gotoolchain.oeGoToolchainSelfTest.test_go_dep_build18:00
RPkhem: oe-selftest -r gotoolchain.oeGoToolchainSelfTest.test_go_dep_build18:00
khemwill that dp ?18:00
khemoh ok :)18:00
smurrayvdl: to add it to an image, you mean?18:01
*** champagneg <champagneg!> has quit IRC18:01
vdlsmurray: yes18:02
*** w00die_ <w00die_!~w00die@> has quit IRC18:02
smurrayvdl: definitely not in the distro conf ;)18:02
*** champagneg <champagneg!> has joined #yocto18:03
*** kpo__ <kpo__!> has joined #yocto18:03
vdlsmurray: if felt legit to add it to the distro conf if your writing a host distro to manage containers18:03
*** w00die_ <w00die_!~w00die@> has joined #yocto18:04
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC18:05
smurrayvdl: nothing stops you from doing it, but it's not recommended practice to tweak IMAGE_INSTALL or related variables in the distro conf18:05
vdlsmurray: in this use case (a distro managing containers), what is the recommended practice? Adding some sorts of suggested/recommended?18:06
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto18:07
*** zkrx <zkrx!> has quit IRC18:07
smurrayvdl: if you're aiming for some form of reusability with different images, perhaps defining an image  feature that pulls in the desired packages or a packagegroup, or perhaps creating a image bbclass that can be used18:08
smurrayvdl: if it's for building a dedicated product image that won't be shared, I'd probably just add whatever is required to IMAGE_INSTALL in the image recipe18:08
vdlsmurray: there's already a "container" image type for the guest systems, so an image "feature" might do the trick. In the meantime maybe just a reference "host" image recipe which can be required is enough.18:09
smurrayvdl: the issue there is there are many options for what the host can use for running containers18:10
* moto-timo currently banging head on podman for instance18:11
moto-timono docker, just cri-o/cni/podman/runc18:11
vdlsmurray: sure, I'm kinda forcing the container engine here with my "reference" host distribution18:12
vdlmoto-timo: Fedora CoreOS? ;-)18:12
moto-timoYocto built18:12
vdlthere's no meta-fedora? damn it!18:12
moto-timoI wouldn't use it anyway.18:13
moto-timoBuild from source. you know what you have18:13
* vdl was joking obviously18:13
*** zkrx <zkrx!> has joined #yocto18:17
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC18:23
*** mbulut <mbulut!> has quit IRC18:23
*** jobroe <jobroe!> has quit IRC18:24
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto18:25
*** gpanders <gpanders!~gpanders@gateway/tor-sasl/gpanders> has quit IRC18:27
khemRP: does oe-selftest expect poky ?18:27
*** gpanders <gpanders!~gpanders@gateway/tor-sasl/gpanders> has joined #yocto18:27
*** ahadi <ahadi!~ahadi@> has quit IRC18:29
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC18:31
*** champagneg <champagneg!> has quit IRC18:31
*** kiwi_29 <kiwi_29!> has joined #yocto18:32
*** champagneg <champagneg!> has joined #yocto18:33
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC18:35
smurrayall the cool kids are doing debuginfod, it seems:
*** ahadi <ahadi!> has joined #yocto18:43
* vdl isn't cool :-(18:44
*** wooloomooloo <wooloomooloo!> has left #yocto18:44
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC18:44
*** vineela <vineela!vtummala@nat/intel/x-cglrwhhheqxfitgq> has quit IRC18:49
mischiefwhats the best method for fixing broken patches?18:50
vdlmischief: I'd personally manually apply the bits to the upstream project and regenerate the patch properly.18:54
*** linums <linums!~linums@> has quit IRC19:05
*** linums <linums!> has joined #yocto19:08
*** vdehors <vdehors!> has joined #yocto19:22
kyanresvdl, smurray: about systemd defined in the distro, the doc says to set VIRTUAL-RUNTIME_init_manager, _dev_manager and cie in the distro19:23
kyanresThose variables are used in the RDEPENDS of, which is used in the IMAGE_INSTALL core-image.bbclass19:23
kyanres(and good night, people :) )19:24
smurraykyanres: that's a bit out of date, now you'd set INIT_MANAGER = "systemd"19:24
kyanresah, thanks, I'll try to use that19:27
*** creich <creich!> has joined #yocto19:34
vdlsmurray: a patch was actually applied to update this part of the doc ;-)19:44
smurrayvdl: I see it mentioned in the zeus migration notes, the common tasks docs could stand to be updated, I think19:47
*** dreyna <dreyna!> has joined #yocto19:48
vdlsmurray: I've only updated meta-poky/conf/local.conf.sample.extended19:49
*** dreyna <dreyna!> has joined #yocto19:49
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto19:49
*** Spooster <Spooster!> has joined #yocto19:50
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC19:58
*** ssajal <ssajal!> has quit IRC20:00
Spoostero/ Currently trying to deal with a hanging build. My coworker and I setup ubuntu virtual machine on our macs. Installed requirements, and I tried to get kas to start on our kas.yml in the VM.20:01
SpoosterThings look decent, but on one of the first steps, I'm having heaps of trouble getting bitbake to pull down its deps, and I can't seem to build core-image-sato without my VM spinning forever and failing to make progress after downloading a couple of things.20:02
SpoosterI'm guessing that the trouble is NOT going to be inside kas, bitbake, or yocto as a whole in any capacity... and most likely some issue with the virtual machine I setup...20:03
SpoosterI'd love to pry further, just need to know where to go for questions, or how to debug further... as the log just sort of indicates that it's trying to download sources, and then stalls after 20-30 minutes20:03
mcfriskSpooster: start with a non-virtual machine, really. yocto is a beast to compile and virtualization only takes performance away and doesn't give you anything. Maybe the device is out of RAM and swapping like hell20:28
Spoosternot a terrible idea...20:32
*** ssajal <ssajal!> has joined #yocto20:36
*** angelo__ <angelo__!~prefetch@unaffiliated/ad/x-0785363> has left #yocto20:43
Spoosterwe're on mac... so getting things running natively seemed like too much of a bother20:44
Spoosterbut obviously this isn't much better20:44
*** f3ddischson <f3ddischson!> has quit IRC20:51
tlwoernerOEHH in 5 minutes :-)20:55
RPkhem: we test it with poky...20:56
*** beneth` <beneth`!> has left #yocto21:07
*** phoo1234567 <phoo1234567!> has quit IRC21:11
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC21:14
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto21:14
*** beneth` <beneth`!> has joined #yocto21:17
*** oberstet <oberstet!~oberstet@> has quit IRC21:18
*** sbach <sbach!~sbachmatr@> has quit IRC21:19
*** berton <berton!> has quit IRC21:19
*** beneth` <beneth`!> has left #yocto21:19
*** sbach <sbach!~sbachmatr@> has joined #yocto21:19
Spoosterhaha! it should have been this obvious, but in our morning haste, before the coffee hit, we setup a two different VM's trying to get things identical... and I forgot to double check allocated memory for the second one we built that we wanted to continue using... so it was indeed doing it's best on 1G ram, and dying to swap...21:25
Spoosterastounding guess +121:25
dl9pfRP: rpm macros: %__font_provides /usr/lib/rpm/fontconfig.prov21:28
dl9pfwe could try and define this as %{nil}21:28
kergothRP: do you know if there's a summary of the yocto development process somewhere? I know there are multiple wiki pages and the like, but I'm looking for a summary/intro21:33
kergothfigured i'd check before i write something21:33
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC21:36
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto21:36
dl9pfRP: package_rpm.bbclass:  add      cmd = cmd + " --define '__font_requires %{nil}'"    ?21:39
dl9pfI'd need to see what the expansion is of ${_rpmconfigdir} for rpm-native when invoked21:40
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC21:40
RPkergoth: not sure if the testing manual has anything? If you do write something please share as I'd like to improve this kind of thing in the manuals if we don't cover it21:43
RPdl9pf: rpmconfigdir should be set correctly to the sysroot21:44
RPdl9pf: happy to try adding that to package_rpm and see what happens21:44
dl9pfwait a few min ... let me take a look21:45
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto21:45
dl9pfok, here is the catch:21:46
dl9pfcontains: fcquery=/usr/bin/fc-query21:46
dl9pfthat will call into $HOST21:46
dl9pfeither we nuke calling it at all (see above)  or we need to depend on fontconfig-native and mange that call21:47
RPdl9pf: lets just remove that21:47
dl9pfok, then please try  --define '__font_requires %{nil}'21:49
dl9pfok, then please try  --define '__font_provides %{nil}' <<<<<<<<<<<<<<<<<21:49
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC21:51
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto21:51
RPdl9pf: I've hacked something into master-next21:52
*** tedfernau <tedfernau!> has joined #yocto21:57
*** linums <linums!> has quit IRC21:58
*** linums <linums!> has joined #yocto21:58
RPWith meson how do I force a result for find_program() ?22:02
*** bzb <bzb!> has joined #yocto22:03
*** Konsgn <Konsgn!~Konsgnx3@unafiliated/joyseph> has quit IRC22:06
khemRP:  I have sent an update for seltest for go toolchain hope that helps22:09
*** linums <linums!> has quit IRC22:14
*** linums <linums!> has joined #yocto22:15
gillesmhello I try to use frm skeleton . .. do I have to put username1 in file1 username2 in file2 ? a,d adjust number of file1 file2 ?22:19
*** agust <agust!> has quit IRC22:23
*** ppavacic <ppavacic!> has joined #yocto22:27
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC22:29
mischiefim trying to upgrade to gatesgarth and for some reason gcc can't find libzstd22:29
fraywhich architecture?22:31
ppavacicI'm trying to create custom distro for my raspberrypi3 using yocto but during development I want to use qemu emulator.22:32
ppavacicTo run qemu emulator I'm using following command: sudo qemu-system-arm -kernel /home/ppavacic/Downloads/qemu-rpi-kernel/kernel-qemu-4.4.34-jessie -cpu arm1176 -m 256 -M versatilepb -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" rpi-basic-image-raspberrypi3-20210224212727.rootfs.rpi-sdimg  -no-reboot22:32
ppavacicWhere kernel argument is kernel downloaded from this git: "ttps://"22:32
frayIf you setup the files proeprly you can use 'runqemu' and it'll do all of the configuration for you22:32
ppavacicso your suggestion is to just change machine type to qemu?22:34
mischieffray: targetting arm building on x8622:35
rburtonppavacic: no, the rpi machine can set the right variables so runqemu just works22:35
frayyou CAN do that, or you can create (or re-use) a rpi machine configuration that has QEMU enabled..22:35
rburtonassuming qemu can emulate an rpi sufficiently22:35
frayit's all down to the machine confgiuration22:35
frayyes, as rburton said22:35
ppavacicwell qemu works perfectly for raspbian22:37
ppavacictthats official distro of rpi22:37
rburtonso find out what qemu flags they recommend, then add them the rpi machine file (qemuarm.conf is a good start, all the QB_* variables). Then every image will also build a qemuboot file, and you can just runqemu22:39
mischief.. now configure zlib behaving weird: | Compiler error reporting is too harsh for ./configure (perhaps remove -Werror).22:39
mischiefnever seen that before.22:39
frayya, look at meta/conf/machine/qemuarm.conf (or qemuarm64 if it's a 64-bit capable rpi) the variables QB_* all list how to configure/execute qemu22:40
fraythis is what 'runqemu' uses to manage everything22:40
ppavacicthis tutorial says that the easiest way is to just build with qemuarm64 as machine so that artifacts are prebuilt22:41
fraythere is getting started, and then there is going beyond that.. for getting started we recommend using qemu* machines..  once you go beyond that, then finding someone else who has already created an rpi configuration or creating one yourself is the next step22:46
frayyou don't have to use the Yocto Project kernel sources, you can use raspbian if you really want..  but using the YP tooling for compilation, qemu, etc will be much easier and then other docs and tutorials can be done22:47
*** Spooster <Spooster!> has quit IRC22:47
RPkhem: did you fix the lib32 issue?22:51
RP(for go)22:51
ppavacicokay thanks! i will start with basic qemu machine22:53
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:b7bd:1d78:9a4c:6909> has quit IRC23:03
*** LocutusOfBorg <LocutusOfBorg!~locutusof@ubuntu/member/locutusofborg> has quit IRC23:10
*** LocutusOfBorg <LocutusOfBorg!> has joined #yocto23:10
*** LocutusOfBorg <LocutusOfBorg!~locutusof@ubuntu/member/locutusofborg> has joined #yocto23:10
*** ppavacic <ppavacic!> has quit IRC23:11
*** gillesm <gillesm!> has quit IRC23:28
*** leon-anavi <leon-anavi!~Leon@> has quit IRC23:30
khemRP:  I fixed the selftest I thought that was primary issue ?23:55
khembtw. I am seing today did something change ?23:56
RPkhem: two issues, second is
RPkhem: I don't think I did anything to cause that23:58
khemhmm I wonder whats going on I rebooted the build machine and also rebuilt qemu-native23:58

Generated by 2.17.2 by Marius Gedminas - find it at!