<RP>
Hard to reproduce, easy to fix now the cause is known
Guest3365 has joined #yocto
Guest3365 has quit [Client Quit]
ollie88r has joined #yocto
<ollie88r>
hi. im having issues getting "shadow" to be installed in my targets image. I can across the following
<ollie88r>
When runtime package management is disabled in the image, several packages are removed including base-passwd, shadow, and update-alternatives. You can specify functions separated by semicolons:
<ollie88r>
could this be the reason? and if so, can someone help me work around this?
argonautx has joined #yocto
<keepitsimplejim[>
I've found a patch that looks to correct the error with 'libebl' when compiling for Gatesgarth and I'm in the process of compiling so I'll have to get back if it works. I've attached a link to the patch.
<patrick_r>
am cross compiling for imx-6 so it is an arm 7 processor, some software here can be either native of cross compiled. need to -D__ARM__ for example only for the cross compilation as I have parts of the source code (#ifdef etc) that I don't want to compile in native
<kanavin>
mcfrisk, that's just the first one out of 6 or 7
<mcfrisk>
sigh
<mcfrisk>
but I managed to build it today on local machine, not on our CI servers. I might have them all
<mcfrisk>
is this the full set of files: langtools-fd2fdb20d858.tar.gz jdk-d7ecb57d3c61.tar.gz jaxws-d92eda447bca.tar.gz jaxp-77e7219c7424.tar.gz corba-79ee8535bc51.tar.gz hotspot-a456d0771ba0.tar.gz
<ecdhe>
I'm using a kernel recipe that's been extended several times. What's the easiest way to inspect the final rendering of its .config file? `devtool modify` puts it in a workspace directory for me but the .config hasn't been generated at that point.
<mcfrisk>
I went through icedtea7-native SRC_URI and found those files from my local download cache. Would be nice to get them to yocto side mirrors, if nothing else.
<kanavin>
mcfrisk, corba is not there for one thing?
<kanavin>
I guess both should be added to yocto mirror and then someone should attempt a build
Guest1 has joined #yocto
<mcfrisk>
"bitbake -c fetch icedtea7-native" is enough to test
<mcfrisk>
or there may be more java recipes broken...
patrick_r has joined #yocto
<v0n>
I have tty devices which requires to send them a specific letter at a specific baudrate in order to identify it and receive an ID. Are there tool out there to do that already or should go with a simple C program tweaking termios structs?
paulg has joined #yocto
<RP>
mcfrisk: let me add those...
<RP>
mcfrisk: files should be either there or in the process of the server syncing them in
sakoman has joined #yocto
yates has joined #yocto
<ilunev>
I wonder why a "devtool modify linux-raspberrypi" does not apply any patches from SRC_URI whilst bitbake happily uses them.
<yates>
i'm seeing "ld.bfd" used as the linker. what is that? i thought "ld" was the linker?
prabhakarlad has joined #yocto
<RP>
yates: there are two possible linkers, the older one (bfd) and gold
<yates>
RP: ok
<yates>
going decades back, i always thought the executable "ld" was the old/standard one, not "ld.bfd". perhaps that's relatively new?
<RP>
yates: now there are two you need a way to specify it
<yates>
that makes sense.
rcw has joined #yocto
<yates>
new question: isn't it a common problem to require a driver within u-boot, e.g., a specific file system, as well as for the booted linux kernel? is it necessary to develop the two drivers independently or is there some way one driver can be shared?
<rburton>
brotli/c/enc/encode.c:1473:20: error: argument 5 of type ‘const uint8_t *’ {aka ‘const unsigned char *’} declared as a pointer [-Werror=vla-parameter]
<rburton>
spider sense tingling
<jonmason>
wasn't this patched recently?
<rburton>
yes
<rburton>
will revert and see if this is all khem's fault
prabhakarlad has quit [Ping timeout: 250 seconds]
<jonmason>
lol, blame khem!
<RP>
at least I'm not getting blamed for a change :)
<rburton>
yet
<rburton>
you may have just jinxed it
<RP>
heh, can't wait :)
<rburton>
fired a manual build on that worker to poke
prabhakarlad has joined #yocto
zpfvo has quit [Quit: Leaving.]
<rburton>
hm ok so reverting that didn't help
<rburton>
aha
<rburton>
thought my spider sense was tinging and it wasn't the last patch
<rburton>
got a fix
<rburton>
grr
<rburton>
does THISDIR get updated for inc files?
<rburton>
so if I require, the path is where the include is?
vmeson has quit [Ping timeout: 240 seconds]
<rburton>
(yes)
vmeson has joined #yocto
TommyGilchrist has joined #yocto
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<rburton>
RP: rule of thumb is that tumbleweed has gcc11
tnovotny has quit [Quit: Leaving]
<TommyGilchrist>
Hi folks, just joined and I'm new to IRC in general. I've joined to hopefully get some help getting a compiled driver to work in a Yocto based build
prabhakarlad has quit [Quit: Client closed]
<rburton>
RP: got a fix locally, should be in meta-arm tomorrow
<TommyGilchrist>
But I'm not sure of the local rules / good manners. I don't want to just barge in with "someone fix this for me"
<TommyGilchrist>
Also, this is for use on an Nvidia Jetson board so not sure if this it would be better to ask on meta-tegra or here
<TommyGilchrist>
Issue is that a company has provided a pre-compiled driver (they won't release the source) for their video card and it works fine for the Nvidia supplied Ubuntu 18.04 reference build but when I try to modprobe the driver files in Yocto I get “modprobe: ERROR: could not insert 'videobuf_dma_sg': Exec format error”
<TommyGilchrist>
And this is my first foray in linux drivers
prabhakarlad has joined #yocto
ilunev has joined #yocto
zyga-mbp has quit [Ping timeout: 268 seconds]
ilunev has quit [Ping timeout: 240 seconds]
ilunev has joined #yocto
<ecdhe>
TommyGilchrist: welcome!
<ecdhe>
What are the kernel versions that work and don't work?
<TommyGilchrist>
Thanks ecdhe - That's what's confusing me (well, that and a lot of other things). I think they're the same. Just digging out the details
<v0n>
I'm adding "gcc" to IMAGE_INSTALL but I don't have (g)cc on the target. Is it the wrong package?
<TommyGilchrist>
From the Yocto build - uname -r => 4.9.201-l4t-r32.5+gc68230c5b46a
<rburton>
v0n: gcc-symlinks to get the 'gcc' binary
<v0n>
rburton: thank you
zyga-mbp has joined #yocto
<TommyGilchrist>
and from the Nvidia build => 4.9.201-tegra
<TommyGilchrist>
What I did notice is that the Nvidia kernel was built with GCC 7.3.1 whereas the Yocto build used GCC 8.3.0 and I did find some articles indicating that the "Exec format error" could be related to GCC version but I don't know if that's actually relevant in this case
<TommyGilchrist>
modinfo ./videobuf-dma-sg.ko (the first of the precompiled drivers that tries to load) reports
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gsalazar has quit [Ping timeout: 272 seconds]
ilunev has quit [Ping timeout: 244 seconds]
ilunev has joined #yocto
<smurray>
TommyGilchrist: I could imagine modversions being problematic, even with the same kernel commit level I think differences in .config might yield different checksums
zyga-mbp has joined #yocto
ilunev has quit [Ping timeout: 268 seconds]
<moto-timo>
qemu-system-native is failing do_configure missing pthreads/headers... but I don't see libpthread-stubs as a dependency in qemu/ recipes
<moto-timo>
seems like a 6.0 change
<khem>
rburton: I fixed sbsa-acs recipe not edk2-firmware
<khem>
but it seems you need same fix there too
ilunev has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<moto-timo>
so it might only be happening with one of those configs?
<moto-timo>
(on master)
prabhakarlad has quit [Quit: Client closed]
<TommyGilchrist>
Thanks smurray - my problem is that I vaguely understand those terms but it looks like I've a steep learning curve ahead of me
<TommyGilchrist>
Or rather I know what they mean but not how to address it :-)
<ecdhe>
TommyGilchrist: I msg'd you
ncaidin_lf has joined #yocto
<ncaidin_lf>
Hi Richard, I don't know if you've identified anyone to respond to the LTS discussion yet, but as I was reviewing my notes again, I was wondering if I should respond with the following: The recent survey made it relatively clear that folks might be interested in 3 or 4 years for support. We haven't had a mix-in layer in practice. Members who share
<ncaidin_lf>
an interest in a particular kernel version could come together and support. Experimenting with this approach could be quite valuable for the community to learn from.Changing the compiler would have a big ripple effect (which I assume means lots of churn and changes and not so easily manageable).There was a mention about 6 year Android releases and
<ncaidin_lf>
whether YP should take that into consideration?An acknowledgement that it may not be easy to figure out the best kernel strategies.At least one company/org seemed interested in updating the Linux Kernel in the 2nd year of the Yocto LTS. Is there any shared interest for this? This potentially could be where experimenting with the mix-in layer
<ncaidin_lf>
would come in.
<ncaidin_lf>
(those are supposed to be bullet points)
prabhakarlad has joined #yocto
TommyGilchrist is now known as tommyg
xmn has joined #yocto
kpo_ has quit [Read error: Connection reset by peer]
<JPEW>
RP: Would the word "ERROR" in stderr cause a AB job to think it had an error?
<JPEW>
RP: Adding tests for the streaming compressor patch I sent; LZ4 prints "Error ..." to stderr when I test for expected failure conditions; want to know if that will confuse the AB, or if I need to supress stderr
kpo_ has joined #yocto
ncaidin_lf has quit [Quit: Client closed]
<moto-timo>
qemu-system-native config issue is self inflicted... needs PACKAGECONFIG pie
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ncaidin_lf has joined #yocto
ncaidin_lf has quit [Client Quit]
<moto-timo>
seems to happen when adding gtk+ to PACKAGECONFIG
<ecdhe>
I have a SRC_URI = git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git;protocol=git;tag=v5.13-rc6
<ecdhe>
The commit hash of this specific commit is 009..33d
<ecdhe>
So then I get a "Failed to fetch URL"
<ecdhe>
Then I get "Fetcher failure: Unable to find revision <commit hash> in branch master even from upstream"
<ecdhe>
I did not specific a commit hash in the recipe, so the fact that I'm seeing the expected commit hash means it found the tag I specified and found the correct commit hash.
<ecdhe>
What I don't get is why the fetcher cares whether this tag/commit is on master or not
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
<moto-timo>
RP: looks like qemu-system-native PACKAGECONFIG is yet another case where variable precedence is.... not exactly as 'expected'
<RP>
JPEW: it won't confuse tasks, it would confuse the main console so it depends where it is logged
<RP>
moto-timo: I talked about that on in my previous oe-arch email :/
<JPEW>
RP: Ok. I decided to add an option to suppress stderr (which the tests use) anyway
<moto-timo>
yeah... it's the first time it bit me (and I knew it bit me)
<moto-timo>
fingers crossed graphical qemu works this time.
<RP>
rburton: right, I suspected something like that, thanks!
<moto-timo>
need to figure out why qemu (graphical) isn't launching properly with testimage on master... something changed since hardknot/qemu-6.0.0
<moto-timo>
check that... I think I saw the same issue with hardknott. some system configuration nonsense to be sure
<RP>
moto-timo: I think I have gtk and sdl enabled in my local.conf for reasons I don't remember
moto-timo_ has joined #yocto
moto-timo_ has quit [Client Quit]
moto-timo_ has joined #yocto
<dvorkindmitry>
how can I write my bblayers.conf file to force it to include some -meta automatically if it exists? I want to write something like BBLAYERS ?= " ${TOPDIR}/../meta-openamp" and it should pass Ok if there is no meta-openamp dir
moto-timo_ has quit [Client Quit]
Vonter has quit [Ping timeout: 268 seconds]
moto-timo_ has joined #yocto
moto-timo_ has quit [Client Quit]
moto-timo has quit [*.net *.split]
moto-timo has joined #yocto
<moto_timo[m]>
RP: yeah, I need to understand that better (sdl vs. gtk+)
<moto-timo>
libera went a little nuts there for me for a moment
<moto-timo>
luckily matrix carried the converation
<vmeson>
RP noted but I've run out of attention span for the day. The sun is out and the patio is calling me...
<RP>
vmeson: its only 10pm here and I'm still going :(
<RP>
Those logs suggest three separate qemu instances in separate bitbake builds were taken out at roughly the same time
<RP>
and on 1804 again
wesm has joined #yocto
yannd has quit [Quit: Quitte]
<paulg>
okay, I'll bite - what is 1804? Some sekrit code name for a sector of Area51?
yannd has joined #yocto
vmeson has quit [Ping timeout: 244 seconds]
<RP>
paulg: ubuntu 18.04 host machines
<RP>
paulg: yours is more fun
<paulg>
ah, right - the whole "commas save lives
<paulg>
and "lets eat Grandpa" thing.
* paulg
was actually thinking line numbers in some test log or similar.
<paulg>
rcu stall messages are pretty much designed to be impenetrable by mere mortals w/o doing two hours of reading of the source...
prabhakarlad has quit [Quit: Client closed]
<ant_home>
if it'd happen often on arm I'd try to lure arnd on #armlinux
<ant_home>
s/mere mortals/arnd/
<ant_home>
and it is penetrable
<paulg>
checked #mklinux the other day to see if the ppc folks moved from FleaNode to Belarus Chat - both looked like ghost towns.
rob_w has quit [Quit: Leaving]
<paulg>
I guess I should start saying "FleeNode" instead of my usual "FleaNode" :-P
<paulg>
I left when I saw yocti left.
<paulg>
Can't argue with a bot.
<moto-timo>
/close #fleenode
<moto-timo>
9 out of 10 lemmings agree
<jordemort>
so here's a really weird one, i am mounting a ubifs root in my initramfs - if i just let that script run, it works fine, but if i sleep 10 seconds before trying to mount the filesystem, it hangs hard, no logs, completely unresponsive, no kernel panic
<jordemort>
i have dealt with filesystems that get angry if you mount them too soon but this is the first one i have encountered that gets angry if you mount it too late
<jordemort>
no background processes or anything, my init script in the initramfs is pid 1
goliath has quit [Quit: SIGSEGV]
<ant_home>
jordemort, derRichard is your man
<ant_home>
are you sure the ubifs is sane?
<RP>
paulg: they removed my nick reg so that was the end of it for me
<derRichard>
jordemort: this makes no sense at all
<jordemort>
ant_home: sane enough for u-boot to load the kernel and initramfs off of it, sane enough that if i mount it right away then the device boots up and plays nice
<derRichard>
did you enable the kernel hung task or lockup detector?
<moto-timo>
Paula
<moto-timo>
Argh
<jordemort>
derRichard: yeah it super doesn't, it seems like if i wait more than ~4-5 seconds to mount it after things come up then i get the freeze
ant_home is now known as ant
<moto-timo>
paulg: when they kicked IRCcloud clients I said “ you are too insane for me to waste my time”
ant is now known as Guest1692
<jordemort>
i'm wondering if there's something dumb happening in my kernel? something wrong in the device tree that makes the kernel step on something important like an interrupt or something... but if that was the case i'd expect the device to hang in normal operation, it doesn't, no NAND or FS problems once it comes up
<jordemort>
derRichard: not explicitly, i'll look into that
<paulg>
[06/16 18:48] -NickServ- Nick paulg isn't registered.
<paulg>
Hrrmph. Never noticed that. Savages.
Guest1692 has quit [Quit: Leaving]
ant_home has joined #yocto
<derRichard>
jordemort: one thing that comes into my mind is the ubi wearleveling worker. maybe(!) it starts with work and gets stuck after some time while doing io
<derRichard>
a buggy nand driver could cause this
kpo_ has quit [Read error: Connection reset by peer]
BCMM has quit [Quit: Konversation terminated!]
<jordemort>
hm, booting with nmi_watchdog=1 and softlockup_panic=1 hasn't produced any debugging
<derRichard>
did you enable these in the kernel?
kpo_ has joined #yocto
<derRichard>
e.g CONFIG_HARDLOCKUP_DETECTOR=y
<jordemort>
ah are there associated kernel config options?
<derRichard>
and CONFIG_SOFTLOCKUP_DETECTOR=y
<derRichard>
yes
<jordemort>
ok
<derRichard>
jordemort: did it trigger?
<jordemort>
derRichard: still rebuilding the kernel
<jordemort>
derRichard: i'll let you know tomorrow, going to wander off to dinner soon
<derRichard>
ok :)
<jordemort>
thanks for the help!
<derRichard>
np
<jordemort>
i am like 99% sure i messed up the device tree here or something porting from the vendor's 4.14 to 5.4
<jordemort>
i should really just hand them back my kernel tree and tell them "you fix it" :D