<alex88>
nvm it seems that using append instead of += fixed it
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
qschulz has quit [Ping timeout: 245 seconds]
qschulz has joined #yocto
alinucs has quit [Ping timeout: 250 seconds]
alinucs has joined #yocto
gioyik has joined #yocto
rcw has quit [Quit: Leaving]
gioyik has quit [Ping timeout: 276 seconds]
Vonter has joined #yocto
sakoman has quit [Quit: Leaving.]
deurzen has joined #yocto
<deurzen>
Hi guys, is there a way to `do_install_append()` a specific package? So, say, in a .bbappend file, I have 2 packages, PACKAGES =+ "packageA packageB", and I want to define a separate `do_install_append` for both packages. Would that be possible? Thanks :)
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
gioyik has joined #yocto
troth has quit [Ping timeout: 264 seconds]
gioyik has quit [Ping timeout: 276 seconds]
troth has joined #yocto
<kroon>
kanavin, for identical native binaries built in different paths, we need to pass the correct -fdebug-prefix-map, so that the paths in the debuginfo are the same, since the build id checksums include the debug info
<kroon>
RP, I sent a new version of the 'ar' wrapper patch, I have tested it in my build
gioyik has joined #yocto
<kroon>
kanavin, -ffile-prefix-map is also relevant
<kroon>
kanavin, if I do -fdebug-prefix-map=<a>=<b> and -gdwarf-2, then I get identical binaries that include debug info
Vonter has quit [Ping timeout: 264 seconds]
fleg has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
vd has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
frinke has joined #yocto
GNUmoon has joined #yocto
dmoseley has quit [Ping timeout: 256 seconds]
dmoseley has joined #yocto
leon-anavi has joined #yocto
alessioigor has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
rob_w has joined #yocto
alessioigor has quit [Quit: alessioigor]
mvlad has joined #yocto
zpfvo has joined #yocto
kroon has quit [Remote host closed the connection]
kroon has joined #yocto
fullstop_ has joined #yocto
fullstop has quit [Ping timeout: 250 seconds]
fullstop_ is now known as fullstop
<kanavin>
kroon, cool - are you able to propose a patch?
<kroon>
kanavin, i would propose a patch not to test reproducability for native/cross builds in different build paths, only for the same paths
<dwagenk>
deurzen: I don't think thats possible. AS I understand it the do_install task is run per recipe, the FILES_packageA and FILES_packageB variables are then used to sort the installed files into different packages.
<kroon>
kanavin, just thinking out loud, isnt repro in different build paths a little overkill ? at least as a start..
dmoseley has quit [Ping timeout: 260 seconds]
dmoseley has joined #yocto
<kroon>
kanavin, but I can definetly keep looking at this, just need to learn how to parse the autobuilder native repro test results, if/when they arrive
<kanavin>
kroon, repro from different paths it helps sstate reuse
<kroon>
kanavin, yeah youre right
<kanavin>
kroon, I meant a patch that sets correct native gcc flags and solves the build-id issue
<kanavin>
since you've come quite far in getting to the bottom of it, a patch should not be too much hopefully?
<kanavin>
it builds sysroots in two different paths, both without sstate, but the comparison test isn't done yet, as there's no point until build-id thing is addressed :)
<kroon>
kanavin, the thing is that different build paths in not something that bothers my builds too much, since its usually rebuilding in the same paths. if the path changes, due to version update, the rebuild was probably necessary anyway
<kroon>
kanavin, thanks, ill have a look
<kanavin>
kroon, I do have something 20 different build directories set up locally on the other hand, so anything that helps avoid rebuild is appreciated
<kanavin>
the zoo of target architecures, musl, systemd, no-X11, you name it
<kroon>
kroon, so with native/cross build path repro you could hopefully reuse much native/cross sstate for all the builds ?
<kroon>
kanavin, talking to myself
rob_w has quit [Remote host closed the connection]
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
<kanavin>
kroon, maybe we need RP to weigh in on this :) repro in the same build path is certainly easier
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
chep has joined #yocto
oberon has joined #yocto
leon-anavi has quit [Remote host closed the connection]
ilunev has joined #yocto
<oberon>
what recipe adds sshd server ?
<RP>
kanavin: my view is that repro in different paths would be beneficial even if it is for just the "big" components like gcc
<qschulz>
dwagenk: that is correct
<kanavin>
or even bigger like llvm-native
<RP>
kanavin: indeed
<kanavin>
RP: or even bigger like, er, rust-native :D
<kanavin>
so kroon says we need to add explicit debug-prefix-map to -native builds as well as the first step towards that, and I'm persuading him to send a patch :)
<kroon>
kanavin, RP, or perhaps even -ffile-prefix-map, since it also includes -fmacro-prefix-map
zpfvo has quit [Ping timeout: 268 seconds]
<chrfle>
Hello, when I end up in an unexpected dependency loop, what's the best way to debug it? I see that the loop is printed when the build fails, but it seems to include all dependencies for the packages involved, which makes it hard to see where the real loop is
zpfvo has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
<kanavin>
chrfle, usually it prints several loops I think
<kanavin>
towards the start are the shorter ones
<chrfle>
kanavin: it might perhaps not be so long, but one of the tasks involved depends on many many tasks, and all of those are definitely not involved... What I guess I'm asking if it's possible to get all those tasks that are unrelated to the loop filtered out (do_rootfs has many dependencies)
dmoseley has quit [Ping timeout: 260 seconds]
dmoseley has joined #yocto
<kanavin>
chrfle, it helps if you add a pastebin of the full error msg you're getting from bitbake, all the lines
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<chrfle>
kanavin: I'll see if I can filter out any private stuff... Got some meetings, so will be back at a later point if I don't get it sorted..
<kroon>
kanavin, RP, we could also build native/cross without debug info
<kanavin>
kroon, please no
<kanavin>
when they crash or malfunction debug info is invaluable
<kroon>
kanavin, yeah. scratch that
* RP
thought we might build them without debug info atm
<RP>
adding the prefix/macro map may be necessary but does make you wonder what to map to
<kroon>
RP, i think youre right, at least zstd-native doesn't seem to have any debug info
gioyik has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
florian has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
leon-anavi has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
oberon has quit [Quit: Client closed]
oberon has joined #yocto
<kanavin>
I was wondering about that too, the unstripped binaries are barely bigger than stripped ones
* RP
thinks zeddii's patch series is going to be fun looking at the autobuilder failing before the build even gets going
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
sgw has quit [Ping timeout: 250 seconds]
rob_w has joined #yocto
dmoseley has quit [Ping timeout: 268 seconds]
bps has quit [Ping timeout: 264 seconds]
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
sgw has joined #yocto
dmoseley has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
rber|res has joined #yocto
manuel1985 has joined #yocto
dmoseley has quit [Ping timeout: 264 seconds]
dmoseley has joined #yocto
kroon has quit [Quit: Leaving]
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
dmoseley has quit [Ping timeout: 264 seconds]
oberon has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
dmoseley has joined #yocto
Guest9619 has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
kayterina has joined #yocto
zpfvo has joined #yocto
dmoseley has quit [Ping timeout: 264 seconds]
dmoseley_ has joined #yocto
mckoan is now known as mckoan|away
dmoseley has joined #yocto
dmoseley_ has quit [Ping timeout: 264 seconds]
dmoseley_ has joined #yocto
dmoseley has quit [Ping timeout: 260 seconds]
dmoseley_ has quit [Ping timeout: 256 seconds]
<dvorkindmitry>
why if I have FILES_${PN} += "/lib/systemd/system/my.service" but bitbake says "not shipped in any package" and list this file?
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
prabhakarlad has quit [Quit: Client closed]
dmoseley has joined #yocto
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
pgowda_ has joined #yocto
<qschulz>
dvorkindmitry: which Yocto version?
<qschulz>
I assume it's FILES:${PN} you need (at least honister)
<dvorkindmitry>
qschulz, yes, honister
<dvorkindmitry>
may I use same syntax for dunfell?
<qschulz>
dvorkindmitry: yes
<qschulz>
not ALL dunfell but latest yes
<dvorkindmitry>
"not all", you mean I can use it with latest dunfell rev?
<qschulz>
yes
<JPEW>
kroon, RP, kanavin: if we have to pass debug mapping... The how useful is the debug data when restored from sstate to a different path in the first place?
<qschulz>
it's just that dunfell 3.1 didn't have support for the new syntax at the beginning
<qschulz>
I don't know exactly when it changed
<dvorkindmitry>
qschulz, but latest supports new syntax 100%, right?
<qschulz>
yes
<zeddii>
RP: I
<zeddii>
I have fat fingers apparently
<zeddii>
RP: I can start some of my own AB runs
<JPEW>
I was thinking we could not put debug data in sstate but still generate it on a local build... But I realize this is not helpful because the build id would still be different. Never mind
<zeddii>
I just wanted it out there for reference.
frwol has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
<smurray>
qschulz: I think 3.1.11 was the first dunfell release with it
<dvorkindmitry>
qschulz, so RDEPENDS_${PN} shouldbe converted to RDEPENDS:${PN} too, right?
nad has joined #yocto
<qschulz>
dvorkindmitry: yes
gioyik has joined #yocto
<qschulz>
dvorkindmitry: there's a migration script somewhere
<dvorkindmitry>
may I have several %.bbappend files for the same package?
<zeddii>
RP: I did start an AB run, I see the python package warnings, some I would have created with the new package, but I guess the others are from the existing meta-python recipes.
<dvorkindmitry>
smurray, very useful! thanks!
<zeddii>
ahah. I see what I screwed up. some of those should be rdepends in the recipe
<qschulz>
dvorkindmitry: the script is listed there :)
jmiehe has joined #yocto
prabhakarlad has joined #yocto
eloi has joined #yocto
frwol has left #yocto [#yocto]
gioyik has joined #yocto
Tyaku has joined #yocto
kroon has joined #yocto
<dvorkindmitry>
when building what (x0 of x0/y0 of y1) means?
ar__ has joined #yocto
troth has quit [Ping timeout: 260 seconds]
Tyaku has quit [Ping timeout: 265 seconds]
Tyaku has joined #yocto
codavi has joined #yocto
Tyaku has quit [Quit: Lost terminal]
ar__ has quit [Ping timeout: 264 seconds]
troth has joined #yocto
<rburton>
dvorkindmitry: x is jobs that are taken from sstate, y is jobs that are being run properly
frinke has quit [Quit: Client closed]
dj has joined #yocto
<dj>
what does ${bindir} and ${D} supposed to look like?
<qschulz>
dj: ${D} is the image directory within the ${WORKDIR} of a recipe, ${bindir} is /usr/bin
<dj>
my ${bindir} expands to a massive path: "/home/Shared/code/linuxtime/bitbake/poky/build/tmp/work/x86_64-linux/linuxptp-native/3.0.0+gitAUTOINC+27bc9d52fa-r0/recipe-sysroot-native/usr/bin"
<rburton>
yeah in a native recipe its more 'interesting'
<rburton>
but yes, that's fine
<dj>
so then I shouldn't be using ${D}${bindir}, why is it different for native?
<rburton>
you should, it's not
<dj>
i don't understand, because ${D}{bindir} would give: /home/Shared/code/linuxtime/bitbake/poky/build/tmp/work/x86_64-linux/linuxptp-native/3.0.0+gitAUTOINC+27bc9d52fa-r0/image/home/Shared/code/linuxtime/bitbake/poky/build/tmp/work/x86_64-linux/linuxptp-native/3.0.0+gitAUTOINC+27bc9d52fa-r0/recipe-sysroot-native/usr/bin
<rburton>
yes
<rburton>
relocation happens, it's fine
<rburton>
just always prefix paths with ${D} in do_install
<dj>
relocation?
<rburton>
native files are executed from a different sysroot for each recipe
<dj>
so what directory is actually being used for install -d then?
pgowda_ has quit [Quit: Connection closed for inactivity]
<dj>
still that same long one?
rcw has joined #yocto
<rburton>
yes
<dj>
wouldn't it make more sense to just use ${D}/usr/bin ?
rcw has quit [Client Quit]
<dj>
isntead of adding /home/Shared and all that after image/
<rburton>
there are reasons, which i can't remember
<rburton>
personally yeah it would make things neater in logs, but at the end of the day all you see in the recipe is ${D}${bindir}
<rburton>
when RP is back from having fun he might be able to remember the reason, because I can't.
<kergoth>
doing it the way we do now means its prefix includes the whole path, so could be used as is when unpacked and we didn't need to relocate. then we added that relocation, so now the use of the full dest path as prefix is primarily a placeholder for that relocation. if we used, i.e. /usr, it'd be hard to search/replace / or /usr in scripts without mucking something up, too generic
<kergoth>
afaik anyway
rob_w has quit [Remote host closed the connection]
<kergoth>
i'd like to see a more explicit path placeholder used instead of the current prefix, though
kiran_ has joined #yocto
kayterina has quit [Read error: Connection reset by peer]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<dj>
i can't figure out how to install binaries natively, should I just manually write /usr/bin for oe_runmake install in sbindir?
zpfvo has quit [Ping timeout: 245 seconds]
<rburton>
you can't install binaries to your host
<rburton>
mainly as you're not root
zpfvo has joined #yocto
<rburton>
just use ${D}${bindir} and then they'll be in the native sysroot if another recipe DEPENDS on your native recipe
<qschulz>
and since the native sysroot is part of a recipe PATH, it'll be found without giving the whole path in the filesystem
troth has quit [Ping timeout: 264 seconds]
<dj>
i was told that you don't need to sudo as things are already done as root?
<dj>
i basically build binaries via bitbake that I want access to via all my terminals via /usr/bin on my host machine
<rburton>
no, you were told that do_install runs as 'fake root' so you can chown for packaging. At no point do you enter your root password to write to your host.
<dj>
ah i see
<rburton>
you can run binaries that have been built natively using oe-run-native, but you can't install to the host
<rburton>
if you want to create host packages then use your host package manager
<dj>
and would I be able to run these commands for host package management in the .bb recipe files? do I need to make a bash script and call it in the .bb file?
<qschulz>
dj: I think you need to explain exactly what you want to do because it is very unclear to me and it might be a case of XY problem
<dj>
I am building binaries via native which are constructed through bitbake (I think?) and I want these binaries to be in my host machine's /usr/bin for easy access & usage
<rburton>
sounds like you want to build native packages using your native packaging tools, like rpm or dpkg or whatever
kiran_ has quit [Ping timeout: 250 seconds]
<dj>
possibly, the binaries are being built and are usable but they're in these awkward directories that I hate pathing to run
<rburton>
yeah, that's because they're not meant to be user-visible :)
troth has joined #yocto
<rburton>
i presume you're also building images for some target and not just native binaries
<fray>
Can someone point me at a clue, for the built in self-tests. Does the test runner "login" to the device, or is there an expection once it connects it's directly at a prompt to run the test cases?
<rburton>
fray: testimage? it logs in as root
<fray>
I'm just trying to figure out what the expections re
<dj>
basically i have this time networking app that should link up from my host machine and to a QEMU instance. So I'm building it for QEMU and it works and all, but it's annoying that this binary isn't in my host machine's /usr/bin
<fray>
root w/o a password?
<rburton>
fray: yeah assumes empty-root-password is set
<rburton>
dj: use oe-run-native
<fray>
ok.. so sees login problem, "types" root, and just enter on passwd
<dj>
i guess i will, but it's still annoying that I can't install to my host machine
<dj>
where I was hoping that I could even do a simple `cp` command to bring it to my /usr/bin in the .bb recipe file
<rburton>
dj: but you're not root so you can't do that
<fray>
(We are currently working on disabling the root account by standard, and forcing the user to login to a standard user and sudo to root.. first login requires a passwd change as well).. this certainly complicates things in that case.
<rburton>
fray: it ssh in, not console
<fray>
ohhh ok
<fray>
ya our test harness boots the board and uses the console
<rburton>
ah yeah different codepath
<qschulz>
dj: also, you're linking against libraries that are present in the sysroot and not in your system, so even if you were able to install into /usr/bin, you'd still need to fix LD_LIBRARY_PATH before starting it
<rburton>
i'd say the options are 1) oe-run-native to run the binary from the sysroot, or 2) package your tool using the hosts packaging system so you have a proper host package (right linkage, dependencies, etc)
<rburton>
i guess you *could* write a recipe that uses sudo to install to the host, and edit sudoers so it doesn't prompt for your password (as recipes don't have a tty), but that would be a terrible idea! :)
<dj>
even if the .bb recipe runs a bash script for a package manager there's no prompt for sudo password?
deurzen has quit [Remote host closed the connection]
<rburton>
recipes don't have a console attached at all
<dj>
I see, thank you for your help
<fray>
rburton do you have a pointer to where that login code is? I'd like to play with it a bit and see if I can adjust it to use a non-root login + sudo
<rburton>
fray: the ssh login is in meta/lib/oeqa/core/target/ssh.py
zpfvo has quit [Ping timeout: 245 seconds]
<fray>
thanks..
zpfvo has joined #yocto
<rburton>
fray: oh maybe its oeqa/utils/sshcontrol.py for testimage
<rburton>
fray: did i mention i hate oeqa's code duplication
<rburton>
i've already forgotten how testimage works with a console not ssh
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
roussinm has joined #yocto
<fray>
rburton: :)
<fray>
ya, both sides look nearly, if not the same
eloi has quit [Quit: WeeChat 3.3]
Vonter has quit [Quit: WeeChat 3.3]
camus1 has joined #yocto
dj_ has joined #yocto
manuel_ has joined #yocto
Tokamak_ has joined #yocto
fullstop_ has joined #yocto
alimon8 has joined #yocto
bps has quit [Read error: Connection reset by peer]
Tokamak_ has quit [Read error: Connection reset by peer]
rfried3 has joined #yocto
Tokamak_ has joined #yocto
ernstp_ has joined #yocto
manuel_ has quit [Client Quit]
roussinm1 has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
roussinm has quit [*.net *.split]
dj has quit [*.net *.split]
troth has quit [*.net *.split]
manuel1985 has quit [*.net *.split]
sgw has quit [*.net *.split]
fullstop has quit [*.net *.split]
fleg has quit [*.net *.split]
Tokamak has quit [*.net *.split]
jonmason has quit [*.net *.split]
flynn378 has quit [*.net *.split]
ernstp has quit [*.net *.split]
rhadye has quit [*.net *.split]
nohit has quit [*.net *.split]
kergoth has quit [*.net *.split]
camus has quit [*.net *.split]
madisox has quit [*.net *.split]
Tartarus has quit [*.net *.split]
rfried has quit [*.net *.split]
alimon has quit [*.net *.split]
tgamblin has quit [*.net *.split]
moto-timo has quit [*.net *.split]
fullstop_ is now known as fullstop
ernstp_ is now known as ernstp
camus1 is now known as camus
alimon8 is now known as alimon
rfried3 is now known as rfried
tgamblin has joined #yocto
kiran_ has joined #yocto
jonmason has joined #yocto
flynn378 has joined #yocto
sgw has joined #yocto
nohit has joined #yocto
madisox has joined #yocto
moto-timo has joined #yocto
rhadye has joined #yocto
Tartarus has joined #yocto
kergoth has joined #yocto
kiran_ has quit [Ping timeout: 250 seconds]
<wyre>
hi guys, why do you think I'm having these fetch errors?
<wyre>
ERROR: ca-certificates-20211016-r0 do_fetch: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'git://salsa.debian.org/debian/ca-certificates.git;protocol=https;branch=master')
ilunev has quit [Read error: Connection reset by peer]
ilunev has joined #yocto
<halstead>
dj_: Did you email a request?
dev1990 has quit [Remote host closed the connection]
dev1990 has joined #yocto
<zeddii>
am I the only one with meta-skeleton in his bblayers ? I'm getting a warning about the :append += operators and patched it locally .. but I can't see how it has survived not blowing up the AB, etc, so I must have some sort of strange config.
camus has quit [Ping timeout: 250 seconds]
camus has joined #yocto
<halstead>
push.yoctoproject.org is available again. git.yoctoproject.org is on the new HA servers. Sorting out some cgit display issues.
<zeddii>
RP: The extra dependences and my tweaked dtschema recipe seem to be green on my AB run. Should I send the whole blast again ? since there's v2 three of the patches and 4 new recipe imports, I think that's easiest to sort out. Alternatively, my poky-contrib zedd/kernel has everything rebased and clean.
<RP>
zeddii: sending again sounds good and I'll drop and refresh
kiran_ has joined #yocto
florian has joined #yocto
jmiehe has quit [Quit: jmiehe]
dj_ has quit [Quit: Leaving]
<kroon>
RP, I sent a v2 of the ar wrapper patch
ilunev has quit [Read error: Connection reset by peer]
ilunev has joined #yocto
<halstead>
Pushes are not syncing to the mirrors correctly yet. Resolving that now. New pushes are allowed but won't appear publicly for a bit.
<dvorkindmitry>
Mirror fetch failure for url git://github.com/git/python-pillow/pillow-scripts.git;protocol=https;branch=master (original url: git://github.com/python-pillow/pillow-scripts.git;protocol=https;branch=master)
<dvorkindmitry>
why it transaltes to wrong URL?
dn1 has joined #yocto
mvlad has quit [Remote host closed the connection]
GNUmoon has quit [Ping timeout: 276 seconds]
<zeddii>
RP: something is up with the infrastructure, the same pull request generation line I've been using for years is failing.
<zeddii>
hence why there's no v2 of the request yet.
<zeddii>
hmm. let me try a different branch:
<zeddii>
remote: fatal: bad object 0000000000000000000000000000000000000000
<zeddii>
hmm. nope.
* zeddii
gives up.
<RP>
zeddii: halstead is making some infra changes
<RP>
zeddii: are you using push.yoctoproject.org ?
<zeddii>
yup
<halstead>
zeddii: Objects pushed aren't appearing on the mirrors yet. We are very close.
<zeddii>
gotcha!
<zeddii>
no worries. I thought I was losing it there.
<halstead>
I tested some capabilities incorrectly and they were ready. Building them now rather than rolling back.
* RP
resists commenting on that
<halstead>
RP: And it's built. Starting to bring the mirrors up to date now. Does that change the comment at all?
<RP>
halstead: I was meaning commenting about zeddii losing it ;-)
<halstead>
Got ya RP. Anyone who's talked hockey with zeddii already knows.. ;)
<halstead>
zeddii: Is your object available now?
<RP>
halstead: it looks like the cgit urls changed as my bookmarks don't work. Is that expected?
* zeddii
checks
<halstead>
RP: We had a symlink in place to keep old bookmarks working. I'll check on that now.
<RP>
halstead: I can fix my links if I'm using old stuff but I thought I'd better ask
<zeddii>
halstead: yup. it seems to work now.
<zeddii>
'er wait. now it blew up again.
<halstead>
RP: We will get the bookmarks working again. But yes the cgit urls are changing to be a bit prettier.
<RP>
halstead: the new urls do look nicer. I don't mind changing, I just wanted to make sure I should update
<halstead>
zeddii: There are a few moments delay before pushes appear on the mirrors now. Hooks initiate the sync and clear the cache but it take a few moments.
<zeddii>
FYI: This is what I see. The command in question is what I've run for quite a while. so probably related to the sync ?
<dvorkindmitry>
why fetch2 changes SRC_URI from git://github.com/python-pillow/pillow-scripts.git;protocol=https;branch=master to git://github.com/git/python-pillow/pillow-scripts.git;protocol=https;branch=master ?
<RP>
dvorkindmitry: one of the remappings in MIRRORS or PREMIRRORS?
gioyik has quit [Ping timeout: 276 seconds]
<dvorkindmitry>
RP, my recipe is so simple... no maps
<RP>
dvorkindmitry: there are some set in mirrors.bbclass
<halstead>
RP & kroon redirects for that style link are in place now.
<RP>
halstead: thanks
<RP>
halstead: the new server does seem faster!
<kroon>
halstead, thanks
<kroon>
RP, how is your memory when it comes to the native builds ? It looks like the RUNPATH is set in the binaries in the build directory, but in the sysroot-components/ they are empty
<kroon>
RP, do we strip rpath for native binaries after installing them ?
<halstead>
RP: I'm going to announce the migration complete with reminders to update remotes and a note about adding delays to scripts that require the mirrors to be in sync.
<dvorkindmitry>
RP, oh! nowI see what iswrong. wrong branch.thank you.
<RP>
kroon: we strip off "pointless" rpaths/runpaths if I remember correctly
<RP>
halstead: sounds good. You may want to spell out that if "pushes" hang, they probably need the push.XXX url update. I have loads of them left
<RP>
zeddii: I stopped the test build and restarted with the updated patch
<zeddii>
it still may not be right, I continually screw up the native/target interplay and what magic happens, but it is less obviously wrong :D
<zeddii>
as soon as I tried bitbaking python3-dtschema it blew up here, and I fixed that. the -native also built.
<kroon>
RP, kanavin, so the reason zstd-native is not reproducible in different buildpaths is because we pass rpaths in BUILD_LDFLAGS
<kroon>
RP, kanavin, if I remove them, the sysroot-components directories become binary identical
<kroon>
RP, kanavin, the rpaths most likely get included when calculating the build-id, it doesn't matter that we then later on remove them with chrpath
<kroon>
RP, kanavin, but, I bet they are there so that we can relocate them when installing them to the recipe-specific sysroot ?. But perhaps we could use an identical "marker"
<RP>
kroon: hmm. I'm surprised we'd remove the rpaths entirely
<kroon>
RP, not entirely
<kroon>
RP, doh I don't have the exact value left now, but it was something ling "../lib:lib"
<RP>
kroon: ah, we make them all relative
<kroon>
RP, at least they were identical in both binaries after the chrpath magic
<kroon>
so the only thing that diffed was the build id
<kroon>
simply removing the build id would also be an option, if thats possible
<RP>
kroon: -Wl,--build-id=none is suggested by google
<kroon>
RP, ok ill test
<RP>
or we could strip the section I guess
<kroon>
hmm dunno how that would work if the sections are/can be of different sizes
dvorkindmitry has joined #yocto
<RP>
kroon: I think the section is a separate specifically named one
<kroon>
RP, yes, and actually it should be of the same size since its a checksum
<RP>
kroon: strip --remove-section=.note.gnu.build-id libzstd.so works FWIW
<kroon>
RP, and that "-Wl,--build-id=none" also works
dev1990 has quit [Quit: Konversation terminated!]
gioyik has quit [Ping timeout: 276 seconds]
<RP>
kroon: probably easier :)
<kroon>
kanavin, do you think you can hack some more on that sysroot repro tests ? I don't think that "self.compare_sysroots()" is implemented yet ?
<kroon>
RP, definetley
<kroon>
RP, do you think we are ok with removing the build-id in general for native/cross binaries ?
<RP>
halstead: I think we may have to have the autobuilder pull from push.yp.org. I can't cope with the mirror lag trying to start builds :(
<RP>
kroon: since we don't have debug symbols, I'm not sure it is that useful
<halstead>
RP: How much lag are you seeing?
<kroon>
RP, ah, so that is that the build-id is used for, looking up the correct debug info ?
<RP>
halstead: 30 seconds but it just wrote off a build as I hadn't acounted for it
<RP>
kroon: it certainly helps for that
<halstead>
RP: Clones from the mirrors should be much faster than from the push server if we can allow of the sync delay. :\
<RP>
halstead: well, it is just one more thing I need to remember. Push master-next, then poll on the public site to ensure it is updated, then go and start the build only when it is visible. I'll have to write a script
kiran_ has quit [Ping timeout: 250 seconds]
<halstead>
RP: we can use the push server if that's best. The mirrors are ideal for performance. I think a 30-60 second wait is about as fast as we can make the sync though.
codavi has quit [Ping timeout: 260 seconds]
<RP>
halstead: it is that or we make every build wait 90s before it starts just to give the mirrors time to sync. It is really annoying to start a build and then realise it is building the wrong thing
<RP>
halstead: all the AB users are going to run into this :(
<halstead>
RP: adding a 90 second set up task is a simple fix. It's feels a little sad when we've worked so hard to shave off build time though.
<halstead>
RP: It will be needed for triggered builds like the docs too. Hrm.
<RP>
halstead: exactly. More than a little sad
lowfi has joined #yocto
<RP>
it risks undermines any trust that the AB is doing the right thing
<halstead>
Yeah, and we can't have that.
lowfi has joined #yocto
lowfi has quit [Changing host]
<halstead>
It really shouldn't take 90 seconds. I can run some stress tests and get a better idea of the range.
gioyik has joined #yocto
<RP>
halstead: whether it is 45 or 90, it is still going to be too laggy. We may as well just point it at push even if it is slower
<halstead>
RP: Building from the public mirrors the same way every other user would has value though. Is that be worth adding 45 seconds at the beginning of a-full, a-quick, and docs?
<RP>
halstead: It is needed on *every* possible build :(
<halstead>
RP: I didn't realize that. I agree that's unacceptable.
<RP>
halstead: meta-mingw is impacted, meta-gplv2, any qemu target is built from poky, basically they're all impacted
gioyik has quit [Ping timeout: 276 seconds]
<halstead>
RP: Aren't all of those triggered by the full builds though?
<RP>
halstead: you can run them manually as well
<halstead>
RP: running those manually quickly after pushing could undermine trust.
<RP>
halstead: which is my worry
gioyik has joined #yocto
<halstead>
RP: Could we add a box like "Do we want to deploy artefacts?" labeled "Add 1 minute delay?" and have it always checked by default?
<halstead>
RP: But not have it checked for builds started by a-full?
<halstead>
That triggered builds...
<RP>
halstead: no, this is totally crazy. it is just going to have to use push
<halstead>
RP: Okay. How can I help?
<RP>
halstead: I guess we need to change git.yp.org to push.yp.org in yocto-autobuilder2 and reconfig the controller
<RP>
halstead: is OE impacted the same way or not?
<halstead>
RP: No changes for OE.
<RP>
halstead: ok, I've pushed changed to yp-ab2. I'll pull into the controller and reconfig when the mirror has synced
<RP>
halstead: still waiting for the sync :/
<halstead>
RP: This change will cause failures.
<RP>
halstead: anon access isn't available to push?
* RP
bins the patch
<halstead>
RP: No. I need to whitelist the builders to allow that.
<RP>
halstead: well, I'm open to other ideas
<halstead>
RP: I can start on that. Or we can update the urls to ssh://git@push.yoctoproject.org/
<RP>
halstead: we can use that url instead
* RP
realises he's wiped out a load of local changes now
camus has quit [Ping timeout: 260 seconds]
<halstead>
RP: on typhoon or ?
camus has joined #yocto
<RP>
halstead: no, my local dev stuff. I reset the tree to get rid of that patch and wiped everything
<halstead>
:(
<RP>
halstead: I've pushed the updated patch
<halstead>
RP: I see some leading space on the line. Will that be an issue?
<RP>
halstead: not my day is it. It shouldn't matter but I've fixed
<halstead>
RP: shall I pull it onto the controller?
<halstead>
Looks good. A problem you didn't need today is solved.
<RP>
halstead: Right :) I might head to bed now
<halstead>
Good night RP. Thanks for your patience.
<RP>
halstead: np, the new servers are nice and speedy :)
mckoan|away has quit [Ping timeout: 256 seconds]
mckoan|away has joined #yocto
sveinse has joined #yocto
<sveinse>
When interrupting bb, does it finish the pending tasks (only) or does it finish the current recipes? It seems the former, but it would have been nice with the latter.