<Austriker>
Hi, I am having trouble setting up X11 client on my headless device. I had it working before by adding X11 to EXTRA_IMAGE_FEATURES += "x11". but this had a side effect. The xserver-nodm kept crashing so it was eating up some ressources. I still have X11 in my DISTRO_FEATURES but when I ssh -XY to the device I get `X11 forwarding request failed on
<Austriker>
channel 0`. What is the correct way to get X11 forwarding working without xserver-nodm for example. I have a an app that requires a GUI for configuration.
rfuentess__ has joined #yocto
rfuentess_ has quit [Ping timeout: 250 seconds]
d0ku has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
smsm has quit [Ping timeout: 256 seconds]
<erbo_>
Austriker: Is X11 forwarding enabled in sshd_config, and xauth installed?
<erbo_>
There's also an option for xauth location in sshd_config that might be worth setting, XAuthLocation
<Austriker>
erbo_ yes X11 forwarding is enabled but xauth is not installed.
<erbo_>
Austriker: I'm by no means an X11 forwarding expert, but I think you need xauth on the server side
rfuentess_ has joined #yocto
<michalkotyla>
Hi everyone. I try to disable serial in debug version of my image recipes. I tried to do this with executing systemctl --root=${IMAGE_ROOTFS} disable serial-getty@.service; but it cause an error: systemctl: error: argument command: invalid choice: 'disable' (choose from 'enable', 'mask', 'preset-all')
<michalkotyla>
Do you have any ideas how to do it in different way? i do not want to mask service, only disable
<Austriker>
erbo_ I am building a new image with xauth and the changes in the settings. I hope this will solve the issue.
rfuentess__ has quit [Ping timeout: 250 seconds]
rfuentess has joined #yocto
rfuentess_ has quit [Ping timeout: 252 seconds]
argonautx has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
florian has joined #yocto
<erbo_>
michalkotyla: I guess it's systemd-serialgetty that adds entries in /etc/systemd/system/getty.target.wants/ for all entries in SERIAL_CONSOLES
Vonter has joined #yocto
<erbo_>
So you could remove those entries manually in a rootfs post process command if you only want it done for a certain image. But maybe a more elegant solution would be bbappend the systemd-serialgetty recipe and split /etc/systemd/system/getty.target.wants/* into a separate package and only install that in images where you want it auto-enabled.
Vonter has quit [Ping timeout: 240 seconds]
<michalkotyla>
maybe, i will try with it - thanks
tnovotny has joined #yocto
lucaceresoli has joined #yocto
Austriker has quit [Quit: Client closed]
Vonter has joined #yocto
rfuentess_ has joined #yocto
rfuentess has quit [Ping timeout: 252 seconds]
Herrie has quit [Ping timeout: 260 seconds]
manuel1985 has joined #yocto
rfuentess__ has joined #yocto
rfuentess_ has quit [Ping timeout: 250 seconds]
Vonter has quit [Ping timeout: 245 seconds]
goliath has joined #yocto
Vonter has joined #yocto
<kanavin>
RP: maybe but I do wonder what are those specific products that can be only supported with directfb
<kanavin>
(and I mean something that's not too old)
rfuentess__ has quit [Remote host closed the connection]
rob_w has quit [Remote host closed the connection]
<rburton>
dunfell kernel build failing with ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x10): multiple definition of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x38): first defined here
<rburton>
spider-sense kicking off but i can't remember the fix
<rburton>
zeddiii: can you backport e33a814e772cdc36436c8c188d8c42d019fda639 to the
<rburton>
yeah just found it
<rburton>
zeddiii: can you backport e33a814e772cdc36436c8c188d8c42d019fda639 to the 5.3 kernel in dunfell
<rburton>
oh hang on that's our recipe
<rburton>
so why did it break overnight
<rburton>
aaah new host
<rburton>
mystery over
Vonter has quit [Ping timeout: 252 seconds]
<rburton>
zeddiii: stand down, my fault :)
<qschulz>
rburton: also.. 5.3 :p ?
<rburton>
yeah, don't ask
<rburton>
i spent a week writing a tool to turn a layer into a report for project managers which has bright red annotations for non-upstreamed patches and old releases :)
<qschulz>
rburton: hehe
<qschulz>
switching to 5.4 shouldn't be that big of a task though
<rburton>
correct
<coldspark29[m]>
Is there a way to just generate a toolchain for C? `bitbake -c populate-sdk image` builds everything and I don't need that
<coldspark29[m]>
Would it maybe just build the toolchain for the kernel if I put `bitbake -c populate-sdk linux-imx`?
<rburton>
bitbake meta-toolchain builds just the compilers and a few tools
<coldspark29[m]>
rburton: Looks pretty similar to me though
<RP>
JPEW: The more I look at this reproducibility issue, the more worried I get :(
<rburton>
coldspark29[m]: copy the meta-toolchain recipe and remove stuff you don't need then
<coldspark29[m]>
It inherits populate_sdk :D
<rburton>
thats because the sdk code is common
<rburton>
meta-toolchain is the compiler, binutils, and a few tools.
<coldspark29[m]>
Hmm
<coldspark29[m]>
I will leave it now
<coldspark29[m]>
Hoping it finishes building soon
<coldspark29[m]>
Thanks anyway
<kanavin>
oops
<kanavin>
I just clicked stop on something I shouldn't have
<RP>
kanavin: highlighting the issue so we can debug it would be better :/
<svuorela>
hmm.. looks like my environment setup file for my sdk has gotten -O2 -D_FORTIFY_SOURCE=2 in the CC/CPP/CXX environment variables - given that I during usage of my sdk sometimes want a -O0 build, this is obviously not what I want. What should I look for to find the cause ?
<RP>
In the problem reproducible build, do_package and do_package_write_deb came from sstate, write_ipk and write_rpm did not. The trouble is the binaries in do_package don't match the binaries in do_package_write_deb :(
rfuentess has joined #yocto
davidinux has quit [Quit: WeeChat 2.8]
<svuorela>
hmm. even more. a 3rd of my custom recipes contains TARGET_CC_ARCH += "${LDFLAGS}"
<svuorela>
- is that right ?
<rburton>
that's basically working around the makefiles or whatever not respecting LDFLAGS
<svuorela>
ok. I wonder if that leaks stuff into my environment setup file ?
Vonter has joined #yocto
ardo has quit [Read error: Connection reset by peer]
<Saur>
RP: I started digging a small hole yesterday (to remove \n from mirror variables throughout poky, as I discussed with Michael on the lists), and I ended up with something the size of Grand Canyon. I hope you can help me and maybe throw me rope to get me out of here while saving some of the artefacts that I dug up...
GillesM has joined #yocto
<RP>
Saur: I can try and help!
<RP>
zeddiii: I hate to say this but the reproducibility issues are looking like they're triggered by kernel headers :(
ardo has joined #yocto
<RP>
zeddiii: and the commit which "triggers" this is from abelloni :)
<Saur>
RP: Well, the \n changes were trivial enough, no problems there. However, since one of the changed files was fetcher.py, I made the mistake of thinking I should run bitbake-selftest. Turns I apparently haven't done that before (shame on me), which lead to that I first had to fix so that I can run it (we have global Git hooks that interfere with bitbake-selftest setting user.name to a dummy value.
<RP>
What happens is that the above commit changes the line numbers for the pending and enabled variable declarations in the uapi rtc.h header. rtcwake.c in util linux embeds that info into the debug symbols in rtcwake. For some reason hashequiv isn't tracking this correctly
<Saur>
That too wasn't too hard to fix. Then when I ran it, I first enabled BB_SKIP_NETTESTS since I'm behind a firewall, and realized that's probably something you don't do as it failed the crate tests. Easily fixed.
kroon has joined #yocto
<RP>
Saur: I likely missed adding the skip network test on the crate tests when I added them. yes
<Saur>
Then I managed to configure the proxy settings so I could actually run all the tests. All looked great until it failed two npm tests related to premirror and that is when chaos started.
<RP>
Saur: the npm tests probably aren't being run anywhere at the moment :(
<Saur>
Exactly, I kind of figured that out after having dug into for quite a while.
<RP>
Saur: sorry, they're on my "need to do something about it" list :(
<RP>
along with many many other things :(
<Saur>
The problem now is that I though I should fix them, but I am not really sure what the correct thing to do is, or what is the expected behaviour from the npm fetcher...
<moto_timo[m]>
That list never seems to get shorter does it
<RP>
Saur: we could never enable them on the autobuilder since they need npm from meta-oe. The plan was to figure out how to add that but somehow they bitrotted along the way
<RP>
I don't really know the node stuff well enough to know what the right fix is
<Saur>
Looking at the npm fetcher it uses the downloadfilename= parameter do specify the name of the npm packages it downloads. If you don't specify it yourself it will put the downloaded files in an "npm2" directory. However, if you actually do specify downloadfilename= to npm://, it will not do this and rather put them exactly as the downloadfilename= parameter specifies. This causes confusion if one takes the download directory and attempts t
<Saur>
o use it as a premirror as some npms are in npm2 and others are in the root.
<RP>
JPEW: the question now is how does a kernel header change defeat the hashequivalence mechanism for package_write_deb on util-linux :/
<RP>
Saur: I'd say it should use npm2 in all cases
<Saur>
To me it makes much more sense to always put all downloaded npms in the npm2 directory, which is a trivial change. However, I do not know if there are any consequences of that which I do not realize...
<RP>
Saur: You'd hope that would just cause a few extra downloads for some users?
<Saur>
More like if people have expectations of where the files end up when doing things such as taking the downloaded files a nd creating mirrors or so...
<Saur>
But maybe there aren't that many users of the npm fetcher that that is a problem...
<RP>
Saur: copying DL_DIR would still work and yes, I doubt there are that many users so I think we should fix it
<RP>
Would be interesting to see if anyone does notice
<Saur>
I guess I'll just propose the change to the list and see if anyone objects.
<RP>
Saur: gets my vote FWIW :)
<RP>
Would be nice to have those tests fixed!
<Saur>
I have a fix for the first test so far.
<Saur>
As for the second test, which I don't really understand what it's trying to test, it gets harder. And that's not really due to the npm part, but the fact that it sets a premirror like https?$://.*/.* file:///tmp/bitbake-fetch-s5wcbmf1/mirror/npm2/savoirfairelinux-node-server-example-1.0.0.tgz
<Saur>
The problem is that after uri_replace() has had its go at it, the resulting URI ends up as /tmp/bitbake-fetch-s5wcbmf1/mirror/npm2/savoirfairelinux-savoirfairelinux-node-server-example-1.0.0.tgz, which it obviously will not find sine the URL should actually be /tmp/bitbake-fetch-s5wcbmf1/mirror/npm2/savoirfairelinux-node-server-example-1.0.0.tgz
kroon has quit [Quit: Leaving]
<Saur>
I believe this is a result of commit 96c30007dc0b32eee2b15771daec7948bc9bfd97 in the bitbake repository.
<Saur>
More specifically the call to result_decoded[loc] = result_decoded[loc].replace(uri_basename, basename)
<Saur>
Where, for the npm case uri_basename is node-server-example-1.0.0.tgz and basename is savoirfairelinux-node-server-example-1.0.0.tgz
<Saur>
I don't really see the point of the test in itself, but it did find this problem, which I believe is real.
sakoman has joined #yocto
<RP>
Saur: I don't really see what that test is meant to be doing either :/
<RP>
Saur: I was wondering if we need to go back to when these were added and see if we can bisect down which fetcher change broke them. Not sure if that is worth it and would tell us anything or not
<RP>
It is what I was originally thinking of doing to track down the issues
prabhakarlad has joined #yocto
<Saur>
The first change is 8a3ff9f3eaf19d4258eb070c5dc230dface269b2 which tried to solve the problem where downloadfilename= is used together with a premirror. The tests were modified/added in 61db3e96530d650e098436fd086f0182d32998f7 and 5ba191a0407af9e652e3b86302dce3e952d6b587. Then the second try to fix it is in commit 96c30007dc0b32eee2b15771daec7948bc9bfd97, and that is when the tests got broken.
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<JPEW>
RP: Do you have the depsig files by chance?
<zeddiii>
RP: interesting ... so the fix will have to be in hashequiv ? or did you want me to poke at the headers or are we into another sorting utility ?
florian_kc has joined #yocto
fevi has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 256 seconds]
florian_kc has joined #yocto
fitzsim has joined #yocto
Vonter has quit [Ping timeout: 250 seconds]
davidinux has joined #yocto
smsm has joined #yocto
florian_kc has quit [Ping timeout: 256 seconds]
GillesM has quit [Quit: Leaving]
smsm has quit [Ping timeout: 256 seconds]
smsm has joined #yocto
Vonter has joined #yocto
Dracos-Carazza_ is now known as Dracos-Carazza
<RP>
zeddiii: its a hashequiv issue, the kernel headers are just a trigger :/
<RP>
JPEW: I do not have all of what we need, no :/
coldspark29 has quit [Ping timeout: 268 seconds]
<JPEW>
RP: Fair enough. So the theory is that the kernel header line numbers are getting encoded in the debug data?
<JPEW>
... and somehow that changed between 2 runs of the reproducible build test?
Minvera has joined #yocto
<JPEW>
Or, the first build came from sstate, and hashequiv somehow "missed" that the output change and marked them as equivalent?
smsm has quit [Quit: Client closed]
<RP>
JPEW: The build that came from sstate had a do_package_setscene built with the new headers but a do_package_write_deb_setscene that was built with the old ones (or vice versa)
<RP>
For reasons unknown, ipk/rpm rebuild and didn't come from sstate and packaged the do_package data which then didn't match the deb
<JPEW>
rpm and ipk didn't pull from sstate at all?
<JPEW>
(presumably, that's why the A build took so long?)
<RP>
JPEW: they rebuilt the rpm and ipk step from do_package
<RP>
JPEW: I don't know why :/
<Saur>
RP: After reading through https://bugzilla.yoctoproject.org/show_bug.cgi?id=13039, I now think I know what the problem with downloadfilename= and premirror is. Scotts expectation is that if you have a SRC_URI that asks for foo.tgz and downloads it as bar.tgz, it should still ask for foo.tgz when searching the premirror. And this is sane if you set the premirror to some external source which carries the same files as the origin server in t
<Saur>
he URI. However, if you instead expect to use whatever you have downloaded in one build to serve as your local premirror for another build, then you expect bitbake to look for bar.tgz in the premirror as that is the name it will have when it lands in ${DL_DIR}.
<RP>
Saur: ah, yes. We would expect to be able to reuse a download as a premirror :/
<Saur>
RP: Both uses cases seem to valid. So the question then becomes, should bitbake look for both the downloadfilename and the original file when trying to locate a file?
Vonter has quit [Ping timeout: 252 seconds]
<RP>
Saur: hmm, I can see both cases :/
ar__ has joined #yocto
Vonter has joined #yocto
codavi has joined #yocto
manuel1985 has quit [Ping timeout: 252 seconds]
ar__ has quit [Ping timeout: 256 seconds]
leon-anavi has quit [Quit: Leaving]
<vd>
Can two distro using the same libc can share TMPDIR, or is it better to split them with e.g. TCLIBCAPPEND = "-${DISTRO}"?
<rburton>
khem: meta-oe is still broken with folks depending on mockdbus-native
dev1990 has quit [Quit: Konversation terminated!]
<Saur>
RP: Is it possible to enable the logger messages that are produced while running bitbake-selftest some way? Currently I am adding print() statements as I go along to get it to output what is happening...
<smurray>
vd: I believe sharing would be fine, though you'd likely need to be copying the deployed artifacts you need out after building each one if there's any overlap
<RP>
Saur: Offhand I don't remember how, I usually end up doing that too :(
<Saur>
Ok.
<vd>
smurray: true, because the deploy paths (e.g. DEPLOY_DIR_IMAGE) do not include ${DISTRO} by default
<vd>
smurray: so DEPLOY_DIR:append = "/${BB_CURRENT_MC}" should be just enough in fact, keeping TMPDIR and TCLIBCAPPEND to their defaults
<smurray>
vd: if you're using multiconfig and potentially building both at the same time it's perhaps better to fully split them with e.g. TMPDIR = "${TOPDIR}/tmp-${BB_CURRENT_MC}"
<smurray>
vd: but it kind of depends on what's different in the distro configs. I'm not sure significantly different distro configs that result in a bunch of package differences will play nicely wrt trying to build both rootfs-es at the same time if TMPDIR is shared
Epictek[m] has quit [Quit: You have been kicked for being idle]
mckoan is now known as mckoan|away
<vd>
smurray: you're right. I just want to stick with a default and safe conf that I forget about. I'm adding a site.conf with DEPLOY_DIR:append = "/${BB_CURRENT_MC}", TMPDIR:append = "-${BB_CURRENT_MC}", TCLIBCAPPEND = "".
<smurray>
vd: if you change TMPDIR you shouldn't need to also tweak DEPLOYDIR unless you've changed it to point outside of TMPDIR with some other tweak
<vd>
smurray: correct, on my server I set DEPLOY_DIR = "/srv/http" for development
<smurray>
vd: also note that for the main bitbake BB_CURRENT_MC = "default". In my AGL setup I tweak TMPDIR in the multiconfig .conf's to have tmp, tmp-conf1, tmp-conf1. But that's more of a style thing
<smurray>
err, tmp, tmp-conf1, tmp-conf2
<smurray>
need to go make a coffee ;)
<RP>
vd: it all depends whether your distro configs match or not. If they don't, using the same TMPDIR for them in a multiconfig will not work
<vd>
RP: even if they do match, the cost of splitting them is just that a few files will be copied over, right? (like removing TMPDIR and starting a build again)
d0ku has quit [Ping timeout: 256 seconds]
<RP>
vd: yes
<smurray>
heh, in the one AGL demo build they decided they want Qt configured differently in 2 different multiconfigs, it's slow enough to build that that outweighs everything else ;)
<vd>
RP: how do you feel about a patch adding something like this to bitbake.conf: MCAPPEND ?= "${@'/' + d.getVar('BB_CURRENT_MC') if d.getVar('BB_CURRENT_MC') != 'default' else ''}" DEPLOY_DIR .= "${MCAPPEND}" TMPDIR .= "${MCAPPEND}"; to provide users a safe environment by default that they can tweak if their multiconfigs match, or do you prefer to keep it as it is today?
<LetoThe2nd>
whom should I poke for wiki access? RP ndec michaelo
<qschulz>
halstead: maybe too I think
<qschulz>
^
<LetoThe2nd>
qschulz: ya right
<LetoThe2nd>
i tell ya folks, its only a couple of day until i'm finally back to annoy you all!
<qschulz>
LetoThe2nd: :muscle:
<RP>
LetoThe2nd: halstead
<qschulz>
well, emoji fail
<vd>
smurray: I feel the pain, qtwebengine actually convinced me to buy an AMD 5950X / 64Go RAM build machine...
<RP>
vd: I don't think we want to hardcoded multiconfig layouts like that into oe-core
<vd>
RP: I see. It's better to let one define this in their local/site/auto/mc configs I understand
<LetoThe2nd>
its really a strange feeling to wrap up 14 respectively 16 years at a company, with a full month of PTO.
<smurray>
vd: I've got a Threadripper so it's somewhat manageable on the CPU front, atm memory is the issue, 64GB actually isn't enough for that config w/o cutting parallelism down a bunch. I've got another 64GB sitting here that arrived from Newegg this week to put in ;)
<vd>
smurray: while compiling qtbase/qtwebengine, htop goes to maximum 50Go RAM usage for me. Am I lucky?
<smurray>
vd: it's building 2 copies of qtbase and qtdeclarative, etc. at the same time (one for each multiconfig) that blows up for me here. 64GB + 40GB swap wasn't enough
<RP>
JPEW: I think I see how this breaks. gcc-cross depends on linux-libc-headers and then all the target recipes depend on gcc-cross. The output of gcc-cross might not change when linux-libc-headers changes
<RP>
LetoThe2nd: I know what you mean, I felt odd leaving Intel
<vd>
smurray: ha true you have to qt builds in parallel. At first I saw multiconfig as a nice way to split my build variants (customer branding etc.), but I learnt the hard way to keep as much as possible in a multiconfig and only use different ones for actual architecture variants.
<LetoThe2nd>
RP: yeah. and so many little things involved and surfacing now.
<smurray>
vd: my original setup for this one AGL build had one mc for all the containers, but folks decided they want different configurations for each ¯\_(ツ)_/¯
<vd>
smurray: I'm not in your shoes but I would definitely work hard towards convincing them to go back to a common qt config...
<smurray>
vd: the people involved have said their next step is significantly different distro configs, so I've decided it's somewhat futile to push back
<smurray>
vd: I assume they have better build hardware than I do ;)
<vd>
smurray: if that ends up being two different distro, it actually makes sense yeah. The trap with multiconfigs is wishing to use them to split a common environment, that is definitely bad
<smurray>
vd: it's somewhat debatable in this instance IMO, but I'll not bore you ;)
<vd>
smurray: ha ha no worries, it's friday (whatever that means)
GillesM has joined #yocto
GillesPP has joined #yocto
<Saur>
RP: Argh, I knew it wouldn't be as simple as just look for both the original name and the downloadfilename. My idea was to look for downloadfilename first as that is typically what would be in a local mirror, and then for the original name. However, what if someone specifies a URL like http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.1.tar.gz;downloadfilename=bitbake-1.0.tar.gz, i.e., where both files exists. In this case it i
<Saur>
s probably more expected that the original file is found first... I just can't win, can I?
<khem>
rburton: the needed patch is staged in oe-core master-next
<rburton>
i still maintain that needing dbus-mock-native is a bug in the build
<rburton>
the check is wrong, it needs *target* dbus-mock
rfuentess has quit [Remote host closed the connection]
tnovotny has quit [Quit: Leaving]
<khem>
rburton: you need to prove it, I dont claim to be expert
<vd>
what is the preferred way to add a bootloader as a dependency for a WIC image? EXTRA_IMAGEDEPENDS += "virtual/bootloader", WKS_FILE_DEPENDS_BOOTLOADERS:${MACHINE} = "virtual/bootloader", do_image_wic[depends] += "virtual/bootloader:do_deploy"? The latter is quite intrusive
<khem>
jonmason: yt ?
prabhakarlad has quit [Quit: Client closed]
<RP>
rburton: I thought that but didn't get to investigate
<RP>
Saur: that is rather problematic, yes :(
<Saur>
RP: I actually don't think the problem is solvable without making the two uses cases explicit, by either adding more URI parameters or, e.g., making a distinction between premirrors and mirrors, where premirrors would look for downloadfilename while mirrors would look for the original name. Either way would most likely break someone's use cases...
<RP>
Saur: we probably need to document this parameter behaving in a particular way I guess
<JPEW>
Ah, do cross recipes need the same thing we did to native>
<JPEW>
Ah, do cross recipes need the same thing we did to native?
<JPEW>
erg, can't edit lines in IRC :)
<RP>
JPEW: probably but in this case we have a target dependency on the libc headers as those are target, not cross
<RP>
and cross shouldn't hard depend on target
<RP>
JPEW: this effectively applies to any indirect dependency in the sysroot :/
<RP>
JPEW: recipe A installs header X, recipe B depends on A but doesn't use X, recipe C depends on recipe B, uses header X. Hash from A never makes it to C
whuang0389 has joined #yocto
Tokamak has joined #yocto
Schlumpf has quit [Quit: Konversation terminated!]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 256 seconds]
neverpan1c is now known as neverpanic
prabhakarlad has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
Vonter has quit [Ping timeout: 256 seconds]
amitk has quit [Ping timeout: 256 seconds]
whuang0389 has quit [Quit: Client closed]
<JPEW>
RP: Hmm.... I'm not sure what we can do about that
<JPEW>
RP: Other than C should DEPEND On A
mvlad has quit [Quit: Leaving]
tlwoerner_ has joined #yocto
Herrie has joined #yocto
tangofoxtrot has quit [Remote host closed the connection]
bantu has quit [Ping timeout: 256 seconds]
tlwoerner has quit [Ping timeout: 256 seconds]
zkrx has quit [Ping timeout: 256 seconds]
rfried has quit [Ping timeout: 256 seconds]
bantu has joined #yocto
rfried has joined #yocto
zkrx has joined #yocto
tangofoxtrot has joined #yocto
argonautx has quit [Quit: Leaving]
florian_kc has joined #yocto
manuel1985 has joined #yocto
coldspark29 has joined #yocto
lucaceresoli has quit [Ping timeout: 250 seconds]
florian_kc has quit [Ping timeout: 240 seconds]
alejandrohs has quit [Quit: WeeChat 3.3]
lucaceresoli has joined #yocto
GillesM has quit [Quit: Leaving]
GillesPP has quit [Quit: Leaving]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<vd>
if you want to version your site.conf and auto.conf to share them between co-workers, do you ususally version build/conf/ or do you create a layer to store them?
sakoman has quit [Quit: Leaving.]
<vd>
smurray: actually regarding this ^ how do you version/share your multiconfigs if I may ask?
<smurray>
vd: in AGL they're checked into the conf/multiconfig directory in the associated layer
kernelspace is now known as ad__
florian_kc has joined #yocto
<vd>
smurray: yep ok so the best is to put that in a layer. Public or a custom one, if private. Thank you!
<vd>
I often thought about one having a "build" layer for each project, it kinda makes sense.
<smurray>
vd: in AGL there are specific images and some recipes associated with the multiconfig setup, so it's all been placed its own layer
<vd>
it's definitely cleaner for storing customer specifics recipes, multiconfigs, common site configs, etc. for sure
<smurray>
vd: with something like kas, you could potentially rely on the conf's being generated from the yaml config file, and just track changes by checking it in somewhere
<vd>
smurray: yeah I'm using kas, mainly for fetching/patching the repos, but I'm not a fan of tools which abstract too much other tools like bitbake
<smurray>
vd: yeah, it can potentially be fun to debug when things break
<vd>
kas kinda incites you to store your config in yaml fragments, while you could have a pure bitbake config with multiconfig/site/auto etc., which I prefer
<smurray>
kas or something like the scripting that AGL does to generate bblayers.conf/local.conf kicks in when you have an array of users who want to build with different BSPs or other options
<vd>
smurray: I'm moving towards having only "repos:" stated in the kas yaml config, and use a script to wrap './kas-container shell project.yml -c "bitbake $@"'
<smurray>
it can be hard to juggle making that work in one massive build configuration
<vd>
smurray: totally agree. Especially when you need that patch in meta-openembedded, this patch in oe-core, etc. Kas is wonderful for that. I just wish it was less intrusive and could simply be scoped to only generating the bblayers.conf for the yaml file.
<vd>
Actually I started the conversation with kergoth to implement layer fetching via bitbake recipes, since it already provides a fetcher, dependency management, preferred version, etc. But it didn't go anywhere
<vd>
I'm wondering if that can be an option.
<smurray>
it gets discussed now and again. IMO it's sort of a hard problem because different people want different things, scoping "good enough" isn't easy
<Saur>
Well, you have a bit of chicken and egg problem if you want to use bitbake to fetch the layers, as you need bitbake and the layer that defines the other layers before you can have it fetch the others...
<vd>
smurray: via SRC_URI you can fetch a layer from anywhere really, and DEPENDS could be used as well. It's sad to see this mechanism not used for the layer themselves :)
<smurray>
vd: as Saur says, there's some chicken and egg issues
<vd>
Saur: true. Maybe the only assumption is that 'bitbake' is in $PATH. All you'd need would be a 'bitbake' Docker image for example, if you don't have bitbake locally.
<Saur>
Well you also need to be able to tell it what to fetch, which would be a layer in itself because that is what bitbake knows about, which means you need some way to get that layer...
<vd>
Saur: similarly to how bitbake currently assumes paths for bitbake.conf and bblayers.conf, it can assume a fixed path where to find layer recipes
Minvera has quit [Quit: Leaving]
<abelloni>
RP: what did I break ? :)
<abelloni>
RP: you don't like new ioctls ? ;)
<abelloni>
RP: actually, I'm serious, I don't see how I would have done otherwise