azcraft has quit [Remote host closed the connection]
florian has quit [Ping timeout: 276 seconds]
xmn_ has joined #yocto
xmn has quit [Ping timeout: 256 seconds]
xmn_ has quit [Quit: xmn_]
xmn has joined #yocto
tokamak has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
tokamak has joined #yocto
wCPO7 has joined #yocto
alicef has quit [Ping timeout: 255 seconds]
Vonter has quit [Ping timeout: 255 seconds]
alicef_ has joined #yocto
davidinux has quit [Ping timeout: 255 seconds]
mckoan|away has quit [Ping timeout: 255 seconds]
mckoan|away has joined #yocto
davidinux has joined #yocto
wCPO has quit [Ping timeout: 255 seconds]
wCPO7 is now known as wCPO
Vonter has joined #yocto
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
davidinux has quit [Ping timeout: 248 seconds]
davidinux has joined #yocto
prabhakarlad has quit [Quit: Client closed]
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #yocto
Thorn has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
camus has quit [Quit: camus]
camus has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
camus has quit [Remote host closed the connection]
kiwi_29_[m] has joined #yocto
<kiwi_29_[m]>
Hello ... I am hosting Toaster UI for my team... the members do not know how to use Yocto. The idea is for them to just build their packages using Toaster and test it during development. The tough part of hosting toaster is done...however , how do I let them download the deb packages from Toaster UI?
Thorn has quit [Ping timeout: 276 seconds]
camus has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
camus has quit [Quit: camus]
camus has joined #yocto
camus has quit [Client Quit]
AKN has joined #yocto
sakoman has quit [Quit: Leaving.]
amitk has joined #yocto
camus has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 248 seconds]
camus has quit [Remote host closed the connection]
<JaMa>
patch runs inside S directory, you can use patchdir or striplevel to adjust it relative to S, but it has to be a file there
<rburton>
polprog_: set the patchdir to WORKDIR, but its easier to just provide a new dropbear.default file entirely in your layer
<polprog_>
Thats a good dolution too and thats what im trying now
<polprog_>
I wanted to understand how the patch way works too
<polprog_>
I also have to patch the device tree, so i will try that
AKN has quit [Ping timeout: 268 seconds]
rfuentess has quit [Remote host closed the connection]
AKN_R has quit [Ping timeout: 268 seconds]
<rburton>
basically default patch directory is ${S} and patch stripping level is 1
<rburton>
if those don't work, just change them
rfuentess has joined #yocto
frieder has joined #yocto
AKN_R has joined #yocto
fabo has quit [Ping timeout: 260 seconds]
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
pidge has quit [Ping timeout: 255 seconds]
florian_kc is now known as florian
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
pidge has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<Max[m]>
I'm trying to use devtool to update a recipe to a new upstream version. SRC_URI contains a couple of patches, and rebasing them automatically (with fixing conflicts manually) is my main motivation for using devtool.
<Max[m]>
devtool upgrade prints an error for the first patch conflict and then just tries to compute the license diff, which fails because the set of license files is different between the two versions (some removed, others added).
<Max[m]>
devtool modify after manually updating the version and LIC_FILES_CHECKSUM seems to almost do what I want, but it errors out on the first patch conflict, and on the next run it does the complete unpacking again, which takes ages.
<Max[m]>
Not sure if devtool is even the right choice for this task, or if I should just write a script to automate the rebasing?
imND has joined #yocto
<polprog_>
is there a way to trace what recipes influence a particular file in the target rootfs?
<rburton>
that will tell you the package. should be obvious what the recipe is, if not oe-pkgdata-util lookup-pkg will tell you
prabhakarlad has quit [Quit: Client closed]
<SandrineWolf>
Hello, when I launch runqemu qemux86-64 with yocto version:langdale. I have some time this error No more Space Left ENOSPC, I resolved with change size of /proc/sys/fs/inotify/max_user_instances or reboot my computer. Is It normal ?
<polprog_>
rburton: it's unable to find any package, im running 'oe-pkgdata-util find-path /bin/bash' as a test
<polprog_>
hm, it found the /etc/issue one (base-files), but it can't fint the /etc/shadow one
<rburton>
bash is a bad one to pick as that's a symlink that isn't packaged, but generated
<rburton>
shadow is, iirc, a managed file that also doesn't get packaged
<ArgaKhan>
hello
<ArgaKhan>
rburton: We were talking the other day. I still haven't been able to solve it. This irc doesn't have a notification feature, I couldn't see it and missed it. I am using the Kirk stone branch.
<rburton>
i can't remember what the problem was, sorry
<polprog_>
rburton: hm, ok, i think ill just enable the debug tweaks option then.. thanks
<polprog_>
(petalinux seems to have a rather broken yocto setup)
<ArgaKhan>
rburton: I think I'm getting an error because of the dependency. From linux dummy this was also the log file: https://paste.ee/p/qPzy6
<ArgaKhan>
rburton: I'm using the Kirkstone version by the way.
<JaMa>
Max[m]: devtool is right tool, but if the patches are in bad shape or the diff from new version too big, then it's still not easy to use
<rburton>
ArgaKhan: oh yes, i struggle to believe that ALLOW_EMPTY:${PN} = "1" in linux-dummy.bb didn't fix that
goliath has joined #yocto
<JaMa>
Max[m]: if the source is in git repo already and .patch files have git headers, than I will usually rebase them manually (first apply them with git am in S of the old version, then rebase and git format-patch --no-numbered --no-signature N while updating SRCREV of the new tag I want to upgrade to
<ArgaKhan>
rburton: I added ALLOW_EMPTY:${PN} = "1" to poky/meta/recipes-kernel/linux/linux-dummy.bb. Do I need to do anything else? I saved the file and ran bitbake after adding this option.
bjoscar has joined #yocto
<Max[m]>
JaMa: the source is a tarball, but the patch files do have git headers. I suppose I'll have to keep rebasing them manually them, thanks!
<JaMa>
yes, with tarball it's a bit more boring routine to do it manually (git init, unpack the tarball again, because the one in S already have the patches applied, git add -A ., git commit -a -m init; git am old patches, .. is what I often do, but in tarball case devtool definitely saves this boring routine)
vladest has quit [Quit: vladest]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
prabhakarlad has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
d-s-e has quit [Ping timeout: 276 seconds]
bjoscar has quit [Ping timeout: 268 seconds]
imND has quit [Remote host closed the connection]
<rburton>
RP: INFO: meta-clang ... PASS
<RP>
rburton: nice!
louis_ has quit [Quit: Lost terminal]
<JaMa>
RP: just for me to understand the process - after the final pull request from Steve (e.g. kirkstone yesterday), do you trigger some builds on AB or just merge it whenever you find some time to pull&push?
louis_ has joined #yocto
<ArgaKhan>
rburton: I added ALLOW_EMPTY:${PN} = "1" to poky/meta/recipes-kernel/linux/linux-dummy.bb. Do I need to do anything else? I saved the file and ran bitbake after adding this option.
<RP>
JaMa: the latter since steve has already run the builds
<RP>
JaMa: if there is something urgent like the openssl upgrade I can hurry up!
alicef_ is now known as alicef
<RP>
reproducible builds tests now take 8 hours thanks to rust :(
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
<JPEW>
RP: Gross
alicef is now known as arisut
amitk has quit [Ping timeout: 255 seconds]
sakoman has joined #yocto
* RP
realises he is running ptests under an arm image which is why things are so slow :/
* RP
wonders if rburton/jonmason can remember to send him an arm server
* RP
wonders if mcfrisk could be persuaded to improve the runqemu logging so somewhere there is an ondisk log file you can see what the build is doing in. If the build dies you'd then also still have the logs of the last ssh command
<jonmason>
RP: I was going to buy a mac mini m2 in the next few days and see the viability of using it as a builder (or perhaps a desktop)
xmn has joined #yocto
<rburton>
RP: a mac mini would be my suggestion
<RP>
rburton: fair enough, I don't really have the need. Just kicking myself for not setting that build up right
<rburton>
RP: g'wan you know you want a mac mini
<jonmason>
dammit, now I'm going to have to get one tonight
d-s-e has joined #yocto
florian__ has quit [Read error: Connection timed out]
Notgnoshi has quit [Ping timeout: 276 seconds]
florian__ has joined #yocto
Notgnoshi has joined #yocto
<JaMa>
RP: openssl upgrade will be nice, but I wasn't trying to rush you, I was just curious if the git log (and the git shas) is likely to change (e.g. if you or AB spot something and decide to amend it just before push) or if it's really just pull&push (it usually didn't change before if I remember)
<JaMa>
but thanks for merging it :)
kscherer has joined #yocto
vladest has quit [Ping timeout: 255 seconds]
kayterina[m] has joined #yocto
<kayterina[m]>
Hello, I get this error message from bitbake:
<kayterina[m]>
is it related with the python version in my build machine?
<RP>
JaMa: sometimes I might drop a patch if I see something I worry about
<RP>
rburton: I'd like a mac mini I'm sure but I probably have other things I should spend money on first!
louis_ has quit [Quit: Lost terminal]
<ptsneves>
kayterina[m]: did you run bitbake in different computers or with different versions of python before?
<kayterina[m]>
Not sure what you mean, I am in a shared computer we use for building and I haven't installed any other python version.
<ptsneves>
I believe the cache mentioned here is the parsing cache and the parsing cache is stored with the python pickle module. Bitbake is complaining that the cache is written with an unsupported protocol. Specifically that it is protocol version 5. pickle protocol 5 is introduced in a pretty recent python 3.8. Is this the python version your environment has when bitbake fails?
AKN_R has quit [Read error: Connection reset by peer]
amitk has joined #yocto
tepperson has joined #yocto
yates has joined #yocto
<yates>
is there a free version of linaro somewhere? it looks like the official linaro website charges for it.
<LetoThe2nd>
yates: a version of what?
<yates>
ha ha
<yates>
yes, there are other linux-distro-building tools than yocto
seninha has quit [Quit: Leaving]
Thorn has quit [Ping timeout: 276 seconds]
<rburton>
linaro is a company not a product
<LetoThe2nd>
yates: the question was serious. linaro provides some things for free (toolchains for example), and charges for services. but "linaro" by itself is an organization, not a software thing.
seninha has joined #yocto
olani has quit [Remote host closed the connection]
<yates>
linaro does not provide a tool that will allow one to create an entire linux build, including utilities, libraries, etc.?
<LetoThe2nd>
yates: linaro provides a build system, they even presented on it at the Yocto Project Summit.
olani has joined #yocto
<rburton>
yates: you're telling us there is with "is there a free version, they charge on their web site"
<mcfrisk>
As one of Linaro people here, yes TuxOe/TuxBake/TuxSuite exist as tools and a service to build things including kernels and yocto in the cloud, aka "other peoples computers"
xmn has quit [Quit: ZZZzzz…]
<kiwi_29_[m]>
Hello..any insight here is much appreciated
<yates>
if i were to setup yocto to build an ARMv7-A project, where would the libraries such as libcrypt, libjson, etc., be obtained?
<kiwi_29_[m]>
<kiwi_29_[m]> "Hello ... I am hosting Toaster..." <- Hello...any insight here is much appreciated
<LetoThe2nd>
yates: see the SRC_URI entries of the corresponding recipes.
xmn has joined #yocto
<LetoThe2nd>
yates: what do you actually want to do, respectively expect from this channel?
<rburton>
yates: yocto builds from source. it will download the sources of those libraries, and build them
<yates>
is there a reference build for ARMv&-A?
<rburton>
what do you mean?
<yates>
ARMv7-A
<yates>
an example build
<LetoThe2nd>
yates: that question does not make any sense. there is qemuarm as a supported example machine, which is "as close as can be"
<rburton>
yates: the qemuarm and qemuarm64 machines, and the example images such as core-image-sato
amelius has joined #yocto
<amelius>
Hey I'm migrating to kirkstone right now and haven an recipe with these
<amelius>
and getting do_fetch: Bitbake Fetcher Error: FetchError("Recipe uses a floating tag/branch without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE).", None)
<amelius>
SRCREV = "v${PV}"
<yates>
to answer your previous question, i want to be able to find out where the source of certain libraries come from in an instance of an ARMv7-A rootfs, namely, from the /usr/lib folder
<rburton>
yates: did you build the image?
<yates>
no
<rburton>
is it a yocto image?
<yates>
or find out where they may/probably come from
Thorn has joined #yocto
<yates>
i don't know
<rburton>
so why are you asking here?
<rburton>
if it was a yocto image you could look at the library, determine the recipe that build it, and then look at the recipe to see where the sources come from
<rburton>
but if you don't know its a yocto image then i think you've got bigger problems
<yates>
rburton: i am asking here because i assume that the "standard" libraries folded into such a build are fairly common, at least for common libraries such as libjson
davidinux has quit [Ping timeout: 248 seconds]
<rburton>
sure. have you tried googling "libjson"?
<rburton>
also i have no idea how this follows from the "linaro build tool"
<LetoThe2nd>
yates: again, what do you expect from a *YOCTO* channel? doing your reverse engineering homework?
<yates>
i guess i expect nothing. but if someone had some of the information i was requesting, they could choose to share it. if the choose not to share it, then they are free to remain silent.
<rburton>
you asked where the libjson.so sources come from. i suggest googling 'libjson'.
<rburton>
anyone can download the linaro compilers, so it might be yocto, might be buildroot, might be something else.
<yates>
rburton: yes, you did. i was responding to LetoThe2nd's question.
<rburton>
yates: fwiw i agree with his point
<yates>
and it is a good suggestion. thank you.
<rburton>
vmeson: dude trolling in bug comments, harsh
<vmeson>
rburton: :-)
halstead[m] has left #yocto [#yocto]
thomasd13 has quit [Ping timeout: 255 seconds]
<amelius>
does someone has an idea for my fetching problem? :)
<rburton>
amelius: try taking tag= out of the SRC_URI, it's redundant as you set a SRCREV
rob_w has quit [Quit: Leaving]
<JaMa>
amelius: set git sha in SRCREV or add SRCPV in PV as the message says
<JaMa>
amelius: using tag name in SRCREV is not a good practise (as tags can move)
<JaMa>
amelius: that's why the FetchError forces you to add SRCPV that way at least your PV is changed when someone moves the tag in upstream and tag gets resolved to different SHA
<tepperson>
is there a proper way to copy files to the build folder of a recipe that works with devtool?
gegir has quit [Ping timeout: 276 seconds]
<neverpanic>
mcfrisk: Oh, you're with Linaro now?
<amelius>
JaMa: ah I see, on hardknott this worked well :(
<rburton>
amelius: new releases are more pedantic. tags can move, which means you don't build the same software over time.
<JaMa>
amelius: it still works
<JaMa>
and in hardknott it doesn't work well if you don't have SRCPV in PV, try to use 2 git repos in SRC_URI with SRCREV_a and SRCREV_b, then change SRCREV_b and watch recipe _not_ being rebuilt
<mcfrisk>
msg neverpanic yep, working for Linaro now
<mcfrisk>
noob :)
<JaMa>
unless you use e.g. do_fetch[depends] += SRCREV_b
<JaMa>
do_fetch[vardeps]
frieder has quit [Remote host closed the connection]
<tlwoerner>
how can you build-time depend on something, then not install it?
<rburton>
easily!
<rburton>
if you build with meson, you don't get meson in the target
<rburton>
just add a RDEPENDS:${PN} += "ghostscript", if its mandatory
<tlwoerner>
are libraries a special case?
<rburton>
yes
<tlwoerner>
ah!
<rburton>
do_package digs into the binaries, finds that it links to a shared library, discovers what package that is in, and adds a RDEPENDS for that package
vladest has joined #yocto
<tlwoerner>
all along i thought it was by virtual of DEPENDS
<rburton>
nope :)
<tlwoerner>
but the meson example make ssense
<rburton>
you could argue "rdepend automatically on non-native packages" but what if the recipe you depend on has multiple packages, and the recipe you're building has multiple packages: what are the dependencies?
<tlwoerner>
all of them! (lol)
<tlwoerner>
i'll check, but i have a feeling cups-filters doesn't DEPEND on ghostscript, only RDEPENDS
<rburton>
other way around, but you're right
<rburton>
it only DEPENDS (so its there at build time), but if its binaries and no libraries, there is no RDEPENDS
<tlwoerner>
what i'm saying is, and i just checked, the cups-filters recipe doesn't build-time DEPENDS on ghostscript
<tlwoerner>
it only run-time RDEPENDS on ghostscript
<tlwoerner>
some recipes both DEPENDS and RDEPENDS, but in this case it only RDEPENDS although the recipe said DEPENDS
<tlwoerner>
(patch coming, obviously)
<tlwoerner>
oops, earlier i said "by virtual of" instead of "by virtue of"
<rburton>
the recipe i'm looking at DEPENDS on ghostscript
<tlwoerner>
yes it does, and that's wrong
<tlwoerner>
take ghostscript out of DEPENDS and cups-filters builds just fine
<rburton>
does it build identically though, or does it turn stuff off magically
<tlwoerner>
cups-filters are scripts
<tlwoerner>
no, because --enable-ghostscript is in the ./configure
vladest has quit [Remote host closed the connection]
<rburton>
i've used autotools enough to laugh at your bold assertion
<tlwoerner>
(actually, it's there twice, so another patch...)
<rburton>
so the configure script just assumes the binary is called 'gs' if you're cross-compiling
<tlwoerner>
by the way, when you're speaking of the cups project, saying "autotools" is being generous
<rburton>
which is fair
<tlwoerner>
"autotools-ish" would be more accurate
<rburton>
its autoconf+automake which is enough for me
<tlwoerner>
they don't believe in using auto-hreader
|Xagen has joined #yocto
<rburton>
i never understood people who do autoconf+custom makefiles
<tlwoerner>
they claim it's so it will work on the BSDs
<rburton>
you shoud try changing autotools-brokensep back to autotools and seeing if they've fixed the problems
<tlwoerner>
not even close
<tlwoerner>
it doesn't even try to build outside the source tree
<tlwoerner>
oops, i shouldn't say that, you can try...
Xagen has quit [Ping timeout: 248 seconds]
<rburton>
didnt the cups guy start a new replacement project?
<tlwoerner>
Apple has been doing a lot of cups work, and i think they hired the cups guy
<rburton>
he left
<rburton>
and started rewriting cups piece by piece :)
<tlwoerner>
Michael Sweet
<JaMa>
systemd doesn't print yet? :)
<ptsneves>
Hey guys how do i inherit a class only on class-target? I did:
<ptsneves>
But it did not work
<ptsneves>
inherit ${@'my_precious' if 'class-target' in d.getVar('OVERRIDES').split(':') else ''}
<rburton>
go via a variable
<rburton>
MYCLASS = ""
<ptsneves>
AH!
<rburton>
MYCLASS:class-target = "foo"
<rburton>
inherit ${MYCLASS}
<rburton>
there's load of examples in oe-core if you grep for inherit :)
<rburton>
i think that works, anyway.
<ptsneves>
I think i have done that in the past but my brain was doing crazy python substitutions
<ptsneves>
rburton: thank you!
<tlwoerner>
JaMa: haha ... soon ...
leon-anavi has quit [Quit: Leaving]
ptsneves has quit [Ping timeout: 248 seconds]
prabhakarlad has quit [Quit: Client closed]
<d-s-e>
I'm trying to build an app that uses some tool called conan with cmake. Is there a preferred way to handle that? I'm stuck at the line "include(${CMAKE_BINARY_DIR}/conan_paths.cmake)" in the CMakeLists.txt, that file is not found.
<rburton>
you'll need to make a conan-native recipe
<rburton>
that might be the most painful thing in the world
<d-s-e>
ok, sounds horrible ... why is everyone inventing their own little package manager ....
<rburton>
correct response :)
<rburton>
at least its not bazel!
<rburton>
(could be as bad a bazel, no idea)
florian__ has quit [Ping timeout: 260 seconds]
<d-s-e>
never heard of that.
<rburton>
be glad :)
<d-s-e>
so there's no easier way? or something I could use a basis?
<d-s-e>
I try to stay as far from the c++ world as I can ;-)
rfuentess has quit [Remote host closed the connection]
<rburton>
layer index doesn't show a recipe, so step 1 is making a recipe for conan itself. the docs say its on pypi so that should be _relatively_ easy
<rburton>
then write your recipe that does the right things, calling conan as needed
<rburton>
if it fails to do the build step, at least they've covered a lot of the work
<d-s-e>
I will have a look at that, thanks!
<rburton>
right its in the layer index now
<rburton>
there's quite a lot of non-trivial issues open so... have fun i guess
<d-s-e>
I will :-D
d-s-e has quit [Quit: Konversation terminated!]
<paulg>
so, I figured I'd try and fix sysvinit and read-only-rootfs...
<paulg>
courtesy of rburton 's pointer, I'm looking at SERIAL_CONSOLES_CHECK in sysvinit-inittab_2.88dsf.bb
<paulg>
Even after some "git blame" and looking at old yocto bugs, I'm still at a loss as to why we are rummaging around in /proc/consoles after boot to mangle the /etc/inittab
<paulg>
If we build for board/BSP foobar, we surely know what the console device is.
<paulg>
the only thing I could come up with was an alignment with the bootargs console= --- but even that seem weak.
<paulg>
What am I missing?
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
bjoscar has joined #yocto
<paulg>
Presumably I can clobber the variable locally, but I'm still curious why it exists at all.
bjoscar has quit [Client Quit]
bjoscar has joined #yocto
<yates>
is there a list of common library source locations which yocto developers can find to include in their builds (via SRC_URI)?
<yates>
i'll check qemuarm
<rburton>
paulg: at least one of them was added because the tty devices are different under bare metal vs under xen
<rburton>
ttyAMA0 on bare metal, hvc0 in xen. never both.
<paulg>
yuck
<rburton>
yes
<paulg>
s/y/f
amitk has quit [Remote host closed the connection]
davidinux has joined #yocto
polprog_ is now known as polprog
<zeddii>
:q!
<zeddii>
no exit for me
<JPEW>
1) Require zstd on the host
<JPEW>
RP: On the SPDX in dunfell, what do you want to do about the zstd dependency? I think there are a few options:
<JPEW>
2) Add zstd to build tools tarball (extended?)
<JPEW>
4) Don't compress either extended package data or SPDX data
<JPEW>
3) don't compress extended package data with zstd (this would make zstd only required for create-spdx)
ArgaKhan has quit [Ping timeout: 276 seconds]
<derRichard>
is there a way to share DL_DIR on the same machine across parallel build (and different users)? my goal is not reducing download time but saving disk space. so own-mirrors does not really help.
<derRichard>
so far i see only issues with git and other scms. maybe i should GITDIR and such per project. hmm
<derRichard>
*should set
<mason>
Hi all. Another noob question. I want to see (at least) xt_nat in my kernel, but I'm not immediately clear on how to get it included. Can someone point me to the right documentation? Thanks in advance!
<mason>
Ah, think I have it. I'll come back if I get stuck.
<JaMa>
JPEW: FWIW: seeing how reluctant some projects are to update host, I'm not very fond of 1) for stable release, especially for some new functionality which they might not use in dunfell
<mason>
Alright, I'm back. It didn't like what I specified: https://bpa.st/YTBEG
* JaMa
still trying to get zstd installed on some of jenkins slaves to unblock kirkstone builds natively
<mason>
maybe it's netfilter
<mason>
Wasn't netfilter. What do I want to specify be built that'll provide old-style iptables DNAT? It's not xt_nat nor netfilter
<mason>
Not to jinx it, but the module name I want might well just be "iptables"
<mason>
But... maybe not as I see iptables stuff already included. Anyway, if anyone can short-circuit my search and tell me what I want to include to get xt_nat built I'd be grateful.
<JPEW>
JaMa: Ya, I figured.... it's _an_ option, but not a very good one
<RP>
JPEW: It is already in recent buildtools so we could recommend buildtools to people who don't have it on the host. Perhaps we make the extended packagedata conditional and only add the requirement for zstd if it is enabled?
invalidopcode1 has quit [Remote host closed the connection]
florian__ has joined #yocto
invalidopcode1 has joined #yocto
<mason>
ended up being "iptables" after all
<JPEW>
RP: That's a little tricky; would it be better to either compress with gzip (slow) or not compress (more disk space)
<JPEW>
core-image-minimal is 34M with no compression, and 20M with zstd, so it's not that much more data
<khem>
RP: the glibc issue you are seeing is still same sadly, I dont think its binutils problem
<khem>
the links you pointed did not take me to gstreamer test failure can you send me a link to look into
<RP>
khem: I don't think the ptest issues are related, I reran and they didn't appear so I think they're something else
<RP>
khem: I also found the glibc issue is probably from cache issues from the reproducibility problem
<RP>
khem: I've cleaned caches and taken a risk and merge everything as of a few minutes ago
<RP>
JPEW: lets use gzip, that is a better idea
<JPEW>
OK
<RP>
JPEW: it can't be that slow? :/
<JPEW>
I'll check
<khem>
ah I see now {'gstreamer1.0': ['gstreamer/libs_aggregator.test']}
<JPEW>
(Probably not in the grand scheme)
<RP>
JPEW: right, I'm happy master uses zstd but for dunfell gzip is probably fine
* RP
just had 64 testimages launch in parallel, each running a different ptest
<RP>
The power monitor has gone impressively high
<paulg>
you dino chomping planet hater....
<RP>
paulg: I'm planning to teach the autobuilders to do this ;-)
<RP>
BBCLASSEXTEND = "${@' '.join(['mcextend:'+x.replace('-ptest', '') for x in d.getVar('PTESTS').split()])}"
<RP>
such an innocent looking line
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
florian__ has joined #yocto
florian__ has quit [Ping timeout: 276 seconds]
<mason>
And, I don't need to do anything to get xt_nat.ko to build, but there's something else required to get it to *install*. This is great stuff. :P
<mason>
Plus side, shoving it in by hand and pointing depmod at it resolves my issue, so I'm getting closer.
<JaMa>
RP: that is pretty dark magic :)
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<RP>
JaMa: For some reason I really like this recipe
Vonter has quit [Ping timeout: 268 seconds]
<JaMa>
The Dark Side, Resist you must!
<fray>
(petalinux wrappers and devtool appear to hide a bunch of those kind of messages.. which is why I hadn't seen them in the logs)
<fray>
whoops wrong channel
florian__ has joined #yocto
<RP>
moto-timo: any idea which perl module I should be adding as a dependency to fix "base class package TAP::Base is empty" ?
<moto-timo>
RP: it should be "perl-module-tap-base"
<RP>
moto-timo: I'm also noticing the ptest output for python3-jinja2 has progress reporting and hence isn't separating to individual test results meaning "0" tests are run or pass/fail
<RP>
moto-timo: ok, I was trying to overcomplicate that message then! :)
<moto-timo>
RP: if that isn't it, ping again and I'll dig
<khem>
I think it should be perl-module-tap-base
<RP>
moto-timo: I think there may be a python systemic ptest issue, python3-jsonpointer, python3-markupsafe,python3-more-itertools all have zero counts
<moto-timo>
rburton: poke the bear for consistent pytest output
<RP>
moto-timo: that is horrible :(
<RP>
moto-timo: sorry for bringing this up, it just looked like something systemic broke from where I was looking
<moto-timo>
RP: anyway, the quick answer is almost any of those recipes that hack pytest in run-ptest is what we "need" with the current state of things. perl is slightly simpler just because it has the same test runner/output everywhere.
<moto-timo>
RP: it's ok. this is "On The List"
<RP>
moto-timo: now I know what might work I can give "hitting" those a try with this particular hammer
* moto-timo
wonders about an (ugly) ptest-pytest bbclass that make that universal
kscherer has quit [Quit: Konversation terminated!]
<RP>
moto-timo: maybe just inject a global run-ptest-pyptest file into the global files directory and pull that in?
seninha has joined #yocto
<moto-timo>
RP: yes, that
<RP>
the number of issues I've found with these simple tests is annoying
<moto-timo>
it was just easy to inherit... but that was a younger more naive me
<RP>
hmm, maybe, maybe not
<RP>
moto-timo: for perl it makes sense given the other code
<RP>
I guess it would be needed for the python case too
dlan has quit [Ping timeout: 268 seconds]
<moto-timo>
at least for the pytest case
<moto-timo>
or at least a marginal argument in favor
<moto-timo>
lack of ptest-runner consistency is a challenge... and you would hope that pytest would be a rather standard output... but only for the python packages that don't bork it
<RP>
only 9 more different ptest recipes with broken dependencies to fix :/
* moto-timo
has a strong sense of deja vu
<RP>
moto-timo: this time I will change the way the AB works