sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
frieder has joined #yocto
mihai- is now known as mihai
zpfvo has joined #yocto
zyga has joined #yocto
goliath has joined #yocto
LetoThe2nd has joined #yocto
leon-anavi has joined #yocto
tre has joined #yocto
florian has joined #yocto
<RP>
kanavin_: quite the upgrade series, thanks! :)
<LetoThe2nd>
yo dudX
<kanavin_>
RP: cheers :) my pre-testing on the AB does make it smooth doesn't it :)
<RP>
kanavin_: yes, definitely :)
<kanavin_>
RP: is there still time for additional upgrades?
<RP>
kanavin_: the main issue left is rust. That series isn't ready, it doesn't even build locally for me. The time left really depends what I decide to do with that
<kanavin_>
RP: I mean, if I have more fully tested version updates, when is the last good day to send them in?
<LetoThe2nd>
RP: i want the above quote out of context
<RP>
kanavin_: technically, today is the feature freeze. I suspect I'm going to give things a few days though. There is also the pseudo/glibc 2.34 issue I need to figure out
<kanavin_>
I couldn't resist making a dig at nvidia by the way, I really don't like how they treat nouveau (intentionally cripple) and their own blob (refusing to play along with what everyone else is using)
<RP>
kanavin_: it isn't good :(
<kanavin_>
halstead, is it possible/easy to provision 'modprobe vgem' to all the AB workers? There's a test around qemu and graphics that would be enabled by that.
<kanavin_>
RP: ^^^
<kanavin_>
halstead, if you rememember we talked a while ago about updating graphical HW on the workers, with the above it's no longer an issue
d0ku has joined #yocto
<RP>
kanavin_: given the range of distros I suspect that isn't straightforward :/
o_ndra has joined #yocto
<kanavin_>
RP: right, systemd has a unified way of doing it though, via /etc/modules-load.d/
xmn has joined #yocto
grma has joined #yocto
<wCPO>
tlwoerner: wouldn't be it be better to use ext4 without the journal than ext2 for your zram patch?
<rburton>
prabhakarlad: that's the prerm package manager script, so that's removing the alternatives when it is *removing* the package
<rburton>
if you're still trying to figure out where timeout is, have you checked the configure log yet? timeout is only built if a specific signal name could be found.
<prabhakarlad>
but during do_package its been removed, update-alternatives --remove timeout /usr/bin/timeout.coreutils
camus1 has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
thekappe has joined #yocto
goliath has joined #yocto
zyga has joined #yocto
<wCPO>
hmm, it looks like CONFIG_SCSI_VIRTIO=y is silently dropped with linux-yocto 5.10, hmm
<rburton>
prabhakarlad: that's just a debug note telling you what it is setting as postinst/prerm scripts
<rburton>
prabhakarlad: "oe-pkgdata-util list-pkg-files coreutils" will show you if coreutils contains /usr/bin/timeout.coreutils, which it does here
<rburton>
on install, a symlink for /usr/bin/timeout will be created (unless you've done something to disable alternative generation)
<yates_home>
in my core-image-minimal build of elfutils, there are duplicate files for crti.o: one in recipe-sysroot/usr/lib/crti.o and one in recipe-sysroot/usr/lib/csky-poky-linux/10.3.0/crti.o
<yates_home>
which one is correct?
<yates_home>
they are different files - different lengths
<prabhakarlad>
coreutils is in the RPROVIDES of target-sdk-provides-dummy:
rsalveti has joined #yocto
<d0ku>
Hi, anyone with extensible SDK experience here? I want to generate an eSDK and then use `sdk-install` to add the required `-native` tools, but it seems that the PATH is not extended automatically (e.g. binaries in <native sysroot>/bin/perl-native are not visible unless PATH is manually modified). Did I miss something or my use-case is not supported?
<cengiz_io>
hello. I have changed the value of my MACHINE_OVERRIDES in my layer and how can I verify that that change actually took place in my image?
<tlwoerner>
wCPO: is there much of a benefit to ext4 without a journal vs ext2?
<tlwoerner>
wCPO: i guess it could be configurable
<wCPO>
tlwoerner: ext3 without a journal is basically ext2, but ext4 has some features neither ext2 nor ext3 has https://kernelnewbies.org/Ext4 . I'm unsure if it matters when fs is in memory
<tlwoerner>
wCPO: in any case it would be best if i made it configurable, then people could make their own choice :-)
paulg has joined #yocto
<wCPO>
tlwoerner: agree. In the end I think either choice is good-enough
<tlwoerner>
although that could get messy with having to coordinate with kernel configs
<RP>
tlwoerner: extents in ext4 are nice FWIW
<RP>
paulg: morning!
rperier has joined #yocto
<RP>
paulg: I was looking at ppc serial interrupt handler backtraces and thinking of you :)
<paulg>
uh oh. I was just wondering --- What did I break, or am being volunteered to fix....
<paulg>
it kinda smells like a race between completing driver init and having data come in.
<cengiz_io>
qschulz: thanks. that should at least verify that it propagated
<qschulz>
what did you put in your MACHINEOVERRIDES and in which file?
<paulg>
(i.e. request_irq is too late, or never happens for some odd reason...)
<paulg>
RP, in theory a generic vanilla master build for qemu-ppc should get me similar to that? So I can have one local churning in the bkgd?
<RP>
paulg: that is a standard qemuppc build, yes. I suspect usage of the serial port will reproduce, we don't use it much...
<paulg>
I have NFI what serial driver qemu fakes ; assuming 16550. Will set a build and see what .config says and what .o it creates and go from there.
<RP>
paulg: we previously turned off serial console log messages iirc which helped by removing one of the sources of problems
<paulg>
Awesome. So "problem solved. Didn't see it - didn't happen." :-)
<cengiz_io>
qschulz: it's actually automotive grade linux, which has a template mechanism for including fragments into local.conf
<cengiz_io>
qschulz: my goal is to use mainline kernel with meta-freescale, which seems to be toggled with this `MACHINEOVERRIDES .= ":use-mainline-bsp"` (not sure though)
<qschulz>
cengiz_io: IIRC, this enables etnaviv instead of vivante too
<qschulz>
but you're probbaly on the right track
<cengiz_io>
qschulz: yeah. etnaviv is what I want :)
sakoman has joined #yocto
troth has joined #yocto
<rburton>
prabhakarlad: yeah i see that if i'd build a sdk. blow away tmp and try again, it works fine. should fix that bug.
mihai has quit [Read error: Connection reset by peer]
mihai has joined #yocto
paulg has quit [Ping timeout: 252 seconds]
vd has joined #yocto
zyga has quit [Quit: Leaving]
paulg has joined #yocto
kayterina has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
<prabhakarlad>
rburton: deleting tmp (and rebuilding) , oe-pkgdata-util list-pkg-files coreutils does list /usr/bin/timeout.coreutils
jwessel has left #yocto [#yocto]
<rburton>
deleting tmp won't cause a rebuild unless you put sstate in it, which is a bad idea
florian has quit [Quit: Ex-Chat]
<prabhakarlad>
but built image still has timeout utility missing.
<prabhakarlad>
>[4:30:38 PM] <rburton> deleting tmp won't cause a rebuild unless you put sstate in it, which is a bad idea
<prabhakarlad>
agreed.
tnovotny has quit [Quit: Leaving]
otavio_ has quit [Read error: Connection reset by peer]
otavio has joined #yocto
<tlwoerner>
anyone seen something like this before?
<tlwoerner>
Error, the PACKAGE_ARCHS variable (all any noarch ${PACKAGE_EXTRA_ARCHS:tune-mips32r2el-24kc} qemumips) for DEFAULTTUNE (mips32r2el-24kc) does not contain TUNE_PKGARCH (${MIPSPKGSFX_VARIANT:tune-mips32r2el-24kc}-nf).Toolchain tunings invalid
<tlwoerner>
if something is listed in AVAILTUNES it's available to use?
frieder has quit [Remote host closed the connection]
otavio__ has quit [Quit: leaving]
dev1990 has joined #yocto
alimon has joined #yocto
ssajal has quit [Ping timeout: 240 seconds]
tre has quit [Remote host closed the connection]
zpfvo has quit [Remote host closed the connection]
sethfoster has joined #yocto
<sethfoster>
Hey all. Last week I was asking about kind of hacking together a fetcher for google's gclient in a recipe; qschultz super helpfully pointed me at their meta-rust custom fetcher, which was great. One thing I was wondering though - is there a way to deduplicate files between DL_DIR and the source area? Because the source for this is like 25G and therefore will take a while to copy and also take a bunch of
<sethfoster>
space
goliath has joined #yocto
<halstead>
kanavin_: vgem is loaded on all the workers except centos8*. I need to build the module there.
<kanavin_>
halstead, thanks! not sure why centos doesn't have it, if it's available in e.g. fedora
ant__ has joined #yocto
<halstead>
True. Fedora workers are ready.
<kanavin_>
halstead, any progress on the AUH emails?
o_ndra has quit [Quit: Client closed]
<halstead>
kanavin_: I made some progress. I've gathered debugging info and made contact with support. It's not solved yet.
alejandrohs has joined #yocto
<kanavin_>
halstead, thanks again :)
fleg has quit [Remote host closed the connection]
tp43_ has joined #yocto
<kanavin_>
RP: and here it is in action:
<kanavin_>
2021-08-23 17:23:57,348 - oe-selftest - INFO - runtime_test.TestImage.test_testimage_virgl_headless (subunit.RemotedTestCase)
<kanavin_>
no need to get rid of those trusty G200s :)
jsbronder has quit [Remote host closed the connection]
jsbronder has joined #yocto
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<sethfoster>
How bad an idea do you folks think it would be to symlink a source dir to a dl cache
<sethfoster>
pretty bad right
<manuel1985>
sethfoster: No idea, but I also though about keeping the code for some little applications next to the bitbake recipe in the meta-layer.
<sethfoster>
yeah i have too many dang repos
<sethfoster>
problem here is the source is like 25 gigs so i'd like to not have to have it twice or copy it around
<manuel1985>
One could have files/src dir which is actually a git submodule
<manuel1985>
sethfoster: Oh, ok. Well, that's bad.
<sethfoster>
yeah it's not my favorite thing in the world
alejandrohs has quit [Ping timeout: 240 seconds]
<bantu>
Hello everyone. I am trying to add rxtx to my image. I'm seeing ./gnu_io_CommPortIdentifier.h:3:10: fatal error: jni.h: No such file or directory
amitk has joined #yocto
alejandrohs has joined #yocto
amitk_ has quit [Ping timeout: 252 seconds]
<smurray>
JPEW: I'm curious if you're planning to go to the OpenChain/SPDX mini-summit the day after ELC? Trying to figure out if it's worthwhile registering for it
amitk_ has joined #yocto
<JPEW>
I did not see it. I'll look into it
amitk has quit [Ping timeout: 250 seconds]
sakoman has quit [Ping timeout: 252 seconds]
sakoman has joined #yocto
<jonmason>
RP: today's mesa update is causing build breaks for qemuarmv5. I'm looking into it (something about neon and softfp), but wanted to make you aware
amitk has joined #yocto
amitk_ has quit [Ping timeout: 250 seconds]
bantu has quit [Ping timeout: 268 seconds]
bantu has joined #yocto
<kanavin_>
jonmason, how come AB didn't catch it?
<jonmason>
kanavin_: I don't believe the AB builds qemuarmv5, which is why we do in our CI :)
<kanavin_>
jonmason, it builds 32 bit arm but that's not the same?
<kanavin_>
qemuarm
<jonmason>
no, there is 2 32bit arm machines: qemuarm (ARMv7) and qemuarmv5 (ARMv5)
<kanavin_>
if upstream doesn't test it, things are likely to break
<kanavin_>
mesa upstream
sakoman has quit [Ping timeout: 250 seconds]
sakoman has joined #yocto
florian has joined #yocto
<jonmason>
there was a request to keep ARMv5 around when I updated qemuarm to be ARMv7, but it really only is for ancient machines (like the first gen RasPi in age)
<jonmason>
I have it in our nightly CI, and we run (a subset of )testimage. So we'll find it when it breaks
amitk has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
<sakoman>
A company has contacted me looking for some full time help in "fixing" a sub-optimal rocko based image build -- boot time, package content, and build infrastructure. Ping me if you are interested (or know someone who might be)
amitk has quit [Ping timeout: 240 seconds]
<manuel1985>
Why do some recipes have functions with only a colon as content? do_install () {\n :\n }
<manuel1985>
\n are newlines obviously
<vmeson>
manuel1985: where are you seeing that do_install rule ? What does the git blame/log say about it?
<manuel1985>
I had devtool autocreate a recipe for git://github.com/brettviren/pygst-tutorial-org.git
<manuel1985>
It put a comment in the recipe saying that it couldn't find a Makefile and I'd need to fill in the function bodies myself
sakoman has quit [Read error: Connection reset by peer]
<manuel1985>
for do_configure, do_compile and do_install
<vmeson>
manuel1985: devtool can be helpful but it does not perform magic. As the warning stated, you'll have to look at the docs and other python recipes to figure out what to do.
sakoman has joined #yocto
<manuel1985>
vmeson: Yeah okay, but that still doesn't tell me the purpose of the colons. I mean, why a colon, not a $ or * or ^.
<manuel1985>
I don't speak Python I should add.
<vmeson>
manuel1985: What's the exact comment in the recipe ?
<smurray>
a single colon like that is basically a placeholder in Bash, look at the "SHELL BUILTIN COMMANDS" section in the bash man page, it's the first entry
<vmeson>
smurray: that's what I expected, it would seem like a better choice to have that stage fail but I guess it depends on what the goal is with devtool.
<smurray>
vmeson: it expects you to put something in there per the mentioned comment
<manuel1985>
vmeson: The exact comment in the recipe is "NOTE: no Makefile found, unable to determine what needs to be done"
<manuel1985>
smurray: Thanks, that explains things. Would never have thought that : is shell language. But makes sense. The commeands in put in do_install are shell commands after all.
<smurray>
if there's a script in there that's desired, disabling do_compile and cp'ing the script in do_install is likely what'd you want to do
Guest56 has joined #yocto
Guest56 has quit [Client Quit]
<paulg>
RP, no wonder that turd catches fire. Check out all the flapping and flailing that takes place at 16s when the driver takes over -- this is with debug enabled and IRQ request/free printk added. https://paste.debian.net/1208754/
<paulg>
ideally qemu ppc should target a decade old 83xx or 85xx processor with 16550 and u-boot, and not some pre-y2k 7400 with zilog ttyS.... :-/
<manuel1985>
When I'm building my image, I see do_image_ext3 and do_image_tar tasks executed. I don't need the .tar, because I'm loopback-mounting the .ext3 and netbooting my device. Can I disable creation of the .tar?
<paulg>
obviously if we gut the stupidity of all the up/down up/down up/down nonsense and grab/keep the IRQ at probe, I'm sure zilog ttyS<n> will magically stop blowing up.
sethfoster has quit [Quit: leaving]
camus1 has joined #yocto
leon-anavi has quit [Quit: Leaving]
camus has quit [Read error: Connection reset by peer]
<RP>
paulg: back in may was when we disabled the serial console logs which seemed to "help"
<RP>
paulg: if you wanted to suggest a different config for qemuppc we could try it...
<paulg>
hacking together a fix that moves irq request up some lines ; should fix the steaming POS.
<paulg>
not going to get involved in filtering out all its flapping and flailing if I don't ahve to.
<RP>
paulg: fair enough, thanks :)
<RP>
it'd be nice to have one less set of weird failures
<paulg>
you all get to test it after it passes my "doesn't splat" high standards.
<RP>
vmeson: speaking of weird failures, I'll just say publicly that I'm doubtful about rust at this point
<paulg>
I'll send it onwards to mainline in case there are other necro serial driver afficionados out there.
<yates_home>
RP: pray tell why.
<RP>
vmeson: I have no idea how to try and fix the uninative breakage, other than perhaps trying to merge the rust-llvm and rust recipes, or add an intermediate task the doesn't use sstate
<RP>
yates_home: because it doesn't build/work in too many situations
<RP>
vmeson: if I don't merge it now, I will not be merging it until some of these issues get fixed though, it won't just "merge after we branch"
<RP>
khem: do you have any interest/time to look at rust?
<vmeson>
RP: That's fine with me, better to fix it over the next month in meta-rust or my contrib branch than mess up the release.
<RP>
vmeson: it is a shame as the AB is just showing failures in the reproducibility targets but those failures look hard. If we could resolve that one...
<RP>
vmeson: did we have rsvg and the python crypto module building with this?
<RP>
smurray, paulbarker: I did merge the prserv changes finally, thanks!
<vmeson>
RP: I _had_ librsvg building in Feb but I haven't gotten back to it. I"m not sure if tgamblin has gotten python-cryptography updated.
<smurray>
RP: saw that, thanks!
<RP>
vmeson: fair enough, I just wondered if it actually worked for our intended use
<paulg>
ok. who is the wiseguy who broke kernel devshell ?
<RP>
smurray: I'm jumpy every time I see a build taking a long time
<paulg>
kernel-source#git show
<paulg>
kernel-source#
<paulg>
fatal: bad object HEAD
<moto-timo>
I know tgamblin was looking at py-crypto last week
<moto-timo>
RP: sounds like you would like to see us build it with the rust branch?
<RP>
moto-timo: would show the thing actually does something useful ;-)
<moto-timo>
RP: fair enough!
<RP>
Such a patch could be queued in this changeset
<vmeson>
py-crypto lives in meta-oe right now, of course we could move it...
<RP>
vmeson: ah, we need the librsvg example then :)
<vmeson>
RP: I can work on that this evening / tomorrow.
<RP>
vmeson: I guess it comes down to the uninative issue - is there any chance we can resolve this in a few days, e.g. this week?
<vmeson>
RP - I have no idea what the uninative issue is off-hand so I cant' say. Let me look at your commit logs...
dev1990 has quit [Quit: Konversation terminated!]
<RP>
vmeson: it is this: it is easy to reproduce, you just bitbake rust-native on a
<RP>
vmeson: which is bitbake rust-native on an older system with no sstate present and uninative enabled
<RP>
error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/pokybuild/yocto-worker/reproducible-debian/build/build-st/reproducibleA/tmp/work/x86_64-linux/rust-native/1.54.0-r0/rustc-1.54.0-src/build/bootstrap/debug/deps/libproc_macro_error_attr-9c7a09885c50c72e.so)
<manuel1985>
vmeson: Thanks for the IMAGE_FSTYPES link
<vmeson>
RP: as you suggested: WARNING: Duplicate inclusion for /ala-lpggp31/rmacleod/src/distro/yocto/poky.git/meta/conf/distro/include/yocto-uninative.inc in /ala-lpggp31/rmacleod/src/distro/yocto/poky.git/meta-poky/conf/distro/poky.conf
<vmeson>
but "bitbake rust-native" builds fine!
<vmeson>
That's on master-next on an ubu-18.04.3 distro.
sakoman has quit [Read error: Connection reset by peer]
vd has quit [Quit: Client closed]
<moto-timo>
vmeson: for py-crypto, which requires rust compiler, do you think I should ‘inherit rust’?
<moto-timo>
Or DEPENDS ‘rust-native’
sgw has joined #yocto
sakoman has joined #yocto
<vmeson>
moto-timo: rust-hello-world just has 'inherit cargo', as does suricata in meta-security.
<moto-timo>
vmeson: I’ll have to look at setup.py and see what it is calling
shoragan has quit [Ping timeout: 255 seconds]
shoragan has joined #yocto
goliath has quit [Quit: SIGSEGV]
dev1990 has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
* vmeson
gets a debian-8 container setup enough to start the build of rust-native on poky/master-next and calls it a day.
* paulg
curses BUILD_REPRODUCIBLE_BINARIES
<paulg>
hateful thing will be forever off in any config I use.
<paulg>
mucking with /proc/version is just evil. I want to know I've booted what I just built.
<paulg>
esp. when I'm expecting debug statements and don't get them. Why is on the default anyway?