eduardas has quit [Quit: Konversation terminated!]
<wyre>
why when I build an specific image bitbake is building all recipes in all layers? 🤔
<wyre>
couldn't I restrict the build process to just the recipes that the image installs and their dependencies?
xmn has quit [Quit: ZZZzzz…]
<qschulz>
wyre: this is what's done
<wyre>
qschulz, then why bitbake is building things that I don't need (for now they aren't included in my image recipe) like sudo?
<qschulz>
wyre: there are some build time dependencies that you have not explicitly listed in your image recipe
<qschulz>
it's building only what's requested
<qschulz>
nothing more
<qschulz>
so if it's building something you think you don't want/need, you'll need to debug it, because it is very likely an issue on your side
<qschulz>
bitbake -g <image recipe> and reading the .dot files with your favorite text editor should help you a bit
<qschulz>
also, it's not because something is built that it makes it to the target
tnovotny has joined #yocto
alicef has joined #yocto
LetoThe2nd has joined #yocto
<LetoThe2nd>
yo dudX
* qschulz
waves
<mckoan>
hey
<alicef>
hello, I'm trying to enable BB_GIT_SHALLOW but dosen't metter how I set it up the linux-libc-header git package get downloaded without --depth
<alicef>
mckoan: o/
kayterina has joined #yocto
<mckoan>
alicef: konnichiwa :-)
<alicef>
mckoan: do you know something about BB_GIT_SHALLOW ?
<RP>
michaelo[m]: I'm thinking about how to handle documenting the overrides change. Are you looking at that or should I try and write something about it to get started?
<mckoan>
alicef: probably Paul Barker
<mckoan>
alicef: or definitely RP
* paulbarker
ears perk up
<mckoan>
paulbarker: I didn't rememer your nickname :-)
<mckoan>
*remember
<paulbarker>
`BB_GIT_SHALLOW` probably does need documenting, I understand some of what it does. I only ever use it in combination with `BB_GENERATE_MIRROR_TARBALLS` & `BB_GENERATE_SHALLOW_TARBALLS`
<paulbarker>
In that combination it creates tarballs consisting of just the commit referenced in `SRCREV` instead of the full history
<paulbarker>
The same settings allow those tarballs to be pulled from a mirror
<paulbarker>
Not sure on the behaviour of `BB_GIT_SHALLOW` on its own without re-reading the relevant bitbake sources
<paulbarker>
alicef: The initial download will always be non-shallow
<paulbarker>
That's a limitation of git not of bitbake
<paulbarker>
RP: I'll take that one as I have the context here
<paulbarker>
Should be a quick job to add it to the docs
<RP>
paulbarker: ok, thanks!
camus has quit [Ping timeout: 276 seconds]
jordemort has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
cody has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
hmw[m] has quit [Quit: Bridge terminating on SIGTERM]
kayterina[m] has quit [Quit: Bridge terminating on SIGTERM]
SamuelDolt[m] has quit [Quit: Bridge terminating on SIGTERM]
t_unix[m] has quit [Quit: Bridge terminating on SIGTERM]
barath has quit [Quit: Bridge terminating on SIGTERM]
jwillikers[m] has quit [Quit: Bridge terminating on SIGTERM]
dwagenk has quit [Quit: Bridge terminating on SIGTERM]
asus_986_gpu[m] has quit [Quit: Bridge terminating on SIGTERM]
moto_timo[m] has quit [Quit: Bridge terminating on SIGTERM]
PascalBach[m] has quit [Quit: Bridge terminating on SIGTERM]
jonesv[m] has quit [Quit: Bridge terminating on SIGTERM]
fabatera[m] has quit [Quit: Bridge terminating on SIGTERM]
JonasVautherin[m has quit [Quit: Bridge terminating on SIGTERM]
SnowBeast[m] has quit [Quit: Bridge terminating on SIGTERM]
Saur[m] has quit [Quit: Bridge terminating on SIGTERM]
timbert[m] has quit [Quit: Bridge terminating on SIGTERM]
lacouture[m] has quit [Quit: Bridge terminating on SIGTERM]
Pierre-jeanTexie has quit [Quit: Bridge terminating on SIGTERM]
nicolas[m]12 has quit [Quit: Bridge terminating on SIGTERM]
alex88[m] has quit [Quit: Bridge terminating on SIGTERM]
keepitsimplejim[ has quit [Quit: Bridge terminating on SIGTERM]
michaelo[m] has quit [Quit: Bridge terminating on SIGTERM]
xicopitz[m] has quit [Quit: Bridge terminating on SIGTERM]
rodrjassoccom[m] has quit [Quit: Bridge terminating on SIGTERM]
shoragan|m has quit [Quit: Bridge terminating on SIGTERM]
christophs[m] has quit [Quit: Bridge terminating on SIGTERM]
Alban[m] has quit [Quit: Bridge terminating on SIGTERM]
Spectrejan[m] has quit [Quit: Bridge terminating on SIGTERM]
Emantor[m] has quit [Quit: Bridge terminating on SIGTERM]
lexano[m] has quit [Quit: Bridge terminating on SIGTERM]
TrevorWoerner[m] has quit [Quit: Bridge terminating on SIGTERM]
meck[m] has quit [Quit: Bridge terminating on SIGTERM]
m1kr0[m] has quit [Quit: Bridge terminating on SIGTERM]
ndec[m] has quit [Quit: Bridge terminating on SIGTERM]
TurtleCrazy[m] has quit [Quit: Bridge terminating on SIGTERM]
tokamak[m] has quit [Quit: Bridge terminating on SIGTERM]
ejoerns[m] has quit [Quit: Bridge terminating on SIGTERM]
AlessandroTaglia has quit [Quit: Bridge terminating on SIGTERM]
behanw[m] has quit [Quit: Bridge terminating on SIGTERM]
jordemort has joined #yocto
frieder has quit [Ping timeout: 265 seconds]
meck[m] has joined #yocto
camus has joined #yocto
kayterina[m] has joined #yocto
Emantor[m] has joined #yocto
khem has joined #yocto
moto_timo[m] has joined #yocto
cody has joined #yocto
Saur[m] has joined #yocto
shoragan[m] has joined #yocto
Pierre-jeanTexie has joined #yocto
ejoerns[m] has joined #yocto
t_unix[m] has joined #yocto
hmw[m] has joined #yocto
SamuelDolt[m] has joined #yocto
jwillikers[m] has joined #yocto
TrevorWoerner[m] has joined #yocto
barath has joined #yocto
keepitsimplejim[ has joined #yocto
Alban[m] has joined #yocto
lexano[m] has joined #yocto
shoragan|m has joined #yocto
alex88[m] has joined #yocto
Spectrejan[m] has joined #yocto
rodrjassoccom[m] has joined #yocto
AlessandroTaglia has joined #yocto
xicopitz[m] has joined #yocto
asus_986_gpu[m] has joined #yocto
ndec[m] has joined #yocto
JonasVautherin[m has joined #yocto
m1kr0[m] has joined #yocto
PascalBach[m] has joined #yocto
behanw[m] has joined #yocto
tokamak[m] has joined #yocto
lacouture[m] has joined #yocto
christophs[m] has joined #yocto
jonesv[m] has joined #yocto
timbert[m] has joined #yocto
TurtleCrazy[m] has joined #yocto
michaelo[m] has joined #yocto
SnowBeast[m] has joined #yocto
fabatera[m] has joined #yocto
dwagenk has joined #yocto
nicolas[m]12 has joined #yocto
jmiehe1 has joined #yocto
jmiehe has quit [Ping timeout: 268 seconds]
jmiehe1 is now known as jmiehe
camus has quit [Ping timeout: 245 seconds]
frieder has joined #yocto
goliath has quit [Quit: SIGSEGV]
camus has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus has joined #yocto
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
goliath has joined #yocto
georgem has joined #yocto
paulg has joined #yocto
jwillikers has joined #yocto
argonautx has joined #yocto
xmn has joined #yocto
nucatus_ has joined #yocto
nucatus has quit [Ping timeout: 252 seconds]
nucatus has joined #yocto
nucatus_ has quit [Ping timeout: 268 seconds]
alimon has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
otavio has quit [Remote host closed the connection]
otavio has joined #yocto
nucatus has quit [Ping timeout: 252 seconds]
nucatus has joined #yocto
buffo has joined #yocto
buffo has left #yocto [#yocto]
nucatus_ has joined #yocto
rosa has joined #yocto
Tokamak has joined #yocto
rosa has quit [Client Quit]
nucatus has quit [Ping timeout: 272 seconds]
nucatus_ has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
rosa has joined #yocto
camus has joined #yocto
kayterina has quit [Remote host closed the connection]
rosa has quit [Quit: Konversation terminated!]
eduardas has joined #yocto
roussinm has joined #yocto
vd has joined #yocto
<vd>
JPEW in the context of multiple hardware and multiple customers, how do you map this with whisk products and modes?
<JaMa>
RP: looks like icecc_dep_prepend in icecc.bbclass will need similar exception in the scripts/contrib/convert-overrides.py as you already did for base_dep_prepend and autotools_dep_prepend. Or can we use different function names to not look as an override?
<JPEW>
vd: I would make one product per machine-customer pair
sakoman has joined #yocto
<vd>
I see
<JPEW>
vd: But, you can share a large amount of the configuration through various means :)
<RP>
JaMa: I did think about renaming those. prepend in a function name like that wasn't ever really supported
<RP>
JaMa: I'll fix that one way or another, thanks
bps has quit [Ping timeout: 265 seconds]
<JaMa>
RP: thanks, another interesting case might be:
<RP>
JaMa: these are going to be the painful part, it is most of the exclusion list in the script :/
<JaMa>
but I understand that there is a limit of what this script can handle
<vd>
JPEW one cool thing with kas was that using their docker container, I can simply have a wrapper script in the root of the project which calls docker run. No need to prefetch the tool, quite convenient.
<RP>
JaMa: I guess the next step would be to separate out the append/remove/prepend handling and try to exclude anti-patterns from the exclusion
<JPEW>
vd: Ya, the bootstrap in whisk could be better
<JaMa>
good that in this case it causes parsing issue which cannot be overlooked (instead of silenly using "remover" as an override on completely unused variable
<vd>
JPEW other than publishing a container image along with whisk release, I don't see how you could simplify the bootstrap unfortunately. But I understood Pyrex doesn't work quite like a classic container.
<RP>
JaMa: right, it does tend to at least break things visibly :)
<alicef>
paulbarker: why not just use --depth 1 ?
<JPEW>
vd: whisk doesn't run in Pyrex FWIW, and you can have whisk fetch Pyrex with --fetch
<JPEW>
vd: I suspect that the easiest would be to publish whisk as a python module so it can be used with `pip install`
<JaMa>
and any idea why I would see bitbake-server hanging after these parsing issues? I wasn't seeing any hangs recently, but today couple times already with:
<vd>
JPEW indeed, that's what kas does. It's a python package, and they have a docker container per release containing the yocto build tools and the said package
goliath has quit [Quit: SIGSEGV]
<JPEW>
vd: Ya, it would be difficulty to publish whisk itself in a container, but it can bootstrap pyrex to run actual builds.... would you mind raising an issue in GitHub to publish whisk as a python package?
<vd>
JPEW sure
Tokamak has quit [Ping timeout: 240 seconds]
<JaMa>
RP: also please add print("processing file '%s'" % fn) at the top of processfile() or something similar as on bigger layer this script takes couple minutes without showing any progress
<vd>
JPEW in fact maybe the simpler would be to strongly recommend the usage of submodules with whisk. Like docker containers, they can be the simplest way to fetch the necessary module in an agnostic way (python tools for non pythonistas can really be a PITA)
<vd>
(again, there would be submodules handled by whisk and other managed by the developer itself, might be confusing)
<JPEW>
vd: The way we use it gives us the best of both worlds: developers do `git submodule update --init` and they get everything, but CI does `git submodule update whisk && . init-build-env --fetch` and it only gets the submodules actually required for the build
<vd>
Thanks, I'll continue my quest for the simpler customer/hardware combination builds ;-)
<vd>
Unrelated question: would IMAGE_VERSION_SUFFIX be appropriate to use the build number from the CI environment?
<JPEW>
vd: We set `BUILDNAME`
<vd>
in other words, can IMAGE_VERSION_SUFFIX be set to SOME_JENKINS_ENV_VAR or fallback to a default value?
<vd>
JPEW is BUILDNAME whisk-specific?
<JPEW>
vd: No
<JPEW>
vd: On Jenkins, we do `echo "BUILDNAME = \"${BUILD_TAG}\"" >> local.conf`
Tokamak has joined #yocto
<vd>
oh ok
<vd>
JPEW you might want to use auto.conf for that
<JPEW>
vd: Sure
<vd>
but I get the idea
<JaMa>
vd: we do something similar in webOS builds, that's why I've added those variables to oe-core, but it's still not complete (for how we use it)
bps has joined #yocto
bps has joined #yocto
frieder has quit [Ping timeout: 250 seconds]
<RP>
zeddii: FWIW I was able to reproduce that stap failure with genericx86-64 under qemu
<JaMa>
zeddii: you will need to re-run the conversion script in master-next or fix newly added overrides in recipes-extended/images/xen-image-minimal.bb
<RP>
zeddii: I did fix that PKG_INFO in the conversion script btw
eduardas has quit [Quit: Konversation terminated!]
nucatus has quit [Remote host closed the connection]
<vd>
Is there a variable referring to the multiconfig being used? i.e. foo in mc:foo:core-image-minimal?
<JaMa>
BB_CURRENT_MC?
<vd>
JaMa is it documented somewhere?
<qschulz>
michaelo[m]: I assume halstead is taking care of that and is the person to contact but I may be wrong :)
<JaMa>
vd: you can watch JPEW's talk from last summit I think he mentioned it there as well
goliath has joined #yocto
<JPEW>
JaMa: BB_CURRENT_MC.... *except* that it's not correct for the "base" multiconfig (e.g. where no multiconfig is active)
<JPEW>
JaMa: There is has the value "default", but you can't plug that into an `mcdepends` for example
* JaMa
is lucky enough not to use MC at all :)
<JPEW>
JaMa: It's actually really nice, I like it a lot :)
<fleg>
michaelo[m], I think this mirroring is done on the Matrix side, so it would be a question to the matrix.org staff
<JaMa>
lucky not to need it :)
<JPEW>
JaMa: Fair, it does get more complicated :)
<vd>
JPEW any specific reason why whisk moves DEPLOY_DIR out of TMPDIR?
<zeddii>
hah. I had just done pass #2 and pushed a separate commit to master-next on the conversion. :D
<zeddii>
RP: aha. that's good. I'm not going to have much for cycles for fixing much until Aug 12th. I'll be reading my opensource email, but am on vacation from now until then,
<JPEW>
vd: No, just our preferred layout. PR to make it configurable (if it's not already) welcome :)
<zeddii>
RP: the stap SRCREV bump was trivial when I did it here, but there wasn't much that looked like it would address the error.
<halstead>
qschulz: michaelo[m]: I'm not running the matrix bridge. I can't recall who is at the moment. Maybe khem knows?
<RP>
zeddii: it looks to be the difference between the kernel asm/pthread.h and the userspace asm/pthread.h
bizulk has quit [Quit: Client closed]
<JaMa>
RP: FYI: the script doesn't replace RDEPENDS_${PN}-ptest_remove_class-target (which I have quite a few of these)
<zeddii>
RP: yah, this is what always happened with perf as well. We had to capture copes of headers, etc.
<zeddii>
RP: remind me, what is the mix, this is current stap on master with the 5.13 libc-headers ?
<RP>
zeddii: yes. Enjoy the vacation, I'll poke at it a bit more
<zeddii>
and so it only happens on 5.10 and 5.4 ? I could delete those kernels ;) (kidding).
<RP>
zeddii: I think so, not sure yet
<zeddii>
RP: I am around for the next few hours (then packing), but I fired up some builds of genericx86-64, 5.10 kernel preference and systemtap. I'll see if I can make it go boom on the booted target as well.
mckoan is now known as mckoan|away
<RP>
zeddii: cd /usr/src/kernel; make scripts prepare; stap --disable-cache -DSTP_NO_VERREL_CHECK /tmp/hello.stp seems to make it happen in short order
<RP>
pulling hello.stp from the meta/lib/oeqa/runtime/files
<zeddii>
yah. that's how I always test stap. I just scp on the bits I need from the tests. so that's good.
* paulg
tries to think of large patch series to fill zeddii vaca inbox with
* zeddii
shakes his fist
<vd>
TMPDIR *must* be different for every variant of hardware, libc, etc., but is it same to share a common DEPLOY_DIR_IMAGE?
<JPEW>
vd: That would be tricky
<paulg>
RP, I saw today that linux-stable picked up our cgroup/LTP fix for v5.10 and v5.4 and v5.13 ; not that we really care ; zeddii put it where needed already IIRC.
nucatus has joined #yocto
<vd>
is it safe*
<JPEW>
vd: Maybe... it would depend on having no multiconfigs that overwrite the same files
tnovotny has quit [Quit: Leaving]
<vd>
indeed. I *just* need to make sure that filenames are unique for every multiconfig (including the default)
<JPEW>
vd: I think so... one way to make sure they are all unique is to put each in it's own directory ;)
yates has joined #yocto
nucatus has quit [Ping timeout: 272 seconds]
<vd>
indeed.
<vd>
But isn't there a feature of the deploy class or anything to ensure that you're not overriding a file from another recipe?
<vd>
that'd be just perfect.
creich_ has quit [Read error: Connection reset by peer]
bps has joined #yocto
bps has joined #yocto
<vd>
The thing is I never really understand why DEPLOY_DIR_IMAGE contains ${MACHINE}, if TMPDIR is expected to be different for any machine/libc/distro combinations. Isn't it redundant and useless?
<fray>
tmpdir is distro specific, you can build multiple machines in a distro
sakoman has quit [Ping timeout: 250 seconds]
<vd>
fray but you shouldn't share the same TMPDIR for different machines, right?
<fray>
I build multiple machines with the same TMPDIR all the time.. it's the distro configurations (and sdkmachine) that need specific TMPDIR
<vd>
ho
<vd>
fray so you're saying you can safely build a distro for x86 and arm in the same TMPDIR, as long as the distro conf is the same?
<fray>
"multiconfig" is different. These need their own TMPDIR because they may be writing tmp files, even for multiple machines..
<fray>
the TMPDIR sharing between multiple _machines_ is from single (non-multiconfig) builds
<vd>
ho ok
<vd>
I'm having hard time figuring out how to properly separate the config for "a customer build", which is a given hardware (or multiple), a given distro (always the same) and tweaks to the default image recipes.
<vd>
I thought maybe distro conf + auto.conf was enough but I guess multiconfig really is what's needed here
argonautx has quit [Ping timeout: 272 seconds]
<kergoth>
multiconfig is just a way to kick off multiple builds with differing configuration in a single bitbake command
<kergoth>
well, mostly. you can still build those without it, is the point, just via changing local/auto
<vd>
JaMa: btw is there a way to override "default" in BB_CURRENT_MC? (e.g. if I want "vanilla" instead).
<kergoth>
you dont need to override anything, just where you *use* that variable you'd use inline python if 'default' isn't the value you need
<vd>
kergoth: ok so I must see a multiconfig as a clean way to store a known config, instead of hacking on local/auto
florian has quit [Quit: Ex-Chat]
<kergoth>
yeah, it's a way of encoding that knowledge as well as being able to build them all in one go, without having to encode that knowledge in your CI jobs or something...
<vd>
( kergoth: it's just that "vanilla" is more obvious than "default" in our company vocabulary, so BB_DEFAULT_MC ?= "vanilla" would be convenient, but inline python is fine ;-) )
<kergoth>
still, i'd recommend minimizing local config. if you're changing the default images, you probably just want your own images, for example
<vd>
kergoth I figure appending the default images would be cleaner since I have a distro, a few machines, default (vanilla) images, then for each customer there small tweaks to do, like overriding the default root password via EXTRA_USER_PARAMS, embedding custom images via ROOTFS_POSTPROCESS_COMMAND, etc.
<vd>
A multiconfig for each customer combination seemed more appropriate than defining their own image recipes. Would you recommend a different approach?
zpfvo has quit [Quit: Leaving.]
<RP>
paulg: I saw, nice it made it through. What about the RCU stall thing? :)
<kergoth>
ah, yeah, if there were image hcanges common to all customers itd make sense to create your own images for your distro, but if not what you're doing makes sense
<RP>
paulg: as you say, "we're" kind of sorted now
vd has quit [Quit: Client closed]
vd has joined #yocto
<vd>
kergoth: so I would have a generic distro-image-base recipe, and something like IMAGE_INSTALL_pn-distro-image-base_append = " customer-conf" in a multiconfig.
<vd>
But even though it's not technically correct, a different machine configuration for every customer would be way simpler?
<paulg>
RP, the 406a2f008f2e RCU stall still languishes in -next and not mainline, as paulmck effectively does a two release soak cycle for any given change.
<paulg>
(and linux-stable won't normally touch anything that isn't in mainline yet)
<RP>
zeddii: Adding -DSTAPCONF_X86_UNIREGS to the stap command makes it work
<RP>
paulg: for what is a pretty horrible machine crash, that is a bit sad :(
<RP>
Does anyone know anything about how systemtap sorts these defines?
nucatus has joined #yocto
jwillikers has quit [Remote host closed the connection]
<RP>
moto-timo: ^^^ - looks like we have the problem identified
<michaelo>
Back on a normal IRC client (instead of Matrix)
<moto-timo>
RP: excellent. I was looking at commits but didn’t get to that one yet
goliath has quit [Quit: SIGSEGV]
<RP>
michaelo: wasn't working out with the notifications?
<michaelo>
RP: if you're talking about the Matrix interface, indeed, I just get a fraction of the messages. Didn't you say you're using Matrix too?
florian has joined #yocto
<RP>
michaelo: I'm not, I just noticed you were
nucatus has joined #yocto
nucatus has quit [Ping timeout: 265 seconds]
nucatus has joined #yocto
nucatus has quit [Ping timeout: 252 seconds]
ykrons has quit [Ping timeout: 265 seconds]
ykrons has joined #yocto
<zeddii>
RP: well that's nicely simple.
<zeddii>
I'll kill my build
<vd>
kergoth: JPEW: I think I will start by defining one machine per customer instead of multiconfigs, even though it isn't techically correct (it's the same hardware after all), it will allow me to customize the default images from there while keeping the build simple.
nucatus has joined #yocto
<vd>
then I'll need multiconfig to build them, forget what I've said...
LetoThe2nd has quit [Quit: Connection closed for inactivity]
nucatus has quit [Ping timeout: 272 seconds]
<jsbronder>
vd: Are you trying to use machine so that you can use the override syntax? SOME_VAR_machine = "..."
goliath has joined #yocto
kpo has quit [Read error: Connection reset by peer]
kpo has joined #yocto
nucatus has joined #yocto
<RP>
zeddii: thankfully nothing horrible, thanks for ramping up ready :)
Tokamak has quit [Ping timeout: 258 seconds]
nucatus has quit [Ping timeout: 265 seconds]
LetoThe2nd has joined #yocto
LocutusOfBorg has quit [Ping timeout: 256 seconds]
LocutusOfBorg has joined #yocto
vd has quit [Quit: Client closed]
frieder has joined #yocto
florian has quit [Ping timeout: 265 seconds]
<smurray>
RP: during local testing with just the prservice selftests I managed to reproduce what looks like the same failure as you saw on the AB yesterday, even with rebasing onto JPEW's rework to move the asyncio loop creation
<smurray>
RP: I think there's maybe a race in the PR export now, I'll need to try to decipher the backtraces
ochredoke has quit [Ping timeout: 240 seconds]
ochredoke has joined #yocto
nucatus has joined #yocto
zyga has quit [Ping timeout: 240 seconds]
<RP>
smurray: glad you could reproduce! :)
<smurray>
RP: tbh I think it was just luck, I've run it about 20 times in the last 2 days
nucatus has quit [Ping timeout: 240 seconds]
nucatus has joined #yocto
nucatus has quit [Ping timeout: 276 seconds]
sakoman has quit [Quit: Leaving.]
nucatus has joined #yocto
frieder has quit [Remote host closed the connection]
nucatus has quit [Ping timeout: 252 seconds]
<override>
so im writing some user space code that would set what rootfs partition to use for next boot cycle. Im using libubootenv for it. does anyone have any other recommendations / stuff theyd want to link me to?
sakoman has joined #yocto
vd has joined #yocto
<LetoThe2nd>
a steady hand and a magnetic needle.
<LetoThe2nd>
or if you
<LetoThe2nd>
if you're really brave, then a handful of butterflies.
<vd>
jsbronder: I was considering one machine configuration per customer profile yes
florian has joined #yocto
<vd>
At the moment I'm trying multiconfig with IMAGE_BASENAME = "${BB_CURRENT_MC}-${PN}" and TMPDIR = "${TOPDIR}/tmp/${BB_CURRENT_MC}" and see how it does.
<jsbronder>
Then you'd do IMAGE_BASENAME_customerabc = "whatever"
<jsbronder>
which has no affect in all of your other multiconfigs where "customerabc" isn't in OVERRIDES.
Tokamak has joined #yocto
<vd>
jsbronder I thought you we talking about MACHINEOVERRIDES and defining one machine configuration file per customer profile
<jsbronder>
MACHINEOVERRIDES are just included in OVERRIDES.
nucatus has joined #yocto
leon-anavi has quit [Quit: Leaving]
<vd>
jsbronder is it what you're using?
<jsbronder>
For something similar yes.
nucatus has quit [Ping timeout: 272 seconds]
<jsbronder>
I have a number of images I need to build that are >99% the same. For each there's only a few customizations that I put in my recipes/appends themselves.
<jsbronder>
This includes setting IMAGE_BASENAME sometimes or adding a patch in SRC_URI.
<vd>
jsbronder kind of the same for me actually. I have vanilla images, each customer has a different password, a few default images pre-embedded inside of them, etc.
<vd>
I thought about adding the customization inside a multiconfig, but if I understand correctly, you set an OVERRIDES and you add the changes inside the recipe itself. Is that correct?
<jsbronder>
Yes, I like the locality of the customization in the recipe its modifying. If I need a list of all of them it's easy enough to `git grep _customerabc`
ant__ has joined #yocto
nucatus has joined #yocto
<vd>
I think I would prefer to centralize all customization for a customer inside a single file, but your way is actually simple
nucatus has quit [Ping timeout: 245 seconds]
jmiehe has quit [Quit: jmiehe]
nucatus has joined #yocto
amitk_ has joined #yocto
nucatus has quit [Ping timeout: 276 seconds]
amitk has quit [Ping timeout: 256 seconds]
zyga has joined #yocto
<vd>
jsbronder so the OVERRIDES mechanism is not only for machines, it can be anything? Hence your approach for customizing recipes
<vd>
jsbronder you could actually lighten up your multiconfig files by setting OVERRIDES .= ":${BB_CURRENT_MC}" in your distro conf for example. It will hold the multiconfig name, or "default" otherwise.
<jsbronder>
huh, good point ;)
<vd>
jsbronder how would you deal with 2 machines for the same customer? 2 multiconfig customer-mach1 and customer-mach2 ?
<jsbronder>
maybe something like OVERRIDES =. "customer:customer-mach1" so you can still do generic stuff for that specific customer.
<vd>
very true. This way I can tweak config packages (with _customer) or machine package like kernel or bootloader (with _customer-mach1)
<vd>
jsbronder do you customize everything in your image recipe, things such as SUMMARY_foo = "My recipe for foo"?
<vd>
jsbronder did you consider doing bbappend for your image in order to split the image customization in another file?
nucatus has joined #yocto
BobPungartnik has joined #yocto
<jsbronder>
I don't actually have different customers, my use-case is just somewhat similar to what you were describing.
creich has joined #yocto
BobPungartnik has quit [Client Quit]
<jsbronder>
for instance, I have an x86 image that gets deployed to $very_expensive_hardware_every_dev_cannot_have.
<jsbronder>
So we leverage container images that are also built using the same layers and mostly the same configuration.
nucatus has quit [Ping timeout: 272 seconds]
florian has joined #yocto
<jsbronder>
We also deploy some stuff to our manufacturers in containers.
<RP>
JaMa: for your ptest_remove issue, I wonder if adding that to the 'if "ptest_append" in line:' in the script would help
Tokamak has quit [Ping timeout: 258 seconds]
<RP>
JaMa: I think that should be ok so I'll fix the script with that
nucatus has joined #yocto
nucatus has quit [Ping timeout: 240 seconds]
Tokamak has joined #yocto
<vd>
jsbronder I see, thanks. I might add .bbappend file for my generic recipes in some recipes-customer or even a meta-customer layer, but the idea is the same as yours with OVERRIDES. I'm hacking on it rn!
nucatus has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
<vd>
Can you conditionally enable a recipe bbappend? By the mean of overrides for example?
<vd>
forcing the _override inside of the bbappend recipe seems unnecessarily complex, but it's not a big deal if there's no other choice
nucatus has quit [Ping timeout: 240 seconds]
<vd>
Other question, does ${IMAGE_NAME_pn-some-image-recipe} works? I'd like to have a robust way to get an image name from another recipe.
<vd>
s/robust/reliable/
risca has joined #yocto
sakoman has quit [Ping timeout: 256 seconds]
ant__ has quit [Quit: Leaving]
sakoman has joined #yocto
<kergoth>
vd: only if the variable is defined as that in the global configuration metadata. one recipe can't access variables of another directly by design, only its own and what flows down from the configuration metadata
nucatus has joined #yocto
<vd>
I see, so it's a bad idea. It is still better (with the current code) to rely on the formula used for IMAGE_NAME. e.g. ${BB_CURRENT_MC}-${IMAGE_BASENAME}.
florian has quit [Ping timeout: 258 seconds]
<vd>
The downside is that it's specific to your configuration and not very generic, but well that's for a private layer after all.
nucatus has quit [Ping timeout: 268 seconds]
vd has quit [Quit: Client closed]
vd has joined #yocto
<vd>
how can you conditionally do do_rootfs[depends] += , but dor a given OVERRIDES?
nucatus has joined #yocto
LetoThe2nd has quit [Quit: Connection closed for inactivity]
nucatus has quit [Ping timeout: 265 seconds]
yates has quit [Remote host closed the connection]