<pgowda_>
Am getting the following error during bitbake meta-toolchain using latest yocto sources
<pgowda_>
Cleaning and trying again.
<pgowda_>
WARNING: Renaming build/downloads/libxslt-1.1.34.tar.gz to build/downloads/libxslt-1.1.34.tar.gz_bad-checksum_0f48107788b888364801b2051a42fae2d007ce09266c6b0e6ef378eb5aeef5eb
<pgowda_>
Checksum mismatch for local file build/downloads/libxslt-1.1.34.tar.gz
<pgowda_>
Plz let me know if anyone else is facing the same issue?
<pgowda_>
Any workaround to fix the issue?
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
xmn has quit [Ping timeout: 268 seconds]
Schlumpf has joined #yocto
gourve_l has quit [*.net *.split]
iokill has quit [*.net *.split]
rfried has quit [*.net *.split]
fray has quit [*.net *.split]
dv_ has quit [*.net *.split]
ldericher has quit [*.net *.split]
fray has joined #yocto
iokill has joined #yocto
gourve_l has joined #yocto
dv_ has joined #yocto
ldericher has joined #yocto
goliath has joined #yocto
marex has quit [*.net *.split]
zeddii has quit [*.net *.split]
kmaincent has quit [*.net *.split]
beneth has quit [*.net *.split]
marex has joined #yocto
kmaincent has joined #yocto
zeddii has joined #yocto
adrian__ has joined #yocto
kroon has joined #yocto
beneth has joined #yocto
tre has joined #yocto
sstiller has joined #yocto
rob_w has joined #yocto
fleg has joined #yocto
rfuentess has joined #yocto
gsalazar_ has joined #yocto
gsalazar__ has joined #yocto
zpfvo has joined #yocto
gsalazar_ has quit [Ping timeout: 265 seconds]
JaMa has quit [Quit: reboot]
lucaceresoli has joined #yocto
<qschulz>
tlwoerner: I think there's a misunderstanding, it is both in 5.15 upstream tree and >=5.14.12 upstream stable releases. I was just wondering how to handle a Yocto release which has a 5.14 kernel < 5.14.12 and one >= 5.14.12, one being the original release and the other in dot releases (yet to be released)
<qschulz>
jaskij[m]: no worries, I'm interested to see where you go with those dot files and if it can finally be useful when rendered :) (and not take days to be rendered :p)
<qschulz>
jaskij[m]: nice tool!
<qschulz>
pgowda_: I assume the tarball you're receiving from upstream has a bad checksum but I'd have guessed this would result in an error if no mirrors with valid checksum were available
<RP>
pgowda_: FWIW I tried re-downloading that here and it seems to work ok
nad has joined #yocto
<pgowda_>
It had issues during download,,, One of my colleague working in the same machine encountered the same issue
<RP>
qschulz: the only way to do that is going to be conditional patch application
<pgowda_>
Just replaced the http with ftp... Maybe issue with our network blocking hhtp
RobertBerger has quit [Remote host closed the connection]
<RP>
pgowda_: the original url seems to work fine here FWIW
<qschulz>
frosteyes: very nice commit log :) thanks for contributing :)
camus1 has joined #yocto
<pgowda_>
OK,,, Thanks for confirmation,,, Maybe the issue in our side
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
RobertBerger has joined #yocto
<qschulz>
jaskij[m]: wondering if we could also add information on common inter-recipe dependencies (e.g. DEPENDS is do_configure[depends] += "recipeB:do_populate_sysroot" (or is it do_prepare_recipe_sysroot? I always mix both))
<qschulz>
so something like a text above the "dependency arrow" between what you call clusters, to explicit if it's DEPENDS or RDEPENDS/RRECOMMENDS
zpfvo has quit [Ping timeout: 265 seconds]
<qschulz>
if you have access to that kind of information, maybe even point the file/line where it is defined but just saying "this dependency is VERY commonly the result of a DEPENDS" would be very helpful for benon-veterans :)
<qschulz>
-be
<qschulz>
RP: yes that's what I gathered from your answer last Friday (thx BTW :) ), was just answering to tlwoerner :)
RobertBerger has quit [Read error: Connection reset by peer]
leon-anavi has joined #yocto
florian has joined #yocto
Granjow has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
zpfvo has joined #yocto
<JosefHolzmayrThe>
yo dudX
<qschulz>
o/
tnovotny has joined #yocto
<Granjow>
Hi there =)
JaMa has joined #yocto
kroon has quit [Ping timeout: 265 seconds]
kroon has joined #yocto
Granjow has quit [Ping timeout: 265 seconds]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
zyga-mbp has joined #yocto
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
xmn has joined #yocto
Granjow has joined #yocto
<jaskij[m]>
qschulz: edges ("arrows") between clusters are possible. That said, the only data I have are task dependencies - so either I'll need help identifying those common dependencies and creating the data from there, or need extra info dump from BB.
<jaskij[m]>
I already have separate code paths for the cluster and non-cluster version anyway
<jaskij[m]>
changing topics: looking through kernel-devicetree.bbclass, `KERNEL_DEVICETREE` supports listing multiple device trees, but it is not mentioned in the docs?
adrian__ has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
kroon_ has joined #yocto
kroon has quit [Ping timeout: 268 seconds]
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
<qschulz>
jaskij[m]: send a patch :)
<jaskij[m]>
Once I understand the logic in the class :P
<qschulz>
jaskij[m]: to me at least, it'd be enough to re-use the existing edges and add text to it?
<qschulz>
e.g. the "with clusters" image, you can see there's one arrow from a task of one cluster to another
<jaskij[m]>
Yes, but does it come from DEPENDS or RDEPENDS?
vd has quit [Quit: Client closed]
vd has joined #yocto
<jaskij[m]>
Also, GV is generally bad with placing edge labels, so it might end up messy :/
<qschulz>
jaskij[m]: well, DEPENDS and RDEPENDS are always between two distincts tasks so the guess from task names is pretty safe
<jaskij[m]>
Cool. Now I just need to know which tasks those are ;)
<qschulz>
jaskij[m]: GH can do answers by mail too.
<qschulz>
jaskij[m]: I sent one for DEPENDS about 3h ago :)
<jaskij[m]>
qschulz: now I feel like an idiot for not RTFMing. Thanks.
<jaskij[m]>
*thanks for checking
<jaskij[m]>
No irony or sarcasm intended
<qschulz>
It took me some time to put one and one together and figure out that DEPENDS relies on tasks too. It should have been obvious but it wasn't in my brain
gsalazar__ has quit [Ping timeout: 250 seconds]
<qschulz>
When I send links it's just to add sources, or not retype its content, no RTFM'ing intended :)
<qschulz>
I don't know how RDEPENDS dependencies are handled in the task tree tbh :/
<qschulz>
I'm not even sure if it's handled by bitbake or by the package manager handling the rootfs building from packages :/
<jaskij[m]>
Nah, I'm irritated with myself for not checking the manual and having you do it for me, is all.
<qschulz>
I assume there is something for bitbake otherwise it wouldn't know which recipe to build for which RDEPENDS
<rburton>
automatic RDEPENDS are added in do_package based on linkage
<qschulz>
rburton: the question is how to identify RDEPENDS "relationships" between two recipes
<rburton>
typically the providers are in DEPENDS (albeit implicity, maybe) as otherwise you get warnings
<qschulz>
from the task tree
<rburton>
i guess you don't, from the task tree
<qschulz>
rburton: s/DEPENDS/PACKAGES/ ?
<rburton>
pkgdata has the complete set of runtime deps
<RP>
The information about where a dependency comes from is lost in the final task graph as it really doesn't make much sense any more
<qschulz>
RP: from BB PoV sure, but from user PoV, if I want to understand why a package/recipe is pulled-in, knowing how it
<RP>
A dependency could be from a direct [depends] line, an [mcdepends], a DEPENDS, an RDEPENDS:XXX, from the runall/runonly commandline options and so on
<qschulz>
's added is a nice thing :)
camus has quit [Remote host closed the connection]
<RP>
qschulz: we don't store that info in the resulting taskdata/runqueue and we simply can't afford to :(
<qschulz>
RP: mmm yeah, it was more a suggestion like "likely to be from a DEPENDS in recipe A" to be added on an edge
camus has joined #yocto
<rburton>
from the users point of view you want to look at the package dependency tree, not the bitbake task tree, surely
<RP>
For example, a recrdepends can all all kinds of dependencies
nad has joined #yocto
<jaskij[m]>
-g used to output a pn-depends.dot, but that was dropped
prabhakarlad has quit [Quit: Client closed]
<RP>
jaskij[m]: specifically because it was broken, it didn't show all these dependencies and that upset people trying to use it
<RP>
it showed some subset of the dependencies
<RP>
This is why in the bug you mentioned I suggested the "exclude a recipe" approach to answering this question
<jaskij[m]>
I don't have it at hand, pet me finish my lunch brake and I'll read the bug convo again
<jaskij[m]>
But yes, exclusions are already planned
<jaskij[m]>
I think I could even default to excluding anything *-native and *-cross
<RP>
jaskij[m]: my point is that by doing the exclusion in bitbake, you find out exactly what is including it
<RP>
even if it is via some recrdepends or something else odd
warthog9 has quit [Quit: Leaving]
xmn has quit [Ping timeout: 264 seconds]
warthog9 has joined #yocto
mckoan_ is now known as mckoan
<jaskij[m]>
So it comes back to using BB. Unsurprising - there's only so much you can do with task-depends.dot
<RP>
the data simply isn't there and internally bitbake doesn't have it in runqueue either :(
Schlumpf has quit [Quit: Client closed]
<jaskij[m]>
If I understand it right, `tinfoil` is a Python module for external software to work with BB's cache?
<rburton>
not just the cache, but its for external software to interface with bitbake
<jaskij[m]>
Is there any sort of Bitbake dev manual? Or do I just look at the code?
<RP>
jaskij[m]: tinfoil lets you have access to bitbake's internal apis. However whilst that does have task dependency graph functions, they will only give you the data that is in task-depends.dot too
<RP>
My point is that runqueue which is where this data is built, doesn't have the information about which dependency line causes which end dependency because that doesn't really make sense in the way bitbake computes the task graph
dmoseley has joined #yocto
<jaskij[m]>
RP: I'm trying to make sense on your comment in 3362 (that dep tools bug). Do you mean to actually blacklist the package from build and see what fails?
<RP>
jaskij[m]: yes
kroon_ has quit [Remote host closed the connection]
kroon_ has joined #yocto
<jaskij[m]>
That would definitely work, but I'm concerned about the speed of such a solution.
<jaskij[m]>
OTOH, I've realized that to efficiently work with task-depends.dot, you'd need a GUI where you can set up filters on the fly.
tre has quit [Remote host closed the connection]
akica has joined #yocto
manuel1985 has quit [Ping timeout: 268 seconds]
codavi has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
akica has quit [Ping timeout: 265 seconds]
paulg has joined #yocto
FredO2 has quit [Remote host closed the connection]
FredO2 has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
sakoman has joined #yocto
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 265 seconds]
__Ozymandias__ has quit [Quit: Konversation terminated!]
zpfvo has joined #yocto
gsalazar_ has joined #yocto
gsalazar has quit [Ping timeout: 250 seconds]
kiran has joined #yocto
Granjow has quit [Ping timeout: 265 seconds]
rob_w has quit [Remote host closed the connection]
jsbronder has quit [Quit: WeeChat 3.2]
jsbronder has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest2 has joined #yocto
Guest2 has quit [Client Quit]
Tokamak has joined #yocto
florian has quit [Quit: Ex-Chat]
cperon has quit [Quit: You have been kicked for being idle]
sstiller has quit [Quit: Leaving]
pgowda_ has quit [Quit: Connection closed for inactivity]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has joined #yocto
ant__ has joined #yocto
<vd>
hi there -- what should I grep to find examples of copying file via python?
<vd>
thank you. Can a bitbake function have dash in its name? i.e. ROOTFS_POSTPROCESS_COMMAND += "func-with-dashes;"
<vd>
or is it unusual
troth has quit [Ping timeout: 264 seconds]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rburton>
use underscores
<jaskij[m]>
vd: dashes are not legal in Python function names, so even if you're writing a shell function I'd avoid them
<vd>
thanks
dev1990 has joined #yocto
troth has joined #yocto
zpfvo has quit [Remote host closed the connection]
<vd>
does bitbake detect that a class defines a variable already defined by another class?
<vd>
or does it lead to hard to debug issues?
<rburton>
no, the second just overwrites the first
<rburton>
autotools.bbclass sets EXTRA_OECONF to a default value, and other classes can extend as needed
<rburton>
so you really wouldn't want that to cause a warning
mckoan is now known as mckoan|away
<vd>
I'm writing my own class to embed an initrd image within the rootfs, but INITRD is already used by the image-live class (which I don't use but still).
<vd>
I must choose a more unique name instead of initrd.bbclass I assume :)
<rburton>
well, you could just use that name and assume people don't inherit both :)
<vd>
they shouldn't, because it is two distinct initrd strategies
<vd>
mine is more of an extension to bootspec to embed an image and add an initrd line to the specs
rfuentess has quit [Remote host closed the connection]
nad has quit [Quit: Client closed]
Tokamak has joined #yocto
florian__ has joined #yocto
<kanavin>
rburton, I'm going to force correctly formatted and spelled upstream-status in oe-core patches
<kanavin>
keep discovering patches that either lack it completely, or misspell things
<kanavin>
via insane.bbclass
<kanavin>
would be nice to force [reason] on Pending patches too btw, but maybe in the glorious future
<kanavin>
RP ^^^
<rburton>
i used to run patchreview weekly but that was on an intel machine that doesn't exist anymore
florian__ has quit [Ping timeout: 250 seconds]
roussinm has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP>
kanavin: abelloni did promise me a patch. You can check them with "./scripts/contrib/patchreview.py meta "
<RP>
kanavin: but yes, enforcing that way may help. I've been hoping we get patchtest aback
<jaskij[m]>
`I_SWEAR_TO_MIGRATE_TO_PYTHON3` - beautiful. No, I'm not using Python2, just looking at the recipe for python-can
adrian_ has quit [Ping timeout: 250 seconds]
<jaskij[m]>
What's the status of Rust? Do I need to update to honister, or is `meta-rust` usable for Hardknott (and Dunfell)?
<kanavin>
jaskij[m], you need to use the separate meta-rust layer for the older releases
<kanavin>
otherwise, just check if rust recipes are in meta.
<kanavin>
meta/
<kanavin>
ah
<kanavin>
I guess you need to try and see
<kanavin>
the project doesn't test the layer in CI
<jaskij[m]>
qschulz RP : One idea I just hit upon for clearing up the task dependency tree for rendering is that *many* tasks only have a single dependency (eg. `do_compile -> do configure`). Personally, I see no harm in collapsing those into a single node for the purposes of displaying stuff.
whuang0389 has joined #yocto
tnovotny has quit [Quit: Leaving]
rfried has joined #yocto
manuel1985 has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
deurzen has joined #yocto
codavi has quit [Read error: Connection reset by peer]
<deurzen>
Hello everyone, I'm attempting a very basic (config-wise) Yocto build, with the end goal of getting Kubernetes (or K3s) running. Has anyone successfully attempted this? I'm getting 'dial tcp ... no route to host' and other 'dial tcp ...' error variations all over the place. I've tried building K3s on Hardknott and Kubernetes on Dunfell, both without success
codavi has joined #yocto
whuang0389 has quit [Quit: Client closed]
prabhakarlad has joined #yocto
leon-anavi has quit [Quit: Leaving]
rfuentess has joined #yocto
florian__ has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
rfuentess has quit [Remote host closed the connection]
Tokamak has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
adrian_ has joined #yocto
<vd>
is there a python equivalent for 'install' in recipes?
<vd>
(to install files in the target filesystem)
<JPEW>
vd: do_install is _usually_ shell code, but I suppose you could write it in python if you wanted? Not sure if that would break anything
<vd>
JPEW I'm actually looking for a better implementation for calling 'install' via bb.process.run which isn't very smart
Tokamak has joined #yocto
kroon_ has quit [Quit: Leaving]
kiran has quit [Ping timeout: 250 seconds]
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
florian has quit [Ping timeout: 250 seconds]
vd has quit [Quit: Client closed]
vd has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP>
jaskij[m]: That is probably reasonable although you'd somehow have to show that in the labelling and you have the dilemma of which side to collapse onto
Tokamak has joined #yocto
xmn has joined #yocto
<jaskij[m]>
<RP> "jaskij: That is probably..." <- Of course for label. As for side, I believe if I merge/collapse the nodes it shouldn't matter. I'm currently booted into the wrong OS to make a graphical example, but say if you have a -> c, b -> c, c -> d, d -> e, d -> f changing it into a -> cd, b -> cd, cd -> e, cd -> f should preserve all the information while simplifying the graph.
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]