<geoffhp>
Since the libtool upgrade on master to 2.4.8 my builds fail building polkit with the "libtool: Version mismatch error. This is libtool 2.4.7, but the
<geoffhp>
..." error. I see Khem's patches to fix this error on various other package on the oe-devel mailing list. The strange thing is if I explicitly run do_configiure in devshell or with bitbake -c configure, the do_compile will work. However, if I do a standard 'bitbake polkit' from a clean state, I hit the libtool mismatch error although I see the do_compile step scroll by in bitbake. Any idea on why I can work-around by manually invoking
<geoffhp>
-c configure?
shoragan has joined #yocto
jclsn has quit [Ping timeout: 245 seconds]
jclsn has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
goliath has quit [Quit: SIGSEGV]
jclsn has quit [Ping timeout: 260 seconds]
otavio has quit [Ping timeout: 250 seconds]
jclsn has joined #yocto
otavio has joined #yocto
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
otavio has quit [Ping timeout: 240 seconds]
jclsn has joined #yocto
otavio has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
otavio has quit [Ping timeout: 240 seconds]
starblue has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
camus has quit [Read error: Connection reset by peer]
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
rob_w has joined #yocto
rob_w has quit [Client Quit]
rob_w has joined #yocto
frieder has joined #yocto
lucaceresoli_ has joined #yocto
<RP>
geoffhp: seems odd but I guess something in the first run does eventually clean up the files, just too late to avoid the mismatch? The second run then works. It has to be a second run as the script wouldn't exist otherwise?
<qschulz>
jsbronder: nope, tags aren't reproducible because they can be moved. Been there, done that. Only reproducible way is to point to a commit hash
<qschulz>
hmw[m]: you need a leading space in your PACKAGECONFIG:append
<qschulz>
(before sql-mysql)
<qschulz>
but since the file makes it, it's likely not the issue (but it can be one, so better fix it :) )
leon-anavi has joined #yocto
<hmw[m]>
qschulz: it is from a larger string ( PACKAGECONFIG:append = " accessibility libinput sql-sqlite mtdev sql-mysql dbus xkbcommon" )
mcfrisk has joined #yocto
<mcfrisk>
I hope others can also test the polkit switch from mozjs to duktape. my tests on one product CI look good.
lucaceresoli_ has quit [Quit: Leaving]
lucaceresoli has joined #yocto
<wyre>
hi guys, I've included `apt` in IMAGE_INSTALL but ... I've not available apt command by just doing this 🤔
<wyre>
is it maybe another different recipe? 🤔
<wyre>
I just have apt-get, maybe this is enough
<qschulz>
wyre: what are you plannign to do with apt?
<Schiller>
Is it possible to run a full build in the YPAutobuilder without setting up a Hash Equivalency Server or do i have to provide a local one? My workers fail currently to connect to typhoon.yocto.io:8686: and it just hangs.
<RP>
Schiller: just don't configure one
<wyre>
qschulz, well, I'd like to make modular updates, I mean ... I'd like to retrieve the debs after the bitbake building process and include them into an apt reposotory
<wyre>
is this possible/good idea? or should I reflash the whole image everytime I make updates?
<LetoThe2nd>
wyre: it "depends"
<wyre>
well, I guess there must be described a proper workflow to do this in the doco, right? 🤔
<LetoThe2nd>
wyre: first things first: "apt" is just the fancy new form of apt-get. if you want to use deb-style package repositories, then apt-get will be perfectly enough. secondly, this is actually only somewhat useful during the development stage. you probably don't want the users of your device to type apt commands into a terminal if you want them to get updates.
<LetoThe2nd>
wyre: so in a nutshell - it can be helpful, but only in very limited situations. usually you're much better off understanding your usecase properly first, and then picking an update solution.
<Schiller>
RP: Do you mean i can just throw the BB_HASHSERVE variable in the config.json out? Btw tasks in the created json file get now worked on. I die setup a new OS and started everything from scratch.
<qschulz>
wyre: I've always ever reflashed the whole thing and package updates seem to be a complex beast to me
<RP>
Schiller: just set it to empty, turn it off
<LetoThe2nd>
qschulz: ++
<RP>
Schiller: was that with the latest buildbot or an older version? Glad you have it working though!
<qschulz>
wyre: if you need package updates for basically "rolling releases", think also if debian or the likes aren't more suitable to you?
<qschulz>
as LetoThe2nd said "it depends"
<RP>
wyre: It is documented somewhere I think and there are basic QA tests for it however getting the packages onto an http service and having your image able to find it can be annoying
<pasherring>
wyre, and maybe, during this first "discovery stage" (if this is where you are), it might be useful just running qemu
<LetoThe2nd>
full disclosure: there are companies who offer solutions for tackling this kind of problem and I work for one - mender.io
<Schiller>
RP currently i am on the Buildbotversion you suggested. But it's hard to tell what the problem was before as i was running Linux Mint and now changed it to Ubuntu 18.04 which i will end up running in the Docker then
alessioigor has joined #yocto
<wyre>
I see, thank you very much guys 😊 I'm going to check the links you pasted, hehe
<RP>
Schiller: ok, just a useful data point for me when we upgrade
<Schiller>
RP: There are some dependencies involved when turning off the BB_HASHSERVE. Currently OEEquivHash says it requires it to be set. Is it safe to throw everything regarding to the HASHSERV to empty?
<kayterina[m]>
SRC_URI has the remote git and inside it there are some files and a tar archive. Can it be extracted with SRC_URI?
<rburton>
kayterina[m]: ah no the big problem is you're doing this in do_install which is fakeroot, so tar behaves differently.
jmiehe has quit [Quit: jmiehe]
<rburton>
if root, tar preserves ownership.
<rburton>
i'd do the unpack in a do_unpack[postfuncs]
<rburton>
so all the unpacking happens in the unpack task
<qschulz>
Alban[m]: I'm sorry, I didn't get the question/suggestion, can you rephrase please?
xmn has quit [Ping timeout: 240 seconds]
<Alban[m]>
This anonymous function changes the content of ${PACKAGE} when ptest is in the DISTRO_FEATURES, but this is not properly tracked by the dependency system. PACKAGEGROUP_DISABLE_COMPLEMENTARY and DISTRO_FEATURES should be PACKAGEVARS to be correctly tracked.
<kayterina[m]>
rburton: a,fakeroot...ok thanks. That was the question really, why it did not work during do_install.
<kayterina[m]>
is do_unpack[postfuncs] equivalent to a do_extract task that is appended in do_unpack_append() ?
<rburton>
yes, but not uglty
<Schiller>
RP: I still get some Errors. Can you confirm i edited the necessary lines correctly. In yocto-auto-helper/config.json Line: 63 "BB_HASHSERVE = ' '", Line: 243 "BB_SIGNATURE_HANDLER = 'OEBasicHash'"
<Alban[m]>
But DISTRO_FEATURE only matter when PACKAGEGROUP_DISABLE_COMPLEMENTARY has a specific value. What I'm wondering is how this should be represented correctly.
<RP>
Schiller: what error do you see? Perhaps just remove the BB_HASHSERV line entirely?
<Schiller>
RP in local.json there are multiple BB_HASHSERVE variables. Should i empty them all? Some are set to 'auto'. I just edited the Lines 63 and 243.
<RP>
Schiller: replace the line on 63 with the BB_SIGNATURE_HANDLER = 'OEBasicHash' setting
<Schiller>
RP and line 243 should remain as "BB_SIGNATURE_HANDLER = 'OEEquivHash'" or also beeing edited to BB_SIGNATURE_HANDLER = 'OEBasicHash'
mihai has joined #yocto
selff has joined #yocto
<RP>
Schiller: I doubt you're running the qemuarm-oecore target so it probably doesn't matter
<Schiller>
RP: Seems to be building fine. Thanks for all the advice.
xmn has joined #yocto
<selff>
hello everyone, im running an image with openvpn in rpi4. i enabled "AUTO_SYSTEM_ENABLE" in "openvpn_2.4.9.bb". i also put the existing client_vpn_test.conf file in /etc/openvpn. however, the service cannot run the config. when "openvpn@client.service" is run, it prints the following error: job for openvpn@client.service failed because the control
<selff>
process exited with error code.
<selff>
See "systemctl status openvpn@client.service" and "journalctl -xe" for details.
<selff>
but when I run it manually the vpn works.
<selff>
"openvpn --config /etc/openvpn/client_vpn_test_conf" works manually
goliath has joined #yocto
<qrsBRWNanyall[m]>
Do you have any logs about it?
<qrsBRWNanyall[m]>
Could be a timing issue. That the OpenVPN client tries to connect to early before network is ready etc etc
ardo has quit [Ping timeout: 272 seconds]
ardo has joined #yocto
<selff>
openvpn@client.service status : "openvpn@client.service: Control process exited, code=exited, status=1/FAILURE"
<selff>
Failed to start OpenVPN Robust And Highly Flexible Tunneling Application On client
<selff>
when i check the openvpn --version . i saw "enable_systemd=no " Is it possible that the problem is caused by this?
<mihai>
selff, try placing the config at /etc/openvpn/client.conf
xmn has quit [Quit: xmn]
<selff>
mihai ty, i changed my config name "self_test.conf" to "client.conf" and restart the service, problem gone.
<mihai>
good :)
<selff>
Thanks for help
<selff>
I couldn't find any information about it anywhere. I was probably searching wrong.
<Tamis>
seems to missing the openldap dependency. Has anyone see that?
dv_ has quit [Quit: WeeChat 2.8]
<Tamis>
Only after I corrected the PACKAGECONFIG with the openldap dependency I was able to see:
<Tamis>
LDAP support: enabled (OpenLDAP)
<Tamis>
LDAPS support: enabled
<Tamis>
on curl configuration
<Tamis>
Shouldn't this be corrected on recipes?
sstiller has joined #yocto
wmat[m] has left #yocto [#yocto]
<qrsBRWNanyall[m]>
@selff:libera.chat: next time. Make sure you check journalctl too. It will show in plain text that it can't open the config file or something similar
mak has joined #yocto
mak has quit [Client Quit]
<rburton>
Tamis: guess so, yes. send a patch?
<qschulz>
Tamis: master branch also does not have it so send a patch to be applied against master first
<MrSaturn>
Is there a way to determine where kernel configuration fragements exist either within the regular bitbake environment, or when using devtool?
<mihai>
MrSaturn, you can find available config fragments in the kernel-meta directory, in the linux-yocto work dir
<qschulz>
MrSaturn: just add your cfg file to SRC_URI of your kernel recipe
<Tamis>
rburton: yeah I will do so.
<MrSaturn>
The base class will know the files ending in .cfg are to be applied to the .config file? and .patch files patch source? Alright, I will give that a shot. Fragments are _way_ more confusing to me than patches
<rburton>
just write your own fragment that does the assignments you want
<mihai>
MrSaturn, yes, write a .cfg file and add it to SRC_URI and the class will know what to do, same with .patch
<MrSaturn>
mihai: I did that, and when I ran "devtool modify virtual/kernel" the source in the workspace does not have the .cfg fragments applied. The fragment files are visible in a directory called "oe-local-files"
<qschulz>
MrSaturn: devtool modify only patches the source files, but config fragments are applied before do_compile is run
<qschulz>
at least that's my quick reading of kernel-yocto.bbclass
<qschulz>
so it's normal, just too early in the process
<qschulz>
do_kernel_configme seems to be the task that needs to run to configure the config
mak_gr has joined #yocto
pgowda_ has joined #yocto
<RP>
JPEW: do you happen to be around? or still away? Had a question about asyncio
<MrSaturn>
qschulz: thanks, I will try that out. I was trying to parse through the class file and getting lost.
* RP
is just wondering whether the hash equivalence siggen client code needs to call .close() and since it doesn't do that (as far as I can tell), would that cause bitbake to hang at exit?
<JPEW>
RP: Ya, possibly. Is there a defined way to know when bitbake is "done" ?
<RP>
JPEW: we'd have to add something, the way siggen is hooked in right now is horrible
<RP>
JPEW: I'm just not clear if the lack of a close() call could intermittently lock up the server exit?
<JPEW>
RP: That seems the most likely culprit for the warning, given it's one of the few places we use asyncio
<JPEW>
Not sure about if that can cause the lockup, but it should probably be fixed either way
<RP>
JPEW: the warning may or may not be a problem, it was just a possible lead
<RP>
but yes, perhaps better to fix anyway
lucaceresoli has quit [Quit: Leaving]
lucaceresoli_ has joined #yocto
lucaceresoli_ has quit [Client Quit]
jclsn has quit [Quit: Ping timeout (120 seconds)]
jclsn has joined #yocto
Schiller has quit [Quit: Client closed]
<kayterina[m]>
when PV is set inside a recipe_0.1.bb to this value
<kayterina[m]>
PV = "1.0+git${SRCPV}
<kayterina[m]>
where does it help? To not rename the .bb file version on every new commit to the source?
<qschulz>
kayterina[m]: this is usually used with AUTOREV
<qschulz>
and yes, it's to have a workdir specific to this version (and probably also make this work with package managers when trying to install packages from different commit hashes)
<kayterina[m]>
I have a project where many(perhaps all) files have set SRCREV to a revision and also set PV.
<kayterina[m]>
so this is a valid set of the variables in a .bb? SRCREV = "${AUTOREV}" PV = "1.0+git${SRCPV}"
<qschulz>
kayterina[m]: yes but not recommended
<qschulz>
as this means you never have reproducible builds
<qschulz>
ok for development
<qschulz>
definitely not okay for releases
amitk has quit [Ping timeout: 260 seconds]
lucaceresoli has joined #yocto
amitk has joined #yocto
akiCA has joined #yocto
sstiller has quit [Quit: Leaving]
<LetoThe2nd>
whats the best practise to patch something in a git submodule that is being pulled in by a recipe?
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
<qschulz>
LetoThe2nd: are you using gitsm fetcher inm SRC_URI?
<LetoThe2nd>
qschulz: nope, go magic is involved :(
<LetoThe2nd>
it would be enough to patch the resulting state, but git add doesn't pick it up because of the submodules.
mak_gr has quit [Quit: Client closed]
<jsbronder>
qschulz: Regarding tags, sure, they can be moved. And we do point to the annotated commit sha in our recipes. Luckily my org isn't so nuts as to move or delete tags. Shas can disappear too if you want to be truly paranoid ;)
RobertBerger has joined #yocto
<qschulz>
jsbronder: that's fine, tags moving, less. Because then you'll be building something you weren't expecting and you will not know about it
rber|res has quit [Ping timeout: 252 seconds]
<qschulz>
jsbronder: sha disappearing should be handled by your org with a mirror
<jsbronder>
I took steev_'s question to only be regarding internal apps.
<jsbronder>
git will eventually delete any unreachable objects, even on a mirror.
<jsbronder>
anyways, I think we agree vigorously, point at the sha of a tag.
<qschulz>
jsbronder: you can deactivate git gc :) but in any case, you can host a PREMIRROS on your premises which will save whatever's needed by bitbake to build your package
Guest8 has joined #yocto
<qschulz>
but yes, we agree :)
amitk has quit [Ping timeout: 240 seconds]
<Guest8>
bitbake question. I'm trying to override a config file. My local .bbappend contains "FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:". However I have another layer I'm inheriting that also tries to override this file using it's on bbappend and FILESEXTRAPATHS_prepend. I added a do_install_append() to my .bbappend and installed
<Guest8>
"my file" to a different path and sure enough it actually installs the file from the other inherited layer. I've altered the priority of my layer in my .conf to be lower than this inherited layer and it makes no diff. What is the solution? Also, I ran bitbake -e but FILESPATH (which I thought was generated from all the
<Guest8>
FILESEXTRAPATHS_prepend and overrides) in the output doesn't contain either my directory or the inherited directory which seems odd.
amitk has joined #yocto
<qschulz>
Guest8: ${WORKDIR}/temp/log.do_fetch will tell you which paths and in which order are traversed to find your file
<qschulz>
typically, if the path relative to FILESEXTRAPATH entry is not the same, whatever the priority is won't matter
<qschulz>
specifically, one can use OVERRIDES in file paths without specifying the OVERRIDE in SRC_URI
<qschulz>
Guest8: which version of Yocto are you using?
<qschulz>
might also be that it should be FILESEXTRAPATHS:prepend actually
<qschulz>
Guest8: ok, so _append should work just fine
<Guest8>
so I just invoke ${WORKDIR}/temp/log.do_fetch in my append() rule?
<qschulz>
Guest8: no no no, it's a log file, it'll just tell you which files are fetched and from where
<Guest8>
oic
<landgraf>
oh. summer time :-/
jmiehe has joined #yocto
<rfs613>
qschulz: you know, when it takes a 75+ page slide deck to "demystify" a concept, that says something about the concept ;-)
Tokamak has quit [Ping timeout: 240 seconds]
<sgw>
Morning all
<qschulz>
rfs613: I wrote the slides in such a way that it isn't necessary to listen to me for 30min :)
<sgw>
Well I think I found a silent failure: NOTE: Command '['depmodwrapper', '-a', '-b', '/srv/nvme/yocto/poky/builds/dbg/tmp/work/genericx86_64-poky-linux/core-image-full-cmdline/1.0-r0/rootfs', '5.15.22-yocto-standard']' returned -11:
<sgw>
b''
<qschulz>
so it's a bit more verbose than usual
<rfs613>
qschulz: I do appreciate the slide deck, have referred to it several times (and probably more to come).
<sgw>
digging deeper into rootfs construction
<rfs613>
I do wonder if all these special cases are really needed, could we not simplify and get rid of most of them? I'm sure it's been discussed... and it would be a mega project, more complex than the recent override syntax change.
Tokamak has joined #yocto
mihai has left #yocto [Leaving]
<qschulz>
rfs613: each special case actually has its usecase so it's difficult to just say to remove them. I don't think anything is not up for debate, just need to formulate something and offer some implementation or suggestion
<qschulz>
there are complex and confusing areas in YP/Bitbake for sure
<qschulz>
the _ override syntax was one
mihai has joined #yocto
mnme has joined #yocto
prabhakarlad has joined #yocto
<mnme>
Hi all! Is anyone else experiencing very slow download speeds from downloads.yoctoproject.org?
<rfs613>
mnme: it's been reported a few times in the past days...
Guest8 has quit [Quit: Connection closed]
<sgw>
RP: so it looks like depmodwrapper has been failing silently in master, not sure for how long
* sgw
hates finding hidden issues
<mnme>
rfs613: Okay, so it's not a problem on my end, that's good to know
<mnme>
I currently have a per-branch download directory on my build server. Could using a single download directory with concurrent builds lead to problems? (I'm still on dunfell)
<qschulz>
it's actually recommended to share them
<qschulz>
same for SSTATE_DIR
jmiehe has quit [Quit: jmiehe]
<mnme>
Perfect, thanks. I knew about sstate being fine to share (I think there was even some conversation about it in the mailing list recently), but wasn't sure for the downloads
<RP>
sgw: ah. We need better tests too :/
<sgw>
Yeah, I will try to address that also, first I need to figure out what's broken
<sgw>
In Master: ResourceWarning: Enable tracemalloc to get the object allocation traceback
frieder has quit [Remote host closed the connection]
<khem>
geoffhp: I think key is to regenerate aclocal.m4
<khem>
before running further tasks
<smurray>
khem: I'm also seeing polkit failing here with libtool version errors, nuking the libtool m4 files from its buildutil dir seemed to work. I guess your test builds aren't seeing it fail, though?
<rfs613>
mnme: I build on dunfell with a single download directory shared by multiple concurrent builds. Mostly works fine. Had some hiccups with cve-check (seems to be resolved for me now) and also with some local packages that make use of MIRRORs feature. No issues for any of the regular poky/meta-oe/etc recipes.
<mnme>
rfs613: Thanks for confirming. I'll use a shared directory and see if anything breaks.
<khem>
smurray: yoe distro does not use pollkit
mnme has quit [Quit: Client closed]
mnme has joined #yocto
<smurray>
khem: it gets pulled into the AGL demo image these days. I'll send a patch in a bit
<smurray>
khem: speaking of kits, I noticed recently when I went to try an experiment with it that rtkit isn't in meta-oe, do you see any value to carrying it there?
pgowda_ has quit [Quit: Connection closed for inactivity]
mnme has quit [Quit: Client closed]
Tokamak has quit [Ping timeout: 240 seconds]
Tokamak has joined #yocto
Tamis has quit [Quit: Client closed]
Minvera has joined #yocto
<khem>
yes it could be
<khem>
thanks for a patch
bantu has quit [Quit: bantu]
Tokamak_ has joined #yocto
bantu has joined #yocto
Tokamak has quit [Ping timeout: 240 seconds]
<smurray>
khem: my interest was for using it with pipewire, but the newest versions of that have some code to poke the rt prio directly if it is run as a system service (which we currently do in AGL)
<smurray>
khem: I'll think about shifting rtkit, the recipe I found in the layer index did seem to work fine. I have to afk for a bit, will send a patch for polkit when I get back
florian has quit [Quit: Ex-Chat]
akiCA has quit [Ping timeout: 240 seconds]
florian_kc has quit [Ping timeout: 256 seconds]
rfuentess has quit [Remote host closed the connection]
kevinrowland has joined #yocto
mckoan is now known as mckoan|away
dev1990 has joined #yocto
akiCA has joined #yocto
amitk has quit [Ping timeout: 252 seconds]
<dirtyflag>
hi, getting this error: ERROR: Nothing RPROVIDES 'nativesdk-qtcreator-mel' but qtcreator-mel_1.0.bb is in the layer
<LetoThe2nd>
dirtyflag: does the recipe actually provide native?
<geoffhp>
RP:, khem:, smurray: Thanks for the reponse re polkit libtool upgrade. Looking forwared to the patch
<vvn>
the /dev/root device in the default wic fstab is only there as info, right? you might symlink your root device to /dev/root if you want this line to be applied but that's not the default behavior, correct?
bantu has quit [Quit: No Ping reply in 180 seconds.]
bantu has joined #yocto
kevinrowland has quit [Quit: Client closed]
prabhakarlad has joined #yocto
<RP>
khem: bitbake codes it and the manuals do mention it I think?
<RP>
jonmason: that was a really bizarre one - the same worker ran two of the same build at the same time and it broke by corrupting the layerinfo.json file
<RP>
jonmason: it isn't supposed to be possible to do that
<RP>
jonmason: probably in the ignore until happens again pile
<jonmason>
thanks
prabhakarlad has quit [Quit: Client closed]
Minvera has quit [Remote host closed the connection]
GNUmoon has quit [Ping timeout: 240 seconds]
GillesM has joined #yocto
rob_w has quit [Read error: Connection reset by peer]
lucaceresoli has quit [Ping timeout: 240 seconds]
<abelloni>
I was really wondering what happened to this one
leon-anavi has quit [Ping timeout: 256 seconds]
<RP>
abelloni: I don't know how it happened, just that the logs say it did :/
mak_gr has joined #yocto
<RP>
abelloni: you got the efi bug and the tinfoil one in the same build :/
GillesM has quit [Quit: Leaving]
a849572 has joined #yocto
a849572 has quit [Read error: Connection reset by peer]
leon-anavi has joined #yocto
a849572 has joined #yocto
leon-anavi has quit [Client Quit]
mvlad has quit [Remote host closed the connection]
a849572 has left #yocto [Leaving]
mak_gr has quit [Quit: Client closed]
Guest79 has joined #yocto
GNUmoon has joined #yocto
<Guest79>
Is there a recipe for telegraf or influxdb ?
GillesM has joined #yocto
<khem>
Guest79: I had then in meta-influx but have not kept them uptodate