ablu has quit [Read error: Connection reset by peer]
sakman has joined #yocto
ablu has joined #yocto
sakman has quit [Ping timeout: 268 seconds]
marex has quit [Ping timeout: 240 seconds]
marex has joined #yocto
jmd has joined #yocto
mulk has quit [Ping timeout: 268 seconds]
mulk has joined #yocto
rob_w has joined #yocto
alessioigor has joined #yocto
pvogelaar has quit [Remote host closed the connection]
sakman has joined #yocto
goliath has joined #yocto
linfax has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
GNUmoon has quit [Ping timeout: 255 seconds]
jmd has quit [Remote host closed the connection]
sakman has quit [Ping timeout: 260 seconds]
GNUmoon has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
mbulut has joined #yocto
mbulut has quit [Client Quit]
vladest has quit [Ping timeout: 264 seconds]
frieder has joined #yocto
frieder has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<landgraf>
mckoan (^_^)/
olani- has joined #yocto
jclsn has quit [Quit: WeeChat 4.1.2]
jclsn has joined #yocto
vladest has joined #yocto
rob_w has quit [Quit: Leaving]
rob_w has joined #yocto
grma has quit [Remote host closed the connection]
pretec has joined #yocto
Kubu_work has joined #yocto
Vonter has quit [Ping timeout: 268 seconds]
Vonter has joined #yocto
prabhakarlad has joined #yocto
prabhakar has joined #yocto
grma has joined #yocto
mvlad has joined #yocto
yannd has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
florian has joined #yocto
xmn has joined #yocto
zpfvo has joined #yocto
prabhakarlad has quit [Ping timeout: 250 seconds]
prabhakar has quit [Ping timeout: 260 seconds]
prabhakar has joined #yocto
prabhakarlad has joined #yocto
prabhakarlad has quit [Client Quit]
prabhakar has quit [Client Quit]
prabhakar has joined #yocto
prabhakarlad has joined #yocto
frieder has joined #yocto
<kanavin>
RP: I'll take a look, the diff doesn't make clear if it's a sorting issue with same entries, or different entries entirely
destmaster has joined #yocto
<destmaster>
Hi, I want to add the "spidev.bufsiz=32768" to the cmdline.txt of my RPI4 distro... I don't know how to do this in Yocto files... can someone help me?
<RP>
kanavin: all the same lines are present just in a different order so I'm fairly sure it is sorting in the CLASSDICT and FILECLASS sections
<RP>
kanavin: it is frustrating there are few tools able to even print those headers, I ended up having to look at the diffoscope code
<destmaster>
yocton It describes how to add to config.txt not cmdline,txt. I think that the best way is to create a bbappend to cmdline
olani- has quit [Remote host closed the connection]
<yocton>
destmaster: ah you are right those are different files :)
schtobia has quit [Quit: Bye!]
schtobia has joined #yocto
olani- has joined #yocto
klug has joined #yocto
klug has quit [Client Quit]
klugology has joined #yocto
khem has quit [Quit: Connection closed for inactivity]
<klugology>
Hi!
<klugology>
I am new to the yocto project. I am trying to add a custom python application to my yocto image for raspberry pi3. I have created a sample python package by following [this](https://packaging.python.org/en/latest/tutorials/packaging-projects/) guide. I have the python package as `example_package_klug-0.0.1.tar.gz` and I am using `devtool`. I did
<RP>
kanavin_: a simple test might be to put a sort in package_rpm, generate an rpm, then reverse the sort, see if it changes
<kanavin_>
RP: it's not the sort. If you run 'rpm -ql --fileclass xz-ptest-5.4.5-r0.core2_64.rpm' on the two rpms, it reports different types for the same .lz files
<RP>
kanavin_: ah, fair enough :/
<kanavin_>
I'll see if there's host contamination from running /usr/bin/file, or some other issue
<jonmason>
I did verify they all built with a prior version
<jonmason>
RP: if you don't want all of these, the base level ones (8-1a, etc) would be nice
<RP>
jonmason: I'll probably just defer to arm on this one
* RP
has other issues to worry about
<jonmason>
JaMa: lies, damn lies, and benchmarks ;)
<jonmason>
looks like patchtest is complaining about my commit message
lexano has joined #yocto
vladest has joined #yocto
<JPEW>
Ah cool. I'll take a look
<JaMa>
sanity check: if I do bitbake-diffsigs tmp/stamps/*do_configure.sigdata* it works, if I use 2 sigdata files it fails with:
<JaMa>
bitbake/lib/bb/compress/_pipecompress.py", line 59, in open_wrap raise TypeError("filename must be a str or bytes object, or a file"
<JaMa>
both files are compressed by zstd according to "file"
<JaMa>
am I crazy or in need of another coffee?
<RP>
JaMa: it should work ;/
<RP>
:/
<JaMa>
ok, will debug
klugology has quit [Ping timeout: 250 seconds]
davidinux has quit [Quit: WeeChat 3.5]
<JaMa>
aha, found a bug will send fix later, it's the walking of dependencies (in this case do_prepare_recipe_sysroot stamp, where "a" isn't the sigdata filename, but dict with "path, sstate, time"
klugology has joined #yocto
<klugology>
i am unable to get the package get the `example_package_klug` get built any pointers on where i am going wrong
ray-san has quit [Remote host closed the connection]
<kanavin_>
RP: local_cache tests passed, so it's a cdn propagation failure?
<kanavin_>
the 404 errors
<RP>
kanavin_: I don't know, I haven't looked or had a chance to think about it. That seems likely
<kanavin_>
there's also a couple of HTTP Error 504: Gateway Timeout fails
<kanavin_>
also known, and halstead has been notified
<RP>
kanavin_: we might want to point him at the further occurrences
<kanavin_>
RP: yes, so halstead: can you please look at the above link? there's two distinct CDN issues there (failure to mirror, and failure to serve with a 504 error)
<Guest52>
but newly created path and file was not added
sakman has joined #yocto
<mckoan>
Guest52: creating your grub .bbappend recipe and including your custom grub.cfg ?
<Guest52>
I tried to add grub-bootconf_%.bbappend, gets deployed to rootfs build/tmp/work/test-linux/test-image-minimal/1.0-r0/rootfs/boot/EFI/BOOT/grub.cfg but for some reason it does not reach the final .wic
<Ad0>
what's the deal with devtool modify in dunfell? it makes the source dir and if I want to apply multiple patches over time, it doesn't let me continue. I first have to mv the dir, do devtool modify, delete the dir, and then move the old one back
<Ad0>
after devtool finish, then devtool modify again, it complains that it exists
<Ad0>
can I trick it into not thinking it is finished ?
<Ad0>
--no-extract ?
<Ad0>
that did it
simonew has joined #yocto
pretec has quit [Quit: Leaving]
<RP>
kanavin_: nicely found, thanks
<kanavin_>
RP: cheers. I read your email, so if there's other items I can take them.
clever has joined #yocto
xantoz_ is now known as xantoz
<Ad0>
does KERNEL_MODULE_AUTOLOAD order the modules as you add them?
Guest52 has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
<mckoan>
Ad0: They are not loaded automatically by udev
<mckoan>
Ad0: They are loaded automatically by udev
<Ad0>
they end up as filenames in /etc/modules.load.d
<Ad0>
but usually you have like 001- in front of them, but not here
frieder has joined #yocto
<mckoan>
Ad0: because are loaded 'on demand'
<Ad0>
but if 2 different modules depend on eachother
<mckoan>
Ad0: you shouldn't have a deadlock
<Ad0>
there's a free stading reset module for the TPM
<kanavin_>
JaMa, thanks, this was somehow overlooked in the fixing I did
<RP>
Are we missing a test case?
<kanavin_>
RP: I think bitbake-diffsigs has no tests at all
<JaMa>
I did run bitbake-selftest before and after and both are failing the same
<JaMa>
I mean in other unrelated tests
<JaMa>
test_that_unpack_does_work_when_using_git_shallow_tarball_but_tarball_is_not_available test_external_svn and my local test_npmsw_local_link_sources
rob_w has quit [Remote host closed the connection]
<JaMa>
test_that_unpack_does_work_when_using_git_shallow_tarball_but_tarball_is_not_available was only temporary "fatal: unable to access 'https://git.yoctoproject.org/fstests/': Could not resolve host: git.yoctoproject.org"
<RP>
JaMa: that isn't so bad. I did even wonder about putting a "svn" repo somewhere on our infra but I couldn't summon up the effort for that on svn in the end
olani- has quit [Ping timeout: 252 seconds]
<mischief>
what's the usual process for getting a commit merged to oe-core? does a secret cabal look at their mail and git-am at their leisure? just curious :-)
Kubu_work has joined #yocto
goliath has joined #yocto
<RP>
mischief: the changes are usually queued and tested by alex/ross/luca/me. At that point if they pass, they get a second level or review, usually by Ross/me and then if they pass that they merge
<RP>
if there are issues, people usually get email replies or some other communication of the problem
<mischief>
okay, perhaps it was just updated after i last checked. thanks!
<mischief>
do you have a reference for where that was discussed on the systemd ml?
alessioigor has quit [Quit: alessioigor]
<simonew>
Btw I could try to help a little with the CVE point from the mail, any packages/branches in particular?
<yocton>
simonew: The first step of CVE is looking at the list and identifying what to do for each (backporting a patch, telling NIST something is wrong in the data, adding a CVE_STATUS) and anwsering the list with this info (rburton has done it a bunch of times). FWIW, I plan to do that tomorrow
<simonew>
yocton, I know those messages, but if you already plan to check the details anyway
<simonew>
Once you did so and updated on the list and there is work to do like porting/upgrading I can see to help there than
<yocton>
simonew: okay, let's do that :)
kpo has quit [Ping timeout: 246 seconds]
sotaoverride has quit [Quit: Lost terminal]
sotaoverride has joined #yocto
Kubu_work has quit [Quit: Leaving.]
ptsneves has joined #yocto
imx has joined #yocto
<imx>
I add the nfs-utils package to my build, after boot, I can’t start the service, how can I solve this problem? Error: unit nfs-utils.service not found
<mischief>
it does not provide a service of that name
vladest has quit [Remote host closed the connection]
ptsneves has quit [Ping timeout: 252 seconds]
<mischief>
is it safe to add to IMAGE_FEATURES[validitems] from somewhere in our layer and use it for conditionals?
dkc has joined #yocto
<derRichard>
239bf770b69e ("kernel-fitImage: Strip path component from dtb")
<derRichard>
...when you learn the hard way that you have badly named device tree files ;-)
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
vladest has joined #yocto
<Saur_Home>
mischief: Yes, you can add to IMAGE_FEATURES[validitems] from your own layers.
<gmorell>
I'm running into an issue where a package built for armhf is segfaulting due to what I believe is a lack of O_LARGEFILE support compiled into the library it uses. I'd attempted to add a bbappend for that library within the package that refers to it that adds a CFLAGS+= " D_FILE_OFFSET_BITS=64",but this didn't actually change the behavior I was seeing. I'm curious what other approaches can be tried here.
<derRichard>
gmorell: can you capture a core file to inspect the crash in gdb?
<gmorell>
I got these results by using strace
<gmorell>
I don't believe we package the coredump utils on our image
<derRichard>
coredumps are created by the kernel
<derRichard>
just set ulimit -c unlimited
<derRichard>
and make sure that the kernel.core_pattern sysctl is something like "core"
<derRichard>
and btw. it is -D_FILE_OFFSET_BITS=64, not D_FILE_OFFSET_BITS=64
<derRichard>
not the dash
<derRichard>
*note
<gmorell>
yep I have the dash, had to make some tweaks to get the coredumps going since they're presently written to /dev/null. gimme a moment longer
<gmorell>
just building gdb for the target and installing it
<derRichard>
no need to run gdb on the target
<derRichard>
just capture the core and inspect it on your workstation
<derRichard>
does your application's build system obey CFLAGS?
<gmorell>
I believe so, I'm building the application with meta-rust, but the actual issue is occuring in an FFI that it calls into. the bbappend is applied to the library that it depends on. so far, the arm64 version behaves correctly, but the armhf doesn't
Kubu_work has joined #yocto
<derRichard>
oh dear, this makes the whole situation 10 times more complicated
<gmorell>
nothing looks super out of the ordinary mostly
<derRichard>
i don't think the problem is in rrdtool
<derRichard>
that code is rock solid
<RP>
JaMa: nice to get there :)
<gmorell>
derRichard: yes, I believe it's a build flags configuration someplace
olani- has quit [Ping timeout: 260 seconds]
justache has quit [Read error: Connection reset by peer]
justache has joined #yocto
olani- has joined #yocto
<marex>
I just recently had another person complain that cloning poky.git takes them some 50 minutes
<marex>
do you have any idea why this could happen ?
<marex>
halstead: ^
<marex>
my first guess would be misconfigured something CI which cloned poky.git in a loop until they got throttled ?
<marex>
is that possible ?
<halstead>
marex: Can you tell me which IP they are hitting?
<halstead>
It shouldn't throttle that way AFAIK.
<marex>
halstead: I will ask and get back to you cca. tomorrow
<halstead>
Thank you.
<marex>
halstead: tbh a local mirror is the least anyone can do
<marex>
halstead: so there is some throttling thing in place ?
Kubu_work has quit [Quit: Leaving.]
goliath has quit [Quit: SIGSEGV]
chep has quit [Ping timeout: 268 seconds]
jmd has quit [Remote host closed the connection]
chep has joined #yocto
Vonter has quit [Ping timeout: 255 seconds]
Vonter has joined #yocto
<halstead>
marex: There is only basic connection management settings in apache. We do denylist bad IPs completely sometimes. There are three mirrors and it helps to know which one is having issues. Also https://git.yoctoproject.org/poky will outperform git://git.yoctoproject.org/poky so we always recommend using https://
Dr_Who has quit [Quit: So long and thanks for all the bits.]
alessioigor has quit [Ping timeout: 255 seconds]
mvlad has quit [Remote host closed the connection]