<michaelo>
qschulz: I see no issue with my latest reply to you (date 09:54 CET).
<qschulz>
michaelo: the message is sent to two addresses, foss (to) and foss+yocto (cc)
mvlad has joined #yocto
<michaelo>
qschulz: yes, because your "From" address is different from the "cc" one you used in your original e-mail. I'll be happy to manually remove "foss" and keep only "foss+yocto" if you prefer.
<qschulz>
michaelo: it isn't the From actually
<qschulz>
it's the "Received: (Authenticated sender: foss@"
<qschulz>
the From is correct\
<qschulz>
the received too technically, it's just that your mail client takes the Received instead of the From
rber|res has joined #yocto
RobertBerger has joined #yocto
<qschulz>
FWIW, Thunderbird picks the From correctly
RobertBerger has quit [Client Quit]
rber|res has quit [Client Quit]
<michaelo>
qschulz: weird. I'm using Thunderbird, and the "From" field is "Quentin Schulz" <foss@0leil.net>
<RP>
michaelo: thanks for the review. I suspect I'd better wait and see if qschulz or ndec have comments before merging :)
<ndec>
hey RP , i looked at the patches. of course using the git data helps. of course some of the patches are 'weird'.. I admit that this has been an issue since the very beginning, and we've never made any attempt to fix the situation..
<ndec>
as it is it breaks the build from a tarball (we still produce release tarballs). should we worry about that?
<RP>
ndec: we don't really have release tarballs as such any more, just snapshots of the codebase
<RP>
ndec: I suspect the benefits outweigh that cornercase?
<ndec>
i think i agree.. it probably does not make sense to have release tarballs anyways these days
<RP>
ndec: I've been pushing to move us away from them
<ndec>
RP: i was wondering if we should split yocto-docs into a tree that 'builds' a flavor of the docs, and a tree that builds the website (e.g. switcher, transition, ..). it's all very much convoluted
<RP>
ndec: maybe, although I'm not sure it would change much in reality :/
<RP>
it is all intertwined
<ndec>
agreed.. it would be nice to be able to easily build the whole website with 'one' tool..
<michaelo>
Yes, starting from infos from the yocto-docs repository looks like a way to keeps things in sync
<qschulz>
RP: will have a look as soon as I can. Been busy with release days/weeks for a while. Last Friday was weirdly not too busy hence the doc patches
mihai has quit [Quit: Leaving]
<manuel1985>
AFAIK Rust is first class citizen of the yocto project now, but also for dunfell?
<manuel1985>
qschulz: That means no support on Dunfell? Am I reading you correctly?
<qschulz>
manuel1985: seems about right, no rust recipe seems to indicate it's not first citizen
<qschulz>
manuel1985: FWIW, kirkstone will be out in about a month or so, and it'll be LTS for as long as dunfell is (at least with current situation)
<qschulz>
so instead of backporting rust support to dunfell, upgrading to kirkstone might not be the worst idea :)
<RP>
qschulz: sorry to ask but do you have a rough idea the timescale? Just to explain why I ask, if it were this week, I'd probably hold the patches and wait. If it were in the next few weeks I'd probably lean to merging and then we'll handle any issues with follow up patches. Not trying to put any pressure, it just helps me to know the timescale
<manuel1985>
qschulz: Depends wether our BSP and OTA solution will also see kirkstone support.
<kanavin_>
halstead, downloading from downloads.yoctoproject.org is very slow, is the link saturated somehow? I'm getting 100K/s speeds
<qschulz>
kanavin_: there was something done last week to prioritize downloads.yoctoproject.org against sstate.yoctoproject.org
<qschulz>
(at least that's what was said)
<kanavin_>
qschulz, I'm not entirely sure if that's on my side, but I tested it with my home machine, and a company server (that's on the other side of Germany), and they both get the slow speed
GNUmoon has quit [Ping timeout: 240 seconds]
<qschulz>
kanavin_: oscillate between 100-300KBps in Austria, /me shrugs
<RP>
kanavin_: michael commented he needed to prioritise the traffic, I'm not sure if he did that yet or not
* zeddii
is back from vacation. oof.
<RP>
zeddii: welcome back
<RP>
zeddii: I wonder how much we broke when you weren't looking? :)
<zeddii>
it's about 20 degrees (c) colder now, that will at least keep me indoors to figure it out :)
<zeddii>
I was watching the python chaos, or skimming would be a closer description.
<zeddii>
I'll have to rebase and test my queues as the first bit of effort today.
<RP>
I'm seriously thinking I should merge the libtool upgrade too
<RP>
the pseudo breakage there worries me a bit
<zeddii>
the 2.4.7 one ? I'd agree it would be nice to get the release.
<RP>
zeddii: yes, been years since 2.4.6 but 2.4.7 doesn't contain that much
<zeddii>
is the pseudo breakage on the list ? I missed that.
<RP>
something is passing crazy shell pipelines as filenames to libc
<zeddii>
RP: yah, I always tend to take those releases. even if late. Support is easier, and it needs an even closer look after release, so nice to get it done.
<zeddii>
ahah.
<zeddii>
6000+ wow.
camus has quit [Quit: camus]
GNUmoon has joined #yocto
pasherring has joined #yocto
<pasherring>
Hello people! I've been experiencing some really slow git fetches, topping around 255kBps, but consistenytly at 85 kBps. The same repo I can manually git clone with 4MBps+. Any ideas on what could I have wrong here on my setup?
<frosteyes>
Hey folks. Just noticed my local mirror of poky (git.yoctoproject.org/poky) had stopped syncing, because master had diverged. It seems they was 3 commits related to poky.yaml. Now removed and is on master-next. Guess it was just an error they where pushed to master.
<kanavin_>
pasherring, it's using the yocto mirror, and it's slow. we've alerted halstead to the issue.
<rburton>
set PREMIRRORS="" in your local.conf and it will go straight to the upstream source
chep has quit [Read error: Connection reset by peer]
<pasherring>
Ah, I see. Thanks kanavin_ , rburton !
<qschulz>
RP: I'll do it this week. How much I hate certification processes...
<rburton>
RP: cherrypicking the tiff CVEs now
<RP>
rburton: great, thanks
kuzz_ has quit [Remote host closed the connection]
kuzz_ has joined #yocto
davidinux has quit [Ping timeout: 256 seconds]
davidinux has joined #yocto
rber|res has joined #yocto
davidinux has quit [Ping timeout: 256 seconds]
davidinux has joined #yocto
tgamblin has joined #yocto
LocutusOfBorg has quit [Remote host closed the connection]
LocutusOfBorg has joined #yocto
jmiehe has joined #yocto
falk0n[m] has joined #yocto
<landgraf>
where (and how) devtool-source.class is inherited? my grep foo didn't help :(
troth has quit [Quit: Leaving.]
<landgraf>
nvm. found it :)
sakoman has joined #yocto
<RP>
qschulz: cool, thanks
angolini has quit [Quit: Connection closed for inactivity]
troth has joined #yocto
Minvera has joined #yocto
pgowda_ has joined #yocto
akiCA has joined #yocto
codavi has joined #yocto
marc3 has quit [Ping timeout: 272 seconds]
marc3 has joined #yocto
akiCA has quit [Ping timeout: 256 seconds]
<kanavin_>
zeddii, is there a correct procedure for swapping linux-xlnx with linux-yocto? I have a customer request to provide 5.15 linux-yocto for zynqmp - I have set PREFERRED_PROVIDER, and wondering if something else should be done.
Guest11 has joined #yocto
Guest11 has quit [Quit: Client closed]
<rfs613>
where does setuptools_build_meta.bbclass come from?
<rfs613>
I see a reference to it in documentation/ref-manual/classes.rst but not the .bbclass file
<qschulz>
manuel1985: very likely unrelated except if you're booting from USB? Try to get logs before the USB subsystem messages
<manuel1985>
qschulz: I'm booting from USB.
<rfs613>
oh, setuptools_build_meta now has a python_ prefix added.
<rburton>
rfs613: the doc update is queued but not yet merged :)
xmn has joined #yocto
<RP>
rburton: I'm not sure the meta-oe piece made it in yet
<rburton>
they did
<RP>
cool
rob_w has quit [Remote host closed the connection]
shoragan has quit [Ping timeout: 256 seconds]
shoragan has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<manuel1985>
After dropping 'LICENSE_CREATE_PACKAGE = "1"' into the local.conf, `oe-pkgdata-util list-pkgs` should list quite a few *-lic packages, right? Don't get it to work here...
SSmoogen is now known as Ebeneezer_Smooge
<RP>
manuel1985: did you rebuild things?
<manuel1985>
RP: I did a `bitbake -e <my-image>` so it would re-parse the local.conf
<RP>
manuel1985: you need to actually run the build to generate packages
<manuel1985>
RP: Ok, will try. Does this var need to go in the local.conf, or is the image definition alright as well? Because I had it in the image definition first, and the build aborted due to gstreamer1.0-lic not being provided anywhere.
<RP>
manuel1985: needs to be in a global config
<RP>
manuel1985: local.conf is global as is distro
<manuel1985>
RP: ok thanks. That still something I haven't understood yet -- what needs to be on global level, and what I can put into the image definition too. COPY_LIC_MANIFEST and COPY_LIC_DIRS worked on the image level too.
<qschulz>
manuel1985: recipes are in their own context and cannot impact other recipes
<qschulz>
conf files are global, so anything set in them will make it to any recipe
<manuel1985>
qschulz: ok and COPY_LIC_MANIFEST COPY_LIC_DIRS do work on the image level as they don't influence other recipes but only take what's already there, kind of? Hmmm I see
florian_kc has joined #yocto
florian has quit [Read error: Connection reset by peer]
<zeddii>
kanavin_: you'd need to set the KBRANCH variable, if you want the contributed BSP patches on v5.15/standard/xilinx-zynqmp, but other than that the linux-yocto process will find the BSP definition and configuration entry point in the kernel-cache automatically assuming the machine is xilinx-zynqmp
jclsn73 has joined #yocto
<moto-timo>
smurray: thank you for the removal patches for recently moved to core python recipes
<smurray>
moto-timo: no worries, figured I'd be hard-pressed to screw up the patches to help clean it up ;)
prabhakarlad has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
<cb5r>
If I see correctly, maliit-framework and maliit-plugins (keyboard) have been removed from meta-oe many years ago. Has this been moved somewhere else? - because I cannot find it anywhere 😕
<qschulz>
RP: + if i in bitbake_mapping: should be if branch in bitbake_mapping I think
<qschulz>
(the second one
rfuentess has quit [Remote host closed the connection]
<RP>
qschulz: yes, well spotted
<qschulz>
RP: since patches are in master-next now and there's a pull request waiting for you, how do you want to proceed actually? Seems like review is a bit late (and I'm reviewing old versions apparently.... I hate Thunderbird)
danielt has joined #yocto
<qschulz>
I guess, the code-unrelated changes can be discussed, otherwise we'll just send patches to fix what we see or make some improvements?
<qschulz>
gotta go now, will read your answer tmrw. have a nice evening folks
<RP>
qschulz: You're not reviewing old versions as such, just that there were follow on patches on the list and michaelo staged some of them
<RP>
qschulz: I've tweaked a couple of things based on your review so far and will resend the patches
chep has joined #yocto
chep has quit [Client Quit]
<kanavin_>
zeddii, thanks, the machine is zynqmp-generic from meta-xilinx-core
<RP>
qschulz: I've sent a v2 of the series to try and ease review
chep has joined #yocto
<RP>
qschulz: if there is no huge disagreement with things I can merge and we can them work on incremental improvements
frieder has quit [Remote host closed the connection]
<zeddii>
kanavin_: ok. in that case, where ever you set KBRANCH (a bbappend presumably), you'd also set KMACHINE:zynqmp-generic = xilinx-zynqmp, since if you don't set it KMACHINE == MACHINE and it won't find that BSP definition in the kernel meta-data.
goliath has quit [Quit: SIGSEGV]
<kanavin_>
zeddii, right, I was wondering why there's a bunch of configcheck warnings printed about not found symbols, including some fairly important ones like CONFIG_XILINX_PHY
Guest79 has joined #yocto
goliath has joined #yocto
manuel1985 has quit [Quit: Leaving]
<Guest79>
Our build system (based on Yocto) has two levels of sstate caching, global and local.
<Guest79>
My question:
<Guest79>
Could we copy artifacts of a locally build package from the local sstate-cache (e.g. build/sstate-cache) to the global sstate cache?
<Guest79>
We have tested this and seems it works, but I am worried about side-effects.
<kanavin_>
Guest79, it's better to mount the global cache as r/w nfs
<Guest79>
kanavin_ ok, but the way we are copying the artifacts would is that okay?
<kanavin_>
Guest79, I think not, if partially copied artifacts can be seen by other users of the global cache
<kanavin_>
it needs to be completely atomic
pasherring has quit [Quit: Leaving]
<rburton>
doesn't rsync write to hidden files and rename?
<rburton>
yes
Tokamak has joined #yocto
<Guest79>
rburton I am sorry I did not understood your comment, if yu could please expand on it..
<rburton>
other users won't see partially copied artifacts
<Guest79>
But we have tested it, and it appears it works ... Or at least our nightly build seems it works...
<kanavin_>
Guest79, if rsync runs while something else is accessing the cache that something may see and fetch a cache artifact that isn't completely copied
<kanavin_>
Guest79, mounting the global cache directly with nfs would avoid that
<Guest79>
kanavin_ thanks understood.
dtometzki has joined #yocto
Qorin has quit [Ping timeout: 245 seconds]
Tokamak_ has joined #yocto
Tokamak has quit [Ping timeout: 240 seconds]
prabhakarlad has quit [Quit: Client closed]
tcdiem has joined #yocto
florian__ has quit [Read error: Connection reset by peer]
florian__ has joined #yocto
<kanavin_>
zeddii, seems like upstream 5.15 isn't quite ready for consumption on zynqmp and I'm going back to 'evil vendor kernel' - linux-xlnx does have a 5.15 branch fortunately
Tokamak_ has quit [Ping timeout: 240 seconds]
Tokamak has joined #yocto
qrsBRWNanyall[m] has joined #yocto
mvlad has quit [Quit: Leaving]
<zeddii>
upstream 5.15 is relatively feature complete, but yah, the vendor tree queue continues to be "not small"
<LetoThe2nd>
what is a neat way to err out if a layer is being parsed? like bb.fatal in a recipe, but for layer.conf?
<paulg>
meta-security layer has an annoying misfeature where it nags you if it is being included but not enabled. I haven't looked at how it does it, but maybe you can steal from what it does?
Guest79 has quit [Quit: Client closed]
<moto-timo>
so although the PCIe 4.0 drive did seem to speed up some tasks, the overall build time was the same... we are really compute bound on rust-native :/
<moto-timo>
JaMa: any idea when meta-ros will start moving to kirkstone?
<LetoThe2nd>
paulg: ah yeah, found it, thanks. too bad i need it in ~20 layers, and no common one that I can rely on :(
<moto-timo>
meta-virtualization has the same feature
<LetoThe2nd>
yeah but c&p-ing a class into 20 layers feels outight wrong.
<moto-timo>
hmmm... generalized common class but with a per layer variable for what it nags about? not sure if it would work...
<moto-timo>
common class in some base layer
<moto-timo>
still annoying to do the per layer config though ;)
<khem>
manuel1985: looking at your logs it seems you have some storage attached to USB ?
<khem>
manuel1985: if so, then it seems there is not enough power supplied to the system unless the USB disk is externally powered
wyre has joined #yocto
<moto-timo>
That will definitely be a problem
Tokamak has quit [Ping timeout: 240 seconds]
<vmeson>
LetoThe2nd: moto-timo if somone makes it easier for a layer to nag users, please also provide a mechanism to have the layer stop nagging!
<moto-timo>
vmeson: meta-virt at least has that knob
Tokamak has joined #yocto
Minvera has quit [Remote host closed the connection]
florian__ has quit [Ping timeout: 240 seconds]
<vmeson>
moto-timo: ah, I did notice that until now. It's in the README even: SKIP_META_VIRT_SANITY_CHECK = 1
<vmeson>
*did NOT
GNUmoon has quit [Ping timeout: 240 seconds]
<khem>
actually having layers to be inert is best practice but it may not be possible all the time.
<khem>
such layers are better of by nagging then silently spewing stuff into your builds
florian__ has joined #yocto
<vmeson>
khem: all the nagging layers that I know of are inert and nag about it by default. Turns out they also have a SKIP_<layer-name>_SANITY_CHECK -- some of them for years!!
<sielicki>
would you guys accept a patch that allows people to not fatally error on `LAYERSERIES_COMPAT` mismatches?
<RP>
vmeson: YP compat requirement, at least the inert bit
<vmeson>
RP, yep, inert is the only sensible default. It was the constant nagging that was bothering me but now I know that it can be and will be turned off! Phew!
<moto-timo>
sielicki: you are better off forking or working with upstream to add release of interest. You will not get any traction to allow it to float.
<RP>
sielicki: it really wouldn't encourage any behaviour that would be overall good for the project