alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
manuel1985 has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
kanavin has joined #yocto
zpfvo has joined #yocto
<qschulz>
o/
<qschulz>
sakoman: 7e64b63f96dd1d71e263e7bbbe6591e51e98395a would be needed in oe-core too
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
beneth has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
xmn has quit [Ping timeout: 268 seconds]
nemik has quit [Ping timeout: 265 seconds]
xmn has joined #yocto
nemik has joined #yocto
florian has joined #yocto
<RP>
rburton: I stopped and restarted the build to get the clang fix into testing since I suspect you'd prefer that in the release
jclsn[m] has quit [Quit: You have been kicked for being idle]
alimon has joined #yocto
Ram-Z has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
Ch^W_ has quit [Ping timeout: 268 seconds]
Ch^W has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<rburton>
RP: yes, that's useful, thanks
<rburton>
hm
<rburton>
what changed in kirkstone in the last week that would mean pzstd is crashing all over the place
<rburton>
ah, all on the same runner
<rburton>
i bet it has a full disk :)
<JaMa>
my 4TV disks are always full even with rm_work :)
<JaMa>
4TB
<rburton>
this was an emergency worker as CI was struggling, the work disk is only 400gb :)
<JaMa>
hmm wouldn't fit my downloads dir :) but I guess it uses NFS for downloads and sstate
<rburton>
it was sstate the filled it up :). the meta-arm CI runs are a lot smaller than your monsters
* JaMa
had to stop running world builds after loosing access to 10+ servers
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
mckoan is now known as mckoan|away
jkorsnes has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<jkorsnes>
FOO_remove = " bar" # i see that space prepended lots of places, but the docs says "When you use this syntax [_remove], BitBake expects one or more strings. Surrounding spaces are removed as well.". It's not clear to me why this space is needed
<rburton>
for remove, it's not needed
<jkorsnes>
i suppose the doc might be refering to spaces in FOO, and not in the string literal
<jkorsnes>
rburton: thanks!
<rburton>
remove basically does .split() on the string you pass, so the string is turned into a list of items
<jkorsnes>
rburton: thanks, that clarifies. also happy to hear that's how it works, dealing with such spaces would seem error prone. but _remove is replaced with :remove in newer versions of yocto if my understanding is correct
<rburton>
yes
<JaMa>
jkorsnes: it's not just :remove many other places as well and there is a conversion script which helps with that (the result needs manual review as there are often some false positives or your own overrides need to be added into the script)
<jkorsnes>
the Release 3.4 (honister) migration override syntax example seems to get this wrong
<jkorsnes>
or do we have to keep the space with `:remove` syntax?
<rburton>
RP: i'm squinting at the gcc default target arch patch and trying to understand what the problem here is
<jkorsnes>
i would hope that used the same .split() approach as _remove
<rburton>
jkorsnes: its identical code, the syntax just changed
jkorsnes has quit [Read error: Connection reset by peer]
kriive has quit [Remote host closed the connection]
jkorsnes has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
jkorsnes has quit [Quit: leaving]
johankor[m] has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<johankor[m]>
JaMa: so nothing wrong in doc per se, but preferably the space shouldn't be there after (or before either, really) the conversion. but this is just nitpick; trying to verify that my understanding is correct
<qschulz>
johankor[m]: that's correct
<johankor[m]>
not my intention to complain. i'll gladly submit a patch, but this is such a minor thing, such patches would likely just be noise on the mailing list i guess
<rburton>
johankor[m]: documentation improvements are always welcome
<qschulz>
johankor[m]: the fact is, this was confusing to some people, so even if it looks like a minor patch, it can be a nice improvement!
<ThomasRoos[m]>
Hi, how to see debug logs (log level debug) when running devtool?
xmn has quit [Ping timeout: 265 seconds]
odra has joined #yocto
GNUmoon has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
ptsneves has joined #yocto
goliath has joined #yocto
<vvn>
Hi all -- If I set PACKAGE_EXCLUDE += "systemd-container", I end up with "package systemd-1:250.4-r0.abc requires systemd-container, but none of the providers can be installed", is that expected?
<qschulz>
vvn: if systemd package depends on systemd-container, yes
<vvn>
qschulz: but I can't find that explicited anywhere, hence my confusion
<rburton>
interesting. it's not in the package explicitly, so there must be a library causing that linkage
rob_w has quit [Remote host closed the connection]
<rburton>
vvn: in master systemd doesn't depend on systemd-container
binance_group[m] has joined #yocto
<vvn>
rburton: I wasn't aware of such scenarios. Do you have systemd-container pulled in in a systemd-based build as well with kirkstone?
<rburton>
do you have an old release? ae3c8d938c261c92ecf06e2d09f7e32bc117ceb8 looks relevant
alessioigor has quit [Remote host closed the connection]
<vvn>
rburton: nope, I'm on ca1c990
<rburton>
you should debug that then :)
<rburton>
the do_package log will talk about dependencies it adds
<vvn>
rburton: indeed, that's my reason for asking, not sure yet where to look at. Is rm_work affecting such debugging or not?
<rburton>
no
<vvn>
thanks, I'll dig into do_package log then.
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<vvn>
rburton: btw I think you worked on allowing RDEPENDS:${KERNEL_PACKAGE_NAME}-base = "" to exclude kernel-image from the rootfs, but 1) I have to clear RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base instead, 2) it still pulls in ${KERNEL_PACKAGE_NAME}-${KERNEL_VERSION} and ${KERNEL_PACKAGE_NAME}-devicetree
<rburton>
patches welcome :)
<vvn>
as always, but I prefer to make sure that I'm on the right track and that's not once again a code 18
<Tyaku>
Hi, I have a strange error when building an image: The following packages have unmet dependencies: kernel-module-jailhouse-5.10.52-lts-5.10.y-az-p01+gf6373dc3d66e : Depends: kernel-5.10.52-lts-5.10.y-az-p01+gf6373dc3d66e but it is not installable
<Tyaku>
Some packages could not be installed. This may mean that you have
<Tyaku>
distribution that some required packages have not yet been created
<Tyaku>
requested an impossible situation or if you are using the unstable
<Tyaku>
or been moved out of Incoming.
<Tyaku>
Do you have any ideas about what appens ? The error is during the do_rootfs() so realy at the end
<rburton>
Tyaku: the log further up should explain why that package isn't installable
<Tyaku>
Oh wait, I have another issue now, well I'm going to check all this mess
<Tyaku>
If you have an idea, you will save my day :d
<Tyaku>
When I execute the commande I see the error:
<rburton>
the actual log.do_rootfs has more information in
<Tyaku>
W: Unable to read /......./tmp/work/x86_64-linux/apt-native/2.2.2-r0/recipe-sysroot-native/etc/apt/apt.conf.d/ - DirectoryExists (2: Aucun fichier ou dossier de ce type)
<Tyaku>
W: Unable to read /......./tmp/work/x86_64-linux/apt-native/2.2.2-r0/recipe-sysroot-native/etc/apt/sources.list.d/ - DirectoryExists (2: Aucun fichier ou dossier de ce type)
<Tyaku>
W: Unable to read /......./tmp/work/x86_64-linux/apt-native/2.2.2-r0/recipe-sysroot-native/etc/apt/sources.list - RealFileExists (2: Aucun fichier ou dossier de ce type)
<Tyaku>
E: Could not open lock file /......./tmp/work/x86_64-linux/apt-native/2.2.2-r0/recipe-sysroot-native/var/lib/dpkg/lock-frontend - open (2: Aucun fichier ou dossier de ce type)
<Tyaku>
All this mess come after that I remove the build/tmp directory to start a fresh build.
<Tyaku>
So I think something has not been regenerated correctly
<rburton>
tbh, apt is the least tested backend, i tend to recommend opkg unless you have a very strong reason to use apt
<Tyaku>
For example in "tmp/work/x86_64-linux/apt-native/2.2.2-r0" I don't have recipe-sysroot-native
<rburton>
it really shouldn't be trying to read from that location
<rburton>
honestly, switch to opkg unless you have a business need for apt on target
<Tyaku>
No we don't need apt on target,
<Tyaku>
So Ok, I'm going to change, but previously it was working (before removing the /tmp folder)
<rburton>
is this master, kirkstone, or what?
<Tyaku>
5.10-hardknott
<rburton>
you know that's EOL, right
<Tyaku>
yes
Minvera has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
xmn has joined #yocto
zpfvo has quit [Quit: Leaving.]
<ptsneves>
I just noticed there can be multiple SRCREVs set for a given repo. Is this by design?
<khem>
so it can override, its like any other variable I guess
<rburton>
ptsneves: given *repo*, no. a *recipe* can fetch multiple git repos and they each need a srcrev though.
<ptsneves>
ok maybe better. SRCREV have logic to check specifically for SRCREV_%s:pn-%s" % (name, pn) , "SRCREV_%s" % name, "SRCREV_%s" % name and only lastly SRCREV as a normal variable behavior. They are evaluated in order.
nemik has quit [Ping timeout: 264 seconds]
<rburton>
name is the name of the repo in the SRC_URI
<ptsneves>
yes. but the code will give priority to the SRCREV with pattern before SRCREV, meaning it goes through a list and the first hit is the chosen SRCEV: I thought this was a mistake, but i just found a nice use case for this
<ptsneves>
yes i do not mean that. I mean that for a given repo name there are several notations and some notations have priority. For example SRCREV_<name>:pn-<pn> will trump any setting. This is cool, but i wonder if it is on purpose
Minvera has joined #yocto
nemik has joined #yocto
<rburton>
kanavin: can you backport "local.conf.sample: correct the location of public hashserv" to kirkstone
ecdhe has quit [Read error: Connection reset by peer]
<kanavin>
rburton, sure but why ask me if it's a single trivial patch?
<rburton>
because i'm about to leave and you sent it :)
ecdhe has joined #yocto
<rburton>
if i don't see it on the list tomorrow i'll hopefully remember
Estrella__ has joined #yocto
<kanavin>
rburton, sent
alessioigor has quit [Quit: alessioigor]
<rburton>
kanavin: my hero
alessioigor has joined #yocto
<rburton>
grumble, why is kirkstone only getting 4% sstate match on the public server
<kanavin>
rburton, I did similar tests, and the hit rate was also both low and non-deterministic (!)
Estrella has quit [Read error: Connection reset by peer]
leon-anavi has quit [Quit: Leaving]
<rburton>
kanavin: last time i tried i managed to get it to hit 100%. something is fragile...
<kanavin>
rburton, yes, and no one to take care of it
florian has quit [Quit: Ex-Chat]
<sakoman>
rburton: kanavin: heh, I had just cherry-picked that patch :-)
vladest has quit [Remote host closed the connection]
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
dmoseley has joined #yocto
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
ecdhe has joined #yocto
Ad0 has quit [Ping timeout: 252 seconds]
Ad0 has joined #yocto
odra has quit [Read error: Connection reset by peer]
odra_ has joined #yocto
rabbi[11] has joined #yocto
amitk has quit [Ping timeout: 260 seconds]
Guest3770 has joined #yocto
<Guest3770>
I have a build script that runs fine in Ubuntu using autogen.sh, configure.ac and makfile.am. When I attempt to make my application with bitbake I start getting errors. Is anyone open for support
mvlad has quit [Remote host closed the connection]
<rburton>
Guest3770: presuming your recipe just inherits autotools? Share the errors.
<Guest3770>
It does inherit autotools in my bb file
<Guest3770>
In file included from /home/michael/Documents/MAIN_Application/build-fb/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/mainapplication/0.0-r0/recipe-sysroot/usr/include/boost/config/detail/select_stdlib_config.hpp:24,
<Guest3770>
from /home/michael/Documents/MAIN_Application/build-fb/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/mainapplication/0.0-r0/recipe-sysroot/usr/include/boost/config.hpp:44,
<Guest3770>
from /home/michael/Documents/MAIN_Application/build-fb/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/mainapplication/0.0-r0/recipe-sysroot/usr/include/boost/smart_ptr/bad_weak_ptr.hpp:20,
<Guest3770>
from /home/michael/Documents/MAIN_Application/build-fb/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/mainapplication/0.0-r0/recipe-sysroot/usr/include/boost/smart_ptr/detail/shared_count.hpp:25,
<Guest3770>
from /home/michael/Documents/MAIN_Application/build-fb/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/mainapplication/0.0-r0/recipe-sysroot/usr/include/boost/smart_ptr/shared_ptr.hpp:17,
<Guest3770>
from /home/michael/Documents/MAIN_Application/build-fb/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/mainapplication/0.0-r0/recipe-sysroot/usr/include/boost/shared_ptr.hpp:17,
<Guest3770>
from ./vendor/carmedialab/SMG/trunk/ISO15118_Stack/sources/EV/state/IsoStatesMachine.h:6,
<Guest3770>
from ./include/CML_Integration/cml_integration.hpp:18,
<Guest3770>
from src/main.cpp:13:
<Guest3770>
./version:1:1: error: too many decimal points in number
<rburton>
That’s entirely on you
<Guest3770>
In what way? I only included a file, I did not write the "version" header file
<Guest3770>
I admit I have an issue here, but I cannot figure out why what I am including gives me this error
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
Andrew20 has quit [Quit: Client closed]
<rburton>
Well first figure out where it came from :)
ecdhe has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
* RP
tries a 4.1 rc1 build
kevinrowland has joined #yocto
ecdhe has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
argonautx has joined #yocto
ecdhe has joined #yocto
argonautx has quit [Client Quit]
Minvera has quit [Remote host closed the connection]
kscherer has quit [Ping timeout: 264 seconds]
<RP>
Turns out no layers mark compatibility with langdale :/
<RP>
smurray, jonmason, rburton, dl9pf, zeddii: You may want to tweak your layer.conf files
Starfoxxes has quit [Ping timeout: 265 seconds]
kscherer has joined #yocto
Starfoxxes has joined #yocto
<Guest3770>
I see that it comes from a file included in boost
<Guest3770>
In file included from /home/michael/Documents/EVCC_Application/build-fb/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/mainapplication/0.0-r0/recipe-sysroot/usr/include/boost/config/detail/select_stdlib_config.hpp:24,
<Guest3770>
from /home/michael/Documents/EVCC_Application/build-fb/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/mainapplication/0.0-r0/recipe-sysroot/usr/include/boost/config.hpp:44,
<Guest3770>
from /home/michael/Documents/EVCC_Application/build-fb/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/mainapplication/0.0-r0/recipe-sysroot/usr/include/boost/smart_ptr/bad_weak_ptr.hpp:20,
<Guest3770>
from /home/michael/Documents/EVCC_Application/build-fb/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/mainapplication/0.0-r0/recipe-sysroot/usr/include/boost/smart_ptr/detail/shared_count.hpp:25,
<Guest3770>
from /home/michael/Documents/EVCC_Application/build-fb/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/mainapplication/0.0-r0/recipe-sysroot/usr/include/boost/smart_ptr/shared_ptr.hpp:17,
<Guest3770>
from /home/michael/Documents/EVCC_Application/build-fb/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/mainapplication/0.0-r0/recipe-sysroot/usr/include/boost/shared_ptr.hpp:17,
<Guest3770>
from ../EVCC_Application/vendor/carmedialab/SMG/trunk/ISO15118_Stack/sources/EV/state/IsoStatesMachine.h:6,
<Guest3770>
from ../EVCC_Application/src/CML_Integration/sources/EV/state/SMG_IsoStatesMachine.cpp:4:
<Guest3770>
../EVCC_Application/version:1:1: error: too many decimal points in number
<Saur[m]>
Guest3770: select_stdlib_config.hpp is expecting to include "version" from the standard C++ headers (e.g., /usr/include/c++/12/version). However, it seems you have another file called "version" in the include paths, e.g., through `-I .` or something similar.
<Saur[m]>
So either rename your "version" file to, e.g., "version.txt", or do not add `.` to the include paths.
Net147_ has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
<zeddii>
RP: I have the changes queued already. I'll push it when I'm back later.
sakoman has quit [Quit: Leaving.]
<jonmason>
RP: on it
dkl has quit [Quit: %quit%]
dkl has joined #yocto
<RP>
abelloni: your builds will hit this too :/
<abelloni>
ah right
<abelloni>
tht'as fine, it is just v3 of the meson patch I wanted to test
<RP>
abelloni: hopefully transient and will quickly get sorted. We may need to retest that mesa patch as it sounds like I reported the warnings incorrectly. I may have mixed builds up
<mischief>
can someone tell me what would happen if i am using the default OEEquivHash over local unix domain socket but also using a remote sstate mirror, if that same machine is also uploading to the remote sstate mirror?
<abelloni>
RP: yes but the patch doesn't apply
<abelloni>
I was going to ask for a rebase
<RP>
abelloni: fair enough, good plan
<RP>
mischief: nothing too bad, others may just not be able to reuse the sstate
<RP>
(since the local hash equiv may make matches others wouldn't be able to see)
<mischief>
i guess i'll eat the warning for now
<RP>
mischief: we just wanted to warn users they may not see the sstate matches they might expect
<RP>
if you're fine with that... :)
<mischief>
would OEBasicHash be more accurate..?
<mischief>
we build in a stable container environment and the sstate dir is sync'd to s3 on builds from the main branch.. in the past when i've tried to use the mirror on my local dev machine, it seemed like at least some was used
<mischief>
though i'd worry about local variables messing it all up
<RP>
mischief: the way sstate works, either the configuration matches or it doesn't so local variables shouldn't matter
<RP>
BasicHash would avoid the hashequiv and allow more reuse for sharing, it would drop the accelerated matches hashequiv offers
<mischief>
i mean for example, if i enabled icecc in my local.conf
<mischief>
would that change all the task hashes?
<mischief>
or enabled buildhistory.. etc.
<RP>
mischief: It is usually configured to do the right thing, so buildhistory wouldn't change the hashes since it doesn't influence the output
<mischief>
i don't think running a bitbake-hashserv instance is an option at all for us, especially since it appears there's no way to secure it
Guest3770 has quit [Quit: Client closed]
<RP>
mischief: we share one publicly as a project so that isn't true
<RP>
mischief: note that you can run two servers against one DB, one RW and one readonly
<RP>
mischief: you then just share the readonly port with the sstate
<mischief>
i mean that there is no transport security for the requests to it :)
sakoman has joined #yocto
<RP>
mischief: I'm sure that could be added if someone really thought it was needed...
<mischief>
i'm sure my employer wouldn't want things like PN flying around in cleartext across the internet, and secured transport is required for any internal services setup. i'll see how we get along without a hashserv for now :-)
nemik has quit [Ping timeout: 268 seconds]
goliath has quit [Quit: SIGSEGV]
nemik has joined #yocto
<mischief>
that's a new one
<mischief>
| qemu-arm: Unable to reserve 0xffff0000 bytes of virtual address space at 0x1000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option)
odra_ is now known as odra
kscherer has quit [Quit: Konversation terminated!]
tlwoerner has quit [Read error: Connection reset by peer]
tlwoerner has joined #yocto
<mischief>
seems like having qemu-arm in binfmt_misc might break the build