<Guest50>
Is this some error in the documentation or I'm I missing something?
<Schiller>
Hello, can someone point me to where the Buildstep Fetch yocto-autobuilder-helper is scripted? I can't find it. And when i have a hook on a repository and try to automate a build with upstream HEAD the autobuilder wants to git reset --hard the yocto-autobuilder-helper repo to that HEAD which obviously doesn't exist. But i can't find any scripts for
<Schiller>
that buildstep :(
<Schiller>
ok I just realized it's a buildbot behaviour. But I still don't get the idea. What is the purpose of the git reset --hard for the yocto-autobuilder-helper repo? We just need the repo in the builddir to use the scripts. Can someone explain?
<mckoan>
Guest50: looks like you found a typo. michaelo[m] ^
<Guest50>
Hello mckoan, thank you for the feedback
manuel1985 has joined #yocto
<Guest50>
Is there a way to report this documentation typo to the YP?
<LetoThe2nd>
yo dudX
Herrie has quit [Read error: Connection reset by peer]
Herrie has joined #yocto
<landgraf>
Guest50: you can submit a patch for the documentation as well as for the code
<landgraf>
Guest50: do you mean s/subpath/subdir/ ?
<Guest50>
yes, in the doc suggests "subpath=${BP}" but I think it should be "subdir=${BP}"
<Guest50>
landgraf ^^
<kriive>
Hey,systemd-resolved with NetworkManager does not symlink /run/systemd/resolve/resolv.conf with /etc/resolv.conf, but it keep a symlink to /tun/NetworkManager/resolv.conf
<kriive>
What should I add/remove to PACKAGECONFIGs to make it work properly? I am using dnufell
<Schiller64>
Hello, can anyone help me with my local autobuilder setup. I have the repo yocto-autobuilder-helper under path /home/pokybuild3 and i point to it in my config.py. In the official project the repo ssh://git@push.yoctoproject.org/yocto-autobuilder-helper gets used. When i recieve an upstream commit <let's say poky>, the Buildstep 2 <fetch
<Schiller64>
yocto-autobuilder-helper> trys a git reset --hard to the HEAD of the poky repo. This fails cause there is no such revision on my local yocto-autobuilder-helper. Note that only upstream build fail the rest works fine. How do the workflows differ can someone explain? Is there first a commit on ssh://git@push.yoctoproject.org/yocto-autobuilder-helper
<Schiller64>
with correct revision or what do i miss?
yann has quit [Ping timeout: 255 seconds]
Herrie has joined #yocto
d-s-e has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
florian has joined #yocto
<Guest50>
hmm, I'm not sure is doing what is supose to do
<Guest50>
I made a new recipe that points to the local repo like so:
<Guest50>
LICENSE = "CLOSED"
<Guest50>
LIC_FILES_CHKSUM = ""
<Guest50>
# No information for SRC_URI yet (only an external source tree was specified)
<Guest50>
I think I need more time to make sure I get it right, I will be back
<qschulz>
Guest50: to be honest, I'm not entirely sure a git repo is a common scenario for sharing rpms?
Herrie has quit [Client Quit]
Schiller64 has quit [Quit: Client closed]
<Guest50>
yes, it does not sound very practical
kris has joined #yocto
<qschulz>
so a file:// or https:// example would be less confusing and more common? (but maybe it is much more common than I think /me shrugs)
davidinux has joined #yocto
<Guest50>
I think I agree on this
sgw has quit [Ping timeout: 252 seconds]
Herrie has joined #yocto
Schiller has joined #yocto
shoragan_ has quit [Quit: quit]
mvlad has joined #yocto
<Schiller>
Schiller64: someone? I
seninha has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
<manuel1985>
On an interactive terminal, can I make bitbake not delete the lines showing the current tasks but rather leave them? So I'd have a log of which tasks ran.
<PhoenixMage>
Is there some secret to getting a fitImage to boot from u-boot. The u-boot errors arent very helpful
<qschulz>
manuel1985: -D
<manuel1985>
qschulz: Thanks
Schiller has quit [Quit: Client closed]
zpfvo has joined #yocto
Guest79 has joined #yocto
<manuel1985>
qschulz: Ok, -D is the debug output. That prints quite a bit more than I need.
<manuel1985>
When I run bitbake in the CI, it prints lines such as "NOTE: recipe vps19-dev-1.0-r0: task do_image: Started", and then "NOTE: recipe vps19-dev-1.0-r0: task do_image: Succeeded" and just lets them stand
<manuel1985>
It logs start end end of every tasks
<manuel1985>
While in an interactive terminal it would print sth like "0: boost-1.78.0-r0 do_compile - 18m23s (pid 27713)" and would just remove the line when empty
<qschulz>
manuel1985: probably something to do with an environment variable set in your CI that is then used by Bitbake, I have the same thing in Jenkins, so I guess just run printenv in your CI and figure out which variable is the most likely to trigger this behavior?
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
Herrie has joined #yocto
<manuel1985>
qschulz: I think they check if FD 0/1/2 are pointint to stdin/stdout/stderr or actual files.
<manuel1985>
Though bitbake might have a switch to override that, but doesn't seem so.
<manuel1985>
Hrmpf
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
florian has quit [Killed (NickServ (GHOST command used by florian_kc))]
florian_kc is now known as florian
florian_kc has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<manuel1985>
qschulz: `bitbake xyz | cat` does the trick
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
d-s-e has quit [Ping timeout: 252 seconds]
sgw has joined #yocto
d-s-e has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
gho has quit [Ping timeout: 248 seconds]
d-s-e has quit [Quit: Konversation terminated!]
d-s-e has joined #yocto
gho has joined #yocto
Schiller has joined #yocto
sgw has quit [Quit: Leaving.]
davidinux has quit [Ping timeout: 248 seconds]
Guest50 has quit [Quit: Client closed]
Guest79 has quit [Quit: Client closed]
d-s-e has quit [Ping timeout: 248 seconds]
seninha has quit [Remote host closed the connection]
zpfvo has quit [Ping timeout: 260 seconds]
amgedr has quit [Quit: Leaving...]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
Guest50 has joined #yocto
tomzy_0 has quit [Quit: Client closed]
<PhoenixMage>
Command should I run to completely clean out a build (leaving the conf) and start the build from scratch?
<qschulz>
PhoenixMage: rm -rf of everything in build except the conf directory
<qschulz>
do you want to keep the tarballs and/or sstate-cache too?
<qschulz>
or do you really want to start it from scratch like you just git cloned your repos and ran source oe-init-buildenv ?
<PhoenixMage>
I have my downloads external to the build dir as I am building same architecture, different boards. rm -rf everythng except conf is fine with me
<PhoenixMage>
It will build over night
<qschulz>
PhoenixMage: is there a specific reason for wanting to start from scratch?
<PhoenixMage>
Just made a lot of changes and have forced unpacks and all sorts of crap, just like a clean slate now and again
d-s-e has joined #yocto
gsalazar has joined #yocto
<PhoenixMage>
Tomorrow I need to work out why the hell the fitImage wont boot
Payam has joined #yocto
<qschulz>
PhoenixMage: ok, that's a valid usecase :)
<qschulz>
PhoenixMage: did you try without a fitImage first?
<qschulz>
the old way with bootz/booti and zImage/Image + dtb?
<Payam>
rburton You make me read a pdf and watch a video on how to connect S3 to my yocto build
<PhoenixMage>
I believe there was a change to the image standard between the legacy uboot I am using and perhaps the uboot-tools version thats making the image
<Payam>
It was useless
<Payam>
It didn't get technical about S3 at all
<PhoenixMage>
qschulz: I have not, perhaps I should copy them to the emmc directly and give that a shot tomorrow
marek has joined #yocto
<PhoenixMage>
uboot is one of those things that doesnt give you a lot to go on some times https://pastebin.com/Wu4vM66z
<PhoenixMage>
later all
<qschulz>
PhoenixMage: if your system is Aarch64, you are also required to have a BL31 (TF-A/ATF) to boot the kernel
<marek>
Hi on kirkstone when want to use sudo in recipe (creating image and need losetup) I'm getting:
<marek>
```| sudo: error in /etc/sudo.conf, line 0 while loading plugin "sudoers_policy"
<marek>
| sudo: /usr/lib/sudo/sudoers.so must be owned by uid 0
<marek>
| sudo: fatal error, unable to load plugins
<marek>
| WARNING: exit code 1 from a shell command.
<marek>
```
<marek>
while on dunfell this works fine
<PhoenixMage>
qschulz: Really?
<qschulz>
PhoenixMage: yes AFAIR
<PhoenixMage>
Since when? My rk3399 didnt ever require it that I recall
<qschulz>
PhoenixMage: the bl31 is part of U-Boot
<PhoenixMage>
And pretty sure armbian doesnt have BL32...
<qschulz>
it's part of the bootloader
<PhoenixMage>
Oh sorry you said BL31\
<PhoenixMage>
Thats how tired I am
<PhoenixMage>
Yeah uboot wont even start without BL31
<qschulz>
it actually does for me
<qschulz>
just get stuck after Starting kernel...
<qschulz>
anyways, not the issue right now, but remember it if you have nothing after Starting kernel
<PhoenixMage>
Cheers
<PhoenixMage>
Now finish beer and bed
<qschulz>
PhoenixMage: are you sure you used the Image.gz in your kernel-1 image?
<PhoenixMage>
It does say its compressed in the fit Image
<qschulz>
I suspect there is a mismatch between what you says the image is (gzip compressed) in the fitimage and what it is
<qschulz>
could also be that the sha256 is not matching the expected one
<qschulz>
(I would expect the sha to be of the compressed artifact but I remember being surprised by some sha checks in fitImage (mainly related to signature IIRC))
<PhoenixMage>
Is there a way to extract the kernel back out of the fit and check it?
<qschulz>
PhoenixMage: don't you have the .its ?
<PhoenixMage>
I do
<qschulz>
then check the filename in there and run `file <file>` on it
<PhoenixMage>
Its generated by yocto
<qschulz>
also, why are you using imxtract?
<qschulz>
running bootm should be just fine
<PhoenixMage>
Because bootm doesnt work
<PhoenixMage>
So was trying to break down the problem
<qschulz>
ack
<PhoenixMage>
I assume now its related to the kernel part of the fit somehow
<PhoenixMage>
Given I cant extract it
<qschulz>
iminfo returns a valid sha so that's interesting
manuel1985 has quit [Quit: Leaving]
davidinux has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
sakoman has joined #yocto
PascalBach[m] has joined #yocto
zpfvo has joined #yocto
<rburton>
Payam: "use rclone" was what i told you last week. also, sorry for trying to help, won't happen again
Notgnoshi has joined #yocto
<Payam>
rburton you tried to help me yes. but it wasn't what I wanted and I would appriciate your help anytime. I'm sorry I didn't mean it like that.
<Payam>
rburton can you elaburate? I want to connect S3 to my yocto build since I run the build on Github actions. I want it to fetch the cache and downloads from S3. why would I need rclone?
<JPEW>
Payam: You can't "directly" use S3 as sstate, sstate must be a local directory. In order to directly share sstate, between builders, it has to be NFS. You could use S3 as an "upstream" sstate mirror, but you would need to manually populate it's contents after every build you do or there would never be anything in it
<rburton>
read with http, write with rclone
<rburton>
just like the in the presentation
<Payam>
rburton yes I saw it but it was only a presentation of word and not technical. For instance I wan to know where I changed those settings.
<Payam>
and what is the differences between cach state and sstate mirror
<Payam>
?
<rburton>
sstate-cache is local. state mirror can be remote.
<JPEW>
Payam: sstate cache is the SSTATE_DIR variable, it's the only cache bitbake really uses when it builds. The mirror is the SSTATE_MIRRORS variable. If bitbake sees an sstate object is not in SSTATE_DIR, it will search SSTATE_MIRRORS for it, if it finds one it copies it to SSTATE_DIR, then uses it from there
<Payam>
okej
<Payam>
so JPEW if I want to save those caches somewhere so that my CI can fetch them. What service oon AWS should I use? and now I am talking about SSTATE_DIR
<JPEW>
Payam: I have no idea, I don't know much about AWS
<Payam>
rburton Do you know? S3? EC2?
<rburton>
<sigh> use rclone to push a local sstate cache to S3.
<rburton>
fresh worker spins up, local sstate-cache is empty and the sstate mirror set to your s3 repo. it builds, pulling from s3 as needed. when the build is finished, rclone the local sstate-cache back to s3 to add anything that was built.
roussinm has joined #yocto
<Payam>
rburton and then what? do I modify sstate_dir = "https://amazon blablablabal"
<rburton>
sstate-cache is local
<rburton>
read what JPEW said, again
<Payam>
"You can't "directly" use S3 as sstate, sstate must be a local directory. In order to directly share sstate, between builders, it has to be NFS. You could use S3 as an "upstream" sstate mirror, but you would need to manually populate it's contents after every build you do or there would never be anything in it"
sgw has joined #yocto
<Payam>
so I can not populate S3 from the build? I have to do it manually?
<rburton>
correct
<rburton>
your CI script would be something like bitbake myimage ; rclone sstate-cache ...
<Payam>
aha
<Payam>
let me check.
<JPEW>
Payam: To read from S3 for sstate you need to use SSTATE_MIRRORS: https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS I don't know precisely what you need to put there for it to work. Then you need to write back to sstate after the build using rclone, as rburton is saying
<JPEW>
More precisely: "write your local sstate (SSTATE_DIR) back to your S3 mirror after the build using rclone"
<rburton>
there's a s3:// fetcher which presumably is good for that, although i'm not sure what it offers over http://
kscherer has joined #yocto
d-s-e has quit [Quit: Konversation terminated!]
<Schiller>
rburton: Hello. Sorry i contact you directly. But I can't quite understand Buildstep 2 fetch yocto-autobuilder-helper. Why is there a git reset --hard <Revision from RemoteRepo> after i clone the yocto-autobuilder-helper locally? It won't have the revision which the GitPoller detected on the remote repository.
<rburton>
no idea, sorry, I didn't write that
Guest13 has joined #yocto
<Schiller>
rburton: Ok. Can you then confirm that there is always the same branch / revision existing on the repository ssh://git@push.yoctoproject.org/yocto-autobuilder-helper when an upstream change from a repo is detected? I don't have excess and it would already help me a lot to know that.
<Guest13>
hi, everyone.
<Guest13>
i built chromium-ozone-wayland successfully but im getting error on runtime.
<Guest13>
Error Output :
<Guest13>
error : XDG_RUNTIME_DIR not set in the environment
<Guest13>
ERROR:wayland_connection.cc(218) Failed to connect to wayland display: no such file or directory(2)
<Guest13>
ERROR:ozone_platform_wayland.cc(220) Failed to initialize wayland platform
<Guest13>
ERROR:env.cc(255) The platform failed to initialize. exiting.
<rburton>
i'd guess that XDG_RUNTIME_DIR is not set in the environment :)
<rburton>
anything wayland *needs* that, so it's easiest to just use systemd/logind and have the user session set up on login
xmn has joined #yocto
kanavin_ has quit [Quit: Leaving]
Guest50 has quit [Quit: Client closed]
rob_w has quit [Remote host closed the connection]
<Guest13>
rburton using debug-tweaks so i have only root user without password. is it caused by this ? my question might sound silly because im newbie :D
<JPEW>
Guest13: Probably not caused by that
<rburton>
Guest13: create a new user, login as them, use systemd/logind
zpfvo has quit [Ping timeout: 246 seconds]
<Guest13>
rburton i will try, thank you
Guest3 has joined #yocto
Payam has quit [Quit: Client closed]
Guest3 has quit [Client Quit]
zpfvo has joined #yocto
<vvn>
In order to split a package (openvpn) conf into a sub package, one only has to do PACKAGES += "${PN}-foo" and set FILES:${PN}-foo = "...", right?
<rburton>
yes
<vvn>
I'm getting the nothing PROVIDES openvpn-foo but openvpn RPROVIDES openvpn-foo error
<rburton>
remembering ordering, packages are evaluated in order of PACKAGES
<rburton>
PROVIDES != RPROVIDES
<rburton>
don't DEPEND on openvpn-foo
<rburton>
you DEPEND on recipes
<vvn>
yes I know about (R)PROVIDES but I don't understand this error since I just set PACKAGES += and FILES:${PN}-foo
Guest1389 has joined #yocto
<rburton>
something is depending on it
florian_kc has joined #yocto
<rburton>
pastebin the actual error might help
kanavin has joined #yocto
<vvn>
I have RDEPENDS:${PN}-foo = "${PN}" but that shouldn't hurt
<Guest1389>
in dunfell, i was able to create it user like this :
<vvn>
rburton: building the image results in "Unable to install packages." "opkg_prepare_url_for_install: Couldn't find anything to satisfy 'openvpn-foo'."
<vvn>
and only when building the package directly as a bitbake target I get: Nothing PROVIDES 'openvpn-foo'. Close matches: openvpn RPROVIDES openvpn-foo
zpfvo has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
<rburton>
are you bitbaking openvpn-foo
<rburton>
you bitbake a recipe, so bitbake openvpn
<rburton>
the image problem is likely because you didn't actually package anything, so the package doesn't exist
<rburton>
<rburton>remembering ordering, packages are evaluated in order of PACKAGES <-- that
<rburton>
if another package takes the files first, thats where they go
<rburton>
if you're trying to steal something that would otherwise be in PN, then you need your package to be before PN
<rburton>
=+ is your friend here
<qschulz>
rburton: we also have PACKAGE_BEFORE_PN variable for that :)
<vvn>
ho, ${sysconfdir} is included recursively, that makes sense
<vvn>
rburton: thank you! I must admit that I thought PACKAGES =+ was a typo...
sgw has quit [Quit: Leaving.]
<vvn>
rburton: I didn't know that subpackages like these weren't bitbakable though, thanks for that too
<rburton>
you bitbake a recipe, not a package
Guest1389 has quit [Quit: Client closed]
Guest50 has joined #yocto
<vvn>
yep, that makes sense now, I was confusing the two
frieder has quit [Remote host closed the connection]
marek has quit [Quit: Client closed]
Notgnoshi has quit [Ping timeout: 252 seconds]
florian_kc has quit [Ping timeout: 248 seconds]
florian_kc has joined #yocto
<vvn>
when creating a subpackage with PACKAGES =+ "${PN}-foo" which ships its own systemd unit instance, can you enable the subpackage only with SYSTEMD_AUTO_ENABLE:${PN}-foo = "enable"?
roussinm has quit [Ping timeout: 260 seconds]
florian_kc has quit [Ping timeout: 252 seconds]
florian has quit [Quit: Ex-Chat]
<qschulz>
vvn: that's what util-linux does so I guess yes
<rburton>
vvn: yes
<vvn>
I think there's an ordering issue as well with the created .preset file
<vvn>
because my /usr/lib/systemd/system-preset/98-openvpn.preset only contains the default (main package) presets
Guest50 has quit [Quit: Client closed]
marek has joined #yocto
<marek>
When use sudo in recipe in dunfell it works now in kirkstone I'm getting:
<marek>
`| sudo: error in /etc/sudo.conf, line 0 while loading plugin "sudoers_policy"
<marek>
| sudo: /usr/lib/sudo/sudoers.so must be owned by uid 0
<marek>
| sudo: fatal error, unable to load plugins
<marek>
| WARNING: exit code 1 from a shell command.
<marek>
`
<rburton>
don't use sudo in a recipe
<marek>
it's in icustom image creation when need to use losetup + cryptsetup
<marek>
how to avoid it in this case pls?
leon-anavi has quit [Quit: Leaving]
<vvn>
I bet that's because I need to set SYSTEMD_PACKAGES += "${PN}-foo" as well, even though that's not what the documentation describes for this variable.
<rburton>
marek: guess you're in a fakeroot task already?
<marek>
rburton: in custom class when creating dmcrypt image: create_dmcrypt_image
<rburton>
is the task fakeroot?
<marek>
rburton how can check that? it's custom image type
mckoan is now known as mckoan|away
<rburton>
ah, so yeah do_image is fakeroot
<rburton>
in theory "PSEUDO_DISABLED=1 sudo" might work
<marek>
rburton: ok fine so any idea why it works on dunfell and not in kirkstone
<rburton>
most likely because pseudo changed
<marek>
rburton: ok let me try that
<marek>
rburton: when use PSEUDO_DISABLED sudo I'm getting:
<marek>
`sudo: /home/ubuntu/yocto/test/build/tmp/hosttools/sudo must be owned by uid 0 and have the setuid bit set`
<vvn>
rburton: qschulz: indeed I needed to set SYSTEMD_PACKAGES += "${PN}-foo" even though the doc says that it's for the system to find the unit file if not in the main package. But the unit file (openvpn@.service) actually is in the main package. I must rephrase that and send a patch for the doc.
gho has quit [Quit: Leaving.]
Schiller has quit [Quit: Client closed]
zpfvo has quit [Remote host closed the connection]
<marek>
rburton: any ideas what else I can check pls?
<rburton>
marek: i guess thats because sudo is a symlink. try using an absolute path to sudo?
<marek>
rburton: unfortunately more less same when using like:
<marek>
`sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set`
<rburton>
pseudo must still be getting in the way, assuming those assertions are true of the actual file
<rburton>
ah try PSEUDO_UNLOAD=1
<rburton>
i might have got the wrong variable name
olani has quit [Ping timeout: 252 seconds]
<marek>
rburton: `PSEUDO_UNLOAD=1 /usr/bin/sudo losetup $LOOP_DEV $OUTPUT_IMAGE` giving: `sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set`
<rburton>
damnit sudo
<marek>
true
<marek>
but why it works in dunfell
<marek>
rburton: any other trick I can try :)
<fray>
setuid is disabled with LD_PRELOAD is enabled. PSEUDO_UNLOAD=1 will still LD_PRELOAD...
<fray>
You ned to run an intermediate BEFORE sudo and it should work..
<fray>
PSUEDO_UNLOAD=1 /usr/bin/env /usr/bin/sudo ... may work
<rburton>
ah yes, LD_PRELOAD entirely breaks suid doesn't it
<rburton>
thanks fray
<marek>
fray @rbu
<marek>
`PSEUDO_UNLOAD=1 /usr/bin/env /usr/bin/sudo losetup $LOOP_DEV $OUTPUT_IMAGE` gives: `sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set`
sgw has joined #yocto
<fray>
Check if LD_PRELOAD is still being set in some way after /usr/bin/env .. if it is, that is the problem..
<fray>
(might also be an LD_LIBRARY_PATH restriction as well for setuid, I'm less sure about that)
florian_kc has joined #yocto
<marek>
@fray: I've used `PSEUDO_UNLOAD=1 /usr/bin/env echo "${LD_RELOAD}"` and it return: `libpseudo.so`
<fray>
So it didn't unload when the echo was executed
<marek>
fray: also when print env I'm getting :` LD_PRELOAD=libpseudo.so`
<fray>
in the past I ran into this and there was some magic you had to do to completely unload..
<marek>
fray: can I unset LD_PRELOAD maybe?
<fray>
with PSEUDO_UNLOAD "probably". LD_PRELOAD is reset on an exec if NOT unloading
florian_kc has quit [Ping timeout: 252 seconds]
<fray>
PSEUDO is designed to be "persistent" even if the environment is completely cleared.. the PSEUDO_UNLOAD is supposed to disable it and on the next exec no longer load it..
<fray>
there is a test case:
<fray>
export PSEUDO_UNLOAD=1
<fray>
id -u
<fray>
id -g
<fray>
wait no...
<fray>
env -i id -u
<fray>
env -i id -g
<fray>
that should show it's running as "not [emulated] root"
<fray>
then to verify it actually unloaded..
<fray>
add 'env -i PSEUDO_DISABLED=0 id -u'
<fray>
that should show the same as the previous run..
<fray>
(-i clears the environment.. so you should be able to adjust that and check LD_PRELOAD)
<marek>
fray: `sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set`
<fray>
PSEUDO_UNLOAD=1 env -i /usr/bin/sudo ...
<fray>
(if that env -i doesn't work.. then I'm really not sure what to try)
<fray>
there is some built-in pseudo diagnostics that can be enabled to show what it's doing with the LD_PRELOAD, that's probably the next thing to try
<marek>
fray: `sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set`
<marek>
weird
<fray>
I've no idea then.. I'd say try to reproduce it independently of the build system, and try the test cases in pseudo. If they all pass, but this keeps failing.. then enable diagnostics and see what it may be doing wrong.
<fray>
that is what SHOULD be running but clearly it's not working right (or there is something we're missing) if you can add diagnostics to it, that could help..
<fray>
that calls the "without_libpseudo" function, which SHOULD be dropping it via what looks like a regex
nerdboy has quit [Ping timeout: 246 seconds]
goliath has quit [Quit: SIGSEGV]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
Guest50 has joined #yocto
amitk has quit [Ping timeout: 260 seconds]
florian_kc has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
prabhakarlad has quit [Quit: Client closed]
goliath has joined #yocto
marek has quit [Quit: Client closed]
olani has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
marek has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
<marek>
fray: do you think I can create an issue? I'm not sure if will be to able track down what you wrote above ;)
nemik has joined #yocto
<fray>
Probably a good idea. Be sure to include the host, kernel version, etc. There is something odd that has changed and I don't know if it's bitbake, oe-core, pseudo, kernel or glibc
<fray>
but they're all candidates
<marek>
fray: ok will do, thansk for support
<fray>
ya as much about your host environment as possible would be helpful.. even things like the environment before oe-init-build-env might be useful (feel free to sanitize stuff as necessary)
Minvera has joined #yocto
<marek>
fray: sure thanks
prabhakarlad has joined #yocto
<marek>
fray: issue tracker is bugzilla? Cos I cannot create new user
<khem>
RP: I think we need to add -D_LARGEFILE64_SOURCE globally to compiler now that we have enabled largefile support unconditionally I wonder if it should be added via tclibc-musl.inc
<khem>
with glibc _GNU_SOURCE implies _LARGEFILE64_SOURCE but not so with musl
Minvera has quit [Ping timeout: 252 seconds]
kriive has quit [Remote host closed the connection]
Guest50 has quit [Quit: Client closed]
Algotech75 has joined #yocto
Algotech75 has quit [Remote host closed the connection]
amelius_ has joined #yocto
mihai has quit [Quit: Leaving]
roussinm has joined #yocto
amelius__ has joined #yocto
amelius_ has quit [Read error: Connection reset by peer]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
Minvera has joined #yocto
prabhakarlad has quit [Quit: Client closed]
amelius__ has quit [Ping timeout: 260 seconds]
Minvera has quit [Ping timeout: 260 seconds]
Minvera has joined #yocto
Minvera has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
sgw has quit [Quit: Leaving.]
prabhakarlad has joined #yocto
<roussinm>
is Alexandre Belloni present here?
Belgarion has quit [Quit: WeeChat 2.3]
mvlad has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 260 seconds]
florian has joined #yocto
<RP>
khem: I agree, I think the time might be right to do this with largefile and time and then release note it all together
<RP>
roussinm: abelloni
<roussinm>
abelloni: if you can ldd llvm-config in the target sysroot of mesa you can see which library it will load. I will guess that it will load something from the target sysroot since the configuration of mesa fails. The host is x86? Looks like target is x86 too.
goliath has quit [Quit: SIGSEGV]
vmeson has quit [Ping timeout: 260 seconds]
vmeson has joined #yocto
<abelloni>
roussinm: roussinm: unfortunately, the builddir has been cleaned out and the worker is currently running a reproducible build
<abelloni>
once it is done, what I'll do is clean the sstate and try to reproduce
<abelloni>
what is weird is that I never got the issue before I tried your patch
<abelloni>
but then, this built fine on ubuntu1804
<abelloni>
so either we really have just a failure of meson or this is host related
<abelloni>
and your fix is not engouh
goliath has joined #yocto
gsalazar has quit [Ping timeout: 260 seconds]
<RP>
roussinm, abelloni: when I saw the patch I wondered if it might only cause an issue when rebuilding from sstate
<roussinm>
RP: I was able to reproduce this issue without sstate.
<roussinm>
abelloni: Looking at autobuilder failures it looks like my fix might be partial at best indeed.
roussinm has quit [Quit: WeeChat 3.0]
vvn has quit [Quit: WeeChat 3.7]
<moto-timo>
How do people deal with needing OpenSSL 1.1.1 and OpenSSL 3.0.y at the same time? Noodling...
<paulg>
delete them both and install rsh/telnet
<abelloni>
<hand gesture>this is not the openssl version you are looking for</hand gesture>