<jclsn[m]>
Think this happens since I fetched the latest commits from linux-fslc
hoba has joined #yocto
<jclsn[m]>
I already tried `bitbake -c cleanall libxkbcommon`
tre has joined #yocto
goliath has joined #yocto
hoba has quit [Quit: Client closed]
lucaceresoli has joined #yocto
Etheryon has joined #yocto
frieder has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
rob_w has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
tgamblin_ has joined #yocto
tgamblin has quit [Ping timeout: 240 seconds]
kroon has joined #yocto
<jclsn[m]>
Really weird error. Happens with mesa and wayland-utils as well. Something must have changed in meta-freescale again
<jclsn[m]>
If I interpret it right, something in the SDK is missing
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
<kroon>
huh. just got "ERROR: Worker process (943374) exited unexpectedly (1), shutting down..." in up2date dunfell
dev1990 has joined #yocto
michalkotyla has quit [Quit: michalkotyla]
Tokamak has quit [Ping timeout: 240 seconds]
Tokamak has joined #yocto
Schlumpf has joined #yocto
leon-anavi has joined #yocto
qschulz has quit [Remote host closed the connection]
<dwagenk>
jclsn: when packaging shows weird errors I usually get rid of TMPDIR and rebuild from sstate. I remember one occasion where even that wasn't enough and I switched from `PACKAGE_CLASSES = "package_rpm"` to `PACKAGE_CLASSES = "package_deb"`, rebuild and then switched back to fix it. I couldn't reproduce that Issue, otherwise I'd have written a bug-report.
<dwagenk>
^ jclsn
Tokamak has quit [Ping timeout: 250 seconds]
qschulz has joined #yocto
Tokamak has joined #yocto
pgowda_ has joined #yocto
florian has joined #yocto
Habbie has joined #yocto
pasherring has joined #yocto
mvlad has joined #yocto
<jclsn[m]>
<dwagenk> "jclsn: when packaging shows..." <- Thanks, I tried deleting tmp
<jclsn[m]>
Currently I am having device tree issues with linux-fslc though. It reports syntax errors, although the same tree has always worked in the past
<jclsn[m]>
Seems that the device tree include syntax with `#include` is not accepted anymore
<jclsn[m]>
Has something in `devicetree.bbclass` changed?
<kroon>
the dts needs to go through cpp for "#include" to work
osama3 has joined #yocto
<jclsn[m]>
kroon: Yes, I read that, but haven't really changed anything
<jclsn[m]>
Also the imx8mm.dtsi uses this syntax
<jclsn[m]>
So it seems to be normal syntax in meta-freescale
<jclsn[m]>
or linux-fslc
meego has joined #yocto
tnovotny has joined #yocto
<jclsn[m]>
I recently fetched the upstream changes from linux-fslc. Something must have changed there
prabhakarlad has quit [Quit: Client closed]
Schlumpf has quit [Quit: Client closed]
<RP>
Saur[m]: I merged your changes but sadly a test failure slipped through in all the patch juggling. I'm hoping my tweaks help resolve it
<Etheryon>
Hello, I'm trying to install a local RPM, but I get this error when running the recipe. cpio: /opt: Cannot change mode to rwxr-xr-x: Operation not permitted (in additino to others Permission denied) any idea how I can investigate this?
<kanavin_>
Etheryon, where is the rpm coming from?
<Etheryon>
downloaded from a website
<Etheryon>
it's an external tool for which the company provides rpm for installation
<kanavin_>
Etheryon, you can't install random rpms onto yocto images
<kanavin_>
Etheryon, that rpm was build for a specific distribution, probably RHEL or Fedora, and isn't meant for yocto
<kanavin_>
Etheryon, is the source code for the tool available?
<Etheryon>
nop, commercial tool
<Etheryon>
OK, thanks, I'll look into another way of installing it
<pgowda_>
Downloaded latest master sources and ran bitbake meta-toolchain
<pgowda_>
binutils-cross-x86_64-2.38-r0 do_fetch is running for more than 2 hrs (unusually)
<pgowda_>
Tried on 2 machines with same issue
<pgowda_>
Plz let me know if anyone else is facing same issue
otavio has joined #yocto
<Etheryon>
If I have a shell script that's an installer, should I run it in my recipe in do_install ?
<kanavin_>
Etheryon, yes, if the shell script can be directed to install to ${D}
<kanavin_>
otherwise, run the script outside of yocto, then make a tarball of what it writes out
<kanavin_>
then put the tarball to SRC_URI
<kanavin_>
Etheryon, even then, the tool is probably using specific shared libraries, which yocto may not be able to provide
<Etheryon>
I've looked in the rpm, and it seems it's a java app, so I'm hoping it's fairly self-contained?
<Etheryon>
ugh, seems like the shellscript also ends up trying to install an rpm package
<rburton>
see if it has a 'just unpack the contents' option
tre has quit [Ping timeout: 240 seconds]
<rburton>
(installers are the worst)
<Etheryon>
seems to do this eventually. - installCmd="rpm -U --replacepkgs --oldpackage '$packageFilePath'"
Schlumpf has joined #yocto
<Etheryon>
and runs it
<rburton>
*worst case* create a 'rpm' script that just does exit 0, and put it in PATH before running the installer
<rburton>
is this a hand-written installer, or is it generated by a tool?
<Etheryon>
can I reverse engineer the rpm and install it manually? Sorry I haven't worked with packages before
<rburton>
i'm guessing the installer is one of those where its a giant shell script with the binaries embedded in it
<Etheryon>
I'm guessing by a tool
<Etheryon>
yeah seems so
<Etheryon>
.pkg__commencement
<Etheryon>
xar!
<Etheryon>
�
<Etheryon>
contains that
<Etheryon>
so I'm back to square one
<rburton>
is this public?
<RP>
Etheryon: if you have an rpm, I'd just try and extract the files manually and see if they're usable
<Etheryon>
so the rpm has got 2 jars in it and a shell script file
<RP>
I think the rpm2cpio.sh script in scripts/ in oe-core may help create something you can get files from out of an rpm
<rburton>
put the rpm in src_uri, bitbake will unpack it for you, ignore the installer, just put the jars in the right place
<Etheryon>
when I tried that I got that permission error I mentioned earlier
<Etheryon>
cpio: /opt: Cannot change mode to rwxr-xr-x: Operation not permitted
<Etheryon>
cpio: Cannot mkdir: Permission denied
<RP>
It sounds like it is is trying to extract the files into the main host OS root filesystem :(
<Etheryon>
eventually cpio -id failed with return value 2
<RP>
Etheryon: you could try manually extracting the files using the rpm2cpio.sh script. It is possible the rpm extraction code isn't working properly :/
<RP>
Etheryon: it doesn't get used often and problbably doesn't have good tests :(
<landgraf>
rpm2cpio *rpm | cpio -id should work
<landgraf>
if it doesn't... something wrong with the rpm I guess
<RP>
something like an ;unpack=0 in the SRC_URI should stop bitbake trying to do it for you which may be where the error comes from
<Etheryon>
should that extract it in the local folder?
<RP>
check the manual for the right param, I'm not 100% sure
<Etheryon>
so is it enough to copy over the contents of this archive?
<RP>
smurray: we generate one and use it to build the rpm but it isn't included in the rpms themselves
<smurray>
RP: okay, TIL ;)
<smurray>
Etheryon: you'll have to see what all those shared libraries expect to be able to link to, as kanavin_ mentioned earlier
<landgraf>
Etheryon: most likely your rpm tries to own /opt and chmod it which is not good idea obviously. If it's done in %files section it's a problem. if it's %post you can try to install with noscript option (man page should mention this, iirc there's posibility)
<landgraf>
it's --noscripts
<Etheryon>
postinstall scriptlet (using /bin/sh): <- is this what I'm looking for? from the rpm -qp --scripts ouput
<cb5r>
How do I get the correct compiler flag values for -march and -mcpu? I am trying to compile an old project with newer SDK and am getting the following error now: "switch '-mcpu=cortex-a9' conflicts with '-march=armv7-a' switch"
<landgraf>
Etheryon: yes
<smurray>
RP: heh, I need coffee, thinking about it, it's been src.rpm's from RedHat/Fedora/etc. that I've pulled apart with rpm2cpio in the past
<landgraf>
smurray: yup. it was
<landgraf>
:)
<cb5r>
NVM - I found the solution: Remove -march because its redundant anyway if compiling for a specific -mcpu. Nevertheless, I find the error message confusing...
<pasherring>
Hey there! Is it possible to clean sstate for recipes from a given layer?
<qschulz>
pasherring: why would you need to do this? cleansstate is the last resort and should rarely be used. If something breaks the sstate-cache, it needs to be fixed :)
<pasherring>
qschulz, probably this has to do with my messed up workflow. I am trying to understand the meta-virtualization for rpi4, and I need to "swap" layers, from stock to some custom layer. And whenever I swap them, I notice that the changes go unoticed. :/
<pasherring>
Also, I know I am probably doing something wrong xD But, I really want to understand the meta-virt and xen for the rpi4. So, probing is really the only way I found to "move forward"
<qschulz>
pasherring: if the change in the metadata (layers) is undetected, cleaning the sstate-cache won't help you
<pasherring>
oh well :/
<qschulz>
pasherring: how do you do the swap of layers?
<pasherring>
qschulz, changing the bblayers.conf
<qschulz>
pasherring: the bblayers from which directory?
<qschulz>
I seem to recall that some vendor provide their own bblayers.conf file with an install script to run before starting a build, hence the question
tgamblin_ has quit [Quit: Leaving]
<pasherring>
qschulz, right, from build/conf/bblayers.conf
tgamblin has joined #yocto
lorenzo has joined #yocto
<lorenzo>
Hi! I want to append a recipe that has a do_install_append that install some sample application. I am now compiling without these sample applications, so my objective is to create a .bbappend that changes that do_install_append. Is there a way to stop it from trying to install files that do no exists?
<lorenzo>
Have you ever faced a similar situation?
<smurray>
lorenzo: my usual approach there is to rm the files from ${D} in my own bbappend
<lorenzo>
smurray: sorry i was not clear. the issue is that the original recipe is installing also the samples like this "cp -f bin/example_* ${D}${datadir}/samples/bin/". The issue is that i have modified the compilation flags so that the samples are not created, thus the install task fails because it cannot find them.
<lorenzo>
While i was writing, i realized that instead of changing the compile flags and can simply delete them after they have been installed (as you suggested)
<lorenzo>
Thank you
<Etheryon>
theoretically if I copy over the files, and all dependencies are met, and I do in do_install what the script for postinstall does, it should work?
<smurray>
lorenzo: the other hack I could maybe see is to do_install_prepend to touch those files so the rm doesn't fail
prabhakarlad has joined #yocto
sakoman has joined #yocto
<lorenzo>
smurray: I ended up touching a dummy file in the _prepend() and later deleting the whole folder in _append(). THank you very much!
<smurray>
lorenzo: you're welcome, good luck with your project
<meego>
apologies if this question already pops up often here: anyone knows where i could buy a few CM4? I've already checked a dozen distributors and they're all out of stock
<meego>
arf, wrong irc channel sorry :p
lucaceresoli has quit [Remote host closed the connection]
<emrius_the_secon>
Strange, when using limechat OSX IRC client I'm getting an error... see #oe channel. However it seems to work from the web client *shrug*
<smurray>
that error indicates the channel has the flag set that only clients coming in over a SSL/TLS connection can join, I assume you need to change the server connection settings in your client
lorenzo has quit [Quit: Client closed]
<emrius_the_secon>
smurray thanks! I tried enabling SSL but the error persists. Hmm... nevermind, it works through the browser client
<emrius_the_secon>
Anyways, the cause that brought me here is the `pip_install_wheel` class which I tried to port back to dunfell. You may have seen this issue already so, I'm really sorry to bother again but I'd love to see this working and I feel that I'm just missing a detail <3
<moto-timo>
emrius_the_secon: you need DEPENDS += “python3-aiohttp-native” if it is a build error
<emrius_the_secon>
So, the issue I'm having is that the fetcher exists just fine. So, I'm guessing the wheel file has been fetched. I tried to grep the problem and find the wheel but couldn't. I'm wondering if somebody knows where it should be located
<emrius_the_secon>
moto-timo thanks! I tried that but that didn't get me further.
<moto-timo>
You will not be able to backport wheels to dunfelll… way to invasive
rob_w has quit [Quit: Leaving]
<emrius_the_secon>
ok! Now, that is a clear perspective that I\ve been waiting for :)
<moto-timo>
this is why we are working so hard to get wheels into kirkstone (the next LTS)
<emrius_the_secon>
ah ok! I'm really looking forward to that as it will be a great improvement! Thanks for the hard work!!!
<emrius_the_secon>
Apparently, during installation `view.py` from the sources is executed which then attempts to import `aiohttp`. At installation time. Which left me a bit confused. Does anybody have a hint how to move forward with this?
<emrius_the_secon>
Let me add the `pytyhon3-aiohttp-native` again to see the exact error stack... wait a sec
<emrius_the_secon>
Ah right (sorry about the confusion - there has been quite a bit of back and forth trying to make this work). When adding `DEPENDS += "python3-aiohttp-native"` this dependency can't be found. So, I'm not sure if I can just add a `PROVIDES += "python3-aiohttp-native"` to my python3-aiohttp recipe. But what actually surprises me is that this is a
<emrius_the_secon>
hard installation dependency. I'm really wondering why
<emrius_the_secon>
Ok, that seems to slowly let me proceed. I need to go through a couple of python dependencies and add the BBCLASSEXTEND="native". What I'm wondering however is: Why aren't all recipes extending bbclass "native" by default?
<moto-timo>
No one needed it yet
<emrius_the_secon>
Ah ok. That adds to my strange gut feeling wondering why this recipe needs that. Anyways, I'll patch a couple of recipes accordingly to see where this will take me
<emrius_the_secon>
moto-timo thank you!
<moto-timo>
And native and nativesdk can add complexity, so not guaranteed to just work
<emrius_the_secon>
Ok I'll give it a first try then I guess
<moto-timo>
Upstream module devs do some very strange things sometimes… this might be one of thos odd corner cases
<tlwoerner>
RP: i've been seeing lots of quilt errors on master lately: "File series fully applied, ends at patch <patch>"
<tlwoerner>
is that the openSUSE issue you've been seeing on the AB?
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli has joined #yocto
<emrius_the_secon>
moto-timo that seems to work! I need to patch about 10 other recipes to provide the native packages but seems to do the job. Thanks!
<RP>
tlwoerner: no :/
<dwagenk>
Hi. I'm currently trying to build an ext-sdk and it fails due to some of the layers not being in the same parent directory as COREBASE. The file doing the layer-copying (meta/lib/oe/copy_buildsystem.py) uses paths relative to COREBASE and seems to assume all layers are either in TOPDIR or in the same parent directory as COREBASE. Is my layer structure wrong, or is copy_buildsystem.py to narrow in what it accepts?
<RP>
not sure which suse issue you mean :/
<RP>
but I've not seen that error
<tlwoerner>
RP: okay i'll investigate/bisect. it's intermittent so... you know
<RP>
dwagenk: nobody has generalised that code I suspect, an eSDK needs to combine everything together which is tricky
<RP>
tlwoerner: all too well
<tlwoerner>
RP: also, so far i've only seen it in my jenkins builds, i haven't seen it on the cmdline, but that might just be a coincidence
<moto-timo>
emrius_the_secon: please send patches for master to fix those recipes
<moto-timo>
emrius_the_secon: after that , backport can be considered
emrius_the_secon has quit [Ping timeout: 256 seconds]
<dwagenk>
@RP Yes, I see that. I've got a patch that would fix my problems and be more general, but at the cost of flattening the directory-structure, e.g. sdk/layers/meta-openembedded/meta-oe -> sdk/layers/meta-oe and sdk/layers/meta-openembedded/meta-networking -> sdk/layers/meta-networking, basically reverting OE-Core rev: 5a59a6997f41e606d088e3e86812de56f72f543b
florian has quit [Quit: Ex-Chat]
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli has joined #yocto
Dhruvag2000[m] has quit [Quit: You have been kicked for being idle]
alvaropg[m] has quit [Quit: You have been kicked for being idle]
grembeter[m] has quit [Quit: You have been kicked for being idle]
osama3 has quit [Ping timeout: 272 seconds]
meego has quit [Quit: Leaving...]
tnovotny has quit [Quit: Leaving]
jmiehe has joined #yocto
tre has quit [Remote host closed the connection]
<RP>
dwagenk: I worried that change might cause problems :(
gsalazar has joined #yocto
cb5r has quit [Quit: cb5r]
florian_kc has joined #yocto
<landgraf>
Etheryon: it should work but doesn't look like right way
florian_kc has quit [Quit: Ex-Chat]
florian has joined #yocto
osama3 has joined #yocto
* Ch^W_
has a hard time not seeing Armbian as yet another example of https://xkcd.com/927/
Etheryon has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dwagenk>
RP: I solved the eSDK relative layer path problem and submitted a patch just now. My local eSDK build works fine now.
jclsn7 has quit [Ping timeout: 272 seconds]
<khem>
dwagenk: thanks for the patch, it helps with some custom distros to generate eSDK
jclsn7 has joined #yocto
amitk has quit [Ping timeout: 272 seconds]
sakoman has quit [Quit: Leaving.]
<kanavin_>
halstead, is there any movement with the AUH email issue? I've seen some mails from bots on the mailing lists, but AUH still isn't able to get through
<halstead>
kanavin_: If it's still unresolved now is the time to fix it.
<kanavin_>
halstead, this is the current config
<kanavin_>
# SMTP server
<kanavin_>
smtp=mail.yoctoproject.org:25
<kanavin_>
# who should get the status mail with statistics, at the end
<halstead>
kanavin_: It's fixed for the AB via sendmail. Those smtp settings will work but not for the lists.
<halstead>
kanavin_: I might be able to fix this without changes on your end. Let me try.
<kanavin_>
halstead, I was wondering if I should change the server to localhost:25 there
<halstead>
kanavin_: not every worker is listening on localhost
sakoman has joined #yocto
<RP>
dwagenk: thanks. I think we may need to get some better tests for this...
<fray>
Does anyone know if a 'git-lfs' (native or nativesdk) recipe exists? I didn't find one, but I may have been looking in the wrong place
<fray>
(I have a repository that uses git-lfs, and it doesn't seem to work via the buildtools..)
<sgw>
zeddii: how much do you know about depmod? Changing the debug generation for kernel modules seems to have triggered an issue when they are installed in an image and depmod finds both <module>.ko and .debug/<module>.ko, which causes depmod to fail. A workaround would be for depmod to ignore .debug directories, thoughts?
<fray>
sgw, or move the debug modules into a different path
<sgw>
fray, yeah that would be another possiblity with having to change depmod, have a rootfs-postprocess that runs to move the /lib/modules/.../.debug/ files someplace
<sgw>
without having to change kmod, is what I meant.
<fray>
I was going to say, fix the package function that splits the binaries.. and move the split modules somewhere else..
<fray>
there may already be a config switch for the path..
<fray>
or at least a limited set of places that need modification
<sgw>
fray, that's some of the code that I changed for the SBOM to enable, but I don't think there's a switch to change the location.
<fray>
I don't see anything specific to kernel mdoules in that list, but it would certainly be easy to add something there and in the function "splitdebugfile" function for kernel modules
<fray>
we used to have some stuff there for special cases already
tgamblin has quit [Read error: Connection reset by peer]
<fray>
(i.e. there is a splitstaticdebuginfo already.. would be reasonable to do a kernel module if something special was needed)
<sgw>
Yeah, looking at that again, it might work
tgamblin has joined #yocto
<sgw>
We used to have kernel specific to skip the split/strip, which I removed for SBOM manglement
tgamblin has quit [Remote host closed the connection]
GNUmoon has quit [Ping timeout: 240 seconds]
<kanavin_>
halstead, let me know when I can test it then
<zeddii>
sgw: w0t fray said
<halstead>
kanavin_: Alright.
<halstead>
kanavin_: Not yet. Its a bit more difficult then I expected. I might switch to localhost and install MTAs on all the workers. I'll let you know.
<RP>
halstead: if it helps we could limit the workers we run auh on
<RP>
fray: there was something horrible about git-lfs which meant a recipe wasn't easy. I can't remember what now though
<halstead>
RP: That would make it easier. I'll grab a list.
<fray>
git-lfs requires go
<halstead>
RP: For now what if we limit to AUH the Alma workers?
<kanavin_>
halstead, I don't mind that
<RP>
halstead: I'll defer to kanavin_
<RP>
fray: that would be it :)
<fray>
ya, after I asked I found the go thing.. I suspect 'nativesdk' go is a complete mess [if it even exists]
<RP>
fray: last time this came up we didn't have go in core
<fray>
Ya, as far as I'm concerned it's not there either.. I REALLY have no desire to try to make this work right now
tgamblin has joined #yocto
mvlad has quit [Remote host closed the connection]
<Ch^W_>
RP: I am always amused by that impression...
<halstead>
kanavin_: If you change settings to point at localhost:25 and only run on the Alma workers that would be a good test.
<kanavin_>
halstead, let me first try a manual test, then I will submit a patch for the auh config
* halstead
has to run out for a bit.
Tokamak has quit [Ping timeout: 240 seconds]
vd has quit [Quit: WeeChat 3.4]
Tokamak has joined #yocto
<kanavin_>
halstead, sadly the email didnt show up on the oe-core list
<kanavin_>
>>> smtp = SMTP('localhost', 25)
<kanavin_>
{}
<kanavin_>
>>> smtp.sendmail('auh@yoctoproject.org','alex.kanavin@gmail.com','test email from AUH')
<kanavin_>
>>> smtp.close()
<kanavin_>
the above works
<kanavin_>
>>> smtp = SMTP('localhost', 25)
<kanavin_>
>>> smtp.sendmail('auh@yoctoproject.org','openembedded-core@lists.openembedded.org','test email from AUH')
<kanavin_>
>>> smtp.close()
<kanavin_>
{}
<kanavin_>
and this does not
<kanavin_>
(that's python's prompt)
<kanavin_>
I'm on alma8-ty-1
<kanavin_>
let me also try to send a 'well formed' email
<halstead>
kanavin_: okay. If that fails I'll check into it after my appointment. Anything wrong with the from address will block it
<halstead>
And I might need to allow that address again on the mailing list. Afk for an hour or so though.
vd has joined #yocto
<kanavin_>
halstead, looks like it went through \0/
<kanavin_>
halstead, let me know if auh config should be changed to use localhost:25 then