reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
jclsn has quit [Ping timeout: 276 seconds]
jclsn has joined #yocto
KanjiMonster has quit [Ping timeout: 252 seconds]
KanjiMonster has joined #yocto
Daanct12 has joined #yocto
nerdboy has quit [Ping timeout: 260 seconds]
mbulut has joined #yocto
mbulut has quit [Client Quit]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
mbulut has joined #yocto
Minvera has quit [Ping timeout: 252 seconds]
jmd has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
ablu has quit [Ping timeout: 252 seconds]
ablu has joined #yocto
wooosaiiii has joined #yocto
Guest60 has joined #yocto
amitk has joined #yocto
kanavin_ has joined #yocto
kanavin has quit [Ping timeout: 252 seconds]
Daanct12 has quit [Quit: WeeChat 4.3.5]
enok has joined #yocto
Daanct12 has joined #yocto
enok has quit [Quit: enok]
enok has joined #yocto
enok has quit [Ping timeout: 252 seconds]
Jones42_ has joined #yocto
Guest92 has joined #yocto
enok has joined #yocto
Jones42_ has quit [Ping timeout: 248 seconds]
frieder has joined #yocto
enok has quit [Read error: Connection reset by peer]
enok has joined #yocto
frieder has quit [Ping timeout: 245 seconds]
Jones42_ has joined #yocto
Jones42__ has joined #yocto
leon-anavi has joined #yocto
Jones42_ has quit [Ping timeout: 276 seconds]
zpfvo has joined #yocto
florian_kc has joined #yocto
florian_kc is now known as florian
enok has quit [Quit: enok]
enok71 has joined #yocto
enok71 is now known as enok
frieder has joined #yocto
enok has quit [Ping timeout: 252 seconds]
goliath has joined #yocto
Guest60 has quit [Quit: Client closed]
leonanavi has joined #yocto
alessioigor has joined #yocto
leon-anavi has quit [Ping timeout: 252 seconds]
BenBE has joined #yocto
<jclsn>
Morning guys, I want to split systemd-timesyncd into its own package. Is it sufficient to add PACKAGES =+ "timesyncd" into the .bbappend for this?
leonanavi has quit [Ping timeout: 244 seconds]
<jclsn>
or maybe do a PACKAGECONFIG:remove = " timesyncd" PACKAGES =+ "timesyncd" PACKAGECONFIG_timesyncd:add = " timesyncd"
kanavin_ has quit [Ping timeout: 276 seconds]
<jclsn>
I want to find a way to not build systemd-timesyncd when chrony is installed
<mcfrisk>
arhg, few days wasted due to += overwriting systemd PACKAGECONFIG which is set with ??=, what's the point with that...
eminboydak has joined #yocto
<RP>
mcfrisk: I wish I could find the time to sit down and try and work out a better way of handling this :/
<mcfrisk>
I think use either ??= or ?= on oe-core, not both
florian has joined #yocto
<RP>
mcfrisk: it does depend on conf vs class vs recipe context
<mcfrisk>
I should just learn to always, always check bitbake -e output. assignments and various things which impact variables across layers are so far from trivial
<mcfrisk>
and runtime impacts are even more interesting. at least systemd reported the PACKAGECONFIG output on first line in boot so I got the hint to check that
<eminboydak>
Hello, I am using Yocto to create the rootfs and the kernel provided by the board manufacturer. Wi-Fi works on the default Debian rootfs but not on the rootfs I created with Yocto. I reached out to the company about this issue, and they told me to copy the kernel module file to the "/system/lib/" directory and then enable the module in Yocto. I
<eminboydak>
want to enable the "bcmdhd" module in Yocto, but I can't find the proper solution. Is there anyone here who knows how to do this?
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mckoan|away>
eminboydak: the manufacturer gave you a bad advice. "/system/lib/" directory doesn't exist
mckoan|away is now known as mckoan
<mckoan>
eminboydak: and moreover you can't mismatch kernel modules from a kernel to another
<mckoan>
eminboydak: you are still in time to change board manufacturer :-D
sveinse has joined #yocto
zhmylove has joined #yocto
<sveinse>
Is it possible to look up RDEPENDS:xyz from another recipe? I would assume via bb, but I haven't found any viable ones yet.
<zhmylove>
Hey everyone! Is there any way to specify sha/md5 checksums for local file:// ? I've already tried adding `;sha256sum=XXX` and `;name=XXX` + `SRC_URI[XXX.sha256sum]` -- Yocto just ignores that
<sveinse>
I'm trying list every RDEPENDS package recursively in order to generate dependencies do run package_write_ipk on all of them
Daanct12 has quit [Quit: WeeChat 4.3.5]
Minvera has joined #yocto
sa7mfo_ has quit [Quit: Lost terminal]
zpfvo has quit [Remote host closed the connection]
zpfvo has joined #yocto
<rburton>
sveinse: no. if you want to look at rdepends then bitbake's concept isn't accurate: you want to iterate pkgdata
<rburton>
zhmylove: checksums are not validated for local files
<sveinse>
rburton: ok. Hmm. Seems so trivial problem to collect all ipks from a given RDEPENDS hierarchy, but it truly isn't
<rburton>
sveinse: rdepends are generated at build time so asking the parse-time data store isn't useful at all
<rburton>
sveinse: pkgdata contains the final rdepends and is exactly what you want
<sveinse>
Packagegroup provides the dependencies, but it's not enough to simply bitbake it, as the generation of `package_write_*` is not depended on
<rburton>
what do you actually want to do?
<sveinse>
Collect all ipks from a given list of packages, hierachical. Its for collecting uploading to a distro package repo.
<RP>
sveinse: have a look at the runall and runonly bitbake options
<rburton>
sveinse: pkgdata can tell you that, or bitbake your target with a clean deploydir and whetever ends up in deploy will be what you want
<sveinse>
ipk packages aren't built unless they are explicitly used in images
<sveinse>
RP: I tried runall some time back, but it was enormous. More than what I got if I did a bitbake of a packagegroup in a build with empty sstate cache. What is runall doing? Is it world-like?
<RP>
sveinse: the dependency chains are more convoluted than people think
<RP>
sveinse: it looks at any recipe included in the given target and sees whether any of it's dependencies have a write_ipk task and recurses, adding any it finds
<sveinse>
Just to back up for context: I have a packagegroup with a list of RDEPENDS. If I do a complete rebuild from scratch withou sstate I get a collection of ipks that I want. If I repeat the process after removing tmp/ but with sstate cache, I do not get the same set of ipks. Nor if I use --runall. Then I get an even bigger set.
<rburton>
the runnall set is the _complete_ set
<rburton>
as you say, it only builds the ipkgs that is needs at a particular point in time
<sveinse>
And its that (partial) list I'm looking to compile -- to repeat the output from a fresh build
<sveinse>
Making a fake image doesn't work that well either. These packages are for the distro repo and might conflict, so they may not be able to be installed into a fake image.
<sveinse>
It is possible to make tooling outside of bitbake, but I'd hope I could do this in a bbclass or somesuch
enok has joined #yocto
<rburton>
you can either have the partial subset that a particular build wants, or the complete set. you want to runall on the packagegroup. if you can name a package which is built but shouldn't be then identify it
<rburton>
if you don't trust bitbake then pkgdata will be useful and. you can read that outside of bitbake
<sveinse>
I trust bitbake, but I'm curious to why "bitbake packagegroup-x" returns less packages than its --runall all does. What does it exclude in the former?
paulg has quit [Remote host closed the connection]
<sveinse>
The second run of "bitbake packagegroup-x" is an, uhm, feature, of the sstate mechanism and another issue
<rburton>
runall is most likely causing buildtime only dependencies to also be packaged up. but that shouldn't be that many so again i'm curious what the differences are
<sveinse>
I can probably setup a test to see. It'll take me 5-8 hours do to, since I need to wipe the sstate cache for it
<sveinse>
I wonder what others that maintain distro package repos does to collect ipk/deb/rpm files.
<sveinse>
Or are most only building images and stop at that?
paulg has joined #yocto
<rburton>
sveinse: surely you can do the same experiment with packagegroup-boot in core?
<rburton>
also no need to wipe sstate, just wipe tmp
alessioigor has joined #yocto
<rburton>
if you're interested in package feeds and binary distros then i point you at zeddii who is running a project to improve tooling here. this has been discussed a lot in the weekly status calls/mails.
<rburton>
but yes most people don't use a binary feed because they're terrible for production.
<sveinse>
Running `bitbake packagegroup-x`, extracting the ipks, deleting tmp, running `bitbake packagegroup-x` again won't yield the same set of ipks.
Tyaku has quit [Quit: Lost terminal]
<sveinse>
which is the primary cause of the problem
<rburton>
sveinse: what happened before the first bitbake? or are you saying that with a clean tmp, bitbake isn't reproducible?
Xagen has joined #yocto
<sveinse>
rburton: Yes, because say `packagegroup-foo` RDEPENDS bar. On the first build `bar_*.bb` will run everything, producing output ipks. On the second build, however, the RDEPENDS will be satisfied with the setstate from the sstatecache. It will not, however, rebuild the output ipks. Thus they are different.
<rburton>
<cough> runall :)
enok has quit [Ping timeout: 252 seconds]
<sveinse>
So it seems :D
<sveinse>
rburton: Its interesting that yocto isn't used for basis for building binary feeds. It does advertise to be something that builds distros. And most distros have a rich set of additional packages available.
<rburton>
sveinse: sure it can. you bitbake world, and rsync the result :)
<rburton>
if you have thoughts here then please do get involved with the effort to improve it
<rburton>
but in many production situations, a feed is the wrong answer: a proper A/B updater works much better
<rburton>
i don't want a bricked soundbar because i had a power cut whilst opkg was running, for example
<sveinse>
No, but for development communities, having embedded HW systems with rich tooling is expected. You can't fathom how many times our team is asked "but I can do apt install in raspberry pi? Why can't you."
<rburton>
so bitbake --runall && rsync
<sveinse>
FTR, I agree, A/B is absolutely best
<sveinse>
I'm going to test why my --runall is so big
<sveinse>
thank you
<RP>
sveinse: we have two conflicting user groups - those who want everything built when they run "bitbake image" and those who want the things needed for the image. The runall and runtask options were our attempt to try and give people all the options
<RP>
sveinse: I'd be interested to know if runtask does what you want instead of runall
<RP>
sveinse: might be worth a try against your sstate in case that does work
* RP
has a suspicion it might
<sveinse>
I'll post what my findings are. It will take some time thou, since at the present this is our full system. Once I've identified, I can start reducing the problem into something public, like poky.
<RP>
sveinse: the runtask test should be straight forward if you have the sstate and know what the result should look like?
zhmylove has quit [Quit: Leaving]
<sveinse>
RP: With runtask you'd need a list of the recipes you'd want to run do_pacakge_wrike_ipk, not?
aardo has joined #yocto
<RP>
sveinse: no, that would be the -c option. --runtask does something a bit different
<RP>
sveinse: try it with your packagegroup or which ever target you want to reproduce a from scratch build of
<RP>
sveinse: I say this as the person who implemented it
ardo has quit [Ping timeout: 252 seconds]
<sveinse>
testing now with emptied tmp and with populated sstate cache
<RP>
sveinse: I mean runonly, I'm getting confused now
<sveinse>
Alas. I'm on kirkstone on this system
<sveinse>
Should the hashsrv db be wiped when the sstate cache is emptied?
<sveinse>
rburton: What email list can I find the discussions about the improved tooling discussions?
dgriego has joined #yocto
ray-san has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
BenBE has quit [Ping timeout: 265 seconds]
Vonter has quit [Quit: WeeChat 4.3.5]
alessioigor has quit [Remote host closed the connection]
<fray>
I started with the confgi_only=True because in some of my configs parse time is excessive (if I don't need to run a build) but I still need to get some bitbake vars
<RP>
fray: wrong window :)
enok has quit [Ping timeout: 245 seconds]
<fray>
ohh well.. ;)
alessioigor has quit [Remote host closed the connection]
_whitelogger has quit [Ping timeout: 246 seconds]
_whitelogger has joined #yocto
Ram-Z_ has joined #yocto
Ram-Z has quit [Ping timeout: 246 seconds]
mckoan is now known as mckoan|away
florian has quit [Quit: Ex-Chat]
zpfvo has quit [Remote host closed the connection]
rfuentess has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
leon-anavi has quit [Quit: Leaving]
sgw has quit [Quit: Leaving.]
BenBE has joined #yocto
Jones42__ has quit [Ping timeout: 260 seconds]
<fullstop>
good news, everyone, I'm finally migrating from mickledore to scarthgap. \o/
mjm has joined #yocto
florian has joined #yocto
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
jmd has joined #yocto
berton has quit [Quit: Connection closed for inactivity]
rynofinn____ has joined #yocto
mbulut has quit [Ping timeout: 260 seconds]
enok has joined #yocto
ecdhe has quit [Ping timeout: 260 seconds]
<sveinse>
RP: I have some test results: Short summary is that --runall is the way to go for gathering ipk. --runonly does nothing new. It does not trigger the package_write_ipk for depended on packages. So you we're right. Thanks.
<sveinse>
I also found that my previous test runs were flawed, no a "bitbake packagegroup-something" with an empty sstate cache and a subsequent run with populated sstate cache produce the same ipk output. That is, it does not have the files I need. So I withdraw the suspicion that it behaves differently.
ecdhe has joined #yocto
alessioigor has joined #yocto
enok has quit [Ping timeout: 252 seconds]
Starfoxxes has quit [Read error: Connection reset by peer]
alessioigor has quit [Remote host closed the connection]
|Xagen has joined #yocto
Xagen has quit [Ping timeout: 255 seconds]
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
<RP>
sveinse: ok, that is good to know from my perspective at least that it is consistent
mvlad has quit [Remote host closed the connection]
enok has joined #yocto
jmd has quit [Remote host closed the connection]
enok has quit [Ping timeout: 252 seconds]
Kubu_work has quit [Quit: Leaving.]
ente has quit [Quit: Caught SIGSEGV, exiting...]
amitk_ has quit [Ping timeout: 265 seconds]
prabhakalad has quit [Ping timeout: 248 seconds]
prabhakalad has joined #yocto
prabhakalad has quit [Ping timeout: 265 seconds]
prasmi has joined #yocto
prasmi has quit [Client Quit]
prasmi has joined #yocto
prasmi has quit [Client Quit]
prasmi has joined #yocto
prasmi has quit [Client Quit]
prasmi has joined #yocto
frieder has quit [Remote host closed the connection]
<sveinse>
When building for aarch64, are there any real gains in building for this MACHINE on a machine of the same architecture? As opposed to building on an Intel CPU
<sveinse>
RP: Yes, I am too. Consistency is always best.
<sveinse>
I see that some tools (looking at you nodejs) that takes forever and a day to build due to the arm emulation
florian has quit [Ping timeout: 252 seconds]
prasmi has quit [Ping timeout: 276 seconds]
|Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]