seninha has quit [Remote host closed the connection]
sakoman has quit [Quit: Leaving.]
ente` has joined #yocto
GNUmoon has joined #yocto
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
dtometzki has quit [Ping timeout: 260 seconds]
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
camus1 is now known as camus
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
thomasd13 has joined #yocto
odra has joined #yocto
amitk has joined #yocto
odra_ has joined #yocto
odra has quit [Read error: Connection reset by peer]
beneth has quit [Read error: Connection reset by peer]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
rob_w has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
ptsneves has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
beneth has joined #yocto
frieder has joined #yocto
davidinux has quit [Read error: Connection reset by peer]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
davidinux has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
rfuentess has joined #yocto
milosv has joined #yocto
zpfvo has joined #yocto
xmn has quit [Quit: ZZZzzz…]
mvlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<barath>
morning
<barath>
does anyone know whether the way du is used to determine the size of the rootfs to write to an image is on purpose? the reason I'm asking is that it seems like its current usage can lead to incorrect behavior when the backing filesystem is zfs with compression enabled
<barath>
if du were to use -b to give the actual size in bytes then using zfs with compression as a backing fs would work
<barath>
(the problem is that since compression is used du returns a value that's smaller than the actual "apparent size"/number of bytes written to the output image)
goliath has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
prabhakarlad has joined #yocto
florian has joined #yocto
vvn has quit [Ping timeout: 264 seconds]
dkl has quit [Quit: %quit%]
dkl has joined #yocto
<patersonc[m]>
Morning all. Newbie question....
<patersonc[m]>
TIA x
<patersonc[m]>
I've got an issue where the kernel image isn't being copied into the rfs image tarball at the end of the build. Does anyone have any pointers of where to look to debug?
<RP>
barath: we can't win since on other filesystems we need to account for the rounding up of the block size. I think there is an open bug
<RP>
patersonc[m]: You mean including it in the rootfs I assume? That could be a missing dependency on the kernel itself? Some bsps add it, some don't depending on the hardware and the usual file layout.
<barath>
I see, that makes sense. maybe it could be parameterized somehow? I'll look some more for the bug, didn't find one
<RP>
barath: the code assume one rootfs size works for ever output format so I think there is a bit more of a challenge :/
<RP>
barath: we should add this problem case to the bug
<patersonc[m]>
RP: Yes, I mean in the rootfs. The strange thing is that I get the kernel image for one machine, but not another - so I'm assuming there must be something different for a specific machine.
<patersonc[m]>
Thanks qschulz I'll take a look
rber|res has quit [Ping timeout: 250 seconds]
<ptsneves>
Does anybody know why this kind of error exists and how to work around them:
<ptsneves>
> ERROR: python3-flit-core-native-3.7.1-r0 do_prepare_recipe_sysroot: Manifest /home/pneves/Projects/yocto-superproject/poky/build-st/tmp/sstate-control/manifest-x86_64_ubuntu-20.04-libnsl2-native.populate_sysroot not found in x86_64 x86_64_ubuntu-20.04 (variant '')?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<mischief>
how do i find out what causes a psuedo abort?
<mischief>
rerunning my recipe reliably triggers it
<ptsneves>
have a look at the pseudo.log
<ptsneves>
it says what is the file that had the inode mismatch
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
<mischief>
ptsneves: yes, but why :)
<ptsneves>
mischief: because something changed the inode of a file tracked by pseudo. When pseudo does not see the file matching the inode in it's db it aborts
rob_w has quit [Remote host closed the connection]
<ptsneves>
you cannot modify files that are tracked by pseudo outside of pseudo If you do you will get these issues
<mischief>
i'm not intentionally
<ptsneves>
i often found this appearing when some script running after or before bitbake does something with some file tracked by pseudo
<mischief>
it's just running cmake_do_install inside do_install task that triggers it
<ptsneves>
yes, this is why looking at the pseudo.log is useful. So it lets you figure out what might mistakenly touching it
<mischief>
unfortunately it is not enlightening
<ptsneves>
mischief: my answer or pseudo.log?
<mischief>
the log
nemik has quit [Ping timeout: 244 seconds]
<mischief>
it says 'path mismatch [3 links]: ino 19552522 db '....package/usr/src/debug/...foo.h' req '...git/...foo.h'
janvermaete[m] has quit [Quit: You have been kicked for being idle]
nemik has joined #yocto
<ptsneves>
can you pastebin it?
janvermaete[m] has joined #yocto
janvermaete[m] has left #yocto [#yocto]
<mischief>
with redacted paths, yes.
<ptsneves>
sure
<patersonc[m]>
RP: Appending kernel-image fixed my issue. Thank you. I'll have to dig deeper to work out what was suppressing it to start with.
<mischief>
it seems the 'db' path is from the split debug package and 'req' is from ${S} but i'm not sure of the significance of that.
<ptsneves>
can it be you are running some extra task that does something to those files?
<mischief>
the only classes we inherit are cmake and pkgconfig, nothing weird going on that i can tell
<ptsneves>
hmm then i do not know
<mischief>
wouldn't anything executed under bitbake use libpsuedo's LD_PRELOAD and be recorded by it anyway?
<ptsneves>
not all tasks. And indeed most of the times the issues comes up in my experience is when something outside bitbake(and thus without the PRELOAD) changes the inode
<mischief>
is it possible that badly written cmake could trigger this?
<wkawka>
Hi, what are the changes between package and packages-split after my recipe is baked?
<landgraf>
pjoh: 09:56:08 rburton | if pjoh joins again, someone tell him yps2022.11 is virtual
pjoh has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<ptsneves>
wkawka: do you mean the directory?
<wkawka>
I mean what are they giving exactly
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<ptsneves>
the packages split directory contains the packages in plain directories and each of these directories have the corresponding package contents/files. The package directory if i recall correctly contains packaging info like dependencies versions etc
<ptsneves>
you can look it up yourself :)
<ptsneves>
mischief: the issues on pseudo abort manifest more or less the same way(unhelfpully) but are usually caused by very different things, including user action
<wkawka>
so if directory package is empty and packages-split contains some packages, will they be added to image or not?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<ptsneves>
mischief: i have not debugged a case where a debug file gets a pseudo abort but in the past i made the file immutable to try to trap what was "touching" the file
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
ecdhe has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 265 seconds]
ecdhe has joined #yocto
wkawka has quit [Quit: Client closed]
nemik has joined #yocto
wkawka has joined #yocto
<rburton>
wkawka: stuff goes into an image if you tell the image to install a package. Just because a file is packaged doesn’t mean it goes into an image.
tselfs has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
vvn has joined #yocto
<mischief>
ptsneves: i cheated and put `PSEUDO_IGNORE_PATHS:append = ",${WORKDIR}/git"` or so in my recipe. :/
nemik has joined #yocto
<mischief>
there was a mention in the documents about gatesgarth psuedo changes if ${S} is set to a nested directory but the build touches files above ${S} but below ${WORKDIR} in the repo and gave an example of tcl recipe, so i just mimicked that.
<ptsneves>
might be your case. Well that is a nice workaround though :)
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
<wkawka>
How can I change version of a package only for one recipe?
<wkawka>
To explain, I need openssl < 3.0, I have a recipe for openssl and it builds, I tried do set in my target recipe `PREFFERED_VERSION_openssl = "1.1.1o"
<wkawka>
but it still takes the 3.2 version as I see
leon-anavi has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
zpfvo has joined #yocto
alessioigor has quit [Remote host closed the connection]
<wkawka>
Will it work in recipe or should it be in distro or local.conf
<qschulz>
wkawka: is there actually a recipe for openssl 1.1.1o somewhere?
<landgraf>
I don't think it will work on recipe level.
<qschulz>
wkawka: configuration files only
<landgraf>
wkawka: you may want to package openssl-1.1.1 separately, rename is and put it into different directory and then use this "fake" package to build with but it will require more work than just `PREFFERED_VERSION'
<qschulz>
wkawka: ah my bad, "for only one recipe" is not possible
<qschulz>
all your recipes will be depending on openssl 1.1.1o instead of openssl 3.0
<qschulz>
if you want only one recipe to depend on openssl 1.1.1o and the rest on openssl 3, you need to follow the tip fiven by landgraf, create a new package called openssl1 for example
<qschulz>
IIRC there used to be a layer just for that
<d-s-e>
Hi, I got a problem while building a package: It says "opkg-build: not found". The opkg-build binary is available at the path .../mypackage/... but in the PATH environment there is .../defaultpkgname/... instead of the correct package name, which could be the reason. Any ideas why this is the case or how to fix this?
jmiehe has joined #yocto
<RP>
ptsneves: I think it is cancelled due to the conference, yes
<RP>
d-s-e: Are you 100% sure that is correct debugging? That is normally from bitbake -e without a recipe context
tselfs has quit [Quit: finish]
<d-s-e>
RP: That's what I derived from the error message. Also when starting the devshell the path is correct.
<RP>
d-s-e: sounds like PN isn't being set correctly then
alessioigor has quit [Quit: alessioigor]
pjoh has quit [Ping timeout: 252 seconds]
alessioigor has joined #yocto
kscherer has joined #yocto
<d-s-e>
RP: shouldn't be this be set automatically according to the filename of the package?
<d-s-e>
RP: I mean the recipe filename
Guest99 has joined #yocto
thomasd13 has quit [Ping timeout: 268 seconds]
camus has quit [Quit: camus]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Guest99 has quit [Ping timeout: 252 seconds]
Xagen has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
d-s-e has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
d-s-e has joined #yocto
zeddii has quit [Ping timeout: 265 seconds]
milosv has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
Payam__ has joined #yocto
<d-s-e>
Ok, setting PN in the recipe seems to fix this; but I can't remember I ever had to do this in the past ...
<qschulz>
d-s-e: bitbake -e (or bitbake-gervar) to check if something is messing with PN
zeddii has joined #yocto
<d-s-e>
qschulz: thanks, I'm looking into that, but that's really a lot of output :)
rfuentess has quit [Remote host closed the connection]
<qschulz>
d-s-e: bitbake-getvar should help with that if your versionof Yocto supports it
<qschulz>
otherwise, bitbake -e example | awk '/^# \$FOOBAR \[/,/^FOOBAR/'
zpfvo has quit [Ping timeout: 268 seconds]
<d-s-e>
Oh, I didn't know bitbake-getvar, thanks! I will try that.
alessioigor has quit [Quit: alessioigor]
zpfvo has joined #yocto
Payam__ has quit [Quit: Leaving]
dtometzki has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<Xagen>
in my build environment there's a tool that comes with the linux kernel code that i want to build
zpfvo has quit [Remote host closed the connection]
d-s-e has quit [Quit: Ping timeout (120 seconds)]
PhoenixMage has quit [Ping timeout: 252 seconds]
frieder has quit [Remote host closed the connection]
PhoenixMage has joined #yocto
dtometzki has quit [Read error: Connection reset by peer]
d-s-e has joined #yocto
ente` has joined #yocto
kevinrowland has joined #yocto
<kevinrowland>
does anyone know why glib RRECOMMENDS shared-mime-info?
<Emantor>
kevinrowland: I think glib has content type identification which uses shared-mime-info.
<kevinrowland>
hmm ok. I never really understood why anyone would use RRECOMMENDS - if shared-mime-info isn't there then glib will lose a feature, right? I'm actually trying to understand if I can remove it from my image, in order to remove libxml2, which is a dependency of shared-mime-info.
DavidM[m] has joined #yocto
<DavidM[m]>
Hi all, trying to build image first time: however bitbake cannot connect to servers Connect call failed i.e. '44.231.179.46', 8687 , '44.229.61.12', 8687
<DavidM[m]>
are there really any problems with servers? thanks
<gstinocher[m]>
Hi David M. There was a routing problem recently that may have affected communication to/from the workers. It appears to be resolved now. You may want to try again.
behanw has joined #yocto
<DavidM[m]>
gstinocher: Thank you for prompt reply. The problem is still persist: Multiple exceptions: [Errno 110] Connect call failed ('54.69.118.73', 8687), [Errno 110] Connect call failed ('44.231.179.46', 8687), [Errno 110] Connect call failed ('44.229.61.12', 8687)
<DavidM[m]>
Hosts are not pinging via online tools also
<DavidM[m]>
unable to connect hash equivalence server at 'typhoon.yocto.io:8687': timeout('timed out')
<gstinocher[m]>
David M.: looking...
<halstead>
ELC conference goers are heading to J.W. Sweetman 1-2 Burgh Quay, Dublin 2, D02 F243
<gstinocher[m]>
David M.: I am having trouble finding any problem right now. Please inform me how to reproduce or view the errors you are getting
<DavidM[m]>
Linux parallels-Parallels-Virtual-Platform 5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7 09:18:32 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
<gstinocher[m]>
David M.: I don't think the yocto controller is pingable.
<DavidM[m]>
gstinocher[m]: thank you. I am trying to run $ bitbake core-image-full-cmdline
<gstinocher[m]>
DavidM[m]: I am not familiar with bitbake. Perhaps someone on this thread can give you some better assistance. As far as I can tell all infra is available and functioning properly.
<halstead>
gstinocher[m]: DavidM[m] that server was renamed. It's hashserv.yocto.io or maybe hashserv.yoctoproject.org now. There is a post on the mailing list.
<DavidM[m]>
I commented #BB_HASHSERVE_UPSTREAM and now it works. Thank you all for help
florian_kc has joined #yocto
wkawka has quit [Quit: Client closed]
kevinrowland has quit [Quit: Client closed]
amitk has quit [Ping timeout: 260 seconds]
ptsneves has quit [Ping timeout: 250 seconds]
d-s-e has quit [Quit: Client closed]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
prabhakarlad has quit [Quit: Client closed]
jclsn has joined #yocto
mvlad has quit [Remote host closed the connection]
jclsn has quit [Client Quit]
behanw has quit [Quit: Connection closed for inactivity]
odra_ has quit [Ping timeout: 250 seconds]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
seninha has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
Minvera has quit [Remote host closed the connection]
seninha has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
seninha has quit [Remote host closed the connection]
Guest31 has joined #yocto
Guest31 has quit [Client Quit]
rexut has joined #yocto
rexut has left #yocto [#yocto]
rexut has joined #yocto
rexut has quit [Quit: Leaving.]
prabhakarlad has joined #yocto
sakoman has quit [Quit: Leaving.]
jmiehe has quit [Quit: jmiehe]
<Xagen>
RP: i got the build working that i was having issues with earlier
<Xagen>
however now it's complaining about how the files were installed but not shipped
<Xagen>
but i have them added to FILES_${PN} and FILES_${PN}-dbg
<Xagen>
very confused why it says that files won't be shipped that i said to ship
sakoman has joined #yocto
leon-anavi has quit [Quit: Leaving]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
<RP>
Xagen: which release? it should be FILES:${PN} now for master
<Xagen>
RP: we're still on dunfell at the moment
<RP>
Xagen: check your value of the variable is really what ends up set then?
<Xagen>
RP: they look correct based on the output from bitbake -e
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<RP>
Xagen: "bitbake -e <recipename>" right?
<Xagen>
correct
<RP>
Xagen: offhand I don't know then
<Xagen>
just in case someone has a better idea on what i'm doing, or what's wrong, i'm building `tools/power/x86/intel-speed-select` which is a part of the `linux-yocto` recipe
<Xagen>
i cd'd into the dir, used oe_runmake to build it, then used do_install to install it to ${D}/usr/bin/
<Xagen>
and added that path to FILES_${PN} and the debug path to dbg
kscherer has quit [Quit: Konversation terminated!]