<NiksDev>
btw, I have a premirror where the required git objects are present in the tarball, but the bitbake tries to sync the objects after premirror step as well
<rburton>
NiksDev: update your ca-certificates package
<JosefHolzmayrThe>
and refresh the cache, thats also important :)
<rburton>
(and if you need to update ca-certs, i suggest doing a full update, as you've not updated for ages)
<rburton>
to be clear we mean on the host system, nothing in yocto
goliath has joined #yocto
<NiksDev>
I have a ubuntu VM spawned in a server and that;'s the host. I run apt-get upgrade before every build, so all packages are latest of that ubuntu version
<rburton>
what release of ubuntu, and what's the version of ca-certificates
<rburton>
and presumably you do apt-get update first
<JosefHolzmayrThe>
just like i said, updating alone doesn't do the trick, you also need the update-ca thing.
<rburton>
surely the postinst does that bit for you
<barath>
base docs.yoctoproject.org is also broken so server issues I guess
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
<qschulz>
add current/ after yoctoproject.org/ and that should fix it for now
<qschulz>
halstead: ^ FYI, docs.yoctoproject.org displays a file browser instead of the usual HTML page
Anon has joined #yocto
Anon is now known as Guest367
kriive has joined #yocto
pidge24 has quit [Quit: Client closed]
Guest367 has quit [Quit: Leaving]
<kriive>
Hello there! I'm trying to split a package in two components: package-client and package-daemon. I'm installing them in ${bindir}/package and ${bindir}/packaged. I have a PACKAGES += "${PN}-client ${PN}-daemon" and subsequent FILES_${PN}-daemon = "${bindir}/packaged" and FILES_${PN}-client = "${bindir}/package".
<kriive>
dnf complains abount not finding package-client
<kriive>
What am I doing wrong?
kiran has joined #yocto
<rperier>
o/, did anyone test yocto 3.1.x LTS on debian 11 ? (just in case...)
kayterina has quit [Remote host closed the connection]
yates has joined #yocto
<yates>
there seems to be a problem with docs.yoctoproject.org
<vmeson>
I suspect this is just an error as the 3.4 release is prepped.
tre has quit [Remote host closed the connection]
whuang0389 has joined #yocto
<halstead>
yates: I've put it back to normal. The docs builds aren't working correctly.
<yates>
halstead: thank you
<halstead>
qschulz: Something is wrong with the docs builds not putting files at the root.
roussinm has joined #yocto
kriive has quit [Ping timeout: 252 seconds]
kriive has joined #yocto
<whuang0389>
Hi, I have a bbappend that applies patches to the linux kernel. When I do devtool modify virtual/kernel, those patches aren't applied/copied over. Is there a way to apply the patches when modifyign the recipe via devtool?
<sakoman>
rperier: dunfell 3.1.12 will support debian 11 (and fedora 34)
<sakoman>
scheduled to be out 26 Nov
<abelloni>
sakoman: what about fedora35? :)
<sakoman>
abelloni: I'll get right on that :P
<qschulz>
halstead: yeah I figured, is there any error printed in some log to help with that?
<vd>
hi all -- bb.data.inherits_class() checks is the given class is currently inherited in a recipe, right?
<vd>
or if it simply exists?
pgowda_ has quit [Quit: Connection closed for inactivity]
dev1990 has joined #yocto
leon-anavi has quit [Quit: Leaving]
<rburton>
vd: if the datastore you pass inherits the class
<vd>
rburton: what does a datastore refers to in this context, a recipe being build or the whole bitbake instance?
<rburton>
the recipe's datastore, you'll encounter is as 'd'
rfuentess has quit [Remote host closed the connection]
<rperier>
sakoman: super, thanks for the feeback
camus has joined #yocto
<vd>
rburton: ho ok so it is safe to use bb.data.inherits_class() to check if the current recipe has a specific class inherited or not
nucatus has quit [Remote host closed the connection]
<kergoth>
hmm time for my first swat triage, swatbot seems handy
jmiehe has quit [Quit: jmiehe]
<vd>
is there a way to inherit a class programmatically via python or does one need to do d.setVar('FOO', 'class') then inherit ${FOO}?
Elkly has joined #yocto
Elkly has quit [Client Quit]
tnovotny has quit [Quit: Leaving]
Pan5ky has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<qschulz>
vd: you can do inherit ${@} or whatever the correct syntax is (inline python)
<vd>
I'm wondering if it's a good or bad idea to have a "smart" class to INHERIT which inherit subclasses conditionally, or if it's better to let users explicitly inherit the correct classes
bps has quit [Ping timeout: 264 seconds]
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
<vd>
one convenient scenario is to have core-image-minimal to work "out of the box" since it needs to inherit some classes to work with my layer, stuffs like that.
Pan5ky has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
bps has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
florian has quit [Quit: Ex-Chat]
<kergoth>
vd: It's a tough balance, ease of use vs too much implicit / magic behavior
nucatus has quit [Ping timeout: 260 seconds]
<khem>
vd: convenience classes serve purpose but are bad if overused
<khem>
oh hey kergoth
amitk has quit [Quit: leaving]
<zeddii>
online FOSDEM in 2022. :(
kiran has quit [Ping timeout: 258 seconds]
nucatus has joined #yocto
kiran has joined #yocto
nucatus has quit [Ping timeout: 260 seconds]
<moto-timo>
:(
<vd>
kergoth: khem: I agree with you, too much explicit makes it harder to maintain et evolve. A good documentation suggesting to add INHERIT in your local.conf would be better.
* zeddii
curses gmail for hiding email that I'm directly copied on
<vd>
an image feature can cause a class to be inherited, correct?
<vd>
like a common image class doing inherit ${@bb.utils.contains('IMAGE_FEATURES', 'foo', 'some-foo-class', '', d)}
nucatus has joined #yocto
nucatus has quit [Ping timeout: 260 seconds]
nucatus has joined #yocto
florian has quit [Ping timeout: 260 seconds]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<vd>
same topic, can a feature set IMAGE_FSTYPES?
wwilly has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
NiksDev has quit [Quit: Client closed]
nucatus has quit [Ping timeout: 260 seconds]
sakoman has joined #yocto
Pan5ky has quit [Ping timeout: 260 seconds]
whuang0389 has quit [Quit: Client closed]
<smurray>
vd: that's likely possible, whether it's a good idea or not is hard to say. IMO you really want to avoid using IMAGE_FEATURES outside of image recipes
<vd>
smurray: that'd be from inside a recipe. In other words, IMAGE_FEATURES += "foo" would implicitly make the image recipe inherit some-foo-class
<smurray>
vd: I'd have to think on that a bit more, but it doesn't seem unreasonable. Generally IMAGE_FEATURES is just pulling in packages via FEATURE_PACKAGES definitions, but there's no hard rules that I know of
lucaceresoli_ has joined #yocto
lucaceresoli has quit [Ping timeout: 264 seconds]
nucatus has joined #yocto
<vd>
as a concrete example, I would like to factorize code for systemd-based initramfs recipes, which involves: setting IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}", adding the systemd-initramfs package and adding a ROOTFS_POSTPROCESS_COMMAND function to link /etc/initrd-release. This could be a systemd-initramfs.bbclass, or an systemd-initramfs image feature
nucatus has quit [Ping timeout: 260 seconds]
lucaceresoli_ has quit [Ping timeout: 260 seconds]
florian has joined #yocto
<moto-timo>
FYI, the crops containers have been updated and pushed. Catch them all!
xmn has joined #yocto
nucatus has joined #yocto
nucatus has quit [Ping timeout: 260 seconds]
<RP>
JPEW: I think we needed the task dependency chains for something
<JPEW>
RP: but I really want my images in sstate! :)
<RP>
JPEW: you're trying to enable the sstate bypass code?
<RP>
JPEW: I know people complain whenever I remove image tasks :/
<RP>
JPEW: Not convinced about images from sstate (hence that code)
<JPEW>
RP: Ya, that's fair; I'm trying to see if I can optimize our CI builds to restore everything (images included) from sstate when nothing changes
<JPEW>
Basically, trade sstate size for trivial rebuild speed
<fray>
I get a lot of complaints from people about images from sstate-cache.. they thought it would rebuild the image..
<fray>
equally I've gotten complaints about NOT reusing it from sstate-cache..
<fray>
so I'm not sure we can in.. :P
kiran has quit [Ping timeout: 252 seconds]
rmmr has quit [*.net *.split]
madisox has quit [*.net *.split]
dtometzki has quit [*.net *.split]
sgw has quit [*.net *.split]
opello has quit [*.net *.split]
JaMa has quit [*.net *.split]
paulbarker has quit [*.net *.split]
cengiz_io has quit [*.net *.split]
Crofton has quit [*.net *.split]
troth has quit [*.net *.split]
marka has quit [*.net *.split]
opello has joined #yocto
JaMa has joined #yocto
marka has joined #yocto
troth has joined #yocto
madisox has joined #yocto
paulbarker has joined #yocto
rmmr has joined #yocto
cengiz_io has joined #yocto
Crofton has joined #yocto
dtometzki has joined #yocto
sgw has joined #yocto
<RP>
we probably can't. I know a lot of people aren't happy about the UI task numbers :/
<JPEW>
RP, fray: Ya, fair enough. It would be nice if users could enable it by overriding SSTATE_SKIP_CREATION. Anyway, my more egregious problem is that we have an image that depends on an SDK being built (... ya... it's *great*
<JPEW>
so we *really* need that SDK in sstate or it takes forever. Fortunately, that fix seems easy
zyga-mbp has joined #yocto
<vd>
We agree that PREFERRED_PROVIDER_virtual/kernel = "linux-dummy" cannot be set in an image recipe, right?
mvlad has quit [Remote host closed the connection]
<smurray>
vd: yes
<smurray>
vd: there's perhaps a chance it'd work if nothing else DEPENDed on virtual/kernel, but that's not true in practice
<vd>
that's really inconvenient, it would be sooo simpler to set the linux-dummy from the image rather than forcing us to use a multiconfig or something
sakoman has quit [Quit: Leaving.]
<smurray>
PROVIDES affects build dependencies, so it has to be in global scope
<smurray>
I can maybe imagine rigging up an image that gets no kernel bits with NO_RECOMMENDATIONS and overriding a bunch of variables
<vd>
smurray do you mean it's possible ?
nucatus has joined #yocto
<smurray>
vd: what's your usecase? In theory, you can tweak a bunch of things to prune IMAGE_INSTALL, but if you need to use core-image as a base with a bunch of DISTRO_FEATURES, it might be not straightforward
<moto-timo>
Global as in distro.conf, site.conf, auto.conf, local.conf etc
nucatus has quit [Ping timeout: 268 seconds]
angolini has quit [Quit: Connection closed for inactivity]
<vd>
smurray my use case is that I'm creating rootfs images which include container images that I had in ${IMAGE_ROOTFS}/var/lib/machines with a ROOTFS_POSTPROCESS_COMMAND
sakoman has joined #yocto
<vd>
and in theory, it shouldn't require to use a multiconfig to acheive this if your using the same distro/libc
<vd>
it's just a rootfs image without kernel or machine specific artifacts
<smurray>
vd: that's essentially how I install system containers in one of the types of AGL images, but we do use a multiconfig with linux-dummy for the guest image builds
<smurray>
vd: w/o linux-dummy you run into fun things like systemd RRECOMMENDing kernel modules, it's been a topic of recent discussion in AGL
<smurray>
vd: if you're doing app containers, I can imagine trying what you say, but it might take a bunch of tinkering
sakoman has quit [Quit: Leaving.]
<smurray>
vd: system containers might get fun since NO_RECOMMENDATIONS might turn off a bunch of stuff you do want, so then you need to work through that for every image
sakoman has joined #yocto
<vd>
smurray: I'm ok with a multiconfig but the problem is that then, you need to specify your container image with mc: and mcdepends, it fucks all your recipes
<vd>
I wish bitbake was smart enough to accept mc:foo:recipe:task from do_task[depends] directory
<smurray>
I just wrote a class for images that are going to pull in the guest containers so the mcdepends is really only in that one place
<smurray>
it's still early days for it in AGL, we'll probably evolve it some
<smurray>
and it's for a specific usecase that the instrument cluster expert group have come up with
<smurray>
note there's a bug in there wrt handling multiple guest images (need to add a space when appending to mcdepends), I was only testing with one when I cooked that up
<smurray>
vd: wrt to making depends handle mc dependencies, probably need RP to weigh in on why that's difficult
<vd>
smurray: you can write all your code with mcdepends and use mc:::recipe:task to use BB_CURRENT_MC, but again you have to adapt your code.
<smurray>
vd: if it's specifically for pulling one image into another I've not really found that to be a problem, tbh
<vd>
yep, I'll convert all my code to use this mcdepends syntax, but you have to add some smartness to prefix the image if it doesn't start with mc:: etc. Not really handy
<vd>
I meant, there's a bit of work to do here.
<smurray>
in my uses of multiconfig so far I've only ended up with one or two mcdepends required in the host, so I guess your usecase is a lot more involved
<smurray>
vd: if you ask again on Monday, some of the other folks that use mc like JPEW or somone from Xlilinx might have more ideas
florian has quit [Ping timeout: 258 seconds]
<vd>
I'm wondering if [mcdepends] = mc:::recipe:task is the same as [depends] = recipe:task, performance wise. If it is, it'd be nice to patch depends to add this fallback before ultimately having just one dependency declaration mechanism