<berton[m]>
Hi! I'm working with a recipe that has PN, PN-tools and PN-test. These 3 packages has .debug files and I need to put this .debug file in PN-dbg, PN-tools-dbg ... I can't find a way to do this, the .debug files always goes to the first PN-*-dbg entry in PACKAGES list. Is there a way create more than on -dbg package?
berton[m] has quit [Quit: Reconnecting]
berton[m] has joined #yocto
berton[m] has quit [Client Quit]
berton[m] has joined #yocto
vd has quit [Quit: Client closed]
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
vd has joined #yocto
vd has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
jmiehe has joined #yocto
sakoman has quit [Quit: Leaving.]
jmiehe has quit [Quit: jmiehe]
<zeddii>
RP: khem: I have the vbox drivers building, I had to re-learn SVN and tease out the patches.
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
sakoman has joined #yocto
<zeddii>
khem: around ?
arlen has quit [Ping timeout: 264 seconds]
camus has quit [Ping timeout: 252 seconds]
camus has joined #yocto
amitk has joined #yocto
<zeddii>
halstead: do you happen to be around ? I'm trying to push updates for the 5.15 kernel and the git.yoctoproject hooks are once again taking issue with names in mainline commits and rejecting the pushes
<zeddii>
I'll try and grab you tomorrow. I'm calling it a day ..
<halstead>
zeddii: Please send me the error message when you get a chance.
xmn has quit [Quit: ZZZzzz…]
sakoman has quit [Quit: Leaving.]
kiran has joined #yocto
oobitots has joined #yocto
<oobitots>
Hi
Sion has joined #yocto
ThomasD13 has joined #yocto
fbre has joined #yocto
rob_w has joined #yocto
oobitots has quit [Quit: Client closed]
Guest2944 has joined #yocto
Guest2944 is now known as oobitots
oobitots has quit [Client Quit]
oobitots has joined #yocto
camus1 has joined #yocto
<JosefHolzmayrThe>
yo dudX
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
Schlumpf has joined #yocto
Wouter0100 has quit [Remote host closed the connection]
Wouter01008 has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning JosefHolzmayrThe, everyone
<JosefHolzmayrThe>
yo mckoan
leon-anavi has joined #yocto
lucaceresoli has joined #yocto
ant__ has joined #yocto
<RP>
zeddii: great, thanks
prabhakarlad has joined #yocto
xmn has joined #yocto
grma has joined #yocto
argonautx has joined #yocto
mihai has joined #yocto
mihai has quit [Quit: Leaving]
tnovotny has joined #yocto
florian has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ThomasD13>
Good morning: Short question to MACHINEOVERRIDES: machine1 = j7-evm, machine2 = j7-paradise, FOOBAR = "morning", FOOBAR_j7-paradise = "evening", MACHINEOVERRIDES for machine2 = "j7-evm".
<ThomasD13>
When building for machine2, is FOOBAR set to morning or evening?
zyga-mbp has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
<RP>
ThomasD13: I can't quite understand which override is set where but if j7-paradise is in overrides, it will be evening, otherwise morning
<ThomasD13>
OH sorry - MACHINEOVERRIDES in j7-paradise.conf is set to "j7-evm"
<ThomasD13>
hmmm...
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<barath>
RP: we've had more dunfell builds failing with the covered/notcovered issue. I'm gonna try to backport the fix for ourselves and test, unless there is an official dunfell backport in the pipeline?
<ThomasD13>
When I use the exact same config and build for MACHINE=j7-evm, FOOBAR is set to "evening"
camus has quit [Read error: Connection reset by peer]
<ThomasD13>
oh man.... thank you so much - i guess its missing for j7-evm ?
<RP>
ThomasD13: yes, I think so
xmn has quit [Quit: ZZZzzz…]
willo has quit [Ping timeout: 260 seconds]
xmn has joined #yocto
willo has joined #yocto
xmn has quit [Quit: ZZZzzz…]
Schlumpf has quit [Quit: Client closed]
jpnurmi has quit [Changing host]
jpnurmi has joined #yocto
xmn has joined #yocto
<Wouter01008>
Hey guys! I'm trying to build my first recipe for gocryptfs, but I get a lot of "no non-test Go files" (https://hastebin.com/pepesaduja.apache). As a reference I took the rclone recipe from the recipe index, and here it seems they remove specific folders in do_install_prepend - but I tried doing this, but it doesn't seem to work. My current recipe:
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
<rburton>
lists.yoctoproject.org
camus has quit [Quit: camus]
Sion has joined #yocto
camus has joined #yocto
jmiehe has joined #yocto
<RP>
or lists.openembedded.org
arlen has joined #yocto
<Tartarus>
So, I figured out the handful of missing packages from the existing oe-core sdk related packagegroups needed to build 5.14's arm64 defconfig. Should I post those as a patch somewhere? Or getting a bit task specific rather than general dev?
<Tartarus>
(It's bison, flex, bc and perl-module-integer, the first two are arguably general buildessentials, bc maybe should be default'd on in busybox? and that last one tho..)
RP has quit [Ping timeout: 264 seconds]
fbre has quit [Quit: fbre]
<zeddii>
Tartarus: see the OE core thread/patch titled "[OE-core][PATCH] nativesdk-packagegroup-sdk-host: add perl integer module "
<zeddii>
for the perl question, as for the others, we normally collect them in devsrc, but the ones you list are already there.
<zeddii>
but it might be missing the SDK bbclass extend, since that is mainly tested for on target builds.
<Tartarus>
zeddii: Note that I'm talking about on-device.
<zeddii>
:D
<zeddii>
which is what we do with devsrc all the time.
RP has joined #yocto
<Tartarus>
zeddii: I guess I'm missing something then. Rather than tools-sdk being added to my image features, what should I have done?
<Tartarus>
Yeah, that seems a bit wrong-headed frankly. I want a generic image that I can build on. Step one was wget'ing stable from kernel.org
* zeddii
shrugs
<Tartarus>
I admit the perl question is rather sticky
<Tartarus>
Maybe looking at it differently, what's the knob for "I want to be able to re-build anything installed on this image" ? That would be the generic approach since the kernel is just another thing installed on the system
* tlwoerner
looks for a knob
camus has quit [Quit: camus]
camus has joined #yocto
<RP>
Tartarus: I'm not sure we capture that information anywhere as nobody usually does that
<RP>
You'd want sources and build dependencies for everything with the build deps being translated to the target
<Tartarus>
RP: I'll admit this usecase is a tad odd, I'm trying to make an image that's useful as a "build stuff natively on it" image
<Tartarus>
But I've gone down another hole now, I can't spot how kernel-devsrc is made
<RP>
Tartarus: it has a recipe
Sion has quit [Ping timeout: 265 seconds]
<Tartarus>
🤦
<RP>
Tartarus: the "build stuff natively" has a packagegroup iirc
<Tartarus>
Lemme go make that other cup of coffee now
<RP>
Tartarus: I'm trying not to laugh :)
<Tartarus>
RP: Yeah, there's a buildessential packagegroup, and it's missing flex, bison, bc and then that perl module, for the kernel
<Tartarus>
Glad I could brighten your Friday :)
<smurray>
Would packagegroup-self-hosted be useful, I've used that for build containers?
<RP>
Tartarus: patch welcome to add those
<smurray>
Though I guess self-hosted is for the OE build aspect, vs build-essential being more like Debian's I assume
<zeddii>
I guess it depends on what is essential :D
<zeddii>
I've used the self-hosted image/package group to build servers that can rebuild themselves in the past.
<Tartarus>
RP: OK, thanks, I'll do that, and I'll put enabling bc in busybox on the list too, and see what the feedback gets to be
<RP>
Tartarus: other option is a new group build-essential-kernel
sakoman has joined #yocto
<Crofton>
anyone know how to get a ssh login if I plug my pi into my laptop directly with a network cable
<qschulz>
Crofton: easiest way is to setup a hardcoded IP address for your Pi at boot on the Ethernet interface and manually add an IP address on the Ethernet interface on the laptop
<qschulz>
with the appropriate netmask, should be good to go
argonautx has quit [Ping timeout: 252 seconds]
<Crofton>
ok
<Tartarus>
So long as you remembered to enable ssh as an image feature :)
<Crofton>
we need an idiot guide to using a pi4 with an oe build :)
mihai has joined #yocto
<qschulz>
Tartarus: indeed
<Crofton>
which I did not :)
<halstead>
zeddii: You are all set to push.
<smurray>
Crofton: if you don't have serial cable for the pi and know it'll do dhcp, the quick and dirty method is dnsmasq on the laptop
<berton[m]>
rburton: you mention to see patches in lists.yoctoproject.org. Is there a tool like pwclient to get patches? I wondering how is a smart way to get patches and apply locally
yates has joined #yocto
<rburton>
berton[m]: not sure what the state of getting patchwork up and running is again. halstead?
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #yocto
whuang0389 has joined #yocto
<halstead>
rburton: we are working on a replacement. We got reliable list collection working yesterday. I think that was the main block so it should be less than a week now.
kiran has quit [Ping timeout: 260 seconds]
kiran has joined #yocto
<berton[m]>
Nice :)
<zeddii>
halstead: thanks! works perfectly.
<rburton>
halstead: cool
Tokamak has quit [Read error: Connection reset by peer]
* tlwoerner
always has "quick and dirty" running on my embedded boards subnet
Tokamak has joined #yocto
<tlwoerner>
zeddii: what's the best way to start with a completely empty kernel config, to which i then start adding fragments via the BSP layer, yocto-kernel-cache, IMAGE_FEATURES, etc?
<tlwoerner>
zeddii: KBUILD_DEFCONFIG = "" ?
cengiz_io has quit [Ping timeout: 240 seconds]
paulbarker has quit [Ping timeout: 268 seconds]
NishanthMenon_ has quit [Ping timeout: 268 seconds]
awafaa has quit [Read error: Connection reset by peer]
awafaa has joined #yocto
armpit_ has joined #yocto
CosmicPenguin has quit [Ping timeout: 268 seconds]
armpit has quit [Ping timeout: 268 seconds]
armpit_ is now known as armpit
paulbarker has joined #yocto
cengiz_io has joined #yocto
CosmicPenguin has joined #yocto
NishanthMenon_ has joined #yocto
tnovotny has quit [Quit: Leaving]
<qschulz>
tlwoerner: or just remove the .config and then run make menuconfig and select the options by hand?
<qschulz>
it's tedious though
<zeddii>
tlwoerner: I was just writing something up for you, I sent my last series to get rid of 5.13 and was going to spend the afternoon fixing up an old script and instructions.
<tlwoerner>
zeddii: sweet! thanks :-D
<tlwoerner>
qschulz: in my opinion, providing .configs is old-skool. we have the ability (thanks to the work by zeddii) to do *SO* much better. users should be able to "build their own" configs, based on:
<tlwoerner>
- what they're including in their images
<tlwoerner>
- choosing features explicitly
<tlwoerner>
the BSP should provide what's required to get the basics running, user's/configs should select the rest
<qschulz>
tlwoerner: I meant "do that for the base defconfig"
<qschulz>
i.e. to start with a completely empty kernel config
<tlwoerner>
qschulz: in other words... create fragments? ;-)
<qschulz>
I'm not sure it makes sense to really have nothing as a base?
<qschulz>
there sure is something in common on all those boards :)
<tlwoerner>
like what? support for qcom chips? ;-) (i jest)
<tlwoerner>
i believe yocto-kernel-config already has "base" fragments based on "tiny" "regular" "large" kernels
<tlwoerner>
ideally this "build your own" config would happen behind the scenes. the config would get built "magically" based on image options (and users could pick things explicitly on top too)
<tlwoerner>
image options, distro options, etc...
vd has joined #yocto
lucaceresoli has quit [Ping timeout: 252 seconds]
dev1990 has joined #yocto
wooosaiii has quit [Remote host closed the connection]
wooosaiii has joined #yocto
<yates>
i'm having a problem building u-boot for my new architecture. the do_configure is complaining that .config does not exist: http://paste.debian.net/1213114/
<yates>
any hints?
oobitots has quit [Quit: Client closed]
<tlwoerner>
yates: Nothing to be done for '/mnt/NVMe2/yocto/build-toolchain-0/tmp/work/qemucsky-poky-linux/u-boot/1_2020.07-r0/git/configs/qemu-csky-defconfig
<tlwoerner>
that line would have created the .config, if that defconfig had been found
<yates>
tlwoerner: thanks. that line resulted from the following make: make -f /mnt/NVMe2/yocto/build-toolchain-0/tmp/work/qemucsky-poky-linux/u-boot/1_2020.07-r0/git/scripts/Makefile.build obj=scripts/kconfig configs/qemu-csky-defconfig
<yates>
originally it was this: /mnt/NVMe2/yocto/build-toolchain-0/tmp/work/qemucsky-poky-linux/u-boot/1_2020.07-r0/git/scripts/Makefile.build obj=scripts/kconfig qemu-csky-defconfig
<yates>
there is no qemu-csky-defconfig target in Makefile.build
<yates>
(i had attempted to "correct" the missing target by simply supplying the file)
<yates>
is Makefile.build generated by either yocto or perhaps automake?
<tlwoerner>
yates: you would need to create a patch adding the defconfig, then you can set it with UBOOT_MACHINE in your configs
<yates>
tlwoerner: if i did that, then wouldn't the end result be that qemu-csky-defconfig would end up in git/configs, and that the build would again fail with no .config found?
<tlwoerner>
the u-boot build will generate the .config from the specified *_defconfig
<tlwoerner>
(use underscores, by the way)
<yates>
right
<yates>
ok
<tlwoerner>
qemu_csky_defconfig
<yates>
right
Tokamak has quit [Ping timeout: 252 seconds]
<yates>
thanks!
<tlwoerner>
np
<yates>
should the patch add that config to git/configs?
<yates>
to build-toolchain-0/tmp/work/qemucsky-poky-linux/u-boot/1_2020.07-r0/git/configs ?
<tlwoerner>
yates: yes. note that there's a difference between a config and a defconfig
<tlwoerner>
you'd add a patch to u-boot, which, relative to u-boot, would add that file into configs/
Tokamak has joined #yocto
<tlwoerner>
then yocto will do a "make qemu_csky_defconfig" which causes u-boot's build to generate the .config
<yates>
ok i think i got it
<tlwoerner>
yates: if i were doing it...
<tlwoerner>
1. generate the cross compiler using yocto. install, source
<tlwoerner>
2. checkout u-boot sources (outside of yocto)
<tlwoerner>
3. run "make menuconfig", choose your settings and options
<tlwoerner>
4. run "make savedefconfig"
<yates>
tlwoerner: check/egg problem. you can get the cross compiler built until you can successfully build an image, and a successful image requires a successful u-boot build
<tlwoerner>
5. move/add the defconfig into u-boot's configs/ directory and rename it (qemu_csky_defconfig)
<yates>
s/you can/you can't/
<yates>
...chicken/egg problem...
<yates>
sheesh.
<tlwoerner>
yates: you can build the cross compiler well before needing to generate an image
<tlwoerner>
"bitbake meta-toolchian"
<tlwoerner>
all you need is a MACHINE config
<yates>
really? that's news to me!
<yates>
let me give that a go
<tlwoerner>
or you can do "-c populate_sdk"
* tlwoerner
has been meaning to blog about this workflow for a while
<yates>
tlwoerner: well that's what i'm doing: bitbake -c populate_sdk_ext core-image-minimal
<tlwoerner>
leave off the "core-image-minimal" at the end, switch to "populate_sdk" (leave off the _ext)
<tlwoerner>
or just do "bitbake meta-toolchain"
<yates>
ok lemme give those a try.
<tlwoerner>
oops sorry
<yates>
thanks man!!! very sorely needed your guidance!
<yates>
yes?
<tlwoerner>
you wouldn't be able to leave off the core-image-minimal from the end
<yates>
ok well i can try bitbake meta-toolchain ?
<tlwoerner>
but by adding "-c populate_sdk" you're saying "stop after generating the sdk"
<tlwoerner>
yes, that's what i do
<tlwoerner>
just like saying "bitbake <recipe> -c configure" stops after the do_configure step of <recipe>
<tlwoerner>
6. with the defconfig in u-boot's configs/ directory, create a u-boot patch adding the defconfig
<yates>
but literally what i need to do is just "bitbake meta-toolchain"?
<tlwoerner>
yes, just do "bitbake meta-toolchain" for a basic cross-compiler sdk, that's what i do
<yates>
does that create the install script too?
<tlwoerner>
but i had to mention that there's a second way to do it (for completeness)
<tlwoerner>
the sdk install script? yes
<yates>
yes, ok good
<tlwoerner>
7. import the u-boot patch into your custom csky layer (u-boot_%.bbappend)
amitk has joined #yocto
<yates>
tlwoerner: is 7 the last step?
<tlwoerner>
8. "bitbake u-boot"
<tlwoerner>
:-)
<yates>
9. have a glass of wine
<tlwoerner>
by the way, between 3. and 4. you would probably want to run a "make" to see how it goes
<tlwoerner>
;-)
<yates>
does "bitbake meta-toolchain" build just the sdk (not the sdk_ext)?
<yates>
that's fine, we only need the sdk for now at least, i'm just curious
<tlwoerner>
yes
<tlwoerner>
you only need an _ext if you need devtool, which you don't in the early stages of board bring-up
<yates>
why would devtool need it?
<yates>
aren't you still building on the host when using devtool?
whuang0389 has quit [Quit: Client closed]
<tlwoerner>
esdk = sdk + devtool
<yates>
oh, right
<yates>
how do you build the native target toolchain?
<tlwoerner>
and devtool is useful for updating recipes, deploying recipes to target, etc
<yates>
tlwoerner: yes, right, i've used it before.
<tlwoerner>
"native target toolchain"? a toolchain to run on the target?
<yates>
yes
<yates>
like "gcc" on your standard ubuntu/x86 system
florian has quit [Quit: Ex-Chat]
<yates>
we probably won't need that, but it would be good to have in my "back pocket".
<tlwoerner>
once you have an image running on your target, you can add "tools-sdk" to EXTRA_IMAGE_FEATURES
<yates>
ok
<tlwoerner>
yates: not it's not ;-) just use yocto and cross-compile ;-)
<tlwoerner>
in order to build on-target you need all the header files and all the dependent libraries installed.... it gets huge quickly
<yates>
it snot? yah, building on a wee tiny board is probably unbearable
<tlwoerner>
you need to install all the -dev packages
fleg has quit [Ping timeout: 240 seconds]
<tlwoerner>
9. submit your u-boot patch upstream
<jonmason>
does anyone actually use qemutinyrunner.py?
<jonmason>
because it has hardcoded values for x86, which seem like a bad idea
<jonmason>
I fixed something similar in meta-zephyr, but seems like a better idea to remove if not actually being used
<RP>
jonmason: don't we need that to test poky-tiny ?
<jonmason>
RP: that was my guess, but is poky-tiny only ever tested on x86?
<RP>
jonmason: yes :/
<jonmason>
RP: I would think Arm would like that for them ;-)
<RP>
jonmason: patches very welcome
<jonmason>
also, qemuzephyrrunner.py is hosed currently
<RP>
jonmason: given the large number of people we have working on all the QA stuff, I'm not suprised
<jonmason>
the child is exiting with sys.exit(0), and now that we care about systeemxit in build.py, boom
<RP>
jonmason: I guess we could catch the 0 case and pass it
<RP>
jonmason: and add another logging test for this :)
<jonmason>
I thought about that, but thought it was a little hacky
<jonmason>
but I'm happy to be hacking on a Friday afternoon
<jonmason>
err...hacky
<RP>
Torn on that. You'd think it would just return I guess
<RP>
can we stop it using sys.exit ?
<jonmason>
that is my current hack and it seems happy
<RP>
jonmason: that is easier
<jonmason>
I see a similar line in qemurunner.py, I wonder if that should be removed too
<tlwoerner>
it will be a 3-day event this time, including beginner presentations, intermediate to advanced hands-on labs, talks/presentations
<tlwoerner>
the final format of the conference has not been 100% determined yet, but there will be talks and hands-on and i encourage members to think about submitting their proposals
<JosefHolzmayrThe>
tlwoerner I'll go wild on Monday!
<tlwoerner>
implying your not wild on the weekends?
<tlwoerner>
or permanently?
* tlwoerner
uses the wrong "your/you're" (grrr)
<tlwoerner>
the CfP is open for the next ~3 weeks + 3 days
<jonmason>
tlwoerner: It would be nice to give us a little more notice that this is coming. Something like 3 months, 1 month of heads up, one month of CFP, and one month to get the presentation ready. Probably much more once travel starts to happen (travel budgets need approval way ahead of time)
<jonmason>
JosefHolzmayrThe: you can present on gitlab-ci and how awesome it is ;-)
<tlwoerner>
jonmason: 2 is not enough for a virtual event? ;-)
<tlwoerner>
the plan, going forward, is to continue having some sort of virtual YPS every 6 months indefinitely (i.e. as long as someone organizes it)
<jonmason>
I'm on my second in 3 weeks, with another next week. I'm about conferenced out right now
<tlwoerner>
so May-ish and November-ish
<tlwoerner>
well yes, that's why we're not doing YPS now, that's exactly why we've planned it for 2 months from now
<jonmason>
I think adding them again to ELCs would be awesome
<tlwoerner>
for the time-being, while everything is virtual, YPS grew
<jonmason>
tlwoerner: don't get me wrong, I think you are doing an awesome job
<tlwoerner>
YPS now has: beginner, hands-on, talks, OEDvM, social
<jonmason>
It takes me a while to forget how much I hate presenting ;-)
<tlwoerner>
but when we go back to in-person meetings, YPS will shrink
<jonmason>
we need to find a way to continue to do itvirtual
<tlwoerner>
annoyingly, elc is too "unstable". they've been doing elcs all over the map
<jonmason>
honestly, they have no excuse for it now being aligned anymore
<jonmason>
they've had a full year to reset
<tlwoerner>
yes, that's the plan. even after we go back to in-person events, we still want to have some part of YPS continuing on virtually (training mostly)
<jonmason>
virtual would allow for prerecordings and allow for people who do the trainings to attend the developer meetings
<tlwoerner>
in 2 months you'll be jonesing for another conference ;-)
<jonmason>
but I do have a concern that it might be the only way some people cang et travel funding approved though
<jonmason>
this is all a fun dance, right
<tlwoerner>
so when it comes time to split YPS into virtual and in-person, the in-person parts will align with ELC, the virtual parts... don't know yet
<tlwoerner>
jonmason: we're not running the developer meeting at the same time as the trainings (or the talks)
<tlwoerner>
(this time)
<tlwoerner>
day 1 will be 2 tracks:
<tlwoerner>
- beginner
<tlwoerner>
- hands-on
florian has joined #yocto
<JosefHolzmayrThe>
jonmason good idea, actually.
Tokamak has quit [Read error: Connection reset by peer]
<RP>
JPEW: do I remember you needing to do something to force pseudo to sync it's DB at exit with docker?
amitk has quit [Ping timeout: 252 seconds]
<JPEW>
Yes. Look at the cleanup script in pyrex (AFK right now or I would send a link)
amitk has joined #yocto
jmiehe has quit [Ping timeout: 250 seconds]
<khem>
RP: meta-openembedded layers are now fixed with master-next
<khem>
thanks zeddii for the vboxdrivers fix
<khem>
JPEW: how do you do user mapping in pyrex ?
<JPEW>
khem: very carefully. We make sure the user in pyrex has the same uid/gid as the user running the container
<khem>
how do you do that though, is it done during env setup ?
<khem>
or do you modify the container somehowo
<RP>
jonmason: it is interesting. We certainly struggle with the patch review dilemma too
<RP>
khem: thanks! Sorry about the issues, I think they are worth fixing though
<khem>
RP: yeah I would not have fixed them otherwise :)
<jonmason>
RP: i liked all the work they did, but the mailing list issue is a major hurdle
<JPEW>
khem: pyrex.py captures the state and passes it to the container which recreates it inside
Tokamak has quit [Read error: Connection reset by peer]
<JPEW>
It means it's basically impossible to correctly invoke just the pyrex container manually, since it needs a bunch of arguments, but we are ok with that
<JPEW>
We are willing to require the container be invoked pyrex.py to get the transparency we want
<RP>
JPEW: thanks for the pointer. I think someone else ran into it
<khem>
RP: i think my world builds have improved with latest changes it came down to 7hr12mins for qemumips which use to be around 8hrs
<khem>
I wonder if its just the latest changes or VM also got some lift
<RP>
khem: it should allow the system not to throw as much IO around
<JPEW>
RP: ya. The "fix" has works really well for so long I don't recall the exact circumstances when it was a problem.... I know it was at least a huge deal when users would Ctrl+c a build... That would almost always corrupt pesudo
<RP>
JPEW: this is someone using docker and seeing what looks like pseudo database corruption
<RP>
JPEW: it isn't making much sense but I'm betting it is that again
<RP>
JPEW: I guess in pyrex you can know which processes to wait for. We're not as lucky in the wider world :/
<JPEW>
Probably. There is an option to make pseudo dump the database more often? Might have them try that to see if it goes away. If so, probably there same issue
<RP>
JPEW: I was able to reproduce the issue so I'm experimenting
<JPEW>
Ya, the analogy in the real world would be someone using magic sysrq reboot to stop a build ;)
<JPEW>
"just kill everything, I don't care!"
Tokamak has joined #yocto
<RP>
JPEW: I've replied in the bug. Shame you weren't in triage as you might have saved me a day on this :/
<JPEW>
Sorry, busy week :(
<RP>
JPEW: np. I guess i'm happy it isn't a "real" pseudo bug
<RP>
I think we need to address the pseudo shutdown issue
<khem>
tlwoerner: do you know 5.11 onwards kernels dont boot on rockpi4b ? latest I can get going is 5.10
<abelloni>
khem: rootfs on emmc ?
<khem>
its on SD card
<khem>
I caan see kernel boots but it falls back into systemd emergency shell
<vd>
khem: hi! I think you're maintaining meta-browser, right? I'm trying to run wayland/chromium on a beaglebone black, but I get a command failed with Ninja. Do you have a working config for wayland-ozone-chromium on beaglebone?
<manuel_>
Hi all. I'm installing bitbaking a python app into my yocto image and am doing "inherit setuptools3" in my recipe. When I start my app in the image, I get an "ModuleNotFoundError: No module named 'pkg_resources'". What am I missing?
<vd>
(I've seen in the commit messages that the beaglebone is used for testing)
goliath has quit [Quit: SIGSEGV]
<manuel_>
"oe-pkgdata-util list-pkgs | grep setup" tells me there is no setuptools package available in my recipes
florian has quit [Ping timeout: 252 seconds]
<khem>
vd: I build for bunch of 64bit ARM plats e.g. rpi4/rockpi4 but have not done 32bit builds for long
<abelloni>
khem: 98e48cd9283dbac0e1445ee780889f10b3d1db6a upstream breaks emmc and possibly sdcard access
<abelloni>
for some reason it has been baclported to earlier stable kernels...
Tokamak has quit [Read error: Connection reset by peer]
<khem>
abelloni: I think it is the WIC_CREATE_EXTRA_ARGS ?= "--no-fstab-update" that I need
<khem>
I thought it was already applied but seems not yet
<khem>
abelloni: I think 5.14 will comeout ok once I have the wic issue handled
<khem>
lets see
<abelloni>
let me know, it breaks after a few writes on my helios64
<vd>
khem: would you expect web browser to run on a beaglebone? what would be the "smaller" setup? wayland/chromium?
<khem>
vd: It works ok on qemux86 with 1G RAM so I think it should work on bbb too
<khem>
512M DRAM might be a bit tight without some opts
<khem>
abelloni: it booted into weston after adjusting wic as above so 5.14.6 booted ok
<tlwoerner>
khem: i'll have to setup my ci for systemd builds. i've been booting post 5.10 kernels on my rock-pi-4b every day, in fact i was pleasantly surprised to see zeddii's 5.14 kernel booting on it this morning