jwillikers has quit [Remote host closed the connection]
tp43_ has quit [Ping timeout: 252 seconds]
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 244 seconds]
goliath has quit [Quit: SIGSEGV]
sakoman has quit [Quit: Leaving.]
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
sakoman has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
amitk has joined #yocto
cocoJoe has joined #yocto
paulg has quit [Ping timeout: 252 seconds]
sakoman has quit [Quit: Leaving.]
pgowda has joined #yocto
pgowda98 has joined #yocto
pgowda98 has quit [Client Quit]
pgowda6 has joined #yocto
xmn has quit [Quit: ZZZzzz…]
pgowda has quit [Quit: Client closed]
pgowda6 has quit [Client Quit]
pgowda has joined #yocto
m4ho has quit [Quit: WeeChat 3.1]
m4ho has joined #yocto
Guest28 has joined #yocto
frieder has joined #yocto
<Guest28>
what transport formats are supported on PACKAGE_FEED_URIS? http seems ok, but what about tftp/ftp etc.
Vinay75 has joined #yocto
<JosefHolzmayr[m]>
yo dudX
<mihai>
yo
<Vinay75>
hi
pgowda has quit [Ping timeout: 256 seconds]
<RP>
vd: that should work
<JosefHolzmayr[m]>
RP: i just skimmed over the last night re sbom patches and discussion, but failed to grasp the bottom line. so where are we now with that topic?
mckoan|away is now known as mckoan
<mckoan>
good morning
<JosefHolzmayr[m]>
yo mckoan
<RP>
JosefHolzmayr[m]: we have a patchset of two halves. One cleans up a load of "BSD" license references and one adds some do_package backend functionality and adds spdx manifest generation
ecdhe has quit [Read error: Connection reset by peer]
<RP>
It still needs work but I think we can merge as something to work against for this release
ecdhe has joined #yocto
camus has quit [Ping timeout: 252 seconds]
<JosefHolzmayr[m]>
RP: wow. feels like we're heading to a release with lots of new exciting stuff this time.
camus has joined #yocto
<RP>
JosefHolzmayr[m]: We're "behind" schedule for the release, but yes, I think this is worth getting in
<RP>
JosefHolzmayr[m]: some of the features are starts of things rather than the final completed one. There will be a lot more change from a license perspective in the future I suspect
<JosefHolzmayr[m]>
RP: does it make you feel better if i confirm that this is a good plan? with kirkwood being slated as LTS, getting in the crazy stuff now and polishing the next one is a nice perspective - and actually exactly what the ubuntu folks usually do. the uneven.10 releases get the experimental tech, and then they stabilize and polish for even.04 LTS.
leon-anavi has joined #yocto
<RP>
JosefHolzmayr[m]: We have been trying for this. I just worry there are a few more invasive things that will be needed in kirkstone
<JosefHolzmayr[m]>
ah, kirkstone, not kirkwood. my bad.
prabhakarlad has joined #yocto
pgowda has joined #yocto
<JosefHolzmayr[m]>
oh, one more thing. i've seen the baremetal-image.bbclass enforces TCLIBC = "baremetal" | "newlib". any specific rationale behind that?
<JosefHolzmayr[m]>
respecively, what does this class set off in forms of dirty magic that i probably failed to spot?
bps has joined #yocto
bps has joined #yocto
manuel1985 has joined #yocto
tnovotny has joined #yocto
<mihai>
the sbom patches feel a bit hacky
tnovotny_ has joined #yocto
tnovotny has quit [Read error: Connection reset by peer]
tnovotny_ has quit [Client Quit]
tnovotny has joined #yocto
<mihai>
JosefHolzmayr[m]: what's on for twitch these days?
<JosefHolzmayr[m]>
mihai: i'll do a baremetal hello world this afternoon (e.g. 6hrs from now)
<mihai>
JosefHolzmayr[m]: oh, great, seems like my question was spot on :))
<JosefHolzmayr[m]>
mihai: well how comes you don't already know? its been on twitter, on linkedin...
<JosefHolzmayr[m]>
mihai: i even provided calendar linkd!
* mihai
slowly gets under the desk
<tnovotny>
Hi, is there a preferred way to name recipe for out-of-tree modules? Docs & skeleton in Poky name it hello-mod, the same docs renames it to mymodule and Freescale layers uses kernel-module-foo.
<user123>
I am getting Pseudo_Abort erro when i tried to build Yocto multimedia image with multilib support
<user123>
Any help available on this
<mihai>
tnovotny: you can name it whatever you want, hello-mod is a good example, you can also do hello-module module-hello, whatever
<user123>
Its for I.MX8MM board
<JosefHolzmayr[m]>
user123: can you nail it down to the specific combination, on clean builds?
<mihai>
tnovotny: what actually happens is that by inheriting the module bbclass you'll get two packages, kernel-module-hello which has the actual module in it, and hello-mod which is a meta package pulling in kernel-module-hello
<tnovotny>
mihai: yes, I know that the name doesn't play a big role. I just wanted to align my recipe with the others. And thanks for the further explanation.
<mihai>
tnovotny: yw
<mihai>
tnovotny: also be careful there not to clash with existing module names, e.g. in case you're getting out an in-tree and want to build it out-of-tree
<user123>
JosefHolzmayr: specific combination ?
<JosefHolzmayr[m]>
user123: does the build work under those conditions (all started clean!) 1) without meta-multimedia / without multilib. 2) with meta-multimedia / without multilib 3) without meta-multimedia / with multilib 4) with meta-multimedia / with multilib?
<mihai>
tnovotny: anyway, sorry, back to your question, there's no preferred naming scheme there :)
<JosefHolzmayr[m]>
user123: its not impossible of course, but usually pseudo aborts are caused by problems with sstate/temp, and hardly by layers/recipes/configurations.
<user123>
Yes
<user123>
It works fine without multilib support
<tnovotny>
mihai: ok, thanks
ad__ has quit [Quit: ZNC 1.7.2+deb3~bpo9+1 - https://znc.in]
ad__ has joined #yocto
<JosefHolzmayr[m]>
user123: 1) have you verified that for a really clean build? (no sstate, no tmp) 2) does it fail in a specific class or recipe?
florian has joined #yocto
eFfeM has joined #yocto
<user123>
JosefHolzmayr[m]: yes its clean build. No it does not fail in a specific class or recipe
<JosefHolzmayr[m]>
user123: does the pseudo abort give some form of log/trace?
<user123>
Yes
<user123>
i will share the flag
<user123>
sorry log
<JosefHolzmayr[m]>
user123: can you put it in a pastebin?
<JosefHolzmayr[m]>
user123: the insteresting one would rather be /home/user/imx-yocto-bsp/build/tmp/work/cortexa53-crypto-poky-linux/tk/8.6.10-r0/pseudo//pseudo.log
<JosefHolzmayr[m]>
user123: and, which release is this?
<user123>
i.MX Linux Yocto Project BSP 5.10.35_2.0.0 Release
<JosefHolzmayr[m]>
user123: no idea what real release that does correspond to, please look it up/find uot.
<user123>
JosefHolzmayr: Even i tried bitbake -c cleanall imx-image-multimedia
<user123>
Still same error i am getting
<RP>
kanavin: cool, thanks. Hopefully that one shouldn't be too hard
<kanavin>
RP: just need to check that ptests don't fail too badly
<kanavin>
(they've been selectively disabled for a long time, and we still can't get it under control I think)
<JosefHolzmayr[m]>
user123: like i said - we need the pseudo.log and the release in question.
<user123>
Release is of yocto kernel or BSP?
<JosefHolzmayr[m]>
user123: *sigh* the yocto release. it is even printed right at each bitbake invocation, usually.
<RP>
kanavin: upstream are very willing to work on that - they're trying to look into the intermittent issues
<user123>
5.10.35-2.0 yocto release
<kanavin>
RP: I might then drop the selective disabling patch, and then point them to the fails?
<RP>
kanavin: yes, a summary of where we're at would probably be good at this point
<JosefHolzmayr[m]>
user123: that is no yocto release.
<kanavin>
RP: right, once I have the link to AB logs, we can point upstream to that
<user123>
some layer are hardknott branch are some are zeus gatesgarth, iam attaching the log in pasteboard https://pastebin.com/8b3WwQ4W
<RP>
wCPO: hmm. I am an admin there so that may make a difference :/
<user123>
RP: So, you want us to change that in all the layers?
<RP>
user123: I don't think you mean me?
BCMM has joined #yocto
<qschulz>
user123: yes
<user123>
qschulz : We will try that
<barath>
does anyone know how I can run dumpsig on a task for which there is no sigdata/siginfo file generated?
<barath>
specifically I see that between two hosts, the dbus's do_populate_sysroot hashes have changed because the do_install hashes are different on the two hosts, but those tasks don't have siginfo/sigdata files
<barath>
I've tried dumping the vars for that task on one host, but there's a lot there, and I dont think it's all used to generated the hashes?
<qschulz>
barath: they should unless you have removed the tmpdir and reuse the local sstate-cache
<barath>
it's possible it's simply reusing the sstate cache, yeah
<barath>
I guess then the next step would be clearing the sstate cache for dbus and forcing a rerun of that specific task
<qschulz>
you can force the re-run by using -c do_install -f for dbus
<qschulz>
but in any case, you'll need to rebuild from scratch dbus to make it not tainted anymore
<qschulz>
but for quick debugging that *should* be fine
<barath>
alright I'll try that
<barath>
weird, now after using -f I definitely have a sstate-cache file for the install task for dbus, althrough dumpsig still says it can't find any
<barath>
(when using bitbake-dump -t dbus install)
<qschulz>
I most often give the path to the sig file directly
xmn has joined #yocto
rfuentess has joined #yocto
<user123>
qschulz : after changing all zeus gatesgarth branch to hardknott branch bitbake is not running,its throwing "Timeout while waiting for a reply from the bitbake server (60s)"
<barath>
user123: sounds like you've got a stuck bitbake process
<barath>
I'd confirm by running ps aux|grep bitbake
<barath>
then you can kill it if you want
<qschulz>
if you still have a bitbake.lock, you can run lsof bitbake.lock and kill whatever process is using it, then remove the lock
* RP
quietly curses to himself that the rust issue on centos7 still isn't fixed
<user123>
qschulz : even after changing all zeus gatesgarth branch to hardknott branch we getting same error
Net147_ has quit [Read error: Connection reset by peer]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
zyga-mbp has joined #yocto
<qschulz>
you need to remove the tmpdir too probably and start fromt here
tepperson has joined #yocto
Net147 has quit [Read error: Connection reset by peer]
<user123>
you mean to say, remove /build/tmp directory ?
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
<qschulz>
anything that is not sstate-cache (though it won't be matched so it's safe to remove too; SSTATE_DIR) and downloads (DLDIR) can be removed safely
bps has quit [Ping timeout: 252 seconds]
<qschulz>
user123: also just so you know, hardknott is EOL in November
<qschulz>
hopefully NXP starts using LTS releases but nothing less sure than that :)
<dvorkindmitry>
is it possible to create two WICs with 1 image recipe?
<tepperson>
if i wanted to change the work path of recipes from tmp/<machine name>/<recipe name> to tmp/<machine name>/<related_recipe_name>/<recipe name>, would i be looking at base.bbclass or somewhere else?
<qschulz>
dvorkindmitry: probably not as is, but you could work on image_types_wic to add support to that
<qschulz>
although not sure what the goal for you is with that?
Net147 has quit [Ping timeout: 252 seconds]
<tepperson>
related recipe name - would be the name of an image. say i want image "uimga" to have a different kernel config than "uimgb" - without repeating all of the machine specific customizations
<rburton>
so that's not how it works
<rburton>
i can build a kernel without an image
<rburton>
if you want two different kernels, build two different kernels
<dvorkindmitry>
qschulz, I have two boards with almost same set of peripherial and same CPUs. same MACHINE. want to have 1 image recipe for both. everything is almost the same, except two different DTS files. Want to create two WICs with the same recipe and the same time for both
vics has joined #yocto
<JPEW>
mihai: can you elaborate on why the sbom patches feel hacky?
<qschulz>
dvorkindmitry: is it possible to know which board is currently running from directly on the board?
<rburton>
JPEW: fyi just currently looking at gluing the non-spdx license text stuff in
<qschulz>
rburton: couldn't open the mail on my phone but I spotted an issue with GPL-3.0+ license file, it should be GPL-3.0-or-later, we removed the + thanks to one of our outreachy intern :)
<qschulz>
(tje filename I mean)
<JPEW>
rburton: cool. The changes you made to the script looked good
<tepperson>
rburton: right, i was imagining there would be a non-image specific version of a recipe, then image specific versions of the same recipe - bitbake blab and bitbake image_using_blab could compile two differrent version of blab
<rburton>
tepperson: yeah thats not how it works
<rburton>
normal recipes build packages, packages are combined to make images
<rburton>
so you can't have one recipe build different packages depending on what image they'll end up in
Net147_ has quit [Read error: Connection reset by peer]
<qschulz>
though you could use distro for that
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
<qschulz>
dvorkindmitry: the point I'm trying to make is maybe you don't need those two wics and can ship both DTB and pick the right one to boot from the bootloader at runtime
<rburton>
tepperson: if the different is just drivers then build stuff as modules and pull the right ones in
<rburton>
tepperson: if you want an entirely different config, have two kernel recipes
<tepperson>
rburton: like kernel-blab.bb and kernel-blob.bb, with PREFERRED_PROVIDER_virtual/kernel=kernel-blab ?
<rburton>
qschulz: v2 of the patch drops the + forms
<qschulz>
tepperson: you can't pick a provider from an image recipe
<dvorkindmitry>
qschulz, probably! but in this case I need two different u-boot ENVs in two different WICs :) case I can't detect the device version in u-boot
<qschulz>
rburton: :+1: sorry for the noise then!
<qschulz>
dvorkindmitry: no no, read some HW stuff from U-Boot
<qschulz>
ah, should have finished to read the message before answering :p
camus has quit [Quit: camus]
vics has quit [Remote host closed the connection]
<dvorkindmitry>
qschulz, yea. So seems I have two ways to make it: ctreate two MACHINEs, or create two IMAGEs or have a possibility to create two WICs at the same time.
<dvorkindmitry>
the last option is more convenient.
<dvorkindmitry>
usualy for different boards with almost the same stuff I am creating several DTSes at the same build command. But in case if you need to make WIC, you're limited with one WIC per MACHINE/IMAGE...
vics has joined #yocto
<JPEW>
dvorkindmitry: make two images that include a common conf file, and only change WKS_FILE
<qschulz>
JPEW: they wanted to avoid that :)
<JPEW>
ah, sorry
<dvorkindmitry>
:)
<JPEW>
It is a little annoying that your can't have multiple wic files for an image
<qschulz>
other way could have two image recipes (stay with me), and have image recipe A depends on recipe B to be done when recipe B is called by bitbake. And in recipe B you just have WKS_FILE overriden (and possibly IMAGE_FSTYPES to only have wic to quicken the build)
<qschulz>
feels hackish to be frank with you :)
vics has quit [Remote host closed the connection]
<qschulz>
JPEW: i am more annoyed by the WKS_FILES variable which does not really do what the name implies :)
<JPEW>
Yep
<qschulz>
or at least, that's not what was my first guess
jonmason has quit []
vics has joined #yocto
jonmason has joined #yocto
vics is now known as veq
<qschulz>
dvorkindmitry: it shouldn't be much harder than having a forloop of the content of IMAGE_CMD:wic
<qschulz>
using a new variable WKS_MULTI_FILES or something like that
<qschulz>
and use wks_search from WKS_FULL_PATH in the IMAGE_CMD:wic per entry in WKS_MULTI_FILES
<qschulz>
at least that's where I would start, not sure it's what will work
<qschulz>
if you manage to get something working, please send us a patch :)
<dvorkindmitry>
"the content of IMAGE_CMD:wic" - where to see an example or look for this code?
<dvorkindmitry>
I'd be happy to patch it, but I'm python newbie :)
<mihai>
JPEW: not really, I didn't dive into specifics yet, it's just a feeling I had when looking over the patches, mainly because of some one-liners and the naming choice of some variables
<qschulz>
dvorkindmitry: good news, it's shell :) (with a call to one rather simple pythonj function)
veq has quit [Remote host closed the connection]
<qschulz>
dvorkindmitry: classes/image_types_wic.bbclass in openemebdded-core
<mihai>
JPEW: don't take me wrong, it's great work, I didn't mean to be rude
<JPEW>
mihai: That's fine :)
vics has joined #yocto
vics is now known as veq
<JPEW>
mihai: I've been looking for feedback on "real world" use cases, since the support doesn't do any good if it can't do want someone wants :)
Net147 has quit [Read error: Connection reset by peer]
<qschulz>
JosefHolzmayr[m]: have fun, will look at the recording :)
<qschulz>
s/look at/watch/
vics has joined #yocto
Guest5638 has joined #yocto
<qschulz>
dvorkindmitry: I think we could reuse WKS_FILES if we have a boolean variable such as WKS_ONLY_CREATE_FIRST_WKS_FOUND
<qschulz>
which would keep the current behavior (so needs to be weakly set to 1 in that case, so that we don't break stuff), and then when it's set to 0, loop over all items in WKS_FILES
<qschulz>
just ideas
<qschulz>
up to you how you implement it :)
Guest5638 has quit [Read error: Connection reset by peer]
<JosefHolzmayr[m]>
qschulz: \m/
Net147 has joined #yocto
Net147 is now known as Guest1201
<mihai>
JPEW: I might have some feedback soon :)
<JPEW>
mihai: Excellent!
vics has quit [Remote host closed the connection]
bps has joined #yocto
bps has joined #yocto
vics has joined #yocto
vics has quit [Remote host closed the connection]
camus has joined #yocto
pgowda has quit [Ping timeout: 256 seconds]
Guest1201 has quit [Read error: Connection reset by peer]
Guest3977 has quit [Read error: Connection reset by peer]
Net147 has joined #yocto
Net147 is now known as Guest3053
<mckoan>
JosefHolzmayr[m]: \o/
sakoman has joined #yocto
<dvorkindmitry>
can I use SRC_URI_machine_xxx += "..." in kernel recipe?
<JaMa>
anyone else seeing python3-native segfaulting with latest oe-core/master? python3[41664]: segfault at 5628ded6f005 ip 00007f29a8664f35 sp 00007ffe458f1450 error 4 in _regex.cpython-39-x86_64-linux-gnu.so[7f29a864a000+a4000]
<dvorkindmitry>
where "xxx" is machine-specific
<rburton>
a kernel is machine specific so you can use any machine override yes
<smurray>
rburton: re bumping to the 5.13 kernel for generic-arm64, it looks like the defconfig.patch needs to be updated, and there's a question of whether to just dupe the linux-yocto bbappend from 5.10 or use an inc file. Thoughts?
<rburton>
smurray: sync with jonmason as i think he might be working on this too
<smurray>
rburton: okay
thierryE has quit []
whuang0389 has joined #yocto
thierryE has joined #yocto
<jonmason>
smurray: I've bumped to 5.13 and am seeing a config warning. So, I'm trying to work that out now.
<jonmason>
In addition to merging qemuarm64-sbsa into generic-arm64, per dl9pf request
<whuang0389>
is there a way to tell which systemd services to not be loaded by default?
<smurray>
jonmason: yeah, when I did a quick test last night it looked like a couple of the old warnings are gone, replaced by new ones.
<jonmason>
smurray: yes, fairly trivial to get it sane, pita to get all the warns gone
vics has joined #yocto
vics has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
vics has joined #yocto
vics has quit [Remote host closed the connection]
<smurray>
jonmason: okay, thanks for looking at it
<armoon>
Hi all I want to update the kernel version for raspberry 4 gb from 5.10.59 to 5.10.60 but I failed to update the SRCREV_meta
<armoon>
can some body share how to set the SRCREV_meta value
dev1990 has joined #yocto
<dvorkindmitry>
in linux-at91-4.19 ${P} value expanded to linux-at91-4.19+gitAUTOINC+046113c438. What variable expands to linux-at91-4.19 ?
rfuentess has quit [Remote host closed the connection]
armoon has quit [Quit: Client closed]
armoon has joined #yocto
mckoan is now known as mckoan|away
<smurray>
dvorkindmitry: no single variable, I think, that'd be something like ${PN}-${LINUX_VERSION}
<smurray>
dvorkindmitry: you can see how P itself is built up by looking at its expansion description in the output of 'bitbake -e linux-at91' (note that'll be a lot of output, usually better to pipe it to a file and then look at that)
<dvorkindmitry>
smurray, thank you! forgot about this magic command :)
Vinay75 has quit [Quit: Client closed]
<smurray>
dvorkindmitry: there's a bitbake-getvar in master now that can be used instead, e.g. "bitbake-getvar -r linux-at91 P"
tepperson has quit [Quit: Client closed]
<smurray>
armpit: would you be okay with backporting the dlt-daemon 2.18.[67] version bumps to dunfell in meta-oe?
<dvorkindmitry>
smurray, seems I have to strip "+SRCREV" from PV. how can I do this? I'm python newbie
<smurray>
dvorkindmitry: what is it you're trying to do with the resulting value?
<dvorkindmitry>
to use it in FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" in my .bbappend file instead of corrupted PV
<smurray>
heh, it's not corrupted, the use of the git rev is purposeful
zyga has joined #yocto
<smurray>
you could try LINUX_VERSION instead of PV there
Crofton has quit []
Crofton has joined #yocto
zyga-mbp has quit [Ping timeout: 244 seconds]
<smurray>
dvorkindmitry: are you trying to use a wildcard bbappend against different versions? If not, nothing stops using some other directory name, e.g. ${THISDIR}/files
<dvorkindmitry>
.../files is not beautiful :)
<smurray>
dvorkindmitry: or ${THISDIR}/${BPN}, i.e. linux-at91, that's a "cleaner" option. Having the version in path is only going to be useful if you do have multiple versions of the recipe and they need different versions of the same file
eFfeM has quit [Quit: Connection closed]
<dvorkindmitry>
I have two machines. One uses 4.9, another 4.19. but the patchset is small and fits into one .bbappend file easily. I can put patches intp /files/machine1, /files/machine2, but it is not descriptive
cocoJoe has joined #yocto
BobPungartnik has joined #yocto
BobPungartnik has quit [Client Quit]
<dvorkindmitry>
seems, I found the solution: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${d.getVar("PV").split('+')[0]}:"
armoon has quit [Quit: Client closed]
armoon has joined #yocto
ant__ has joined #yocto
prabhakarlad has joined #yocto
zyga has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
zyga-mbp has quit [Client Quit]
zyga-mbp has joined #yocto
florian has quit [Quit: Ex-Chat]
vics has joined #yocto
vics has quit [Remote host closed the connection]
<smurray>
dvorkindmitry: I'm surprised LINUX_VERSION wouldn't be set by that point
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
manuel1985 has quit [Quit: Leaving]
armoon has quit [Quit: Client closed]
vics has joined #yocto
vics has quit [Remote host closed the connection]
camus has quit [Quit: camus]
te_johan has quit [Remote host closed the connection]
te_johan has joined #yocto
armoon has joined #yocto
florian has joined #yocto
te_johan has quit [Ping timeout: 252 seconds]
florian has quit [Ping timeout: 252 seconds]
armoon has quit [Quit: Client closed]
<frosteyes1>
Hi folks. Has anyone worked with opencv and tried to make the opencv_world lib?
te_johan has joined #yocto
te_johan has quit [Ping timeout: 256 seconds]
tp43_ has joined #yocto
zyga-mbp has joined #yocto
Dracos-Carazza has quit [Quit: ZNC 1.8.2 - https://znc.in]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
agners has joined #yocto
florian has joined #yocto
Dracos-Carazza has joined #yocto
tp43_ has quit [Ping timeout: 252 seconds]
tp43_ has joined #yocto
<dvorkindmitry>
smurray, yea. Atmel forgot to set it correctly in they kernel recipe
<RP>
vmeson: centos7 rust build worked this time
<dvorkindmitry>
Is is OK to set DISTRO in machine.conf file?
amitk has quit [Ping timeout: 244 seconds]
<vmeson>
RP: Super!
te_johan has joined #yocto
<smurray>
dvorkindmitry: no, you don't want to do that. machine/distro/image are 3 separate axis that users should be able to mix and match
<dvorkindmitry>
smurray, in general yes. but for one of my machines it should always be "distro1"
te_johan has quit [Ping timeout: 256 seconds]
<smurray>
dvorkindmitry: do what you like, but whenever I see layers that do things like that I consider them very broken
<RP>
vmeson: merged the changes, calling it done from my pov ;-)
<vmeson>
RP: works for me. Hopefully you can be rust-proof for a while now.
<JPEW>
vmeson: He's galvanized!
<RP>
JPEW: galvanising is no good in fire so that wouldn't be much use
* RP
aims for stainless
<JPEW>
Keep some aluminum in your pocket as a sacrificial anode; you can throw it at anyone who mentions rust!
leon-anavi has quit [Quit: Leaving]
<RP>
JPEW: good plan! :)
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
te_johan has joined #yocto
florian has quit [Ping timeout: 252 seconds]
te_johan has quit [Ping timeout: 245 seconds]
jwillikers has quit [Remote host closed the connection]
angolini has quit [Quit: Connection closed for inactivity]
frieder has quit [Remote host closed the connection]