<bq>
JPEW, but this means if I set the reprod rimestamp it'll rebuild even with kernel from git
<JPEW>
bq: Correct... I guess you could try to second guess what the command will do, but that seems brittle
<JPEW>
Ok, I used `cargo bitbake` to generate a list of crates to put in SRC_URI... and it's a parse error :/
<JPEW>
`Could not find a fetcher which supports the URL: 'crate:`
<JPEW>
... but only when I also have a git:// repo in SRC_URI?
troth has quit [Ping timeout: 264 seconds]
<RP>
JPEW: the crate fetcher can't cope with AUTOREV I think
<RP>
JPEW: I have an open bug for this. It is due to the fetcher module not being imported at the right point as the fetcher is in an external layer and not in bitbake itself
xmn has joined #yocto
<JPEW>
Ok. I'll see if I can make it do the same as our custom fetcher
vd has quit [Quit: Client closed]
rsalveti has quit [Quit: Connection closed for inactivity]
<michalkotyla>
Hi, which hash function is used as default to password inside the /etc/shadow in poky honister? I need to use usermod in my recipe, in the old version of my layer (thud) I do this like: -P cleanpassword user, but I see that now patch for using clean passwords is dropped. It is SHA256, 512, or something else?
<kanavin>
(for once, I am being pedantic about whitespace :) and insist on having spaces there
<RP>
kanavin: ah, ok. I can tweak that. The other script doesn't pick that up :)
<RP>
kanavin: patch queued
<kanavin>
RP: unfortunately I couldn't force mandatory [reason] or [submitted where], there's too much to fix then
<RP>
kanavin: one step at a time
<kanavin>
so there's still plenty of inappropriates without reason, or submitteds without reference
<RP>
kanavin: we used to have no data at all
<kanavin>
RP: fedora/rhel still doesn't
<kanavin>
RP: I wonder if it's a part of their 'vendor lock in' strategy
<kanavin>
have hundres of patches with no metadata ---> profit
<RP>
kanavin: perhaps. it is also so much easier not to send upstream
<RP>
kanavin: As you're finding, there are a surprising number of patches we can simply drop
<RP>
even in gcc :)
goliath has joined #yocto
<kanavin>
RP: yes. Where I am now is: I reviewed all of the pending patches size 4000 bytes or more (except the toolchain stuff). Next I'll be sending my own remaining pending patches, so I can claim the moral high ground! :D
<kanavin>
there was only a dozen of 4K-5K sized patches, but significantly more 3-4K sized ones, so that's where I stopped for now :)
<RP>
kanavin: I did audit libtool and a first pass over the gcc ones
<kanavin>
and a maaaaassive long tail of even smaller ones
<RP>
kanavin: right, but you're right the bigger ones are more likely to be painful at upgrade
<kanavin>
RP: yes, the small ones tend to change only a single line, or a single chunk, or several single lines. We should weed out the ones that change several multiline chunks.
prabhakarlad has joined #yocto
florian_kc has joined #yocto
<kroon>
RP, I suppose tweaking the "Upstream-Status" tags in the gcc patches should not cause a rebuild of glibc/kernel etc ?
<kanavin>
kroon, if hashequiv works correctly then it should not
<kanavin>
that's exactly what was in mind when implementing it
<kroon>
right
<kroon>
but that seems to be the case on my setup 8-/
<ernstp>
Is there a good Yocto way to debug/trace python functions? Following what a do_package in python does for example
manuel1985 has joined #yocto
<kanavin>
I have been wondering the same. I guess it comes down to how to you trace python script execution in general.
<kanavin>
I guess "insert more debug prints into the script" is not the answer you seek :)
<qschulz>
ernstp: ${WORKDIR}/temp/run.do_package
<kanavin>
the question is, do_package tends to be silent about what it's doing and can go on for minutes and minutes and minutes
<kanavin>
how do you make it more chatty, e.g. printing what is being executed (like shells can do)
<qschulz>
ah like set -x but for python scripts
<ernstp>
qschulz: yeah it's quite empty for do_package since it's all python
<qschulz>
ernstp: the run isn't but the log yes, I didn't read kanavin 's answer, thought it was about a different topic. I unfortunately don't have any idea how to do that kind of tracing
<ernstp>
could have more bb.debug()
<ernstp>
but maybe they have a slightly different purpose..
<qschulz>
ernstp: yeah but you can't force layers to do that with their own recipes/classes so the question remains :)
xmn has quit [Ping timeout: 256 seconds]
<RP>
kroon: it will rebuild gcc itself but then things depending on gcc shouldn't rebuild
<RP>
kanavin: the logs are a lot more verbose
<RP>
kanavin: I suspect to bitbake XXX -v -c package would work
pgowda_ has quit [Quit: Connection closed for inactivity]
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
<nad>
Hi. What could be the "proper" way to get rid of a pkg_postinst_ontarget task from recipes I inherited ?
<nad>
Removing the script from ${sysconfdir}/rpm-postinst leads to such output "The following packages could not be configured offline and rootfs is read-only: []"
<nad>
of course, importing the recipe do temporarily the job
<qschulz>
nad: pkg_postinst_ontarget() {:} in a recipe appends
tnovotny has joined #yocto
tnovotny has quit [Client Quit]
tnovotny has joined #yocto
dvorkindmitry has joined #yocto
<dvorkindmitry>
in what branch ":append" and ":remove" ops has been introduced?
<qschulz>
honister
mvlad has joined #yocto
<qschulz>
dvorkindmitry: and it was backported to dunfell and hardknott
<dvorkindmitry>
qschulz, good news! so I can just pull "dunfell", update my recipes and I will be compatible?
<qschulz>
yes
<qschulz>
dvorkindmitry: technically both syntax will work up to honister
<qschulz>
so you can have mix and match in layers
chep has quit [Ping timeout: 268 seconds]
<dvorkindmitry>
qschulz, in hardknott old syntax gives unnoying errors
<dvorkindmitry>
in honister, sorry\
chep has joined #yocto
<qschulz>
dvorkindmitry: "up to honister" :)
<qschulz>
my bad, can't read, what is wrong with me
<qschulz>
loooong friday.. you corrected yourself just after
<qschulz>
but yeah, honister does not support both syntax
<dvorkindmitry>
yea. sorry and thank you
<qschulz>
it's alright, I expect we're going to have lots of questions aorund this new syntax :)
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<kroon>
RP, JPEW, I do "bitbake strace", then change the cover-letter in one of the gcc patches, then run "bitbake strace" again, and gcc -> glibc -> strace is rebuilt. Any of you got any tip on how to debug hashserv and see why this is happening ?
codavi has joined #yocto
<JPEW>
kroon: if you capture the depsig files in ${T} between each build, you can diff them
<kroon>
JPEW, ok, ${T}, you mean TMPDIR ?
<JPEW>
No, $WORKDIR/temp iirc
<JPEW>
Afk, so not exactly sure :)
<kroon>
JPEW, and you mean the "depsig" files for strace ?
<JPEW>
GCC and glib are the more interesting ones
<JPEW>
Hashequiv uses the hash of the depsig files to determine if two sstate outputs are equivalent, so if they differ between the two runs, that would explain it
<kroon>
JPEW, ah ok
<JPEW>
Ideally for trivial changes, they would be the same, but things happen :)
<kroon>
JPEW, so looking at the diff between gcc's depsig.do_populate_sysroot.xxx is the interesting one ?
<JPEW>
Ya, probably. I'd diff them all just to make sure
<kroon>
cause if im reading those correct cc1 and cc1plus binaries dont have identical checksums
florian_kc has quit [Ping timeout: 260 seconds]
<kroon>
JPEW, ok
<JPEW>
That would do it
<JPEW>
If you can figure out why they are different, you can probably fix it
<JPEW>
A lot of hashequiv problems like this are reproducible build problems in disguise
<kroon>
JPEW, yeah, I guess I'd need to extract the binaries from sstate and compare them then
<kroon>
or just keep a copy after doing the first build
<kroon>
and we should replace buildhistory with versioning those depsig files!
<JPEW>
kroon: I recommend diffoscope for diffs. You can probably directly diff the two sstate archives
<JPEW>
Ya, the depsig files could have a lot more uses
<kroon>
JPEW, ok ill try
sakoman has joined #yocto
ar__ has joined #yocto
davidinux has quit [Ping timeout: 264 seconds]
davidinux has joined #yocto
codavi has quit [Ping timeout: 260 seconds]
<kroon>
sigh. vanilla diffoscope in fedora 35 is not working for me
paulg has joined #yocto
<kroon>
but yeah, cc1 and cc1plus differ
<kroon>
and looks like its binary data that is differing
amitk has quit [Ping timeout: 268 seconds]
<kroon>
Comparing output of "readelf -a" for both binaries states that Build ID is differing, which would explain one of the two diff chunks I see
amitk has joined #yocto
<manuel1985>
Is there a canonical place to put docker compose files on the filesystem?
<manuel1985>
libvirt puts VM images to /var/lib/libvirt/images, so would choose /var/lib as well
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
amitk has quit [Ping timeout: 264 seconds]
amitk has joined #yocto
<JPEW>
kroon: If it's only the build ID thats different, it usually means the difference is in the stripped debug data
<kroon>
JPEW, its not only the build id though, there is 16bytes that differ
<JPEW>
kroon: Ah, taht would do it
<kroon>
Im trying to compare the stash_build_dir sstate tasks
<JPEW>
timestamp maybe?
<kroon>
Ive got no clue what those 16 bytes are..
<sgw>
Morning all
<tgamblin>
Is there a way to force a LICENSE override for a recipe that won't generate more warnings? I am looking specifically at hdparm, which has LICENSE, LICENSE_${PN}, and LICENSE_${PN}-dbg lines. The latter two lines are still resulting in warnings during build even if I do e.g. LICENSE_forcevariable_hdparm = "..."
<sgw>
RP: around, not sure if you say my comment about the kernel spdx status yesterday?
paulg_ has joined #yocto
<sgw>
qschulz: yeah, was not exactly sure which order it was, but when done as hdparm_forcevariable we get: WARNING: Variable key LICENSE_${PN} (BSD) replaces original key LICENSE_hdparm (BSD-2-Clause & GPLv2 & hdparm).
<qschulz>
sgw: LICENSE_${PN}_forcevariable_pn-hdparm from a local.conf or LICENSE_${PN}_forcevariable from a bbappend then
<qschulz>
not tested, just an idea
<sgw>
Oh that's a good on, I will give it a try
<kroon>
JPEW, ok diffoscope is working after installing apt
<JPEW>
kroon: I think you can install it though pip alos?
<kroon>
JPEW, but it is taking a long time
<JPEW>
Ya, it might
<kroon>
JPEW, yeah but its only show the same hex diff
<kroon>
JPEW, should I run it on the stash build dir perhaps
<JPEW>
kroon: Probably not helpful then
<JPEW>
Sorry :/
<tgamblin>
qschulz: sgw: that seems to work
dev1990 has joined #yocto
<kroon>
Im hoping some object file will show up
<qschulz>
tgamblin: :muscle:
<qschulz>
:muscle_arm:
<qschulz>
eh, no emoji for you then :)
kiran has joined #yocto
<sgw>
JPEW: ross: did you see any issues with vim LICENSE?
<tgamblin>
qschulz: thanks!
<JPEW>
sgw: I seem to have missed the email
<qschulz>
tgamblin: my pleasure!
<kroon>
JPEW, is it a good idea to tell diffoscope to ignore modified timestamps when diffing (if possible) ? or do you just run "diffoscope a b" ?
<nad>
qschulz: thank for reply. It does not work unfortunately. Even if the task is rewritten as empty, file is created and QA Issue pop up
<JPEW>
kroon: It depends
<sgw>
JPEW no email, just some findings we are discovering running the SPDX verify over many packages. tzdata has issues also PD is not a vaild SPDX License identifier. I have to analzye the rest of the issues, I will send email.
<JPEW>
OK
<sgw>
JPEW: I am still looking the issue of how to deal with the kernel source package from work-shared and getting the "generated" source
<kroon>
RP, JPEW, any of you familiar with build/gcc/cc1plus-checksum.c ? I think the unsigned char executable_checksum[16] in there is the culprit
<JPEW>
kroon: Ah, I wonder if that includes the debug data?
<JPEW>
kroon: Maybe the difference is in the debug data (this is pretty common, which is why I keep mentioning it)
<kroon>
JPEW, hmm how would I check that ?
<JPEW>
kroon: Fine the debug symbols for the executable? I don't remember exactly where they are
<RP>
sgw: I saw you said it was roughly working?
<RP>
sgw: but fun with shared-work
tre has quit [Remote host closed the connection]
<RP>
kroon: That brings back some memory fragment, maybe worth looking at the mailing list as I think it was mentioned
<RP>
kroon: look for "[OE-core] [PATCH] gcc: Improve reproducibility" from October. Patch needed rework but was never resubmitted
<RP>
kroon: it may or may not be related
<kroon>
RP, ok, thanks ill check
bps has quit [Ping timeout: 265 seconds]
tnovotny has quit [Quit: Leaving]
<kroon>
RP, yeah its definetly in that area. ill see what i can find
<sgw>
RP: very roughly, I have the debug info getting parsed and the split/strip working, it did require changes to package.bbclass. Yes loads of fun now with shared-work and finding "generated" files. I know there is a kernelsrc.bbclass that's used by perf, is there a way to generate the kernel-src/linux-yocto-src package that I am missing? And then there is still the modules!
* sgw
afk for a bit
<RP>
sgw: kernel source is done through kernel-devsrc, a separate recipe and is not the complete source
<RP>
zeddii: here we go again :)
<moto-timo>
🍿
<kroon>
RP, well, that proposed patch removed the file "checksum-options" from being included in the checksum, but in my build both of those are identical in the two builds. so it must be something else in here
<RP>
kroon: ok, I did wonder since you are likely rebuilding in the same path
<RP>
kroon: might give some hint as to another issue, I don't know.
<kroon>
RP, yeah. oh yes, there are more things included in that checksum, ill see what differs
<kroon>
and checksum-options is already being filtered out in gcc-cross.inc
kaitsh has joined #yocto
<kroon>
It is all the .a files that are included in the checksum that differ: libcommon.a, libcpp.a, libiberty.a, etc
<kroon>
probably .o added in nondeterministic way
<kroon>
well, the timestamps of the .o files is different
<kroon>
order looks to be the same according to diffoscope
<kroon>
RP, JPEW, any suggestion how/if we want to solve this ?
* kroon
is afk for a while
<kaitsh>
Hey guys, what is the best way to configure a fallback url. I want to fetch a file from a server, but if this fails, I'd like to use a local file as fallback.
<qschulz>
kaitsh: not sure for local files, but you can setup a MIRROR
<qschulz>
you can use file:// for local files I checked in PREMIRRORS which is the same syntax
<qschulz>
if you don't want to mirror git repos, just use the DL_DIR of a succesful Yocto fetch/build. Otherwise run the BB_GENERATE_MIRROR_TARBALL and use this output
<qschulz>
but it's documented :)
<kaitsh>
qschulz: Good idea, thanks! Somehow I thought MIRRORS only work with ftp://, http://, or https:// calls
<JPEW>
moto-timo: I got squeekboard to compile. What a mess!
florian has quit [Remote host closed the connection]
<moto-timo>
we will eventually have enough minds thinking about rust that we will streamline this toolchain
<JPEW>
Ya
<khem>
ninja uses many make systems as build generators e.g. CMake, make, and meson just falls in same line I guess
<khem>
JPEW: I guess meson is delegating the rust build+packaging+dependency tracking to cargo
troth has joined #yocto
<RP>
JPEW: the fetcher "fix" is quite neat but I think we need to do better than this with some kind of proper API
leon-anavi has quit [Quit: Leaving]
<JPEW>
khem: ya, and annoyingly in this case it is dynamicly generating Cargo.toml in meson
<JPEW>
RP: fair. That's just the "hack" we've been using for years on our custom fetcher so we didn't have to modify bitbake
<kroon>
RP, JPEW, do you have any comment on the diffing timestamps in .a files above ?
<kroon>
I know there is a -D flag one can pass to 'ar', but its not used in my build
<RP>
kroon: we should probably stop it using timestamps
mckoan is now known as mckoan|away
Tokamak has quit [Read error: Connection reset by peer]
<khem>
JPEW: Do you have plans for using phosh for some stuff at work or just fun stuff ?
bps has quit [Ping timeout: 264 seconds]
* zeddii
reads
<zeddii>
sorry. I've been buried (and failing) to get the actual technical work done for my presentations at the summit, much less working on the slides.
<zeddii>
so I've been ignoring IRC for the most part
* zeddii
curses networking between his test machines
* paulg
hands zeddii two new soup cans and some string
<paulg>
and a 300 baud modem for each end
<zeddii>
seriously though. I still haven't made it to testing the actual software
<zeddii>
I just needed fully routable networking between the VMs, and had to fixup all the OverC macvtap crap to get it just working some now
<zeddii>
I can ssh between the VMs, so next is CNI networking.
<zeddii>
good times
<paulg>
sounds keyboard smashingly fun times.
<zeddii>
one almost died, yes.
<zeddii>
lets just say the slides won't be done much before my talks ;)
<kroon>
RP, ok
<khem>
I have clang-native rust-native and llvm-native and linux-taspberrypi compiling all in parallel wow, should I call fire deptt soon 🙂
<khem>
have llvm compiled for three different big tools is something to solve
Tokamak has joined #yocto
rfuentess has quit [Remote host closed the connection]
bps has joined #yocto
bps has joined #yocto
<kroon>
RP, i suppose binutils-native isnt used when building gcc-cross ?
<kroon>
RP, cause I think we pass "--enable-determistic-archivers" when compiling binutils-native
bps has quit [Ping timeout: 256 seconds]
<khem>
kroon: right. its primarily use is uninative
<kroon>
khem, ok
<khem>
and binutils testsuites too
<JPEW>
khem: no, not for work. Looking for sato a replacements
<khem>
OK, I wondered if there were UIs which were viable in commercial settings that could be useful, right now I think there are not many good options
<khem>
browser based UIs are quite popular
<khem>
flutter is interesting, I see canonical/ubuntu working on it quite a bit,
<sgw>
RP: back, Ok, I will dig into kernel-devsrc (clearly I forgot about that one), zeddii, I am trying to build SPDX data for the kernel as you know and I need to deal with the combo of upstream source and "generated" files!
<zeddii>
they can be regenerated from devsrc.
<zeddii>
but can't you just look at ${S} ?
nad has quit [Quit: Client closed]
<zeddii>
the generated files in in ${B}, but everything else in ${S}
<zeddii>
s/in in/are in/
<sgw>
zeddii: Ok, I will dig, I have to see exactly where create_spdx is looking, I used the cfg/debug/debug_info fragment and have the debug_info being generated, split and striped (not booted), just making sure the basic packaging is working so far.
<sgw>
No resource (time/size) data yet
eloi1 has joined #yocto
<zeddii>
looks like ${S}, which is work-shared.
<zeddii>
but with the build split, generated bits are in ${B}
<sgw>
${S} might point to the source, but create_spdx is not finding the source on disk, it is getting the debug_info file data correctly, which is the first step.
<sgw>
I am digging, in my normal slow plodding pace!
<kroon>
RP, JPEW, but I don't understand this. Has gcc never been reproducible in OE ?
<JPEW>
kroon: it might be triggered by untested conditions, such as rebuilding without a clean sandbox
<JPEW>
There are other known cases where that can cause non reproducible builds
eloi1 has quit [Ping timeout: 264 seconds]
<kroon>
JPEW, what the heck does this mean... diffoscope when comparing the two .a: the .o files have zero timestamps now when passing -D, but the timestmap for folder "/" differs according to diffoscope
<kanavin>
Alex's pending patches today 42 -> 38
<kanavin>
moral high ground is getting closer \0/
<kroon>
JPEW, and so the sha256sum's of the two .a therefore differ. but what is "/" in a .a-ardchive..
<kroon>
oh, maybe its ranlib doing stuff..
<kroon>
yeah probably need a D there too :-/
<JPEW>
kroon: not sure, sorry
<JPEW>
RP: that meson rust patch in master-next doesn't work for cross-compiling. Would you rather remove it and I'll send a V2, or make a new patch to fix it
jmiehe has quit [Ping timeout: 240 seconds]
<kroon>
JPEW, yeah that was it. both "ar" and "ranlib" needs D
<RP>
JPEW: I can drop it and go for a v2
<kroon>
still im surprised, because I cant find anything in the history, so it looks like gcc has never been reproducible
<RP>
kroon: we test target reproducibility, not so much cross/native binaries since they depend on host gcc
<RP>
kroon: the on target gcc binary *is* reproducible
<kroon>
RP, yeah, i guess that because binutils is built with --enable-deterministic archives
<RP>
kroon: sadly if gcc-cross doesn't reproduce, that affects hash equivalence effectiveness
<RP>
kroon: so we need that in the cross case? or the issue is binutils from the host?
<kroon>
RP, i started looking into this because of the gcc patch upstream status tag cleanups. it forced all my target packages to rebuild, which seems unnecessary
<kroon>
so yeah gcc-cross didnt reproduce
<RP>
kroon: you're right, it shouldn't do that. Sadly I've only been able to push things so far with the reproducibility work and so on :/
<RP>
kroon: it sounds like a new test case we should add too once we get that working
<RP>
kroon: I get a little frustrated everyone just wants everything to work so I appreciate you digging into it
<kroon>
RP, yeah of course, well fix it.
<kroon>
RP, no problem, I hope upstream gcc would also want to be reproducible
<vd>
can you control the bitbake output during a build? In an interactive environment, there's nicely redrawn progress bars, but in a non-interactive environment (CI/CD), lines are printed every X seconds, which generates unnecessary long logs
<kroon>
RP, s/well/we will/
<kroon>
:-D
<RP>
kroon: :)
<RP>
vd: There is code in knotty (the terminal UI) which calls istty() and reacts accordingly. Sounds like your CI is trying to be too clever about pretending to be an interactive terminal. Do "bitbake XXX | cat" ;-)
davidinux has quit [Quit: WeeChat 2.8]
<vd>
RP: is there a bitbake variable I can set to avoid such terminal trickery?
bps has joined #yocto
<vd>
RP: the | cat trick won't do it I think, because it stills erase/reprint percentages e.g. "Parsing recipes: 57% || ETA: 0:00:39", which prints a new line for each update
<vd>
still erases/reprints*
<RP>
vd: no variable to do it
chep has quit [Ping timeout: 260 seconds]
<RP>
vd: the progress bars shouldn't be displayed in the non-interactive mode
chep has joined #yocto
<vd>
RP: you still have clear/reprint in non-interactive mode
<RP>
vd: that sounds like a bug then :/
<vd>
RP: I think so. My CI/CD logs have hundreds of lines like "Initialising tasks: 87% || ETA: 0:00:00"
<moto-timo>
michaelo: is there a way to use variables in Sphinx, e.g. for the linux version that is repeated multiple places in my docs? I know we did things with entities in the old docbook worfklow
<moto-timo>
michaelo: my google fu is not being useful yet
florian has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
chep has quit [Ping timeout: 268 seconds]
chep has joined #yocto
<RP>
vd: It is strange that our autobuilder doesn't have those
<RP>
moto-timo: isn't that what poky.yaml is for?
<moto-timo>
RP: Right! I totally forgot! THANK YOU
<moto-timo>
vd: RP: I see that sometimes locally too. My hunch is something about the console/tty settings?
* moto-timo
completely forgot what we did in Jenkins 4 years ago
<JPEW>
RP: So, how would we make the crate fetcher have a better API? My first thought is that the SRCPV stuff could be made better (since right now only one "custom" fetcher will work)
<moto-timo>
JPEW: I suspect RP means a general fetcher API in bitbake itself?
<JPEW>
Ah, like move the crate fetcher into bitbake?
<moto-timo>
JPEW: that was my interpretation/hunch
aleblanc has quit [Remote host closed the connection]
aleblanc has joined #yocto
aleblanc has quit [Ping timeout: 256 seconds]
<RP>
JPEW: that would be one way, the other would be some sort of bitbake API to add other fetcher modules
<JPEW>
RP: Right. getting the registration early enough would be the tricky part
ecdhe has joined #yocto
<RP>
JPEW: and in all the different contexts
<JPEW>
Is there a reason the cargo fetcher wasn't put in bitbake in the first place?
<moto-timo>
JPEW: hold over from meta-rust porting
<paulg>
yay! moar rustz!
sakoman has quit [Quit: Leaving.]
<moto-timo>
☢️
<moto-timo>
No rust emoji lol
<moto-timo>
⚙️
<JPEW>
🦀
<moto-timo>
Ahhh yes!
<JPEW>
Given the current implementation has some short comings, moving the crate fetcher to bitbake seems the cleanest solution?
* JPEW
didn't follow the history of rust integration... not trying to rehash any old stories
<JPEW>
moto-timo: Is there a reason to have core-image-phosh and core-image-phosh-gnome?
florian has quit [Ping timeout: 264 seconds]
florian has joined #yocto
<moto-timo>
JPEW: yes, core-image-phosh is a "core-image-sato" clone. core-image-phosh-gnome is pure GNOME apps
<JPEW>
moto-timo: K
<moto-timo>
JPEW: different goals. one is attempting to replicate sato as is. the other is trying to replicate what Purism/Librem5 might have from GNOME
<JPEW>
moto-timo: Makes sense
<JPEW>
moto-timo: Should we include squeekboard and gnome-control-center in core-image-phosh? The latter is required for the wifi/networking bar at the top of phosh to function
<moto-timo>
JPEW: that was my original intent, as long as squeekboard isn't a bad citizen... I never tried it since I failed to get it to compile lol
<moto-timo>
JPEW: probably some kind of packagegroup-phosh-essential or similar?
<JPEW>
Sounds good
* moto-timo
overengineers things again
<JPEW>
I'll be testing squeekboard as soon as this image finishes flashing to the rapsberry pi
<moto-timo>
I'll probably get to it on the weekend. kernel-lab is still needing some love
<JPEW>
np
<RP>
JPEW: the fetcher was phase two of the rust merge, nobody has looked at it yet
<moto-timo>
also, I had some wonky issues on QEMU. Like apps would be off the screen
<JPEW>
Ya, it seems better on hardware
<moto-timo>
and the PIN screen was not complete... like the canvas is not scaling properly on QEMU
<JPEW>
Ya, I wonder if that's some virtgpu problem
<moto-timo>
(part of the list of TODO items)
<moto-timo>
yeah, probably
<moto-timo>
it was working so well on rpi4 that I kind of ignored it for now
<moto-timo>
I only recently got gl working on my qemu host anyway, so I might be having <cough> NVIDIA </cough> drivers issues etc. or just configuration
<RP>
JPEW: I think the issue is the crate fetcher may not meet all our fetcher requirements :(
<RP>
JPEW: I don;t remember exactly though
<moto-timo>
:(
<moto-timo>
these "language fetchers" are begging for some love
bps has quit [Ping timeout: 268 seconds]
<moto-timo>
and don't get me started about python wheels
<alex88>
moto-timo, wait, why u-booot-env? shouldn't u-boot be enough?
<alex88>
oh
<moto-timo>
alex88: no, for embedded systems we split things into smaller packages so you only get what you asked for
<moto-timo>
no cruft
<moto-timo>
(less cruft)
<alex88>
I see, did something change regarding that from hardknott and honister?
<moto-timo>
do a git blame on that file
<moto-timo>
(teach a man to fish)
<alex88>
oh yeah sure you're right, no I thought for a moment that maybe the previous version included it anyway.. didn't think about u-boot.inc changed
<alex88>
(previous version of yocto included it anyway even if not in FILES-${PN})
<alex88>
hardknott had the same condition, gatesgarth too... not sure then.. maybe some other recipe was including the env package then
<alex88>
thanks a lot moto-timo!
<moto-timo>
you're welcome
<moto-timo>
might have been a change in meta-raspberrypi too? don't know
<moto-timo>
we do tend to make things more explicit over time
<moto-timo>
as the cruft gets caught by more eyeballs
<alex88>
totally in favor of that, I just need to get better at finding the why things happen
<moto-timo>
bitbake -e <foo> , bitbake-getvar, oe-pkgdata-util are your friends
<moto-timo>
and sometimes bitbake -DDDD
<alex88>
got it, very helpful!
kaitsh has quit [Quit: WeeChat 3.1]
mvlad has quit [Remote host closed the connection]
chep has quit [Ping timeout: 268 seconds]
chep has joined #yocto
<kroon>
JPEW, depsig.* arent generated when building from sstate ?
<JPEW>
kroon: No
<kroon>
ah
<JPEW>
RP and I have discussed doing something like that, since it would open some interesting options
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
ar__ has quit [Ping timeout: 256 seconds]
<JPEW>
moto-timo: squeekboard seems find... looks like by default it only appears when the user presses the keyboard icon in the lower left of the screen?
<JPEW>
There might be some support for applications to make it pop up on their own, but either none of the ones I've tried are doing that or there is some flag that prevents it when the do
<moto-timo>
JPEW: that’s great news and expected behavior.
<moto-timo>
JPEW: I think kanavin said the keyboard was coming up any time a user input field got focus?
<moto-timo>
I can’t wait to try it this weekend!
<JPEW>
moto-timo: It doesn't appear to popup unrequested?
<JPEW>
But... that could just be the applications I'm try
<JPEW>
*trying
<JPEW>
I know the wayland protocol they are using supports that sort of thing
<moto-timo>
Maybe they fixed something!
<moto-timo>
One thing I am wondering about is the mobile adapted or whatever tab vs. the other apps. Like epiphany is in the top tier and everything else below the line
<moto-timo>
My Google fu didn’t come up with anything yet
xmn has joined #yocto
<moto-timo>
Probably some API or interface requirements
jmiehe has joined #yocto
<JPEW>
One would hope GTK dealt with that mostly transparently
<moto-timo>
One would indeed
Gaffel has quit [Quit: What's that?]
bps has quit [Ping timeout: 268 seconds]
florian has joined #yocto
kiran has quit [Ping timeout: 240 seconds]
chep has quit [Ping timeout: 256 seconds]
chep has joined #yocto
sakoman has joined #yocto
Gaffel has joined #yocto
adrian__ has joined #yocto
adrian_ has quit [Ping timeout: 256 seconds]
adrian__ has quit [Ping timeout: 264 seconds]
Gaffel has quit [Quit: What's that?]
<kanavin>
JPEW, that's the behavior I got in Fedora, so maybe it's just wrongly built or packaged there, or many other reasons
<kanavin>
but I did have to deinstall it to get rid of it
manuel_ has joined #yocto
manuel has quit [Remote host closed the connection]