<khem>
its due to a patch I am adding to add util-linux-col to RDEPs of man-db
<khem>
I added util-linux to DEPENDS along but did not solve the problem util-linux has this interesting function doing the dynamic package generation so I wonder what could be done here to make build happy
qschulz has quit [Remote host closed the connection]
ederibaucourt has quit [Ping timeout: 245 seconds]
alcroito has left #yocto [#yocto]
druppy has quit [Ping timeout: 252 seconds]
Jones42 has joined #yocto
grma has joined #yocto
ChristosG has joined #yocto
ChristosG has quit [Client Quit]
leon-anavi has joined #yocto
savolla has quit [Ping timeout: 244 seconds]
chep has joined #yocto
chep has quit [Remote host closed the connection]
chep has joined #yocto
chep has quit [Remote host closed the connection]
chep has joined #yocto
savolla has joined #yocto
frgo has joined #yocto
LainExperiments has joined #yocto
<rburton>
khem: good ;) i can send patches shortly.
babo67_ has quit [Remote host closed the connection]
<RP>
wojci: It would be nice to work out how to get buildinfo to do what you want and then document it in the class
LainExperiments has quit [Quit: Client closed]
LainExperiments has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
enok has quit [Remote host closed the connection]
<dvergatal>
JPEW: around?
<wojci>
RP, I think that the concept is wrong, as changing your local configuration is not reflected in rebuilding of the rootfs image per default. It works fine as soon as you force a rebuild of your rootfs (assuming that you use the same rootfs for all your images).
<rburton>
khem: patchbomb sent
<RP>
wojci: in theory any change in configuration should be reflected. What configuration change are you thinking of? Or do you mean that the git src revisions don't always get updated?
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
florian has quit [Ping timeout: 248 seconds]
LainExperiments has quit [Quit: Client closed]
<wojci>
RP: The idea is that you can use some variable which is to be reflected in the build info output. The variable is defined in your local.conf. When rebuilding the change in the variable and thus buildinfo is ignored.
<RP>
wojci: if the variable changes, it should update so I would say that is a bug
leon-anavi has quit [Read error: Connection reset by peer]
leon-anavi has joined #yocto
cyxae has joined #yocto
florian has joined #yocto
Minvera has quit [Ping timeout: 252 seconds]
GNUmoon has quit [Read error: Connection reset by peer]
GNUmoon has joined #yocto
<Jones42>
is there any functional difference between *.wic and *.wic.in files?
<JPEW>
dvergatal: limited, but yes
Guest47 has joined #yocto
<agodard>
Jones42: you mean wks? I think the difference is that in .in files you can use yocto variable like ${VAR} and they're expanded
Guest47 has quit [Client Quit]
<Jones42>
agodard: yes, thanks! We've been messing with WICVARS in our .wic-files until now. but wic.in seems to be the correct way then i guess
<Jones42>
s/wic/wks of course
<rfs613>
Jones42: traditionally, .in means "input", a file that gets processed via m4 macro processor. This comes from autoconf/automake. I think the wks.in doens't use m4, but it's kind of the same idea (preprocessing step).
rcwoolley has joined #yocto
ChristosG has joined #yocto
rcwoolley has quit [Ping timeout: 260 seconds]
enok has joined #yocto
<Jones42>
rfs613: thanks for the explanation. I couldn't find the part of the code that handles the "in"-part. Didn't think of m4 in that context
<rfs613>
Jones42: I suspect in this case it's just python code doing the work, there is no m4 involved, but the naming convention seems to have stuck
<agodard>
Jones42: this is done in image_types_wic.bbclass's do_write_wks_template if I read that correctly
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
<Jones42>
agodard: oh, there it is! thanks. I've been only looking in the actual wic code which didn't seem to make a difference between wks and wks.in
wojci has quit [Ping timeout: 260 seconds]
enok has quit [Ping timeout: 244 seconds]
rcwoolley has joined #yocto
florian has quit [Ping timeout: 272 seconds]
Guest17 has joined #yocto
<Guest17>
I want to build yocto for TI OMAP 138 but I am not able to find the correct documentation. Can anyone help me in this regard
goliath has quit [Quit: SIGSEGV]
<rburton>
Guest17: looks like meta-ti has a BSP for it
rfuentess has quit [Read error: Connection reset by peer]
rfuentess has joined #yocto
<Guest17>
Can anyone guid me as I am biginner to YOCTO
florian has joined #yocto
LainExperiments has joined #yocto
LainExperiments has quit [Quit: Client closed]
<RP>
khem: PACKAGES_DYNAMIC may be the fix for util-linux btrw
rcwoolley has joined #yocto
florian has quit [Ping timeout: 252 seconds]
jmiehe has joined #yocto
alessio has quit [Quit: alessio]
rcwoolley has quit [Ping timeout: 246 seconds]
<khem>
RP: actually the problem is the col is not buildable for non-glibc libcs and that check is in util-linux configure so we do not get col utility on musl at all thats the problem, now col is deprecated in util-linux so there is no point of fixing it for musl but man-db pokes at native sysroot and finds col there from util-linux-native i guess and assumes it can be enabled in cross compile this is
<khem>
wrong assumption too but its a bigger issue in man-db build system
<khem>
anyhow I have fixed it by feeding col to be empty during configure on musl and this should work
florian has joined #yocto
<khem>
fix libssh2 ptests on glibc and will see if it fixes ptest on musl too although I doubt
frieder has quit [Remote host closed the connection]
<khem>
maybe it is Drop multiple branch/revision support for single git urls
<khem>
just a guess
<khem>
freerdp also shows similar parse errors
<khem>
yep reverting that patch fixed it
<RP>
khem: my bitbake change needs a tweak in meta-oe :/
jmiehe has quit [Quit: jmiehe]
nerdboy has quit [Remote host closed the connection]
<RP>
khem: I've sent a patch but it depends on my one to bitbake merging. I'm not sure whether we should do this at this point the release. I'm tempted to though
<khem>
rburton: btw couple of them in layers not on AB - fbgrab, openl2tp redis
LainExperiments has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
<khem>
ah cool libssh2 ptests are good on musl too, so man-db fix seems to be ok
ChristosG has quit [Ping timeout: 240 seconds]
goliath has joined #yocto
<vmeson>
rust-1.84 news of the day, mostly for RP: FS space wasn't the problem. ID the unit test that's causing the problem, and it's currently excluded. testing running
<RP>
vmeson: ok, sounds good thanks
florian has quit [Quit: Ex-Chat]
<khem>
rburton: libx86-1 fails to install I guess we need to define DESTDIR somewhere and rdist fails during packaging and valkey as well "oe-runmake: command not found"
grma has quit []
<rburton>
wtf
grma has joined #yocto
<rburton>
i literally built those before posting
<khem>
valkey is my typo
<rburton>
tbh i have a followup to remove libx86 :)
<rburton>
yeah i think that was a silly copy-paste
<rburton>
i'll try rdisk for x86
<khem>
my build is for qemux86-64
<RP>
khem: I'm wondering if we should add musl ptests runs to the AB. We probably have the capacity now
DixitP has joined #yocto
<rburton>
khem: my miniupnp v2 is basically a partial rewrite of the recipe with an eye to the incoming upgrade
<khem>
yeah that would be cool
<khem>
rburton: I took that in
<RP>
khem: I do wonder if we should be using gitpkgver out the box in meta-oe by default :/
<rburton>
khem: the libx86 one is a simple s/destdir/DESTDIR/. not sure how that passed testing, must have somehow changed the case after the builds!
DixitP has quit [Quit: Client closed]
Knogle has joined #yocto
rfuentess has quit [Remote host closed the connection]
enok has joined #yocto
LainExperiments has quit [Quit: Client closed]
<rburton>
khem: can you replicate the rdist thing locally? if so can you look at log.do_compile, it appears that compile failures are ignored by the makefile...
<rburton>
looks like a rebuild problem of some sort
DixitP has joined #yocto
leon-anavi has quit [Remote host closed the connection]
DixitP has quit [Quit: Client closed]
<rburton>
khem: v2 sent with fixes. can't replicate that rdist fail without seeing a compile log as those makefiles make me rationally angry
savolla has quit [Quit: WeeChat 4.4.3]
<rburton>
khem: did you see the thing about gcc15 and zero-initialisation? i wonder if we should pass the -f to revert behaviour at first because that just looks dangerous
<rfs613>
khem: thanks, taking a look (also that union initializer is quite interesting... I'd always assumed that union initializer would work the same way as struct, but that's what I get for assuming!)
<rfs613>
khem: i don't reall want to create the refpolicy from scratch - but I do need changes on top of repolicy-targeted. Some of those I can upstream, but others need to be handled locally.
bjdooks has joined #yocto
<rfs613>
for those local ones, adding yet anothe patch file on top of the existing 60-ish ones seems quite fragile.
frgo_ has joined #yocto
frgo has quit [Ping timeout: 252 seconds]
landgraf has joined #yocto
frgo_ has quit [Ping timeout: 252 seconds]
savolla has joined #yocto
frgo has joined #yocto
Guest17 has joined #yocto
frgo has quit [Read error: Connection reset by peer]
frgo has joined #yocto
frgo has quit [Read error: Connection reset by peer]
frgo_ has joined #yocto
<khem>
rburton: rdist only shows the problem when building with gcc-15 works ok when using clang so let me check
frgo_ has quit [Remote host closed the connection]
alessio has joined #yocto
alessio has quit [Client Quit]
savolla has quit [Quit: WeeChat 4.4.3]
savolla has joined #yocto
frgo has joined #yocto
frgo has quit [Ping timeout: 244 seconds]
prabhakalad has quit [Ping timeout: 268 seconds]
prabhakalad has joined #yocto
ptsneves has joined #yocto
michaelo has joined #yocto
ChristosG25 has joined #yocto
ChristosG25 has quit [Client Quit]
druppy has joined #yocto
frgo has joined #yocto
florian has joined #yocto
frgo has quit [Ping timeout: 252 seconds]
ptsneves has quit [Quit: ptsneves]
Knogle has quit [Ping timeout: 245 seconds]
druppy has quit [Ping timeout: 252 seconds]
frgo has joined #yocto
Knogle has joined #yocto
cg1 has joined #yocto
frgo has quit [Ping timeout: 244 seconds]
cyxae has quit [Quit: cyxae]
zenstoic has joined #yocto
cg1 has quit [Quit: WeeChat 3.5]
cg1 has joined #yocto
cg1 has quit [Client Quit]
<rburton>
khem: yes
Kubu_work has quit [Quit: Leaving.]
frgo has joined #yocto
ChristosG has quit [Quit: Client closed]
frgo has quit [Ping timeout: 248 seconds]
<vmeson>
Are you a go-er ? openssl (or chromium) build lots of files so it's useful for testing build regulation. What package, written in go, is similar scale ? 'go build' only has max job limits, right? https://manpages.debian.org/jessie/golang-go/go-build.1.en.html
<vmeson>
^Dear lazy chat^
frgo has joined #yocto
<khem>
vmeson: I can think of kubernetes recipe from meta-virtualization
<khem>
or docker recipe as well, docker is not all in go but significant pieces are
frgo has quit [Ping timeout: 245 seconds]
<khem>
but go compiler is so fast ... I feel like being in a ferrari compared to when chromium is compiled and it feels like corolla
<khem>
:)
<vmeson>
khem: Thansks and yeah, I was thinking that regulating go builds may not be worthwhile.
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
Xagen has quit [Ping timeout: 245 seconds]
Kubu_work has joined #yocto
dkl has quit [Quit: %quit%]
dkl has joined #yocto
dkl has quit [Remote host closed the connection]
dkl has joined #yocto
druppy has joined #yocto
frgo has joined #yocto
frgo has quit [Ping timeout: 252 seconds]
eduter has joined #yocto
<eduter>
Hello. Could someone guide me a bit on this scenario. I just added a new layer into my local.conf "meta-rust". It comes with a newer toolchain version for rust, than the one shipped with POKY<meta<recipe-devtools.
<eduter>
If meta-rust layer has higher priority than the poky layer... why when I compile my recipe which builds my RUST project... the version in use is still the old one from POKY? I thought the "cargo.bbclass" from "meta-rust" layer will take precedence over the "cargo.class" from POKY. Could someone maybe shed some light on this for me?
<eduter>
Thank you very much in advance.
eduter has quit [Quit: Client closed]
kilobyte_ch has quit [Ping timeout: 265 seconds]
Kubu_work has quit [Quit: Leaving.]
kilobyte_ch has joined #yocto
Kubu_work has joined #yocto
enok has quit [Ping timeout: 245 seconds]
Knogle has quit [Quit: WeeChat 4.5.2]
druppy has quit [Ping timeout: 260 seconds]
frgo has joined #yocto
frgo has quit [Ping timeout: 248 seconds]
<khem>
bbclasses do not follow the priority it follows where it appears on BBPATH