<LetoThe2nd>
kayterina[m]: I'd guess that is because the ${D} path is the absolute host path, and FILES is relative to the resulting rootfs. And that usually long path just does not exist on your output rootfs.
simonew has quit [Ping timeout: 250 seconds]
<kayterina[m]>
$IMAGE_ROOTFS is the resulting rootfs path?
huseyinkozan has joined #yocto
frieder has joined #yocto
<kayterina[m]>
and how do I see that FILES or any other variable is relative to some directory?
simonew has joined #yocto
Schlumpf has joined #yocto
dev1990 has joined #yocto
leon-anavi has joined #yocto
alejandrohs has quit [Ping timeout: 268 seconds]
<qschulz>
kayterina[m]: I guess this is something we could add to the documentation
goliath has joined #yocto
dlan has quit [Quit: leaving]
dlan has joined #yocto
<qschulz>
amahnui[m]: please be careful when you send patches that you only send it once. If you modify a patch and want to send a new version, please use git send-email -v2 or git format-patch -v2
<qschulz>
(or v3, v4, etc... and explain just below the three dashes what changed between v1 and v2, v2 and v3, etc...)
alejandrohs has joined #yocto
dacav has joined #yocto
rperier has quit [Remote host closed the connection]
rperier has joined #yocto
Belgarion has quit [Ping timeout: 256 seconds]
Belgarion has joined #yocto
OutBackDingo has quit [Read error: Connection reset by peer]
OutBackDingo has joined #yocto
frosteyes has quit [Ping timeout: 272 seconds]
frosteyes has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
mvlad_ has joined #yocto
mvlad has quit [Remote host closed the connection]
vladest has quit [Remote host closed the connection]
GNUmoon has joined #yocto
vladest has joined #yocto
* RP
just came across a patch from 2017 trying to fix tinfoil's wait_event. 5 years later we might have got there!
<qschulz>
amahnui[m]: to be fair, git is not very user friendly :)
<amahnui[m]>
qschulz: Thanks a lot for the clarification, I will make sure to that using either of this commands you sent.
Schiller has joined #yocto
<Schlumpf>
Hi, does anybody have seen bitbake BrokenPipeErrors in runqueue.py at hatdknott?
prabhakarlad has quit [Quit: Client closed]
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #yocto
<Saur[m]>
amahnui: I recommend using the second variant suggested by qschulz above as that allows you edit the patch files before they are sent, e.g., to be able to add comments (after the line with three dashes "---"), which is especially useful when sending updated patches to inform what has changed compared to the previous version of the patches.
Schlumpf has quit [Quit: Client closed]
Schlumpf has joined #yocto
<amahnui[m]>
Saur: Thanks a lot I think that is what I will go for.
<qschulz>
amahnui[m]: don't forget to use subdirectories or remove patches between git send-email executions or you'll send all patches (if you use *.patch) and not only the ones you wanted to send now
<LetoThe2nd>
I'm seeing gdk-pixbuf failing on master for riscv. Anybody aware of problems there?
<rburton>
khem is my go-to for riscv
<amahnui[m]>
qschulz: I'm sorry I don't understand since I never had an option to pass the specific patch I'm sending. Please could you explain more?
<LetoThe2nd>
rburton: yeah sure, but I (usually) don't pester the VIPs unless I have asked the commons :)
<qschulz>
amahnui[m]: when you use *.patch, the shell will expand this to all files currently listed in the current directory, which ends with .patch
<qschulz>
if you do not remove the patch from v1 when you want to send a v2, then you'll send both v1 and v2 patches, because *.patch will match both
<rburton>
fwiw, this is why i rarely bother with the format-patch/send-email split unless needed
<LetoThe2nd>
and to be honest, this doesn't exactly sound like a riscv-only thing: (glib-compile-resources:2605920): GLib-GObject-CRITICAL **: 10:36:14.842: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
<LetoThe2nd>
../gdk-pixbuf-2.42.6/tests/resources.gresource.xml: Failed to close file descriptor for child process (Operation not permitted).y
<amahnui[m]>
qschulz: Oh okay I understand you clearly now. I remember seeing that on one of the patches I sent which conatined 2 patches instead of 1 patch on the maling list.
<amahnui[m]>
I will do that 🙏
<qschulz>
rburton: I like it this way because I do a last minute check of the commit and I'm also entirely sure of what's being sent
<qschulz>
but to each their own workflow :)
<rburton>
i use 'git show' for that
<rburton>
yeah, each to their own :)
troth has quit [Ping timeout: 246 seconds]
<amahnui[m]>
rburton: I just ran git show on my command line and it showed the most recent change I made and some very useful information too. I will use this command as well so that I will use the format-patch command when I finally think the patch is ready to be submitted
LocutusOfBorg has quit [Quit: ZNC 1.8.2+deb1 - https://znc.in]
LocutusOfBorg has joined #yocto
prabhakarlad has joined #yocto
troth has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 268 seconds]
simonew has quit [Quit: Client closed]
<JaMa>
rburton: new progressbar for stalled tasks works great :)
<ndec>
hi there.. in case you missed the noise on Twitter and LinkedIn.. be aware that we will have our next YP Summit in May, more at https://yoctoproject.org/summit. We have opened the CFP for now, will open registration shortly.
Tyaku has joined #yocto
<Tyaku>
Hi, I am using Yocto to create an image for RaspberryPI3. The image is using meta-raspberrypi. Currently I am stuck with two things: I'm not able to integrate the SPI, and i'm also not able to get the serial console working.
<Tyaku>
In my local.conf I set this: ENABLE_UART = "1" and ENABLE_SPI_BUS = "1"
<Tyaku>
When the linux boot, nothing get out on serial line. And I don't have /dev/spixxx devices. I try to enable the modules but no changes
<rburton>
agherzan: ^^^ meta-rpi question for you
simonew has joined #yocto
Schiller has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
bps2 has joined #yocto
<agherzan>
Tyaku: is that a rpi3 or cm3?
<agherzan>
Also, what version of meta-raspberrypi are you using?
bps has quit [Ping timeout: 268 seconds]
<agherzan>
Are you using uboot, if yes, can you try without it?
<Tyaku>
It's a raspberry pi3, I found something interesting: When I flash a SDCard it works ! When I use the network boot, then the serial console is not working and spidev is not created !
<Tyaku>
Oh, I just see that I can't cat /boot when using network boot. So there is something wrong in my /etc/fstab I think
<Tyaku>
I think there is something wrong with the NFS, So the problem is not related to meta-raspberry (Jesus)
prabhakarlad has joined #yocto
<vvn>
rburton: hi! Regarding our previous conversation, I think the machine configuration is also an integration point for hardware-specific packages since in practice a product will likely need a custom one instead of using a generic one (i.e. to integrate the bootloader of choice, preferred providers, encryption, some hardware acceleration drivers, etc.)
<vvn>
So in theory one could build an image for a generic machine, but a complete product would likely require a custom distro as well as custom machine configurations (and likely custom images). Would you agree?
Schlumpf has quit [Quit: Client closed]
simonew has quit [Ping timeout: 250 seconds]
simonew has joined #yocto
simonew has quit [Client Quit]
<jclsn[m]>
Does anyone has experience with mirroring source repos to Artifactory? Seems like you need an ftp server, which I am not sure Artifactory provides
<jclsn[m]>
s/has/have/
ar__ has joined #yocto
<jclsn[m]>
I only can PUT and GET files with curl.
codavi has joined #yocto
<jclsn[m]>
Seems like I have to pull the tarballs with a shell script before building hmm
<rfs613>
To share the downloads directory across multiple local yocto trees, is there a difference between setting DL_DIR in each (local.conf etc) versus making "downloads" a symlink? eg. what is the recommended approach, if any?
<qschulz>
rfs613: if you set DL_DIR correctly, there's no manual step required (the symlinking)
simonew has quit [Quit: Client closed]
<qschulz>
rfs613: and since you should do the same for SSTATE_DIR, it's two steps less than doing the symlinking manually :)
<rfs613>
is this a reasonable use for auto.conf or site.conf ?
<rburton>
you could put it in site.conf
<rburton>
site.conf works well if you have a eg company-wide layer
<rburton>
so it can set proxies, central mirrors, etc
<rfs613>
ok thanks. I noticed that bitbake uses os.path.normpath() in some places, which is known to break symlinks.
<rfs613>
so I guess that's another reason to use DL_DIR / SSTATE_DIR
<vvn>
qschulz: do you know if downstream users of AGL define their own machine configuration files or if they use the upstream ones solely?
<qschulz>
vvn: is this question really aimed at me?
sakoman has joined #yocto
<smurray>
vvn: AGL upstream supports various dev boards, anyone doing a product pretty much would have to have their own BSP with a machine for their custom h/w (even if it's somewhat minimal to provide a devicetree + kernel config on top of the silicon vendor's BSP)
<vvn>
qschulz: oops nope it was for smurray, sorry.
<qschulz>
vvn: no worries, was surprised because I never played with AGL before :D
<vvn>
smurray: so adding a custom foo.conf machine which requires a vendor bsp is somewhat common I assume
<smurray>
vvn: yes
<vvn>
smurray: how does AGL deal with adding support for a vendor BSP, does it use custom machine configurations too or does it use overrides extensively?
simonew has joined #yocto
<smurray>
vvn: there are no custom machine configurations in upstream (*), AGL upstream only targets dev boards that (at least so far) have existing machine .conf's in vendor BSPs
Minvera has joined #yocto
<smurray>
vvn: the * is that we do carry some tweaks to vendor BSPs to e.g. consistently enable some kernel configs and fix wayland configuration issues
simonew has quit [Client Quit]
<smurray>
vvn: that's done with effectively local.conf tweaks and bbappends, and we try to avoid anything really significant
<smurray>
vvn: and there's actually one custom machine in tree at the moment that I can think of, but it's to target a specific kernel for running in VMs with a bunch of virtio features enabled
<amahnui[m]>
Hello everyone,
<amahnui[m]>
I just wanted ask if there's any outreachy applicant in the chat I wish to connect
<smurray>
vvn: but for some customer engagements around AGL that I've been involved with for Konsulko, we've done what I described, a small product-specific BSP layer on top of the vendor BSP, then a corresponding distro layer
<amahnui[m]>
I also wish to ask how many cores is recommended for an 8gb ram machine when running bitbake core-image-sato
<amahnui[m]>
The machine as 8GB of RAM nad 8 cores
bps2 has joined #yocto
GLumen_ has joined #yocto
Wouter0100 has joined #yocto
bps3 has quit [Ping timeout: 260 seconds]
goliath has joined #yocto
<vvn>
smurray: so something like meta-<company>-bsp with a foomach.conf machine configuration file which does 'require conf/machine/beaglebone.conf' and tweaks, as well as meta-<company>-distro with a foodist.conf which customize the software stack further.
Schiller has joined #yocto
<amahnui[m]>
Please how do I call PARALLEL_MAKE in my conf/local.conf file in the case that iit is not present there
<qschulz>
amahnui[m]: I'm not entirely certain limiting PARALLEL_MAKE in conf/local.conf would be enough (disclosure: I suggested it in private), but just set PARALLEL_MAKE="-j 4" in conf/local.conf for example
<smurray>
vvn: yeah, something along those lines. If the foomach machine is much different from an existing board, the .conf might be a modified copy or a from scratch written one. There's sometimes cruft in the dev board configs you might not want to have to work to undo
<amahnui[m]>
qschulz: thanks I'll add it there rather.
<vvn>
smurray: I see. That's what I wondering if I do well or not. In the example of meta-ti/beaglebone, the BSP machine conf is lacking many things I need (preferred drivers for hardware acceleration, different bootloader, some machine dependencies and tweaks...) but I do not want to miss an upstream fix, so require beaglebone.conf seems safe, even though it's a bit ugly...
<vvn>
I was using a custom include file to add these tweaks, but then it becomes distro specific and it is a bit more obfuscated than a custom machine config :/
<smurray>
vvn: yeah, there can be grey areas
goliath has quit [Quit: SIGSEGV]
<rfs613>
does the autobuild run dunfell branch with meta-openembedded layer?
<vvn>
smurray: true and it can get frustrating. Ideally a machine conf can be generic enough not to be overridden, but the reality is choosing an alternative bootloader, preferred drivers, custom boot scripts and whatnot requires a custom config and loading the distro with overrides or include files can become quickly cumbersome
florian_kc has quit [Remote host closed the connection]
<rfs613>
build #3472 seems to be dunfell-nut branch + meta-selftest layer... but I had to dig the log to find this. Is there another way to search?
Schiller has quit [Quit: Client closed]
<jclsn[m]>
landgraf: I understand how authentication works for Artifactor, but I don't see how I can simply add the URL as SOURCE_MIRROR_URL.
<jclsn[m]>
Does Bitbake support that?
<rburton>
wget will respect .netrc for authentication details
dgriego has joined #yocto
Tyaku has quit [Quit: Lost terminal]
<jclsn[m]>
Ah you can access the Artifactory repos with https. I thought it would only be possible via the REST API
<sakoman>
rfs613: In general, no, most autobuilder runs don't include meta-openembedded. Near release times I do run meta-oe tests to check that nothing is broken
<rfs613>
sakoman: that's the feeling I got after browsing around a bit. Thanks for confirming. I'm seeing some fuzz warnings from a recent CVE patch in polkit, trying to see if it shows up in autobuilder as well.
<landgraf>
jclsn[m]: bitbake fetcher uses wget for https, wGET does GET and don't PUT just because of its name :)
<Saur[m]>
fabatera: No, one recipe cannot affect another recipe in any way.
<jclsn[m]>
<landgraf> "jclsn: bitbake fetcher uses..." <- Yeah I get it. So this means I have to PUT manually via a script, which shouldnt be too bad. It’s not like you have to do it every day.
bps2 has quit [Ping timeout: 240 seconds]
<rburton>
zeddii: it appears that the xtf-image:testimage integration is broken in master. just tried it, and the boot appears to hang.
<vvn>
kergoth: not sure actually. It makes me think about having 'include conf/${MACHINE}-${DISTRO}.inc' upstream in meta/conf/bitbake.conf. It seems nice, but in the end too much include files and variables and overrides make the project cumbersome, and downstream machine/distro/image files to support an actual product often end up simpler and more intuitive. Just my opinion.
<kergoth>
The above bbclass just provides an explicit lever for a build to override a distro, so i don't think it's as bad as directly crossing the distro/machine/image boundaries
<kergoth>
but it's a good point
GillesM has quit [Quit: Leaving]
GillesM has joined #yocto
GillesM has quit [Remote host closed the connection]
<vvn>
and make sure that initramfs-tools is installed as part of whatever initramfs image you are using.
<manuel>
vvn: Makes sense, thank you. How come initramfs-tools is optional? That patch is patching some very fundamental things when booting linux (that is, mounting the rootfs and switching root into it). If initramfs-tools is not in place, what is providing this functionality then?
<vvn>
manuel: actually initramfs-tools is just a tool from Debian used to create an initramfs image. I guess it is run on the target itself to generate /boot/linux-initramfs.img or whatever. It isn't an initramfs package per-se if I'm not mistaken, but a target package.
<smurray>
it's not used by OE/Yocto at all that I can see
<vvn>
manuel: (re)generating the initramfs image from the target itself is one way of doing it, but you may build it elsewhere, like core-image-minimal-initramfs. Or your own recipe.
<manuel>
vvn: Alright, I understand. Wasn't aware this is just the Debian way of doing things. But it all makes sense. Thanks! I know how to proceed now.
<smurray>
vvn: ah, I did look in the layer index just now, but missed it
<vvn>
manuel: and those scripts are just one implementation for mounting the rootfs and switching to it. systemd does it on its own (if part of an initial ram disk for sure). You may have your very own script doing this manually as well.
<smurray>
manuel: perhaps take a look at recipes-core/initrdscripts/initramfs-framework_1.0.bb and the scriptlets it pulls in, that's what's used in the example initramfs images in oe-core
<manuel>
vvn, smurray: cool, will look into that. If I have a systemd system, is this initramfs-framework recipe getting used or whatever systemd comes up with?
<vvn>
manuel: totally up to you. If you want a full systemd stack, you may set INITRAMFS_SCRIPTS = "systemd-initramfs" and INITRAMFS_IMAGE = "core-image-minimal-initramfs" in your local.conf or distro.
<smurray>
vvn: btw, did you happen to get an expired certificate warning from layers.openembedded.org?
<vvn>
smurray: nope
<smurray>
vvn: hrm, okay
Mike23 has quit [Quit: Client closed]
<RP>
zeddii: do you use any systems with make 4.2.1 for testing the kernel builds?
<smurray>
halstead: sort of looks like the SSL cert on layers.oe.org expired about an hour and a half ago
* rfs613
builds kernels with make 4.2.1
<RP>
rfs613: we're seeing hangs occasionally with it :/
ecdhe has joined #yocto
florian has quit [Quit: Ex-Chat]
<rfs613>
RP: hmm, interesting - I've not seen any hang FWIW. I typically do a dozen builds when I am rebasing LTS kernels. And if I am debugging something, I may do many many more (though those are usually incremental)
<zeddii>
RP: all my systems are Make 4.2.1 it appears
<RP>
zeddii: hmm, so how common is this bug :/
<vvn>
having a layer in a meta/ directory won't clash as long as the layer name is unique, right?
<RP>
rfs613: it is rare but does seem to happen on the autobuilder periodically, either in the kernel or perl
<JaMa>
LetoThe2nd: find the corresponding sigdata files and run bitbake-diffsigs on them
<JaMa>
LetoThe2nd: ups, replying to some old message
frieder has quit [Remote host closed the connection]
<RP>
that might help explain things but complicates a fix :/
<rfs613>
there seem to be two potential hangs, SV 51400 and SV 51159
<vvn>
Do not rest your foot on the power cord guys
<rfs613>
vvn: what about the ethernet cord? :P
<rfs613>
khem: has anyone reported issue with the recent CVE fixes for polkit in meta-openebedded?
<rfs613>
i've just figured out that two of them are colliding, which evidently results in the fuzz warning.
<rfs613>
i'll post a fix, just giving a heads up
<smurray>
rfs613: odd, I've been doing test builds locally with meta-oe with that change (d5eef01f, I assume) and I've not seen a fuzz warning
<rfs613>
smurray: this is on dunfell, the two commits are 67ec3e04 and 17e931
<smurray>
rfs613: ah, okay
goliath has joined #yocto
kevinrowland has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<halstead>
smurray: I'll look into it.
<smurray>
halstead: okay, thank you
<halstead>
smurray: I just forced the renewal. How does it look now?
<smurray>
halstead: looks good now, Firefox is happy
<smurray>
halstead: thanks!
<halstead>
smurray: It shouldn't need to be forced. Thank you for the ping. We are moving this into a new system before the next renewal so it won't happen again.
<smurray>
halstead: cool, good to know
huseyinkozan has quit [Quit: Konversation terminated!]
jmiehe has joined #yocto
<LetoThe2nd>
khem: are you aware of any gdk-pixbuf woes on kirkston/master with riscv at the moment?
prabhakarlad has joined #yocto
<LetoThe2nd>
hm.
<LetoThe2nd>
its not even riscv related, but it completely falls over, even for qemux86
mvlad_ has quit [Remote host closed the connection]
jmiehe has quit [Quit: jmiehe]
<vvn>
if you're bsp relies on systemd-cryptsetup to boot an encrypted rootfs, is it ok to have PACKAGECONFIG:append = " cryptsetup" in a systemd_%.bbappend file in both the BSP and distro layers?
<vvn>
s/you're/your/
kevinrowland has quit [Quit: Client closed]
kevinrowland has joined #yocto
prabhakarlad has quit [Quit: Client closed]
amitk_ has quit [Ping timeout: 268 seconds]
mrnuke has quit [Ping timeout: 260 seconds]
mrnuke has joined #yocto
leon-anavi has quit [Remote host closed the connection]
<smurray>
vvn: to me that's a distro thing, ideally the BSP doesn't care if a distro uses sysvinit, systemd, or something else
<vvn>
smurray: true, but I'm writing an initrd service for systemd to create the root subvolume if it doesn't exist (we can't do that via the .wks file). Without it the boot obviously fails. I'm not sure where this recipe belongs :/
<smurray>
vvn: I'd still argue the selection of systemd and using cryptsetup are distro choices. But I realize in practice it can be easier to blend things together, and tbh it's not the end of the world IMO if it's for your own product and unlikely to need that flexibility
<vvn>
smurray: no but you're totally right. The confusing thing is that the bsp in fact *requires* a specific distro crafted for it, i.e. systemd + cryptsetup + musl (if such light libc works). While the rootfs may honor the principle of orthogonal machine/distro/image
<vvn>
smurray: like would it make sense to have poky-initramfs.conf or poky-altcfg-initramfs.conf for instance?
<smurray>
vvn: usually I'd expect the initramfs to not have enough in it that it'd need a full new distro conf
<smurray>
vvn: but I've defined convenience machines and distros for somewhat similar multiconfig stuff for containers, so I could see doing it that way
<vvn>
smurray: a distro conf for it my be handy to remove DISTRO_FEATURES and override some PACKAGECONFIG, otherwise it can be complicated since the distro conf is read after the multiconfig
<vvn>
I mean that DISTRO_FEATURES:remove in the INITRAMFS_MULTICONFIG might not work if the distro is appending features
<smurray>
vvn: yeah, I could see that. I guess I've never encountered an initramfs with enough stuff in it that it mattered
<vvn>
smurray: I'm currently building the initramfs with my normal distro (glibc) and it works fine. With INITRAMFS_MULTICONFIG and forcing the distro in there my bsp will continue to work with any distro/image combination for the rootfs. Such "light" distro variant might just be handy to speed things up a bit, but absolutely not mandatory.
<smurray>
vvn: yeah
<vvn>
I will encounter the same problem actually for containers and portable services, preferring linux-dummy for the kernel...
<smurray>
heh, indeed. I've done both overriding the PREFERRED_PROVIDER in the mulitconfig .conf and just doing it with a derived "container" machine .conf
<vvn>
smurray: do you have a preferred approach?
Minvera has quit [Remote host closed the connection]
<vvn>
So far I think that for the end product, being explicit and defining such alternative distro and machine would help, instead of cluttering some multiconfig or the local.conf
<smurray>
vvn: for AGL I settled on doing it in the container multiconfig(s) with a PREFERRED_PROVIDER overide there because it's so far been easier to support building for a handful of different MACHINEs that way
sakoman has quit [Quit: Leaving.]
<vvn>
indeed, you need to scale easily and not duplicate all distro and machine configs everytime you have a new board variant
<smurray>
vvn: on thing I'll note is that vendor BSPs sometimes have implicit dependencies on their kernel (usually for custom headers for userspace stuff they want to pull in)
<smurray>
err, one
rob_w has quit [Quit: Leaving]
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
codavi has quit [Ping timeout: 246 seconds]
<amahnui[m]>
Hello everyone, Everytime I run `bitbake core-image-sato`, The process gets stuck at 44% `Initialising tasks: 44% |################# | ETA: 0:00:03` and I dont know why it does so. I clone another poky repo and tried again but I ended up with this Please how do I do to make it work.
<vvn>
amahnui[m]: you might try to restart the build from scratch by removing the build/ directory and start again
<amahnui[m]>
vvn: Thanks I will try that out as well
<vvn>
smurray: do you consider the base-files bbappend providing a machine fstab to reside in the distro layer as well, or the bsp?
davidinux has quit [Ping timeout: 246 seconds]
<smurray>
vvn: probably distro, but it could be messy. Some of this comes down to just how likely you are to be actually building the distro for different machines, really
<vvn>
smurray: currently only one hardware but will likely have different platforms in the near future (getting rid of the beaglebone slowly)
<smurray>
vvn: but if I'm given a BSP that forces a specific partition scheme, I'd personally consider it broken unless there's some h/w reason for it. There are vendor BSPs that end up there because they basically are decreeing a partition scheme compatible with booting Android with a bunch of small partitions for bootloader bits
<vvn>
that was the point of using openembedded in fact
<smurray>
some of this can be handled by using machine overrides in the distro layer
<smurray>
or BBFILES_DYNAMIC to add bbappends driven by the presence of BSP layers
<vvn>
hum, crypttab is very machine specific but fstab can be generic (/dev/mapper/foo is used).
<vvn>
smurray: yeah it's always either the bbappend lives in the bsp layer with :foomach overrides or in the distro layer with :foodist:foomach overrides
<smurray>
at the end of the day I'd probably get it working on the one machine, and be prepared to do some rework when you do get around to resuing it on another
<smurray>
err, reusing
<kevinrowland>
can I search IRC archives somehow? I know in the past I've asked about doing something like `devtool deploy-target` but without the whole `devtool` part.. can't find the discussion :|
<smurray>
the log location is mentioned in the channel header
<kevinrowland>
I meant search _programmatically_. grep I guess would've been a better verb
<kevinrowland>
I clicked through to some days where I thought the conversation occurred but couldn't find it
BhsTalel has joined #yocto
<vvn>
kevinrowland: google this: "devtool deploy-target site:https://www.yoctoproject.org/irc/"
<kevinrowland>
oh, yes, of course :) plus my username, I should be able to find it
dev1990 has quit [Quit: Konversation terminated!]
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
<vvn>
smurray: the more it goes, the more I see this as "Does it end up in the final rootfs? If yes, distro layer, otherwise bsp layer".
<BhsTalel>
Hello everyone, sorry if I interrupted a ongoing discussion, but I reached this Yocto IRC to ask about how to contribute to Yocto core (bitbake, poky layers, etc), I already asked the question in the mailing list of Yocto, but I want to understand more the flow. Thanks
<vvn>
BhsTalel: no need to apologize, that's the point of a channel ;-)
<smurray>
vvn: maybe? If e.g. /boot is in the rootfs it may complicate that distinction
<vvn>
smurray: what about files interpreted by both the initramfs and the rootfs, like crypttab and fstab? ;)
* vvn
is becoming crazy
<smurray>
heh, as I said earlier, perhaps get it working, then come back and try adapting it to a second BSP / machine and rework it to clean things up at that point
<smurray>
or wait for someone with a better idea than me to come on the channel ;)
<vvn>
smurray: I am just concluding that true orthogonality between machine/distro/image is just a myth
<vvn>
smurray: I'm pretty much there, I have working layers for my product, just never been really satisfied with the organization.
<smurray>
vvn: I think at the end of the day, one could add a whole bunch of extra configuration to machine .conf's to allow distros to parameterize things, but because so many usecases are different, nothing in that space can be easily hashed out
<smurray>
vvn: so we end up needing to carry that extra metadata at a higher level than the plain BSP
<smurray>
vvn: but there are others who have been doing OE a lot longer than I have that might have a different view of that
xmn has quit [Ping timeout: 248 seconds]
kevinrowland has quit [Quit: Client closed]
<kergoth>
I don’t think it’s a myth, but it is sometimes necessary to have an integration/product layer which pulls the pieces together and doesn’t hold to one of the orthogonal axes. But you can always implement custom features for the features variables, that’s what they’re for, machine enables a feature but the distro has to enable it also to integrate it
<kergoth>
See COMBINED_FEATURES
<kergoth>
That’s what we’ve done at mentor, added “mel-“ prefixed new bsp features in machine_features
<BhsTalel>
@vvn Can you put a brief summary for me, because I did not catch the topic history.
<vvn>
BhsTalel: just discussing the grey area of the yocto design: machine/distro/image are orthogonal, meaning that if you do your job well and still have hair to pull out, you must be able to build any combination of the three.
<kergoth>
It’s common to fuzz the boundaries due to schedule constraints, if not ideal
goliath has quit [Quit: SIGSEGV]
bps2 has joined #yocto
<BhsTalel>
The way I handle the three of them is creating packagegroups that conditionally activate some recipes based on DISTRO_FEATURES that are enabled/disabled in distros which are also conditionally enabled/disabled based on MACHINE_FEATURES, for example, if rs485 machine feature is enabled, then the rs485 distro feature is enabled and finally the
<BhsTalel>
packagegroup-rs485 get enabled in a generic packagegroup that is included in all of my images.
<vvn>
kergoth: for the context, my product is based on meta-ti's beaglebone, where I use a different bootloader, an update framework, and an encrypted rootfs partition which requires a specific systemd service. Ideally I would like to be able to build my distro, or poky, or any distro with this BSPs. I ended up creating a custom machine configuration which requires conf/machine/beaglebone.conf and juggle
<vvn>
with recipes between meta-bsp/recipes-core and meta-distro/recipes-bsp.
<vvn>
You often end up with distro-specific machine and machine-specific distros, in contrary to the ideal generic swappable approach
<amahnui[m]>
<BhsTalel> "Hello everyone, sorry if I..." <- Hi BhsTalel are you an applicant too?
bonalais has joined #yocto
<BhsTalel>
amahnui[m] I did not get the meaning, sorry my english is not that perfect. Did you mean I am a Yocto engineer ?
<vvn>
BhsTalel: for example with an encrypted rootfs, which is a "distro" design, but with a huge impact on the machine (.wks file, initramfs, services, crypttab, key management and so on), do you define custom features?
kevinrowland has joined #yocto
<amahnui[m]>
BhsTalel: No I meant outreachy applicant
<BhsTalel>
vvn I would create new feature that handles all of an encrypted rootfs and depends on a specific wks format, I am not seeing a problem between creating new distro feature and handling a wks file
<BhsTalel>
amahnui[m] I'm not getting your point yet, sorry =(
Starfoxxes has quit [Ping timeout: 252 seconds]
Starfoxxes has joined #yocto
<vvn>
BhsTalel: so let's say you have a luks+btrfs rootfs partition, you would add a custom "luks" and "btrfs" machine feature and respective distro feature, and e.g. enabling a given service in the initramfs image if COMBINED_FEATURES includes "luks" and "btrfs". Same for WKS_FILE = "${@bb.utils.contains('COMBINED_FEATURES', ..., 'encrypted.wks', 'classic.wks'... Something like that?
<amahnui[m]>
<BhsTalel> "amahnui I'm not getting your..." <- BhsTalel: I thought you might be part of outreachy as I am part of it as well but its okay though. I guess your'e not. sorry for bothering