smurray has quit [Read error: Connection reset by peer]
darknighte has quit [Read error: Connection reset by peer]
ldts has quit [Read error: Connection reset by peer]
paulbarker has quit [Read error: Connection reset by peer]
darknighte has joined #yocto
paulbarker has joined #yocto
ldts has joined #yocto
smurray has joined #yocto
tp43_ has quit [Ping timeout: 250 seconds]
amitk has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
_whitelogger has joined #yocto
nohit has joined #yocto
kergoth has joined #yocto
frosteyes1 has quit [*.net *.split]
Dracos-Carazza has quit [*.net *.split]
dmoseley has quit [*.net *.split]
stkw0 has quit [*.net *.split]
risca has quit [*.net *.split]
marka has quit [*.net *.split]
RP has quit [*.net *.split]
ak77 has quit [*.net *.split]
tangofoxtrot has quit [*.net *.split]
splatch has quit [*.net *.split]
mithro has quit [*.net *.split]
Fanfwe has quit [*.net *.split]
vquicksilver has quit [*.net *.split]
yocti` has quit [*.net *.split]
wyre has quit [*.net *.split]
splatch has joined #yocto
dmoseley has joined #yocto
yocti has joined #yocto
Dracos-Carazza has joined #yocto
marka has joined #yocto
frosteyes1 has joined #yocto
vquicksilver has joined #yocto
mithro has joined #yocto
vquicksilver is now known as Guest8645
tp43_ has joined #yocto
wyre has joined #yocto
risca has joined #yocto
stkw0 has joined #yocto
rfs613 has joined #yocto
ak77 has joined #yocto
RP has joined #yocto
tangofoxtrot has joined #yocto
Fanfwe has joined #yocto
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
wCPO has joined #yocto
lexano has quit [Ping timeout: 240 seconds]
lexano has joined #yocto
Bardon has quit [Ping timeout: 240 seconds]
tp43_ has quit [Ping timeout: 240 seconds]
tp43_ has joined #yocto
frieder has joined #yocto
goliath has joined #yocto
Bardon has joined #yocto
LetoThe2nd has joined #yocto
zyga-mbp has joined #yocto
d0ku has joined #yocto
eduardas has joined #yocto
goliath has quit [Quit: SIGSEGV]
florian has joined #yocto
tnovotny has joined #yocto
goliath has joined #yocto
bps has joined #yocto
tnovotny has quit [Remote host closed the connection]
leon-anavi has joined #yocto
<LetoThe2nd>
yo dudX
tnovotny has joined #yocto
zyga-mbp has quit [Ping timeout: 252 seconds]
zyga-mbp has joined #yocto
<qschulz>
o/
tp43_ has quit [Ping timeout: 252 seconds]
<kanavin_>
dudes and dudettes
<barath>
are reproducible builds enabled by default? I see the manual talking about them, but not whether they're enabled... I'm trying to debug why a certain package isn't reusing a pre-existing sstate cache mirror, and it seems the hashes are differing. I've beeing climbing down the dependency tree checking each tasks dependency for what hashes have changed...
<barath>
I just got to the point where net-snmp/net-snmp_5.8.bb:do_deploy_source_date_epoch changed hashes between the two builds/machines...
<barath>
I guess the oe layers should be reproducible then (on dunfell)
Guest38 has joined #yocto
<Guest38>
How can you continue to fetch individual recipes when the option: "BB_NO_NETWORK" is active? We have some local repos that should continue to work with the latest version.
<wCPO>
decide to look into systemd support, I think the init script should do the symlinking.
<tlwoerner>
wCPO: awesome! i'm just starting, today, adding support for systemd. i've completely re-worked my patch to use "mount helpers" which allow you to mount and umount zram-backed filesystems *automatically*
<tlwoerner>
so from the cmdline you could do: "mount -t zram tmpfs /hello" and "umount /hello" and it'll all work magically and handle all the extra steps behind the scenes
fleg has joined #yocto
Guest38 has quit [Quit: Client closed]
otavio has quit [Remote host closed the connection]
<tlwoerner>
wCPO: i'll post a v3 soon, but i want to clean up some of it first
<tlwoerner>
oh, and i need to push a small (hopefully non-controversial) patch to oe-core first :-)
argonautx has joined #yocto
<wCPO>
tlwoerner: sounds good. I'm currently trying to figure out how to get the $major and $minor for the original rootdevice with just busybox
<tlwoerner>
oh right... busybox. ideally i'd handle both cases, right now i'm hardcoding the use of util-linux
<tlwoerner>
it was OnkelUlla who gave me the suggestion to use mount helpers, pretty neat stuff!
<wCPO>
Maybe, I should just use util-linux. Should be very easy to implement then
<eduardas>
hello, I need a sanity check: are machine-specific overrides possible only to task appends, but not the tasks themselves?
<eduardas>
i.e. I know do_install_append_<machine> () is possible, but should do_install_<machine> be possible too?
<qschulz>
eduardas: it should work with machine overrides too IIRC
<eduardas>
qschulz: thanks for answering. Still, I can not find the specific place in the official Yocto documentation that would explain how overrides apply to tasks
<eduardas>
although it works, I can not really find any specific place in the docs that makes it obvious the override syntax can be applied to tasks
jwillikers has joined #yocto
<RP>
eduardas: tasks and functions are just variables to bitbake
<eduardas>
RP: thank you. That makes total sense. However, just out of curiosity: is that clearly stated somewhere? I might sound stupid, but that was not totally obvious to me.
<RP>
eduardas: I'm not sure to be honest. Once you understand things, it is hard to read the docs without that kind of knowledge being in the back of your mind. Feel free to open a bug with a suggestion of where it should be mentioned
<eduardas>
I would expect that to kind of be in the concepts section of the bitbake manual or such
tgamblin has quit [Quit: Leaving]
tgamblin has joined #yocto
<qschulz>
eduardas: "Overrides and override-style operators can be applied to any shell function, not just tasks."
<qschulz>
"Similar to shell functions, you can also apply overrides and override-style operators to BitBake-style Python functions."
<qschulz>
but the examples could benefit from having examples with machine overrides that I can agree on :)
kanavin_ has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
kanavin has joined #yocto
goliath has quit [Quit: SIGSEGV]
<barath>
is there a canonical way to debug why a task gets a different sstate between two machines/builds that doesnt require manually "going to the chain" of the depend sub tasks?
<barath>
it feels a lot like something a tool could be written for
<qschulz>
barath: bitbake-diffsig should help, it sometimes does not stop where it should (too early in the dependency chain) so you might need to rerun it from where it stops to get your info
<tlwoerner>
wCPO: but you don't need the $major/$minor for doing zram?
<barath>
thanks qschulz
<barath>
I already run that, but I guess the problem is that the remote sstate files aren't fetched so they're not matching (I have a remote sstate dir served via http and a local one, I guess)
<barath>
so I've run diffsig against individual siginfo files, it tells me which hashes changed, I fetch those
<barath>
but I guess it might be easier to sync with the entire remote sstate dir and then run diffsig against recipe names instead?
<wCPO>
tlwoerner: sorry, I completely missed/orgot that your patch isn't copying the rootfs to a fs backed by zram (my logic is). It is indeed only relevant if your are copying the rootfs to a fs backed by zram
<qschulz>
barath: probably yes
<barath>
alright, thanks
<tlwoerner>
wCPO: ah, interesting use-case
<wCPO>
tlwoerner: yeh, we are doing it for speed and resilience reasons
te_johan has joined #yocto
fleg has quit [Remote host closed the connection]
fleg has joined #yocto
<wCPO>
Assuming I have a recipe needed the vfat kernel module and dosfstools, should I just use REQUIRED_MACHINE_FEATURES += "vfat" or is there a better way?
sakoman has joined #yocto
fleg has quit [Remote host closed the connection]
fleg has joined #yocto
te_johan has quit [Quit: Ping timeout (120 seconds)]
te_johan has joined #yocto
goliath has joined #yocto
bps has quit [Ping timeout: 252 seconds]
te_johan has quit [Quit: Ping timeout (120 seconds)]
eduardas has quit [Quit: Konversation terminated!]
frieder has quit [Remote host closed the connection]
<barath>
A question around architectures and machines... we have defined our own machine, the conf file of which includes (requires) the arch-arm64.inch file
<barath>
I now see various sstate files and ipks using both aarch64 as their arch and some use the name of our custom machine definition
<barath>
can this mixing lead to problems? I dont quite get why some packages (systemd-conf) use our machine name in their names, and some (systemd) use aarch64...
tnovotny has quit [Quit: Leaving]
CarlesFernandez[ has joined #yocto
bps has joined #yocto
bps has joined #yocto
<qschulz>
barath: could yes. if an aarch64 recipe/package depends on a machine-specific recipe/package, a change of machine will trigger a rebuild of the aarch64 package because technically its dependency changed
<barath>
hm
<barath>
well we're not really changing machines as such. we have defined our own machine which requires this arch-arm64.inc base config, and then we always build for either that or a machine based on the tune-core2.inc
d0ku has quit [Ping timeout: 245 seconds]
<barath>
do you mean switching machines in general, or switching between for instance aarch64 and x86-64 arches?
<barath>
if I understand correctly, mixing things would mean first building something for a "pure" aarch64 machine (what would that look like? a machine which is called aarch64?) and then something using our custom machine based on the aarch64.inc config?
yates_home has quit [Ping timeout: 240 seconds]
dev1990 has joined #yocto
florian has quit [Quit: Ex-Chat]
dv_ has quit [Ping timeout: 252 seconds]
Vonter has quit [Quit: WeeChat 3.2]
Vonter has joined #yocto
willo has quit [*.net *.split]
dv_ has joined #yocto
goliath has quit [Ping timeout: 250 seconds]
goliath has joined #yocto
LetoThe2nd has quit [Quit: Connection closed for inactivity]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
Guest9 has joined #yocto
<Guest9>
Hey all...having a weird issue I'm hoping someone can shed some light on. If I add the following line to my .bb file I get an error about license URL being bad. If I remove the line, all is good. Any ideas?
<Guest9>
It doesn't seem to matter what I set OVERRIDES to. If it is in the file, I get that error, if it's not in the file, everything works as expected.
<Guest9>
Oh...on dunfell branch.
camus1 has joined #yocto
camus has quit [Ping timeout: 250 seconds]
camus1 is now known as camus
<kergoth>
Guest9: you should never go overriding the OVERRIDES variable, it contains a hell of a lot more than just architecture.
<kergoth>
Guest9: see meta/conf/bitbake.conf for its value
<jonmason>
Is anyone else getting bit by the "kernel.bbclass: Use full versions for inter-package dependencies" patch?
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
<Guest9>
I was just following the examples in the docs. Can I append to OVERRIDES then?
<zeddii>
jonmason: what's breaking ? I reviewed it as it went in, and was worried about it causing issue.
argonautx has quit [Quit: Leaving]
<Guest9>
When I add the line "OVERRIDES = "blah:blah2" to my .bb I get the following error:
<Guest9>
"ERROR: /home/ht-linux/SynergyII/yocto/sources/meta-arm/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/gcc-aarch64-none-elf_9.2-2019.12.bb: nativesdk-gcc-aarch64-none-elf: LIC_FILES_CHKSUM contains an invalid URL: None"
<Xagen>
i have a patch that is successfully applying, but with fuzz
<Xagen>
it suggests that I can fix this with devtool
<Xagen>
but when i follow the directions, it gives me `ERROR: Something went wrong with source extraction - the devtool-source class was not active or did not function correctly`
<Xagen>
how do i fix devtool so it will work?
<Guest9>
I just tried an "append" to the OVERRIDES variable in my .bb and that seems to work. The hint kergoth gave did the trick. Thanks.
florian has joined #yocto
Guest9 has quit [Quit: Client closed]
<jonmason>
zeddii: all of the BSPs that I set the kernel to not be 5.13 (i.e., 5.10, 5.4, etc) fail
<zeddii>
rpm or ipk ? It is worth chiming into the thread on the mailing list. I asked about pretty much that scenario.
<zeddii>
ahah. I see opkg in the log.
<zeddii>
I was definitely concerned about it.
kanavin_ has joined #yocto
kanavin has quit [Remote host closed the connection]
<zeddii>
hmm. there's already a similar bug report on the mailing list.
<jonmason>
yes, ipk. I changed to rpm and it went fine. And now it's in my sstate...
<zeddii>
While opkg may not handle the situation you describe as well as RPM,
<zeddii>
the package generation or standard image creation
<zeddii>
we should make sure that the full version doesn't cause issues with
<zeddii>
my comment in the thread "
<zeddii>
wow that pasted badly
<zeddii>
anyway. i asked just that.
<zeddii>
so yah, I think that should be reverted if it can't be fixed very quickly.
<jonmason>
since it is there, give the patch author 24h for a fix
<jonmason>
I hate patch reverts
<jonmason>
UK bank holiday. It sure is quiet today
<RP>
jonmason: some of us still have meetings :/
<jonmason>
RP: I'm surprised you aren't in hospital with a broken leg ;-)
<kanavin_>
RP: testing a qemu 6.1 update so you don't need to (it's for the post-release of course)
<kanavin_>
jonmason, I'd rather RP risks breaking a leg all week than wrestles with rust any longer :)
<jonmason>
he might agree with you ;-)
<jonmason>
you can take drugs to get over the pain of a broken leg. No amount of drugs make rust go away
<RP>
jonmason: at least with this event mountain rescue were ready onsite! :)
<RP>
kanavin_: thanks! :)
* RP
remembers there is still a rust bug :/
<jonmason>
RP: start drinking, it'll teach that brain cell to be uppity
<RP>
jonmason: might have to try that!
<kanavin_>
RP: rpm 4.17 update, with transition to sqlite for the database (instead of bdb) and zstd for rpm compression worked beautifully meanwhile, I love seeing (nearly) all green a-full :)
<RP>
kanavin_: I noticed the patch series. I'm assuming that is for 3.5 :)
<RP>
nice it works
<kanavin_>
RFC implied that, yes
<RP>
Never feels good when you reply negatively to several patches in a row :/
<kanavin_>
RP: it's similar to rejecting CVs :( if you do that ten times in a row, you feel like you're an awful person
<kanavin_>
or at least I feel that way
<kanavin_>
and it's just pushing a button in a system, that triggers an automated reply