LocutusOfBorg has quit [Quit: ZNC 1.8.2+deb3 - https://znc.in]
Saur_Home78 has joined #yocto
berton has joined #yocto
MrFrank has quit [Ping timeout: 256 seconds]
Saur_Home81 has quit [Ping timeout: 250 seconds]
LocutusOfBorg has joined #yocto
mvlad has joined #yocto
mbulut has joined #yocto
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
vthor has quit [Remote host closed the connection]
vthor has joined #yocto
xmn has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
amitk_ has joined #yocto
amitk has quit [Ping timeout: 268 seconds]
Jones42 has joined #yocto
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
prabhakalad has quit [Quit: Konversation terminated!]
dancios has joined #yocto
florian has joined #yocto
dancios is now known as dtmrzygl
rob_w has quit [Remote host closed the connection]
dtmrzygl is now known as dancios
jmiehe has joined #yocto
dancios has quit [Changing host]
dancios has joined #yocto
<dancios>
Hi!
<mckoan>
hello
sakoman has quit [Ping timeout: 260 seconds]
prabhakalad has joined #yocto
florian_kc has joined #yocto
sakoman has joined #yocto
ablu has quit [Ping timeout: 256 seconds]
ablu has joined #yocto
florian_kc has quit [Ping timeout: 264 seconds]
<jclsn>
Hi guys
<jclsn>
Seems really hard to remove systemd-timesyncd from the system in favor of chrony. Has someone here ever succeded in doing that?
<jclsn>
rburton: can't upstream my solution yet. It is quite hard. systemd-timesyncd is started by e.g. the timedactl timesync-status command or also via /usr/share/dbus-1/system-services/org.freedesktop.timesync1.service
<jclsn>
When trying to remove timesyncd from the PACKAGECONFIG, net-snmp and other packages fail to build. It is really tricky
<jclsn>
Now I understand what some people hate about systemd. It is so deep in the system, that you can't remove parts of it easily anymore
<rburton>
it makes almost no sense that net-snmp fails to build if you remove timesyncd from systemd. if it it depends on a bit of systemd and you're disabling that bit of systemd then maybe disable the systemd support in net-snmp
leon-anavi has joined #yocto
<rburton>
looks like net-snmp's systemd support is limited to socket activation so there's no reason why turning off timesyncd would cause that to fail
florian_kc has joined #yocto
dancios has quit [Quit: Lost terminal]
ehussain has joined #yocto
vquicksilver has quit [Quit: WeeChat 4.2.1]
vquicksilver has joined #yocto
alperak has quit [Quit: Connection closed for inactivity]
jmiehe has quit [Quit: jmiehe]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
mbulut has quit [Remote host closed the connection]
mbulut has joined #yocto
lexano has joined #yocto
mbulut_ has joined #yocto
mbulut has quit [Ping timeout: 256 seconds]
xmn has quit [Quit: ZZZzzz…]
<jclsn>
It is also not obvious to me why this happens. I can't see some hard dependency. I tried to disable the systemd support of it, but wasn't successful. Maybe I haven't done it right. I changed to PACKAGECONFIG[sytemd] = "--without-systemd". I was also wondering if this would prevent from starting via a systemd unit or something
Minvera has joined #yocto
<jclsn>
I wait, this is only a list that applies whether systemd is enabled/disabled
CrazyGecko has quit [Quit: Konversation terminated!]
Xagen has quit [Ping timeout: 260 seconds]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
mbulut has joined #yocto
mbulut_ has quit [Ping timeout: 256 seconds]
MattWeb has quit [Quit: Client closed]
Jones42_ is now known as Jones42
jmiehe has joined #yocto
MrCryo has quit [Quit: MrCryo]
<Mayur>
Thanks. rburton . i think it worked.
vthor has quit [Remote host closed the connection]
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
<Jones42>
I have some trouble fully grasping the prepare/populate sysroots tasks. Can someone confirm that this sentence (from the singleindex) is correct?
<Jones42>
"When a recipe B DEPENDS on A, it means what is in SYSROOT_DIRS will be copied from D of the recipe B into B’s SYSROOT_DESTDIR that is “${WORKDIR}/sysroot-destdir”."
<rburton>
no
<rburton>
as part of the build a recipe, it builds both the target packages and the sysroot (as you said, SYSROOT_DIRS defines that installed subset that is the sysroot).
<rburton>
DEPENDS="a" means to pull a's sysroot into the current recipe's WORKDIR/recipe-sysroot
<rburton>
or file a bug, but a patch would be great
<Jones42>
rburton: I'll send a patch then! But just to be sure, I only have to change one character, right? i.e.
<Jones42>
"When a recipe B DEPENDS on A, it means what is in SYSROOT_DIRS will be copied from D of the recipe ~B~ A into B’s SYSROOT_DESTDIR that is “${WORKDIR}/sysroot-destdir”."
<rburton>
hm i'd reword it more
<rburton>
but yes the short version is s/B/A/
<Jones42>
would you mind giving me an example? I'll happily send the patch, but rewording is really out of my comfort zone, tbh
<Jones42>
otherwise I'll just send the minimal patch and wait for someone else to complain ;-)
<rburton>
send the minimal patch, its an improvement!
<Jones42>
alright, thanks! :-)
<rburton>
my brain isn't in 'write coherent english' mode right now :)
* RP
feels simply like "my brain isn't"
tec has quit [Quit: bye!]
tec has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
mckoan is now known as mckoan|away
rjones2 has joined #yocto
Mayur has quit [Quit: Client closed]
florian has quit [Quit: Ex-Chat]
Articulus has quit [Quit: Leaving]
amitk_ has quit [Ping timeout: 268 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Jones42>
The do_populate_sysroot task copies a subset of these files (from D) into ${SYSROOT_DESTDIR}. - alright until here
<Jones42>
"A shared state (sstate) object is built from these files and the files are placed into a subdirectory of build/tmp/sysroots-components/."
<Jones42>
^ shouldn't that be part of "Stage Two" which covers do_prepare_recipe_sysroot ?
<fray>
I don't remember if the sysroot-components is done as part of the staging or as part of prepare_recipe_sysroot for another one. I know that prepare_recipe_sysroot builds up the components in a recipe specific directory, but probably not the generic sysroot-components?
<rburton>
it says prepare_recipe_sysroot links from there
<fray>
there are two different ones. There is the WORKDIR and the generic version. The WORKDIR is package specific and definitely populated in prepare_recipe_sysroot.. but the generic one though I'm not sure about
<Jones42>
rburton: ah, true. but how do things end up in there then?
<Jones42>
fray: I think the tmp/sysroots-components is the only directory. I haven't seen any WORKDIR sysroots-components yet
mvlad has quit [Remote host closed the connection]
<fray>
tmp/sysroot-components is a common (shared) directory where stuff is extracted/copied. But inside of a WORKDIR, we don't use sysroot-components, it uses sysroot-native... in the WROKDIR
<fray>
I just don't remember how all of that is populate.. it's changed since I last had to dig into the internals
<fray>
the WORKDIR/sysroot-native are links to the tmp/sysroot-components (if I remember right)
<fray>
(and I might be off on the directory names)
<Jones42>
hm... so can I understand the tmp/sysroots-components as the method to "bypass" the recipe isolation between thw WORKDIRs?
<fray>
sysroot-components is an optimization, in that multipel workdirs can all link to the same component avoiding having to re-extract and validate stuff..
<fray>
additionally it is used by a few external scripts (like runqemu) to find select components
<fray>
but a build process (running in WORKDIR) should ONLY access WORKDIR specific items
<Jones42>
but then why not link directly to the (source recipe's) sysroot-destdir?
<JaMa>
Jones42: populate_sysroot(_setscene) populates TMPDIR/sysroot-components, prepare_recipe_sysroot populates RSS (recipe-sysroot, recipe-sysroot-native) with hardlinks to TMPDIR/sysroot-components/<all-task-dependencies>
leon-anavi has quit [Remote host closed the connection]
<fray>
WORKDIRs are temporary.. use rm_work and they go away as soon as that recipes build is complete
<Jones42>
hmm... alright, it's starting to make sense, thanks
<rburton>
each recipe produces output files in its own WORKDIR. first it do_installs into D (workdir/image) and that gets turned into packages (workdir/package) and sysroot. the final sysroot goes via sstate into tmp/sysroot-components. then when another recipe is built, each of its depends sysroots from sysroot-components is hardlinked into that other recipe's workdir/recipe-sysroot. this way every recipe _only_ sees its explicit dependencies.