<JosefHolzmayrThe>
wCPO: ok but what would you need the yp autobuilder for, then?
<JosefHolzmayrThe>
i mean - who would be the trigger, and who would be the builder?
rfuentess has joined #yocto
<wCPO>
JosefHolzmayrThe: I haven't thought it all through yet. We could use one of GitHub runners and a sstate mirror, to make it somehow fast. Maybe triggering a autobuilder build isn't worth it
<JosefHolzmayrThe>
wCPO: jon and me are both using gitlab ci/cd for various tasks, and its a pretty neat thing. no need for the autobuilder (and i'd guess most things you can do there also apply to GH actions)
<wCPO>
JosefHolzmayrThe: we use github for the "network effects" (or something like that), but I know gitlab CI can be used with github. Are the .gitlab-ci.yml files public?
<JosefHolzmayrThe>
wCPO: please note that especially the esdk-builder is one of my tinkering places, which may or may not be in a working state at any given point in time.
zyga-mbp has joined #yocto
ant__ has quit [Quit: Leaving]
eFfeM has joined #yocto
<eFfeM>
Hi all, I am having problems cloning meta-gplv2 due to a certificate issue, Is this a known problem?
<JosefHolzmayrThe>
eFfeM: manually or through google repo?
<eFfeM>
cloning using http works
<eFfeM>
JosefHolzmayrThe manually using the command I pasted
<JosefHolzmayrThe>
eFfeM: can't reproduce, work manually over https.
<eFfeM>
hmm, ok
<JosefHolzmayrThe>
eFfeM: yesterday we had a report of somebody else giving a similar problem for poky, but the asker blamed it on google repo which was in the build chain.
eFfeM64 has joined #yocto
<JosefHolzmayrThe>
eFfeM: anyways, i'll give the admin a heads up and ask to verify the cert chain if there is something unusual.
<eFfeM64>
got disconnected
<JosefHolzmayrThe>
Josef Holzmayr (TheYoctoJester) eFfeM: anyways, i'll give the admin a heads up and ask to verify the cert chain if there is something unusual.
<eFfeM64>
I tried this from the office network and it failed, disconnected from vpn (that is why I was disconnected from chat as well) but if I try on my local network it also fails
<eFfeM64>
JosefHolzmayrThe thanks
<JosefHolzmayrThe>
eFfeM64: what distro/release are you on?
eFfeM has quit [Ping timeout: 256 seconds]
<eFfeM64>
JosefHolzmayrThe I just tried to clone on ubuntu 20.04 under WSL, but actually we saw the issue first on our build agent
<JosefHolzmayrThe>
eFfeM64: and the agent uses?
eFfeM has joined #yocto
<eFfeM>
back again, I just tried on an ubuntu 20.04 system and there it worked
<JaMa>
do you have ca-certificates installed in WSL?
<alicef_>
eFfeM: check if works with "git config --global http.sslverify false" ?
eFfeM64 has quit [Ping timeout: 256 seconds]
<eFfeM>
JaMa JosefHolzmayrThe tried on build agent and there it now works, in WSL it still fails but indeed I have no ca-certificates installed there, will try
<JosefHolzmayrThe>
i wonder if there have been recent changes in ubuntu there.
<alicef_>
there have been recent changes in letsencrypt
<eFfeM>
JaMa ca-certificates were installed on WSL
<eFfeM>
alicef_ with setting http.sslverify to false it works
<alicef_>
if so is the ssl root certification probably broken. you should find a way of updating it for a "permanent" solution
<alicef_>
try to update ca-certificates package or try to use update-ca-certificates command
leon-anavi has joined #yocto
tnovotny has joined #yocto
<RP>
abelloni, kanavin: we should be ok on builds again now
<alicef_>
JosefHolzmayrThe: how do you open a yocto issue ? maybe we should document this
<JosefHolzmayrThe>
alicef_: there's a bugzilla
<alicef_>
link ?
<alicef_>
ah found
rfuentess has quit [Remote host closed the connection]
<rburton>
if you get TLS/SSL failures then you just need to update ca-certificates.
<qschulz>
jonmason: if the non-https downloads links are not in literal blocks, please use :yocto_dl: to replace them
rfuentess has joined #yocto
<qschulz>
I should say that on the ML, so will do
<qschulz>
which exists only for yocto-docs and not bitbake/docs
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
<eFfeM>
alicef_ rburton update-ca-certificates didnt fix it for me
<kanavin>
RP: PLATFORM:·noarch-unknown-linux vs PLATFORM:·noarch-pc-linux
<kanavin>
RP: seems like my build with TARGET_SYS changes could've poisoned the cache somehow? :-/
<kanavin>
really don't understand how it could happen - I never seen this before
<kanavin>
RP: also, only noarch packages
<kanavin>
RP: I can check how that header's value gets produced
<kanavin>
there might be undesirable leakage that wasn't triggered before
florian has joined #yocto
<kanavin>
RP: I had changed meta/site in my build and I think that isn't factored into sstate signatures
goliath has joined #yocto
<kanavin>
RP: let me see how rpm gets that value
tnovotny has quit [Quit: Leaving]
wCPO7 has joined #yocto
__ad has quit [Excess Flood]
ad__ has joined #yocto
<eFfeM>
alicef_ just want to let you know that updating ca-certificates did help, also with WSL. Stupid me forgot to do an apt-get update first :O
wCPO has quit [Ping timeout: 264 seconds]
wCPO7 is now known as wCPO
<eFfeM>
thanks for your help alicef_ JosefHolzmayrThe
<JosefHolzmayrThe>
np, have fun!
<eFfeM>
always :-)
<lukma>
Dear Community, Is there any reason that do_rootfs modify the ELF headers of programs?
<lukma>
In the "package" (or even in image directory) the ELF program seems not to be touched
<lukma>
but when I inspect it with readelf on the running rootfs, it has some offset added (to entry point value for example)
<JosefHolzmayrThe>
lukma: you probably have prelink enabled, then.
<michaelo>
Hello. Any reason for having the sstate.yoctoproject.org available only though http, not https?
<lukma>
JosefHolzmayrThe: Thanks for the hint
<lukma>
I will investigate this :-)
<JosefHolzmayrThe>
have fun!
<kanavin>
RP: still not sure. that field is written into rpms during package_write_rpm, the task depends on rpm-native:populate_sysroot, that depends on rpm-native:configure, that depends on BUILD_SYS, which depends on BUILD_VENDOR
<RP>
kanavin: I was wondering if it could have been cross pollution but in the sstatesig patch, I changed sstate version and hash equiv version so it shouldn't have been that, just bad timing I think
<RP>
kanavin: I'm wondering if my changes meant noarch was being crossed between musl and non-musl or something
<RP>
kanavin: it could also be arm host somehow i guess
Nalgas has joined #yocto
jonatan has joined #yocto
<RP>
kanavin: what is the command to view an rpm's tags? I'm sure I did know at some point :/
<jonatan>
Hi everyone. I am setting up a project with a lot of python packages, several of which depend on the Poetry build tool. Yocto doesn't have any poetry-native support yet, right?
<RP>
jonatan: the layer index would be the best place to check and see if it exists anywhere
<rburton>
oh great another "useful" tool
kpo has quit [Read error: Connection reset by peer]
<qschulz>
rburton: there's flit also for python packages :)
<JosefHolzmayrThe>
rburton: cue xkcd "standards"
<jonatan>
Ah, I haven't actually seen the layer index before. That's nice. But nothing with Poetry, it looks like
<rburton>
poetry looks like it does everything possible to be actively hostile to traditional distributions
kpo has joined #yocto
<RP>
kanavin: I'm pretty sure it is arm host built rpms vs those built on x86
<jonatan>
First bad things I hear about poetry, to be honest - but also my first time using it with Yocto. It doesn't play well with buildroot, either
<kanavin>
RP: right, meanwhile the rust target issue seems to be down to just mozjs trying to be clever (and failing), it's not rust-wide :)
<RP>
kanavin: just going off "strings <rpm>" I see noarch-unknown-linux on arm and pc-linux on x86
<RP>
kanavin: I wonder what we should force this value to. Probably "pc" looking at the platform files
<kanavin>
mozjs is calling out to some GNU config.sub nonsense to canonicalize the system name, GNU script adds -gnu to the name, and then that's used as a rust target
<RP>
kanavin: ah, config.sub is rather gnu centric
<kanavin>
I guess I can patch that out, just need to find where
<kanavin>
RP: I suspect those names are provided by the same config.sub, but this time in rpm-native's configure
<kanavin>
you can run it directly to see what it prints
<kanavin>
for rpm, we can simply set --vendor btw
<RP>
kanavin: I think it is way worse, see the rpm/platform/ files. There is no aarch64 one
<RP>
kanavin: but yes, I think we can just code it
<kanavin>
RP: those are dynamically generated
<kanavin>
RP: the value is determined as RPMCANONVENDOR at do_configure
<RP>
kanavin: dynamically generated from what? :/
<kanavin>
${S}/platform.in
<RP>
kanavin: good news, setting _vendor does fix it on the arm worker
<kanavin>
RP: I guess we can just add --vendor=${TARGET_VENDOR} to ./configure
<kanavin>
RP: --with-vendor, exactly
<RP>
kanavin: yes, that would help with determinism I guess
<RP>
kanavin: that also works in testing so I'll send a patch as it is probably the better fix, thanks!
<kanavin>
RP: cheers
<kanavin>
RP: nice coincidence that I am sorting the same issue in mozjs, so have a 'hot cache' in my head ;)
<RP>
kanavin: yes, and ironic you were poking this system wide so it looks like corruption but isn't
<RP>
rburton: it suggests output on the arm workers isn't being well reused on x86 until now, quite interesting
gourve_l has quit [Ping timeout: 260 seconds]
<rburton>
ah interesting
<RP>
rburton: and always norarch only since we don't build x86 on arm and we test reproducibility with an x86 target
<kanavin>
RP: you opted for 'pc'? I guess it doesn't matter.
<RP>
kanavin: it is the value we've had everywhere so far
<kanavin>
RP: right, I'm just a bit worried that this mismatch will come up somewhere
<kanavin>
(pc vs poky)
<kanavin>
but I guess it hasn't until now
gourve_l has joined #yocto
<RP>
kanavin: I suspect there is a much bigger chance there is rpm magic that looks for "pc"
jmiehe has joined #yocto
<CocoJoe>
is it possible to verify a wic with bmap without doing antyhing else?
<JosefHolzmayrThe>
CocoJoe this is mostly a bmap topic I guess, but at least it's manpage mentions nothing like it.
gourve_l has quit [Ping timeout: 265 seconds]
gourve_l has joined #yocto
nucatus has joined #yocto
<nucatus>
hello! What is the yocto way of configure a specific package to use a predefined configuration file based on the image it is built? For instance, if imgA is built, our package would install /etc/confA file, and if imgB is built, out package would install the /etc/confB
ad__ has joined #yocto
ad__ has quit [Changing host]
<JosefHolzmayrThe>
nucatus: none, because thats not how it works. the package recipe has no way of knowing the image in question (think, what would happen if you build two images? or none?)
jwillikers has joined #yocto
<JosefHolzmayrThe>
nucatus: one common way would be to provide seperate recipes, where the images only pull in one each.
<JosefHolzmayrThe>
shared things can go into an include that the packages all use.
<JosefHolzmayrThe>
an alternative are distro flags.
<qschulz>
JosefHolzmayrThe: you could have two packages only from the same recipe (provided the paths of both config files are different, otherwise need to play with pkg_post_inst and RCONFLICTS between the two packages, but not impossible)
<JosefHolzmayrThe>
qschulz: sure, one recipe can provide multiple packages too.
<nucatus>
ok. I think it makes sense now
<JosefHolzmayrThe>
when did it not make sense? ;-)
jwillikers has quit [Remote host closed the connection]
<nucatus>
it was not clear for me whether the image is a proper place to make such configuration
<qschulz>
nucatus: an image is still a recipe and recipes cannot impact other recipes
jwillikers has joined #yocto
mckoan is now known as mckoan|away
xmn has joined #yocto
bunk has quit [Quit: leaving]
bunk has joined #yocto
<jonmason>
qschulz: the yocto_dl is only for inside documentation, correct?
<qschulz>
so, basically any section starting with :: (can be at the end of a sentence, or at the beginning of the line)
<jonmason>
qschulz: looking over the changes, I think all but maybe one hyperlink is in a block
<qschulz>
and MAYBE (haven't checked), the sections started by .. code-block::
<qschulz>
jonmason: not RTFM, I always link the docs in case I misinterpreted (and also for reference :) )
<jonmason>
honestly, it's probably why they were http and not replaced anyway
<jonmason>
qschulz: not offended, just joking around
<qschulz>
jonmason: the shortest way to figure this out is to run make before your changes, then after, then do a git diff or meld on that output and see if the changes are what you wanted in the first place
<qschulz>
if the :yocto_dl: extlink is not replaced, it'll be obvious to the eye :)
<qschulz>
jonmason: I had guessed :)
<qschulz>
jonmason: the thing we COULD do is replace those with an entry in poky.yaml instead
<qschulz>
which would be something like &YOCTO_DL; and then it would work, because we change those and not sphinx (well, it's part of sphinx process but we do it manually, without sphinx help)
<qschulz>
s/change/replace
<qschulz>
which incidentally also only exists in yocto-docs and not bitbake :)
<qschulz>
I think a search and replace will do for now :)
<jonmason>
qschulz: so, what I'm hearing is that for documentation, I should add the yocto_dl and similar into poky.yaml, then replace everything in the blocks with that
<qschulz>
does not apply to bitbake/docs unfortunately
<jonmason>
yes, and I've many changes there as well
sakoman has joined #yocto
Flumpy33 has joined #yocto
<qschulz>
michaelo: we need a download button on docs.yoctoproject.org for the epub and pdf now :)
rob_w has quit [Remote host closed the connection]
eFfeM has quit [Quit: Client closed]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
paulg has joined #yocto
zen_coder has joined #yocto
zyga-mbp has quit [Ping timeout: 265 seconds]
<kanavin>
RP: new master-next a-full started without stopping the previous one, is that intentional?
zyga-mbp has joined #yocto
kiran has joined #yocto
goliath has quit [Quit: SIGSEGV]
jonatan has quit [Quit: Leaving]
artri has joined #yocto
Flumpy33 has quit [Ping timeout: 246 seconds]
atril has joined #yocto
artri has quit [Ping timeout: 265 seconds]
dev1990 has joined #yocto
Nalgas has quit [Ping timeout: 256 seconds]
zyga-mbp has quit [Ping timeout: 245 seconds]
zyga-mbp has joined #yocto
zyga-mbp has quit [Ping timeout: 245 seconds]
zyga-mbp has joined #yocto
manuel1985 has joined #yocto
sstiller has quit [Quit: Leaving]
<ad__>
how can i overlay a bbclass of a lower layer in my bsp layer ?
Nalgas has joined #yocto
zyga-mbp has quit [Read error: Connection reset by peer]
<ad__>
i just tried with same bbclass name inside my layer, in /classes , but does not work
iokill_ is now known as iokill
Schlumpf has quit [Quit: Client closed]
zyga-mbp has joined #yocto
<qschulz>
ad__: you're not supposed to do it
<ad__>
qschulz, ok, i created a custom class and inherited it
<qschulz>
yup, that works :)
leon-anavi has quit [Quit: Leaving]
zyga-mbp has quit [Read error: Connection reset by peer]
zyga-mbp has joined #yocto
<vd898>
kinda existential question: does "core" in recipes-core originally came from the "core" layer (OE-Core) and was then cargocult used by other layers or does "core" as another meaning here?
<rburton>
recipes-core are recipes that are core to a system
<rburton>
recipes-* are basically arbitrary namespaces
<moto-timo>
vmeson: python3-cryptography 3.4.8 (really it's setuptools-rust/pyo3) is failing on musl. it ends up trying to rebuild the rust code in do_install and I don't know why.
<moto-timo>
vmeson: and python3-cryptography 35.0.0 uses a newer version of pyo3 (0.14.5) that only seems to work on host == target
<moto-timo>
vmeson: plus tgamblin is seeing the "rebuild in do_install" even on qemux86-64 which seems somehow to be host dependent :/
<vd898>
when you change a recipe's PACKAGECONFIG, do_configure is naturally triggered again, but does do_compile restart from scratch or from the previous compilation?
<RP>
kanavin: yes, testing two things in parallel
<qschulz>
vd898: tasks are organized in a tree
<qschulz>
all leaf nodes to the current task are retriggered if current task is modified
<qschulz>
and do_compile depends on do_configure so yes
<qschulz>
except... if you have hashequiv server running and two different do_configure actually output the exact same thing, in which case the sstate-cache of compile is used
<rburton>
vd898: most recipes do out-of-tree builds so on configure the build tree is entirely deleted. some recipes don't support that, so you don't get a guaranteed build from clean.
<qschulz>
oh, completely missed the question I see :)
rfuentess has quit [Remote host closed the connection]
xicopitz[m] has quit [Quit: You have been kicked for being idle]
leon-anavi has joined #yocto
xmn has quit [Ping timeout: 245 seconds]
zpfvo has quit [Quit: Leaving.]
xmn has joined #yocto
<vmeson>
moto-timo: is that using buildall-qemu ? I see a glibc then musl failure for rust-hello-world. pgowda_ is working on that...
user_ has quit [Remote host closed the connection]
user123 has joined #yocto
<pgowda_>
A patch is posted as well as per Richard's (RP) suggestions that fixed the issue..
janvermaete[m] has quit [Ping timeout: 260 seconds]
khem has quit [Ping timeout: 260 seconds]
Nate[m]1 has quit [Ping timeout: 260 seconds]
saYco[m] has quit [Ping timeout: 260 seconds]
berton[m] has quit [Ping timeout: 260 seconds]
jmiehe has quit [Ping timeout: 265 seconds]
bantu_ has quit [Ping timeout: 264 seconds]
Spectrejan[m] has quit [Ping timeout: 260 seconds]
bantu has joined #yocto
bunk has joined #yocto
chrfle_ has joined #yocto
chrfle has quit [Ping timeout: 252 seconds]
chrfle_ is now known as chrfle
<RP>
rburton: Sstate summary: Wanted 2672 Local 0 Network 2657 Missed 15 Current 0 (99% match, 0% complete)
<RP>
JPEW: that hack in bitbake master-next does look to solve the problem
<JPEW>
RP: cool
<RP>
(the 15 was base-files rebuilding as I changed the branch head)
Barry[m] has joined #yocto
berton[m] has joined #yocto
Vonter has quit [Quit: WeeChat 3.2]
agherzan has joined #yocto
Vonter has joined #yocto
vd898 has quit [Quit: Client closed]
vd898 has joined #yocto
fabatera[m] has joined #yocto
saYco[m] has joined #yocto
Nate[m]1 has joined #yocto
janvermaete[m] has joined #yocto
<kanavin>
RP: right, I'll wait :)
Spectrejan[m] has joined #yocto
<RP>
kanavin: I have yet another queued too. Trying to sort a few last minute changes and test a key bugfix in isolation
<moto-timo>
vmeson: pgowda_: this was with multiconfig building qemux86-64, qemux86-musl and qemuarm64
khem has joined #yocto
<RP>
kanavin: I did stop the earlier one now we have the needed data from it (the noarch stuff is corrupt in sstate right now :( )
<RP>
I feared that was the case
<moto-timo>
vmeson: pgowda_: to be clear, it is something specific in setuptools-rust and/or pyo3 (the rust bindings for python). Not obviously a problem with rust stack in oe-core.
florian has quit [Quit: Ex-Chat]
<jonmason>
qschulz: thanks for the reviews. patch 7/8 should address what you were mentioning this morning
<vmeson>
moto-timo: ok, thanks for the heads up. there's an uprev of rust to 1.55 in kanavin's poky-contrib tree so you might try that just for fun. pgowda_ says it fixed: DEBUG_BUILD = "1" for rust.
<kanavin>
a lot of other rust fixes too
<kanavin>
latest greatest librsvg and mozjs build ok now :)
<kanavin>
mozjs in particular would've prevented python 3.10 otherwise :-/
<kanavin>
(staying with old rustless one)
<kanavin>
and one can't just blacklist it, because polkit needs it
Ad0 has joined #yocto
CocoJoe has joined #yocto
<moto-timo>
kanavin: great work. I'll try my 2 branches rebased that as well.
<moto-timo>
1 branch is python3-cryptography 3.4.8 which was working for me except musl (but tgamblin had trouble on F34 on qemux86-64 for _reasons_). The other is 35.0.0 which upgrades pyo3 and is failing in other ways...
<moto-timo>
either way, they aren't landing in honister branches anymore I assume so punt to kirkstone
* moto-timo
might go back to phosh for a bit
frieder has quit [Remote host closed the connection]
kpo has quit [Read error: Connection reset by peer]
<vd898>
I was wondering about package configuration. Some recipes like systemd and (meta-arago) qtbase have a ${PN}-conf package to deploy /etc files. Similarly to ${PN}-dev, should ALL package have a ${PN}-conf package so that any package can be easily configure by users and distros?
<vd898>
RP: ^
<vd898>
(or at least a conf.bbclass that one can inherit from a bbappend or from INHERIT so that it activates ${PN}-conf package(s))
kpo has joined #yocto
manuel1985 has quit [Quit: Leaving]
xmn has quit [Quit: ZZZzzz…]
roussinm has quit [Quit: WeeChat 3.3-dev]
pgowda_ has quit [Quit: Connection closed for inactivity]
<RP>
I'm not even sure it would be straight forward to do in the general case
<vd898>
so a conf.bbclass which adds a ${PN}-conf package and e.g. CONF_FILES to fetch from SRC_URI would make sense for huge package like systemd then?
* RP
realises that agl certificate problems took out my queued builds :(
<khem>
vd: re qtlocation, is that due to -fcommon flag ?
<smurray>
RP: I believe dl9pf fixed the certificates on the AGL hosting, yes
<RP>
smurray: I'm just a bit worried that takes out our builds :(
vquicksi1 has quit [Quit: WeeChat 3.1]
<khem>
vd898: I would question the benefits of doing so. I can see multi init system setups but then now a days packages have systemd support in more than conf files
vquicksilver has joined #yocto
<smurray>
RP: he's been on vacation (back next week AIUI), and I've no access to that side of the infra, so if you're seeing issues today, it might be a problem unless he checks irc / email
<RP>
smurray: I think it is fixed now, this build is running past the failure poin
<RP>
smurray: I'd just expected to see a build 2.5 hours in now :/
<smurray>
RP: I notice it's a debian 8 builder, I guess the new ca-certificates is in the buildtools?
<RP>
smurray: yes, should be
<smurray>
RP: it clones with that URI here, so a bit puzzling
<RP>
and in searching for that I found another bug I think I accidentally fixed
<RP>
hmm, actually not :(
<JaMa>
vd898: because foo-conf will be MACHINE_ARCH while main package can stay TUNE_PKGARCH (shared between multiple machines)
<JaMa>
you can even add foo-conf to main package RDEPENDS as long as it's just config file without any ABI different between machines (and you add it to SIGGEN_EXCLUDERECIPES_ABISAFE or SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS), I was using it quite havily in meta-fso (long time ago)
<JaMa>
making qtbase (and everything which depends on it like qtwebengine) effectivelly MACHINE_ARCH is BAD especially when the only reason is small MACHINE specific config file you were too lazy to ship in separate recipe
<marex>
RP: that bug 14466 , i.e. enabling fno-semantic-interposition , does not really do the 1.3x trick, does it ?
<vd898>
JaMa: that's why I'm proposing that OE-Core provides something like that, like a conf.bbclass to easily add machine specific configuration files to an arch specific package
<RP>
marex: well, our hope is that it would
<RP>
marex: your tests suggest it doesn't
<marex>
RP: I tried, it does not (as-is)
<marex>
yep
<marex>
but then, maybe I messed something up ?
<RP>
marex: I've not tried it. I really have my hands full at the moment
<marex>
RP: for me it isnt urgent
nucatus has quit [Remote host closed the connection]
<marex>
RP: so ... no stress ?
<RP>
marex: could you add a comment about what you tried and how you measured the speed?
<RP>
marex: we may as well collect the data we have in the bug
<RP>
marex: I'm sure one of us will get to having a look at it at some point
nucatus has joined #yocto
<marex>
RP: yea....have my hands full too, I'll just add it to my roll of todo paper
nucatus has quit [Ping timeout: 260 seconds]
goliath has joined #yocto
florian has quit [Ping timeout: 260 seconds]
zkrx has quit [Ping timeout: 265 seconds]
<override>
whats the difference between RDEPENDS and RECOMMENDS
<vd898>
override RDEPENDS lists packages that are necessary for the program to run properly (otherwise it may fail) and RRECOMMENDS list package that are not crucial for the execution of the program but that you are likely to want (like plugins for example)
nucatus has joined #yocto
nucatus has quit [Ping timeout: 260 seconds]
jmiehe has joined #yocto
<halstead>
RP: I Debian 8 is running openssl 1.0.1t-1 but the new certs need openssl 1.1.0 or later. I think we need to retire debian 8. I can replace it with Debian 11.
Vonter has quit [Ping timeout: 260 seconds]
Jon96 has quit [Quit: Client closed]
Vonter has joined #yocto
nucatus has joined #yocto
<RP>
halstead: I think buildtools have that covered but retiring I think makes sense at this point
<RP>
debian8 has done well but... :)
roussinm has joined #yocto
<RP>
halstead: oh, I think I understand - the checkout is happening with the host's certs as buildtools isn't present yet
<RP>
If the certs are the issue there then yes, we should retire
nucatus has quit [Ping timeout: 260 seconds]
jwillikers has quit [Remote host closed the connection]
JPEW has quit [Ping timeout: 246 seconds]
halstead has quit [Ping timeout: 252 seconds]
georgem has quit [Ping timeout: 252 seconds]
cengiz_io has quit [Ping timeout: 240 seconds]
Crofton_ has quit [Ping timeout: 252 seconds]
madisox has quit [Ping timeout: 260 seconds]
ldts has quit [Ping timeout: 260 seconds]
armpit has quit [Ping timeout: 260 seconds]
flynn378 has quit [Ping timeout: 240 seconds]
dagmcr has quit [Ping timeout: 246 seconds]
moto-timo has quit [Ping timeout: 240 seconds]
bradfa has quit [Ping timeout: 250 seconds]
aeroraptor has quit [Ping timeout: 260 seconds]
darknighte has quit [Ping timeout: 268 seconds]
rsalveti has quit [Ping timeout: 246 seconds]
NishanthMenon_ has quit [Ping timeout: 246 seconds]
xtopher_ has quit [Ping timeout: 260 seconds]
rmmr has quit [Ping timeout: 260 seconds]
awafaa has quit [Ping timeout: 260 seconds]
mithro has quit [Ping timeout: 260 seconds]
fancer has quit [Ping timeout: 260 seconds]
smurray has quit [Ping timeout: 260 seconds]
elfenix|cloud has quit [Ping timeout: 260 seconds]
Tartarus has quit [Ping timeout: 268 seconds]
angolini has quit [Ping timeout: 246 seconds]
thierryE has quit [Ping timeout: 246 seconds]
ernstp has quit [Ping timeout: 268 seconds]
jonmason has quit [Ping timeout: 252 seconds]
CosmicPenguin has quit [Ping timeout: 246 seconds]
paulbarker has quit [Ping timeout: 260 seconds]
nohit has quit [Ping timeout: 260 seconds]
smurray has joined #yocto
behanw has quit [Ping timeout: 268 seconds]
madisox has joined #yocto
dl9pf has quit [Ping timeout: 260 seconds]
jamestperk has quit [Ping timeout: 264 seconds]
ndec_ has quit [Ping timeout: 268 seconds]
rburton has quit [Ping timeout: 268 seconds]
YogeshSiraswar_ has quit [Ping timeout: 268 seconds]
<marex>
tgamblin: the dumb "add -fno-semantic-interposition to CFLAGS/LDFLAGS" approach does not work
<marex>
there must be something more
ant__ has joined #yocto
georgem has joined #yocto
halstead has joined #yocto
darknighte has joined #yocto
JPEW has joined #yocto
leon-anavi has quit [Quit: Leaving]
dev1990 has quit [Quit: Konversation terminated!]
<manuel_>
Can I have graphics acceleration in qemux86-64?
<manuel_>
Am using wayland.
<JPEW>
manuel_: Yes, using virtio
<manuel_>
JPEW: Archlinux wiki says I have to start qemu with -vga virtio. Does runqemu does this? Guess I can change the default qemu options using some variable