<kroon>
RP, /bin/sh: line 1: cd: /srv/autobuilder/repos/a-quick-1627/poky: No such file or directory
<kroon>
RP, can those be ignored ?
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
hpsy has joined #yocto
<RP>
kroon: I'd never noticed that. I guess so since it is otherwise working but I should probably fix it
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 265 seconds]
troth has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
troth has joined #yocto
MauroAnjo has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
BCMM has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
prabhakarlad has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
camus has quit [Ping timeout: 264 seconds]
camus has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
GNUmoon has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
yocti` has quit [Remote host closed the connection]
yocti has joined #yocto
MauroAnjo has quit [Quit: Ping timeout (120 seconds)]
mckoan is now known as mckoan|away
zpfvo has quit [Ping timeout: 260 seconds]
lucaceresoli has quit [Quit: Leaving]
zpfvo has joined #yocto
MauroAnjo has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
troth has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
<michalkotyla>
Hello, I got a problem with adding a recipe for cryptoauthlib from the Microchip repository. Error says "do_fetch: Fetcher failure: Unable to find revision 055dd4afafb019db1f4d61880aa441832139faa2 in branch v3.3.3 even from upstream", it's weird because it is able to find latest revision with ${AUTOREV}. It works outside the Yocto build system, this repository is fine (i think). Does anyone have a similar issue?
<RP>
michalkotyla: the question is whether that revision actually exists in that branch
<RP>
michalkotyla: looks like v3.3.3 is a tag, not a branch?
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
flynn378 has quit [Ping timeout: 264 seconds]
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
<michalkotyla>
RP: yes, i thought that there is no difference for fetcher. I'd bet that this works for me in the past - thanks, i see that now and i will change "branch=" for "tag=" in SRC_URI
flynn378 has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus has joined #yocto
MauroAnjo has quit [Quit: Client closed]
MauroAnjo has joined #yocto
yocti` has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
yocti has quit [Ping timeout: 256 seconds]
GNUmoon has joined #yocto
TikityTik has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
troth has joined #yocto
davidinux has quit [Quit: WeeChat 2.8]
GNUmoon has joined #yocto
davidinux has joined #yocto
<kanavin>
RP: my sysroot reproducibility effort stumbled quickly: all of the native recipes are non-reproducible on debian 10. host gcc writes a different gnu.build-id every time into the binaries. Investigating...
<RP>
kanavin: isn't this what the patches from kroon were for?
<RP>
kanavin: try master-next as there are working versions there
<kanavin>
RP: I thought the patches were for ar -D? or is the build-id thing a consequence of that?
<RP>
kanavin: there are also path problems there which were a separate discussion and the revised patch never was submitted
sakoman has joined #yocto
<RP>
kanavin: build id is a consequence I think
<kanavin>
RP: right, I'm going to cherry-pick
<kanavin>
RP: another common issue is ${S} leaking into various config files, e.g. target python and perl sysroots both have that issue
<RP>
kanavin: also see " [PATCH] gcc: Improve reproducibility" from oct 27
<RP>
kanavin: I confirmed a path issue in that discussion but we haven't fixed it yet
<kroon>
kanavin, is the build-id the only thing that is diffing ?
<kanavin>
kroon, yes, but I only have two or three data points
GNUmoon has quit [Ping timeout: 276 seconds]
<kanavin>
once that is taken care of, I will have a clearer picture
<RP>
kanavin: we've never really tried for completely identical native binaries so I suspect there will be quite a bit of work :/
<kanavin>
RP: the ${S} leak issue is prominent in target sysroots as well
<kanavin>
I didn't look yet, but I suspect we patch that out for do_package and friends, but not for populate_sysroot() somehow
<RP>
kanavin: the sysroot and package codepaths are quite different and the sysroot can need paths :/
<kanavin>
RP: if the original ${S} doesn't exist anymore (because the sysroot was restored from sstate into a consumer) and AB never complains, I'd say it's pretty safe to strip that out
troth has quit [Quit: Leaving.]
<RP>
kanavin: probably in most cases
<kroon>
kanavin, if the build id is the only thing that diffs, then it sounds like the linker is doing --build-id=uuid, for a random build id
<kanavin>
kroon, there's no evidence of that in the logs, it must come from elsewhere
MauroAnjo has quit [Quit: Client closed]
troth has joined #yocto
<kanavin>
kroon, RP: no cigar. with the two determinism fixes pulled in, I still get different build ids in zstd-native (and that's as close to a dependency-less item as it gets, it only needs quilt-native). I'll try to dig this a bit more, but not immediately.
<kanavin>
the host is Debian 10, gcc 8
camus1 has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus1 is now known as camus
<kanavin>
RP, kroon: the test builds zstd-native in reproducibleSysrootsA and reproducibleSysrootsB, similar to target repro test. host gcc may factor that in somehow, I'll check that
<kanavin>
(e.g the build path matters)
<kroon>
ah, if the build path differs...
<kanavin>
yep, that's a condition for reproducibility
<kroon>
kanavin, that is something I haven't tested, might need more fixes to handle that
BCMM has quit [Ping timeout: 245 seconds]
codavi has joined #yocto
ar__ has joined #yocto
codavi has quit [Ping timeout: 260 seconds]
sveinse has quit [Remote host closed the connection]
vd has joined #yocto
prabhakarlad has joined #yocto
kergoth has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
fleg has quit [Remote host closed the connection]
zpfvo has joined #yocto
kergoth has quit [Client Quit]
fleg has joined #yocto
<RP>
kanavin: you need the fix in that gcc thread I mentioned to fix patch differences
kergoth has joined #yocto
Vonter has quit [Ping timeout: 264 seconds]
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
<kergoth>
yawn
rhadye has quit [Ping timeout: 250 seconds]
nohit has quit [Ping timeout: 264 seconds]
ernstp has quit [Read error: Connection reset by peer]
georgem has quit [Ping timeout: 250 seconds]
bradfa has quit [Ping timeout: 245 seconds]
angolini has quit [Ping timeout: 264 seconds]
jonmason has quit [Ping timeout: 264 seconds]
dagmcr has quit [Ping timeout: 264 seconds]
georgem has joined #yocto
ernstp has joined #yocto
Crofton has quit [Ping timeout: 245 seconds]
rhadye has joined #yocto
nohit has joined #yocto
dagmcr has joined #yocto
bradfa has joined #yocto
flynn378 has quit [Ping timeout: 245 seconds]
Crofton has joined #yocto
flynn378 has joined #yocto
angolini has joined #yocto
jonmason has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
<kroon>
RP, isnt that the one that removes checksum-options from the checksum ? just asking because we already do some pruning of that in gcc-cross.inc
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
kiran has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
<kroon>
RP, and I don't anything in there that looks specific to my host in my gcc-cross build
<kroon>
*I don*t see anything*
davidinux has quit [Ping timeout: 245 seconds]
hpsy has quit [Remote host closed the connection]
<RP>
kroon: I remember seeing hardcoded paths in mine when I looked :/
<kroon>
RP, ok that is odd
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
dev1990 has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
troth has quit [Ping timeout: 245 seconds]
<smurray>
RP: re tracking CVEs in the autobuilder, I guess the issue is how to manage the baseline for checking builds against?
<smurray>
sakoman: heh, I didn't get that far with my local python script. ATM I can pretty much recreate your reports, but I'd didn't follow through on my thoughts to hook up to a database
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<smurray>
sakoman: I could see populating a db with the CVEs seen at different commits, but it'd likey need some thought on how to set what a particular autobuilder run compares against
troth has joined #yocto
<sakoman>
smurray: yeah, I just kept it simple and compare to the previous HEAD for the branch under test (i.e. the previous week's results)
<sakoman>
and you'll find that these runs aren't reproducible over time -- the CVE database changes
<smurray>
yeah
zpfvo has quit [Ping timeout: 260 seconds]
<sakoman>
That's one reason why I decided not to do anything fancy -- a simple weekly comparison is a "good enough" metric IMHO
zpfvo has joined #yocto
zpfvo has quit [Remote host closed the connection]
rfuentess has quit [Remote host closed the connection]
<RP>
smurray, dl9pf: 3.1.12 will be released as discussed
<smurray>
RP: okay, thanks for the ping
<RP>
sakoman: a git repo was our thoughts too...
florian has quit [Quit: Ex-Chat]
<kanavin>
RP: right, I guess we need to get that fix from the gcc repro thread in (and preferably upstream), if we want to pursue native reproducibility. And until all distros adopt it, only possible with the buildtools tarball I guess? :-/
dj has joined #yocto
<dj>
I'm working with a repo that has yocto, I don't have bitbake in my environment, the repo has it. I am trying to test modifications I'm making to a specific recipe via: `./bitbake/bin/bitbake -e ../../meta-linuxptp/recipes-linuxptp/linuxptp/linuxptp-native_3.1.0.bb`
<dj>
but i'm getting: ERROR: OE-core's config sanity checker detected a potential misconfiguration.
<RP>
kanavin: well, I think we may end up patching gcc and it will help hashequivalence a bit which is all we the best we can hope for atm
<dj>
I mean `../bitbake/bin/bitbake
<qschulz>
dj: you're supposed to source some init script to have bitbake in your PATH
<qschulz>
`source poky/oe-init-buildenv ../build` usually (or a filename close to this)
<qschulz>
afk now
<dj>
thanks qschulz, will look into it
bps has quit [Ping timeout: 265 seconds]
<rburton>
dj: also -e is 'show environment' not run the recipe, and you pass a recipe name, not a filename (so linuxptp-native in your case)
<dj>
rburton, thanks
davidinux has joined #yocto
fleg has quit [Remote host closed the connection]
<dvorkindmitry>
how can I refer to file://${MYLAYERDIR}/mylicense in the recipe correctly?
<dvorkindmitry>
I have LICENSE_PATH += "${LAYERDIR}/files/common-licenses" in my layer.conf and I have LIC_FILES_CHKSUM = "file://mylicense;.." in the recipe, but bitbake says: LIC_FILES_CHKSUM points to an invalid file: builddisk/tmp/work/all-myarch-linux/myrecipe/0.12-r0/mylicense
<dvorkindmitry>
why it refers to the builddir instead of layer dir?
<kergoth>
dvorkindmitry: LIC_FILES_CHKSUM isn't just license files but copyright and stated license in the project source, so its relative to the sources by default. but you can do LAYERDIR_mylayer = "${LAYERDIR}" in your layer.conf, then use ${LAYERDIR_mylayer} in the recipe
<dj>
how do I avoid fetches when testing a bitbake <recipe>? I don't want to use up my internet bandwidth for fetching over and over
<dj>
i guess `export BB_NO_NETWORK=1` is sufficient?
<kergoth>
dj: you won't fetch over and over regardless. it always caches them in the DL_DIR
<kergoth>
dj: but yes, BB_NO_NETWORK=1 will enforce it
florian has joined #yocto
GNUmoon has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
gioyik has joined #yocto
amitk has joined #yocto
amitk_ has quit [Ping timeout: 260 seconds]
<kroon>
kanavin, which host path is it that is showing up in checksum-options ?
<kanavin>
kroon, I was, but I did not actually try it yet
<kroon>
kanavin, RP, then can we at least verify that the patch is solving an actual problem, because sofar I haven't noticed the problem it is trying to solve
<kanavin>
kroon, the problem is very easy to reproduce, but I didn't check if the patch helps
<kanavin>
just build zstd-native in two different build directories not sharing the same sstate
<kanavin>
the gnu.build-id will not match
<kroon>
kanavin, then perhaps it is due to the debug info
kiran has quit [Ping timeout: 264 seconds]
<kanavin>
maybe, I didn't check the unstripped binaries
<kroon>
if I build two programs with a simple main.c, in different directories, with debug info and then strip, they get different build ids
<kroon>
without debug info, they get same build id
<kanavin>
kroon, but the unstripped binaries in image/ still seem to differ only in build-id, and not other content
<kanavin>
kroon, and why is this not happening in target builds then?
<kroon>
additional patches in cross-gcc maybe ?
<kanavin>
could be
troth has quit [Ping timeout: 268 seconds]
bps has joined #yocto
bps has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
<kroon>
or rather the use of debug-prefix-map
<kroon>
or lack of
<kroon>
that will surely result in different build ids
mvlad has quit [Quit: Leaving]
troth has joined #yocto
chep has quit [Ping timeout: 245 seconds]
FredericOuellet[ has joined #yocto
kroon has quit [Ping timeout: 245 seconds]
kroon has joined #yocto
troth has quit [Ping timeout: 245 seconds]
troth has joined #yocto
mayco has joined #yocto
<mayco>
hey, is there a way I can make a layer that overrides configuration fragments in yocto-kernel-cache? there is an "arch/riscv/riscv.cfg" file which is forcing CONFIG_RISCV_ISA_C=y and I really need it to be n, but the config fragment in yocto-kernel-cache always seems to take precedence
<kroon>
mayco, I think you might need to change some other config, some other setting is forcing it to y, iirc how that stuff works..
<mayco>
let me clarify what I'm doing and seeing
<mayco>
I'm adding a config fragment in my layer for CONFIG_RISCV_ISA_C=n, and I see in the log file something about CONFIG_RISCV_ISA_C=n requested but overridden (don't have the exact log message at hand, can try to find it if needed)
<mayco>
I grep for CONFIG_RISCV_ISA_C=y and find the arch/riscv/riscv.cfg file in the yocto-kernel-cache repo which has that configuration file in it. I'm not touching that file because I don't know how to modify it in my layer
<mayco>
and I suspect that that file *is* said other setting which is forcing it to y
GNUmoon has joined #yocto
<kroon>
mayco, what does the SRC_URI look like ?
<kroon>
your config fragment should be the last entry
<mayco>
my config fragment is indeed the last entry
<kroon>
then i still think some other setting is forcing the value back to y
dj has quit [Quit: Leaving]
<mayco>
the thing I notice about the arch/riscv/riscv.cfg file is that it looks like it's referenced from arch/riscv/riscv.scc so maybe it is applied by a different system than my config fragments?
<zeddii>
mayco: if something within the Kconfig's themselves are selecting the value, then your change won't make any different. What branch and machine are you building ? There's some kconfig auditing in the recent releases that can shed light on what is going on.
<mayco>
honister, custom machine based on qemuriscv64
<kroon>
config EFI
<kroon>
select RISCV_ISA_C
<zeddii>
yup
<kroon>
so try disabling EFI
<mayco>
oh, yes, that looks promising. thank you! let me finish building and confirm that actually worked
<jonmason>
let me try it locally to see if I can repro
<mayco>
re: CONFIG_RISCV_ISA_C=n, looks like that worked perfectly, thanks so much!
<RP>
jonmason: it is khem's fault sorry
<jonmason>
haha, good
<jonmason>
I pulled in a crap patch yesterday and already got yelled at
<RP>
jonmason: I was struggling to see where it came from sorry
<jonmason>
I was worried I missed something else
<RP>
jonmason: the pattern is that fvp-base, beaglebone-yocto and edgrouter all say that don't have a screen
<jonmason>
ah, its possible that we're not testing hard enough for that
<RP>
zeddii: that pkgconfig stuff is *horrible* :(
<RP>
zeddii: it is used exactly the opposite to anywhere else :(
<zeddii>
we can just create another variable for it, versus PACKAGECONFIG
<RP>
zeddii: I mean the way it is using PKG_CONFIG_* for native rather than target
<RP>
zeddii: this is going to confuse a lot of people in the future
<zeddii>
ahah. yes, well those lines are directly from the cml1 bbclass
<zeddii>
and there's no other option, outside of patching the entire kernel.
<RP>
zeddii: doesn't make them right ;-)
<zeddii>
I can patch linux-yocto easily enough, I'm happy to let all the savages that don't use it suffer :D
<RP>
I understand, and it is unlikely the kernel will be building target pkg-config pieces until the rust modules become common place when this will really become apparent
<zeddii>
yah. I could see scenarios like that as well.
* RP
suspects zeddii can read that as intended
<zeddii>
when the kernel does bring in rust, maybe the pkg-config parts will be fixed at the same time :P
kroon has quit [Remote host closed the connection]
<RP>
zeddii: I wish I could say that jokingly :/
kroon has joined #yocto
<RP>
zeddii: I think we may want to quietly try and nudge upstream to better handle this now
<zeddii>
there have been a few patches over the years that just make pkg-config $(PKCCONFIG), so we can override it as required.
rhowell has quit [Quit: Leaving]
<zeddii>
but that is a small number. That's likely what it'll take to get done. I can eventually do that, or see if I can convince someone with more influence in k.org to take up the cause
leon-anavi has quit [Remote host closed the connection]
mayco has quit [Ping timeout: 264 seconds]
<zeddii>
when my yocto summit slides and presentations are hand scrawled or one slide and I ramble for 30 minutes, I blame detangling this at all :D
<jonmason>
zeddii: wasn't that your plan regardless?
<RP>
zeddii: right, we just need to try and stop this turning into a total minefield in the future if we can
<RP>
zeddii: sorry for distracting
<zeddii>
jonmason: maybe ;)
<zeddii>
I still have to get both presentations working, before I can even do the slides
<zeddii>
tomorrow, I'm deploying a meta-virt build flask application to my meat-virt k3s cluster.
<zeddii>
that'll take the day. that gives me the weekend to write slides :D
lowfi has quit [Read error: Connection reset by peer]
florian has quit [Ping timeout: 264 seconds]
<alex88>
anyone using polkit? I'm getting error `chown: invalid user: ‘polkitd:root’` after adding it to distro_features and image_install
ar__ has quit [Ping timeout: 260 seconds]
vd has quit [Ping timeout: 256 seconds]
gioyik has quit [Ping timeout: 276 seconds]
vd has joined #yocto
gioyik has joined #yocto
florian has joined #yocto
vd has quit [Ping timeout: 256 seconds]
<alex88>
nvm the issue was with how polkit and systemd distro features were added