<Guest42>
somehow the names get mixed up and can't be found when trying to deploy p11-kit
alessioigor has joined #yocto
Guest40 has joined #yocto
Guest42 has quit [Ping timeout: 250 seconds]
<neverpanic>
Guest42: The *recipe* name is libtasn1, that does not mean that the *package* name cannot be libtasn1-6. Those are different namespaces, and if you have debian renaming enabled, packages that contain only libraries are automatically renamed to match the library's SONAME and SOVERSION.
<mckoan>
Guest40: does 'bitbake p11-kit' work ?
<mckoan>
Guest42: does 'bitbake p11-kit' work ?
Guest64 has joined #yocto
Guest40 has quit [Ping timeout: 250 seconds]
xmn has joined #yocto
<Guest64>
neverpanic: thank you for your response. but I still don't get it why the libtasn1-6 package is not found. As far as I can tell, I'm not doing something wired and debian renaming seems to be the default?
<Guest64>
mckoan: bitbake p11-kit works
<Guest64>
I'm getting the error when I try to install myPackage (which depends on p11-kit) in qemu:
<mckoan>
Guest64: sorry, I mean opkg opkg list_installed
<mcfrisk>
Guest64: what neverpanic said, the issue is with Debian package renaming. use RDEPENDS name libtasn1 which is different than the actual opkg binary package name libtasn1-6 after Debian package rename
<Guest64>
mckoan: both invokations (with list_installed) did not return anything
<mckoan>
Guest64: you are installing packeges manually instead of including them in the final image. Did you properly setup opkg config on target and host side?
<rburton>
khem: personally i'd be removing e-d-s-native entirely. it just builds two files, do those in a do_compile:prepend. (and curse cmake for being terrible at cross compiling)
<rburton>
but yes setting GNOMEBASEBUILDCLASS=cmake is the correct thing to do anyway. it doesn't use autotools.
<Guest64>
mckoan: the actual delopy step I illustrated is used only during development. I'm not responsible for setting up opkg on target/host, this is provided by coworkers of my company and seemed to worked fine until now.
<mckoan>
Guest64: maybe, but your configuration doesn't manage package dependencies ore are not built
<Guest64>
mckoan: myPackage depends on various other packages. Only after I added p11-kit the problem showed up. Therefore, I assume that dependencies are managed, but it seems to have problems with Debian-renamed files. Could you maybe provide me a pointer where to find information on that topic. I'm quite new to yocto and sometimes it's hard to even know
<mckoan>
Guest64: how and where did you add p11-kit? You said is not installed.
Guest18 has joined #yocto
jmiehe has joined #yocto
jmiehe has quit [Quit: jmiehe]
alessioigor_ has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor_ is now known as alessioigor
Guest64 has quit [Quit: Client closed]
Guest13 has joined #yocto
<Guest13>
mckoan: sorry for rejoining all the time (and hence changing the user name), but i regularly loosing connection all the time. in my recipe I add it like this:
<Guest18>
Can someone help me how i can fix this issue in the warrior ? As if i checkout to other branches of meta-security(zeus,dunfell) i am getting conflict errors while building.
<rburton>
kanavin: the patch cleanup in the py3.12 upgrade is nice to see :)
Guest18 has quit [Quit: Client closed]
<kanavin>
rburton, this update took me almost two months :-/
<rburton>
worth it, thanks muchly
<rburton>
i suspect 3.12 is going to take a while to trickle out into all the distros
<kanavin>
rburton, sadly the so-called 'mikey special' lives on in setuptools, as distutils isn't actually removed, but de facto moved there, and the 'hack' had to follow
<kanavin>
rburton, I have 3.12 on latest fedora here
<kanavin>
they can build python without rebuilding any of its consumers (or checking that they even work, apparently)
<kanavin>
'Signed-Off: Michael 'Mickey' Lauer <mickey@vanille-media.de>' this one
alperak has quit [Quit: Client closed]
<rburton>
kanavin: yeah the fun of most other distros is that they get away with adding new stuff without forcing a rebuild
<kanavin>
rburton, that has a cost too, if you want to locally build your .deb and it fails in mysterious ways
<kanavin>
(upstream .deb I mean)
<kanavin>
I need a break from 'version updates', there's still rpm 4.19 to finish up, but then I'll do something else for a bit :)
<rburton>
yeah, it has a big cost, just spread out over time and people. I think i prefer our way in the long term.
alperak has joined #yocto
<kanavin>
I like not having a 'distro vendor'. Even one as benevolent as Debian - just look at the vicious war they had over systemd. Something yocto entirely sidestepped.
davidinux has quit [Ping timeout: 264 seconds]
davidinux has joined #yocto
<kanavin>
Now can we please not have silicon vendors either
<kanavin>
ideas how to make that happen? :D
astlep550401 has quit [Ping timeout: 245 seconds]
astlep550401 has joined #yocto
camus has quit [Quit: camus]
goliath has joined #yocto
Vonter has quit [Ping timeout: 246 seconds]
Vonter has joined #yocto
<JaMa>
heh Bitbake still alive (no events for 39000s). Active tasks: (and no active tasks shown, just setscene tasks running, which doesn't count as a event?)
<RP>
JaMa: where is that running? any chance of a python backtrace?
<JaMa>
it's world build on lge jenkins running for 10+ hours already (sometimes takes 24+ hours to finish, so time itself isn't surprising), but it's first time I've noticed this message without active tasks in the middle of the build (sometimes it's shown before the tasks start running)
<JaMa>
will check cookerlog once the job eventually finishes (it's printed in jenkins console after build)
<JaMa>
and it's happening in 2 builds from 9 triggered with latest master yesterday
<RP>
JaMa: there is a new interesting thing too, the eventlog if you can grab that somehow
<RP>
kanavin: this sounds similar to what you described
<RP>
If someone has an eventlog from one of these builds I can take a look
<JaMa>
will try to get credentials for the node it runs on to get it
<RP>
kanavin: I realised we might be able to use toaster to investigate these logs. I already found one bug :/
wooosaiiii has joined #yocto
<JaMa>
RP: do you want whole 214MB log or just the end of it or just the classes without vars?
<JaMa>
setscene tasks were finished after 11hours and now it runs the regular tasks without the "still alive" messages
Xagen has joined #yocto
<RP>
JaMa: probably the whole thing, it should compress. Its the timestamps of the task start/finishes I want to try and extract somehow
<RP>
Sadly importing this into toaster rebuilds the stamps :(
prabhakarlad has quit [Ping timeout: 250 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Guest13 has quit [Ping timeout: 250 seconds]
prabhakarlad has joined #yocto
Vonter has quit [Ping timeout: 255 seconds]
Vonter has joined #yocto
jmd has joined #yocto
JerryM has quit [Quit: Konversation terminated!]
prabhakarlad has quit [Quit: Client closed]
prabhakar has quit [Quit: Connection closed]
rcw has quit [Ping timeout: 256 seconds]
prabhakar has joined #yocto
prabhakarlad has joined #yocto
<khem>
RP: I can create an empty do_configure to shunt the one coming from cmake class but I thought deltask would be better
<khem>
rburton: yeah having that merged into main recipe might be a good idea perhaps a thing for follow up
florian has quit [Quit: Ex-Chat]
<landgraf>
what's the best way to pass KCFLAGS to the kernel make command? I tried "export KCFLAGS=" in do_compile:prepend() and it doesn't seem to work
<rburton>
khem: gmime libgxim glade telepathy-glib raptor2 are mine, i'll fix. gutenprint doesn't look like me.
<landgraf>
vmeson: I guess users may use it for creating/verifying of the certificates
<vmeson>
landgraf: yeah, I've never done that myself and it seems like an unusual requirement. I guess it's time to learn more about openssl certificates.
<rburton>
vmeson: you might be building signed code in the SDK and need to use openssl for that
<khem>
rburton: | rmdir: failed to remove '/home/pokybuild/yocto-worker/meta-oe/build/build/tmp/work/core2-64-poky-linux/gutenprint/5.3.4/image/etc': Directory not empty
<vmeson>
rburton: signed code - ugh, sounds Orwellian! ;-)
<rburton>
khem: yeah i didn't touch anything there
<khem>
does gtk_doc changes emit something into it ?
<rburton>
not afaict
<rburton>
i accidentally deleted my build tree and now for some reason it wants to rebuild from scratch
<khem>
then i would blame inherit_defer next
<khem>
heh thats not accident, its just too much drinks :)
<rburton>
lol i wish
<Nonkel>
Vmeson: yes, but where do I need to copy this in my custom layer? Its all new for me, I read already the documentation but it is still more Chinese then English and clear. I need to modify imx_atf with a bbappend
<landgraf>
Nonkel: you don't have to copy original bb into your layer
<khem>
I also see it reported on internet in few posts, Does this test 10ddf-fail-spare work in AB runs ?
<khem>
btw. thats the last issue remaining for core-image-ptest-all to run clean when built with clang + llvm runtime
<Nonkel>
rburton: I got a BSP from my board supplier, now there is a problem, I received a bbappend file for solving this problem imx_atf
mckoan is now known as mckoan|away
<rburton>
Nonkel: worst case just copy the bbappend alongside the recipe, but you should have your own layer for your customisations/distro/recipes. if you don't have one, consider making one.
<Nonkel>
rburton: I got my own layer, with a directory conf, recipes-example. So I need to add directory distro/recipes?
<rburton>
Nonkel: create a recipes-bsp/imx-atf/ directory in that layer and put the bbappend in it
<rburton>
(naming doesn't matter, you could put it in recipes-examples/fofofofo for all bitbake cares, but sensible structure is sensible)
<RP>
JaMa, kanavin: looks like we don't have timestamps in the events :(
<RP>
I definitely thought about doing it but clearly never did
<RP>
rburton: that was probably partly the blocker on the timestamps in logs
<RP>
khem: mdadm can pass so it at least sometimes works
<RP>
khem: landgraf is looking at cleaning up the mdadm recipe and possibly disabling the tests
<Nonkel>
rburton i did is, now when i run bitbake i got "No recipes in default available for:"
<khem>
RP: OK, I will send a patch meanwhile to mark this one test broken
<rburton>
Nonkel: that's only half the error but it sounds like the bbappend doesn't actually match the recipe name you expect. the bbappend name has to match the recipe.
<khem>
it fails same way with clang or gcc, It must be my build host which makes it consistent dont know
alimon has joined #yocto
prabhakarlad has joined #yocto
zpfvo has quit [Remote host closed the connection]
<Nonkel>
i got this error: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'file://0003-plat-imx8mm-tauri-l-use-uart4-as-rs485.patch'), but the file is in the same directory where the bbappend
<rburton>
Nonkel: put the patch in a folder called files/ alongside the bbappend (or whatever directory the bbappend specifies in FILESEXTRAPATHS)
<rburton>
if it doesn't set a FILESEXTRAPATHS then they've sent you a broken bbappend
<rburton>
khem: aaah so it looks like the bulk of those failures are from recipes that don't inherit gtk-doc but now try to configure the docs as autoreconf will do that
<rburton>
khem: so good news is easy fixes, just waiting for stuff to build
<Nonkel>
i create a directory files and moved the file, now it is building
<khem>
rburton: good deal
florian has joined #yocto
rcw has quit [Ping timeout: 264 seconds]
kpo_ has joined #yocto
<rburton>
khem: gutenprint isn't me, builds fine with master
<rburton>
but i've touched the recipe in the past and it's "fun"
<rburton>
other patches about to be posted
kpo has joined #yocto
kpo_ has quit [Ping timeout: 264 seconds]
rcw has joined #yocto
<khem>
cool ok, gutenprint could be an intermittent issue too, I have seen it fail in past
<rburton>
posted
alperak24 has joined #yocto
<khem>
yeah thanks for sending series, b4 shazam 'ed it
alperak has quit [Ping timeout: 250 seconds]
kpo_ has joined #yocto
kpo has quit [Ping timeout: 245 seconds]
alperak24 is now known as alperak
goliath has joined #yocto
florian has quit [Ping timeout: 264 seconds]
<vvn>
yocto/bitbake has no variable to describe the current oe-core version or templateconf being used, right?
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
simonew has joined #yocto
kevinrowland has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
sukbeom has quit [Quit: Ping timeout (120 seconds)]
jmd has quit [Remote host closed the connection]
sukbeom has joined #yocto
<kevinrowland>
Super high level question - not looking for a huge amount of help, but hoping someone recognizes the issue off the top of their head: a recipe's do_configure task calls a script that calls `pip install`; the `pip install` command fails in the bitbake task, but succeeds when I use the recipe's devshell and run `run.do_configure` directly. The error
<kevinrowland>
from `pip` in the bitbake task is a "Temporary failure in name resolution", so a DNS issue of some kind? I'm using Mickledore, trying to fetch a package from https://pypi.org
jmd has joined #yocto
<kevinrowland>
So why a DNS failure in the task, but not in the devshell? It could very well be an issue with the recipe, which I'm looking into. This has popped up as I'm upgrading from Hardknott to Mickledore, if that helps.
jmd has quit [Remote host closed the connection]
florian has joined #yocto
<neverpanic>
kevinrowland: do_configure doesn't have network access, it's run in a network namespace without a route
<neverpanic>
The proper way to do this is to use one of the bbclasses that deals with installing python modules from pypi, it'll have a correct do_fetch task that also ensures the sources end up in your download cache and the license compliance tasks package the correct source code (none of which works if you just pip install in do_install)
vladest has quit [Remote host closed the connection]
<kevinrowland>
neverpanic: thank you - and understood about the bbclass. the struggle will be bitbake-izing a setup script that's used outside of bitbake, and then keeping it all in sync. that'll be a problem for another day
<neverpanic>
if your outside script doesn't already correctly cross-compile, that work probably needs to be done one way or the other anyway
Nonkel has quit [Quit: Client closed]
<kevinrowland>
oh its for some host tools that are required for some autogen stuff at build time