jwillikers has quit [Remote host closed the connection]
tp43_ has joined #yocto
amitk has joined #yocto
paulg has quit [Ping timeout: 250 seconds]
tp43_ has quit [Ping timeout: 252 seconds]
tkoskine has quit [*.net *.split]
tkoskine has joined #yocto
<wCPO>
Can WIC add empty space at the end of the image? I need a bigger WIC image, so I can use systemd-repart when running in QEMU to add a extra partition
leon-anavi has joined #yocto
<wCPO>
IMAGE_ROOTFS_EXTRA_SPACE🎉
alinucs_ has joined #yocto
alinucs has quit [Ping timeout: 252 seconds]
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
te_johan has joined #yocto
<te_johan>
moin moin, i'm having issues with post install scripts failing to change owner during do_rootfs: copyfile
<te_johan>
the poky repo is owned by my user and the build is done in docker with uid and gid 1000. so bitbake copies the file and afterwards it tries and restore the owner to the original owner. I don't understand why it would want to change owner at all. I've seen other have similar issues mentioning a change in PSEUDO_IGNORE_PATHS.
<te_johan>
does anyone have any insight in who ownership of files are changed in bitbake:utils:copyfile?
te_johan has quit [Quit: Ping timeout (120 seconds)]
te_johan has joined #yocto
amitk has quit [Remote host closed the connection]
amitk has joined #yocto
frieder has joined #yocto
override_ has quit [Ping timeout: 252 seconds]
override_ has joined #yocto
LetoThe2nd has joined #yocto
goliath has joined #yocto
yannd has quit [Ping timeout: 252 seconds]
eduardas has joined #yocto
te_johan has quit [Quit: Ping timeout (120 seconds)]
<barath>
this is related to a question I had yesterday, about packages being assigned (their names contain) both aarch64 and our custom machine name which has the aarch64 architecture, and whether that can cause issues
<barath>
I now see there's a variable called PACKAGE_ARCH, which can be set per recipe (?) to define the "actual" arch... would that fix some packages being "assigned" this machine we have defined instead of the arch it's actually built for? does it make sense to invest time in doing that?
te_johan has joined #yocto
yannd has joined #yocto
<LetoThe2nd>
yo dudX
te_johan_ has joined #yocto
te_johan has quit [Quit: Client closed]
rfuentess has joined #yocto
<qschulz>
barath: yes set per recipe, that would make sense though you have to be "careful" so that you make machine specific only what's needed otherwise you'll have a ton of technically duplicate recipes/packages between two different machines
<barath>
yes that's what I'm investigating... while investigating why some packages always are rebuilt even tho we have sstate cache files from another machine
zyga-mbp has quit [Ping timeout: 252 seconds]
<qschulz>
barath: you could also technically introduce another arch, an intermediate one which is common to your machines, provided the outcome of a recipe is identical for both machines (i.e. compiler flag and architecture, etc.)
<barath>
so is that "best practice"? ie that when you define a machine, you should actually set the package arch to the underlying PACKAGE_ARCH?
<qschulz>
barath: no
<barath>
hm I see...
zyga-mbp has joined #yocto
<barath>
:D okay
<barath>
so what's usually done? I imagine this is something people do a lot: define a machine using the aarch64 arch and then build custom recipes (or even systemd, which has some of its packages marked as aarch64 and then some with our custom machine name)
<qschulz>
you set the PACKAGE_ARCH to MACHINE_ARCH if anything in the recipe uses something that can change between machines of the same "base" architecture (aarch64, cortexa8-hf, ... whatever)
<qschulz>
e.g. using MACHINE in there, or an override with a MACHINEOVERRIDES
<barath>
hm okay, so it's for being specific when the difference between arch variants becomes important for a recipe
<qschulz>
arch variants or machines, yes
<barath>
hm okay
<barath>
so let's take system. I some of the systemd packages are built for aarch64, some for our custom machine name
<barath>
is that "okay"? we've done this for ages, so it obviously works
<barath>
but it feels very strange now that I've tested package feeds and some are put in aarch64 and some under our custom machine name
BCMM has joined #yocto
<qschulz>
well, it seems it does not since you're having trouble with sstate-cache re-use :p
BCMM has quit [Client Quit]
BCMM has joined #yocto
<qschulz>
systemd package specific to your custom machine should have PACKAGE_ARCH set to MACHINE_ARCH
<barath>
:D yeah, question is whether this is to blame
<barath>
it's been hard for me to nail down exactly where/why the hashes start differing between hosts, a lot of base hashes seem different
<barath>
> systemd package specific to your custom machine should have PACKAGE_ARCH set to MACHINE_ARCH
<barath>
hm. I see that the systemd-conf package is stored under our machine name, while the systemd package itself is marked as/stored under aarch64
<barath>
sorry if these are noob questions, I'm trying to align our yocto usage with something that approaches best practice/actually how it's meant to be used instead of hacks everywhere...
florian has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
d0ku has joined #yocto
camus1 is now known as camus
cody has quit [Quit: You have been idle for 30+ days]
m1kr0[m] has quit [Quit: You have been idle for 30+ days]
<RP>
kanavin_: looks like your build found a bitbake socket file race :/
m1kr0[m] has joined #yocto
m1kr0[m] has left #yocto [#yocto]
<kanavin_>
RP: I saw that one in a previous master-next build too
<RP>
kanavin_: I think it is harmless and just a race over removing the file so the code should be ignoring it?
<kanavin>
'qemu 6.1 wip' is now tested, I just need to write a proper commit message
<RP>
kanavin: I'll leave it for now but people generally ignore the freeze so we'll see what happens, I have to queue things somewhere
<kanavin>
RP: master-next-next?
<RP>
kanavin: or master-next2
whuang0389 has joined #yocto
<zyga-mbp>
hello
<zyga-mbp>
I'm trying to package a go program I'm trying to understand how to handle dependencies exactly
<zyga-mbp>
my -staticdev packages (which all use go-mod.bbclass) contain /usr/lib/go/pkg/mod/cache/ full of downloaded files from what should really be other packages
te_johan has joined #yocto
<zyga-mbp>
am I doing this wrong by trying to package each dependency separately?
<zyga-mbp>
should I strive to remove pkg/mod from the -staticdev packages? (or change go-mod.bbclass)
<zyga-mbp>
right now I end up with clashes for files like "/usr/lib/go/pkg/mod/cache/download/github.com/kr/pty/@v/list" which are clearly an implementation detail of how go modules work internally
d0ku has quit [Ping timeout: 252 seconds]
<zyga-mbp>
(cc agherzan for awareness)
tnovotny has joined #yocto
te_johan has quit [Ping timeout: 245 seconds]
<zeddii>
zyga-mbp. there's no proper solution for go.mod yet. We need a fetcher module for go.mod processing, so we can properly get those dependencies, mirror, cache, license, etc, on them.
<zyga-mbp>
I've found some of the things I need in a meta-sca layer, it's built using a custom gosrc.bbclass
dvorkindmitry has joined #yocto
<zeddii>
I've spent quite a bit of time working on a proper fetcher for it, or other ways to manually handle go.mod to generate SRC_URI entries, and I'm not happy with it.
<zeddii>
zyga-mbp, I've been through that as well, it won't really help what you want.
<zeddii>
well, it will a bit.
<zeddii>
but it's similar to what I've used for adding the depenencies on the SRC_URI as individual fetches.
<zeddii>
that can work, but it doesn't scale well, unless you automate it.
<zeddii>
but trying to package all the dependencies separately will fail, so you can throw out that idea :D
<zyga-mbp>
I'm entirely lost after a day of poking at the .bbclasses and trying various things
<zyga-mbp>
should I just package my top-level program and totally ignore the rest?
<zyga-mbp>
(making something that cannot be really built offline)
<zeddii>
if you don't care about it fetching things during the compile, and don't need mirroring, archiver, etc, you can do that.
<zyga-mbp>
while I'm very comfortable with go itself I'm not familiar with the details of how go modules are implemented by the toolchain, all the files that were clashing or were being added to the packages challenge my ignorance there
<zyga-mbp>
zeddii is there anyone working on this for the next release? anything I can try to align with
<zeddii>
I'm having a run at it :D
<zyga-mbp>
or backport something limited to an otherwise-dunfell layer to do sensible packages?
<zeddii>
since once go removes vendored support, we are absolutely hosed.
<zyga-mbp>
yeah
<zyga-mbp>
zeddii what are your plans for go-mod support?
<zyga-mbp>
and is the work in meta-sca useful or is it a dead end from your pov?
<zeddii>
zyga-mbp: there's a lot of 'it depends' on the packaging front. step 1 is getting the fetcher aware enough to get the sources, put them in downloads, setup the env so they are used first by go.mod, just for the build.
<zeddii>
not really useful there.
<zyga-mbp>
the mod format is quite elaborate
<zeddii>
step 2 are you building static, etc, then you don't even package up those depends.
<zyga-mbp>
it can use other versions than prescribed IIRC
<zeddii>
zyga-mbp, I spent 5 hours reading the docs, and yes, I concur :D
<zyga-mbp>
hmm, can you clarify what you mean by step 2?
<zeddii>
meaning, you don't care about packaging the dependencies, just ignore them, if the final app is statically linked, since it won't need them at runtime. I have many different go applications that we just statically link. We then queue the discussions about dynamic or static go apps ...
<zeddii>
but I'm not an expert in the bizarre go build process. My loathing of it is well documented :D
<zeddii>
I've searched in vain to see if there are any 3rd party parsers of go.mod, nothing I've found. So it will likely be a matter of letting go.mod doing it's thing in the fetch phase, grabbing the results of that, shuffling them into the right places for downloads, etc
<zyga-mbp>
I wonder if anything can be learned from fedora, debian or suse
<zeddii>
nothing that I've seen.
<zyga-mbp>
IIRC they do support go.mod builds now
<zeddii>
due to the different and non-cross builds.
<zeddii>
I checked buildroot as well, nothing super re-usable that I've seen.
<zeddii>
well, technically we can support go.mod builds as well, it's just wrong :D
<zyga-mbp>
is cross a big factor? I mean apart from CGO it's mostly effortless
<zeddii>
it's not the cross part, it's the host contamination part.
<zeddii>
and most of the things I build, are all CGO.
<zyga-mbp>
I see
<zyga-mbp>
I'll think about what to do
<zyga-mbp>
I'd love to help on go mod support, except that I have some commitments to fulfill first
<zyga-mbp>
zeddii thank you for the time and explanations
<zeddii>
I won't be digging into it until after the release myself.
<zeddii>
feel free to ping me if you start looking and we can coordinate.
<zyga-mbp>
which release?
<zyga-mbp>
ack, I'll surely will
<zeddii>
yocto 3.4
<zeddii>
~this October
<zeddii>
I lack some of the go knowledge, but have a lost of the rest. So I may ping you when I get lost in a moment of "what is go doing here" :D
mihai has quit [Remote host closed the connection]
<Guest2>
Hi, I actually use dunfell. Now I've experienced a bug in the freescale network driver. Do you think it's easy to update the driver to today's version without updating the whole yocto version?
<Guest2>
Or is it better to update to a newer yocto release as a whole?
<Guest2>
Partial update vs. full update, so to speak
<JPEW>
sgw: I suspect we need to skip the package creation code in create-sdpx.bbclass in cases where no packages are actually created (e.g. native). I'm not sure the best way to do that
<JPEW>
Although.... I thought we were already doing that, since we call oe.packagedata.packaged in the loop where we create the package SPDX files :/
<JPEW>
sgw: Ah, OK. That error comes from read_subpackage_metadata itself, which we always call unconditionally so that we have the correct view of the packages
<sgw>
JPEW: Not sure which is why I took the approach. I probably should have shared that with you.
<sgw>
earlier
Xagen has joined #yocto
<Xagen>
how do you fix devtool when you get `ERROR: Something went wrong with source extraction - the devtool-source class was not active or did not function correctly`?
goliath has quit [Quit: SIGSEGV]
eduardas has quit [Quit: Konversation terminated!]
d0ku has joined #yocto
tnovotny has quit [Quit: Leaving]
Guest2 has quit [Quit: Guest2]
rber|res has joined #yocto
eduardas has joined #yocto
<vmeson>
tlwoerner: where is this pseudo, seccomp thread?
rfuentess has quit [Remote host closed the connection]
<rburton>
last post in the thread is a @gentoo account but mentions we and CrOS, so presumably is a googler
<tlwoerner>
vmeson: libc-help mailing list
vd has joined #yocto
DataDrake|zzz has joined #yocto
DataDrake|zzz is now known as DataDrake
<DataDrake>
I think zyga-mbp stepped away, but regarding his tweet about go modules in bitbake, there's an easier solution. upstream could generate tarballs with vendored deps easily enough: https://golang.org/ref/mod#go-mod-vendor
<zeddii>
DataDrake, yes. that's the same approach we we talking about.
<DataDrake>
ah, great minds think alike
<zeddii>
but the complications start to arrive when we move it into a fetcher/downloads format and get the env setup properly for builds that may not be vendored
<DataDrake>
that's fair. I figured it might be a reasonable request of upstream to generate the tarballs like this and am looking into doing it myself, personally
<zeddii>
it solves licensing issues, and avoid needing to process go.mod (which no sane person would do), and then we arrive at the getting it used by the build parts, which are the same regardless of how we get the sourced into the sysroot
<DataDrake>
I think I follow
<DataDrake>
we have a similar system in Solus where we use a chroot container to perform isolated builds and we definitely prefer to not need networking enabled wherever possible. for us the major "offenders" are Go, Rust, Node, and Java stuff.
<zeddii>
the usual criminals, yes :D
<zeddii>
we need something in place for go before they remove go mod vendor'd build. things get painful then
<DataDrake>
oh shoot, I didn't realize that was on the chopping block
<zyga-mbp>
DataDrake hey!
te_johan has joined #yocto
<DataDrake>
hi :)
<zeddii>
most of the complex go builds I support, we've set GO111MODULE=off (with vendor being the second choice). When that goes away, we need a full go mod solution. That's mainly what I'm referring to.
<zyga-mbp>
DataDrake I'm trying to wrap my head around things but my strongest argument so far (with myself) is that we need to make both yocto and go sides happy, and that's mainly around fetcher, without getting the very complex problem in the way (multi-version), while, and this is probably more important to my corporate life than to most, having clear license situation
eduardas has quit [Quit: Konversation terminated!]
<zyga-mbp>
I lean towards building apps, not libraries, fetching the code with `go download` somehow and still tying into the license checker
<DataDrake>
I definitely don't have a straight answer for licensing, that's hard
<zyga-mbp>
but those are early thoughts from a walk in the park
<zyga-mbp>
I need more time to research this
<DataDrake>
go mod vendor feels like a good half-way measure, but I realize that Go modules have been a bit of a moving target
<zyga-mbp>
given that go has nice tooling and libraries for working with modules I think the best solution will work based on those, without re-inventing the wheel
<DataDrake>
yeah, there might be some deeper magics in there somewhere
<zyga-mbp>
I wonder if things like patching are sensible in this case
<zyga-mbp>
given that bitbake doesn't (seem to, please correct me if I'm wrong) do multi-version things
<DataDrake>
you honestly might have a better time of working with them to find something that works
<DataDrake>
they may not have remotely considered this sort of thing
<agherzan>
I guess the problem is the same as with the rust projects
<zyga-mbp>
I was trying to package a single binary with a check.v1 dependency
<zyga-mbp>
and realized that internally chec.v1 depends on two versions of the same package
<zyga-mbp>
because various dependencies pinned different versions for their own testing
<DataDrake>
yeah, that's pretty common
<zyga-mbp>
only a fetcher that can understand go.mod properly would untangle that
<zyga-mbp>
and build the (single, more recent) version of the dependency
<zyga-mbp>
but there's a lot of other details, like the sum database and the proxy files and the list files
<zyga-mbp>
so I just need a moment to constrain this in my head
<zyga-mbp>
anything that is impossible is not worth doing
<zyga-mbp>
what remains must be right
<zyga-mbp>
hey agherzan :)
te_johan has quit [Ping timeout: 256 seconds]
<zeddii>
in my travels, there's no real way to shoot for re-use (in a packaging sense) of any of the dependencies.
<zyga-mbp>
I don't really want re-use, I want compliance and correctness
<zyga-mbp>
and not to cheat offline buillds
<agherzan>
zyga-mbp: There is no need for reuse at this point to be honest - for your specific usecase
<zyga-mbp>
(that's just robustness over time)
<agherzan>
Compliance on the other hand...
<zyga-mbp>
agherzan agree
<zyga-mbp>
*agreed
<zyga-mbp>
yeah, licensing is important
<zeddii>
that's what I mean. you just need to get them fetched and put into downloads in the right format, so they are available when go mod goes looking during the build, or you can otherwise get them into the sysroot.
<zeddii>
but considering them as anything more than source, is pretty much doomed.
<DataDrake>
I personally went down this route with Haskell on Solus, it was not fun and I still don't know if I made the right decision
<DataDrake>
networking is on because we were still on an older version of cabal that couldn't do offline yet
rcw has joined #yocto
<DataDrake>
Setup.hs doesn't resolve dependencies which I found annoying
agherzan has left #yocto [#yocto]
<DataDrake>
whereas Cabal does that and more
agherzan has joined #yocto
agherzan has left #yocto [#yocto]
agherzan has joined #yocto
<zyga-mbp>
DataDrake does haskel have multi-version libraries?
<zyga-mbp>
or is the ecosystem smaller / more stable?
<DataDrake>
it can actually
<zyga-mbp>
(go is notoriously fragmented IMO)
<agherzan>
The more I think about it, the more I find the per mod recipe approach unfeasible zyga-mbp
<zyga-mbp>
what do you do about them?
<zyga-mbp>
agherzan I really agree
<zyga-mbp>
I think a tool-based approach that can create a recipe and extract, recursively, all the licenses is required
<zyga-mbp>
agherzan so only apps are packagec
<zyga-mbp>
*packaged
<zeddii>
'er yah.
<agherzan>
Yes.
<zyga-mbp>
the downside is that you cannot patch anything
<DataDrake>
I honestly don't lol. I hold things back if I need to and sometimes I even patch the .cabal files to allow newer versions that were tested on hackage
<zeddii>
run away from creating recipes.
<agherzan>
We need to sort out the licensing part of it.
<zeddii>
it won't scale, and you'll have thousands
<agherzan>
Exactly.
<zyga-mbp>
yes
<zyga-mbp>
even fedora caved a little
<agherzan>
How did the rust guys do this?
<zyga-mbp>
for the record, fedora still requires you to tell about each bundled package
<agherzan>
How do they handle the license in the bitbake recipes?
<zyga-mbp>
but not package them separately
<DataDrake>
I think we are sort of getting to the point where networked builds are unavoidable and I definitely don't have a one-size-fits-all answer to that
<zyga-mbp>
agherzan given that REUSE guys asked me to create a custom license to express 3-clause BSD license with a specific copyright as a custom spdx entry
<vd>
hi there -- in a device tree, how can I attach a pinmux config not related to a specific node? (i.e. these are gpio pins hog)
<vd>
Is there a way to create a dummy node to attach the pinctrl-0 to maybe?
jmiehe has joined #yocto
Tokamak has joined #yocto
<rburton>
mihai: the patches that we mark with DON'T USE THESE?
<mihai>
:))
<mihai>
rburton: I guess so
LetoThe2nd has quit [Quit: Connection closed for inactivity]
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
zyga-mbp has quit [Ping timeout: 252 seconds]
zyga-mbp has joined #yocto
xtopher_ has quit [Ping timeout: 240 seconds]
rmmr has quit [Ping timeout: 240 seconds]
JPEW has quit [Ping timeout: 240 seconds]
JPEW has joined #yocto
xtopher_ has joined #yocto
rmmr has joined #yocto
Tokamak has quit [Ping timeout: 252 seconds]
JosefHolzmayr[m] has joined #yocto
<JosefHolzmayr[m]>
yo dudX
<JosefHolzmayr[m]>
ah, thats how it looks from this side.
<mihai>
yo
<mihai>
from this side
* JosefHolzmayr[m]
is just tinkering with Matrix/Element
yannd has quit [Ping timeout: 244 seconds]
goliath has quit [Quit: SIGSEGV]
yannd has joined #yocto
cocoJoe has quit [Quit: Client closed]
<whuang0389>
noob linux question. can I use install command to copy a folder over?
<nohit>
hi, does yocto work on WSL2 ?
<RP>
nohit: basically yes but see the notes in the docs
<nohit>
ok thx
bps has joined #yocto
bps has joined #yocto
<JosefHolzmayr[m]>
@whu
<JosefHolzmayr[m]>
whuang0389 nope, such needs cp. check the existing recipes for examples, its important to get uid/gid and permissions right.
<whuang0389>
thanks!
goliath has joined #yocto
<RP>
vmeson: I did quickly poke at centos7 again. What is really odd is that it claims it is running "/home/pokybuild/yocto-worker/reproducible-centos/build/build-st/tmp/work/x86_64-linux/cargo-native/1.54.0-r0/wrapper/target-rust-ccld" and it fails yet I've edited that script and it isn't being run
<vmeson>
RP: that's more progress that I've had. I'm wrestling with docker. I guess I could use one of the yocto.io boxes, but I prefer not to do that.
amitk has joined #yocto
<RP>
vmeson: I'm just using one of them...
<vmeson>
yeah, if I don't wrestle docker to the ground, I'll do the same after dinner.
amitk has quit [Ping timeout: 252 seconds]
rewitt3 has quit [Remote host closed the connection]
rewitt3 has joined #yocto
<RP>
vmeson: I'm starting to wonder if the rust binaries are too old to run on the centos7 kernel :/
<RP>
er, too new
<smurray>
heh, had me scratching my head there for a sec
rewitt3 has quit [Remote host closed the connection]
rewitt3 has joined #yocto
<RP>
vmeson: I think what happens is that the ccld wrapper has a #!/bin/sh and that causes it to execve() /bin/sh. That links to libtinfo and it finds the sysroot one rather than the system one, which then can't find the libc it wants since it is using the system interpreter/loader rather than the uninative one which knows where our C lib is
<RP>
only happens on centos7 as there are big differences between the system libs and buildtools/uninative
<RP>
think the unknown syscall is clone3 and a red herring
rewitt3 has quit [Remote host closed the connection]