qschulz has quit [Remote host closed the connection]
jclsn0 has quit [Ping timeout: 240 seconds]
qschulz has joined #yocto
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 240 seconds]
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 244 seconds]
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 258 seconds]
jclsn0 has joined #yocto
Tokamak has quit [Ping timeout: 250 seconds]
jclsn0 has quit [Ping timeout: 244 seconds]
Tokamak has joined #yocto
jclsn0 has joined #yocto
sakoman has quit [Quit: Leaving.]
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 240 seconds]
camus has joined #yocto
starblue has quit [Ping timeout: 244 seconds]
starblue has joined #yocto
jpuhlman has quit [Ping timeout: 248 seconds]
jpuhlman has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
jclsn0 has quit [Ping timeout: 246 seconds]
sakoman has joined #yocto
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 276 seconds]
jclsn0 has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
jclsn0 has quit [Ping timeout: 240 seconds]
jclsn has joined #yocto
jclsn0 has joined #yocto
Tokamak has quit [Ping timeout: 244 seconds]
Tokamak has joined #yocto
jclsn0 has quit [Ping timeout: 256 seconds]
Tokamak_ has joined #yocto
Tokamak has quit [Ping timeout: 256 seconds]
jclsn0 has joined #yocto
Tokamak has joined #yocto
Tokamak_ has quit [Ping timeout: 246 seconds]
prabhakarlad has quit [Quit: Client closed]
Tokamak_ has joined #yocto
ptsneves has quit [Quit: Client closed]
Tokamak has quit [Ping timeout: 256 seconds]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
dev1990 has quit [Remote host closed the connection]
dev1990 has joined #yocto
Tokamak_ has quit [Ping timeout: 255 seconds]
sakoman has quit [Quit: Leaving.]
RobertBerger has quit [Quit: Leaving]
rber|res has joined #yocto
Tokamak has joined #yocto
kroon has joined #yocto
davidinux has quit [Ping timeout: 246 seconds]
Guest58 has joined #yocto
Guest58 has quit [Client Quit]
Tokamak has quit [Ping timeout: 246 seconds]
Tokamak has joined #yocto
olani has quit [Ping timeout: 272 seconds]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
te-johan has joined #yocto
rfuentess has joined #yocto
<te-johan>
hi, i'm trying to debug why i'm so easily getting pseudo mismatch abort errors. at the moment if i do any changes to my layer i usually have to rebuild everything to avoid it. Is there any gotchas when building in docker, like inodes changing or similar?
frieder has joined #yocto
rob_w has joined #yocto
rfs613 has quit [Quit: restart]
goliath has joined #yocto
rfs613 has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
xmn has quit [Ping timeout: 276 seconds]
<LetoThe2nd>
yo dudX
Schlumpf has joined #yocto
<mckoan>
hey LetoThe2nd
<LetoThe2nd>
mckoan: howdy
ptsneves has joined #yocto
m4ho has quit [Ping timeout: 240 seconds]
prabhakarlad has joined #yocto
leon-anavi has joined #yocto
m4ho has joined #yocto
davidinux has joined #yocto
simpat2022[m] has joined #yocto
bps has joined #yocto
gsalazar has quit [Quit: Leaving]
gsalazar has joined #yocto
GuestNew118 has joined #yocto
<qschulz>
o/
<GuestNew118>
Hello Yocto Wizards, after bumping to Yocto 4.0 bitbake complains about recipes based on Tag as SRCREV (Recipe uses a floating tag/branch without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev()) there is a way to disable it ? all my recipes are based on tags...
<LetoThe2nd>
GuestNew118: well the obvious fix is changing your recipes, because tags are not immutable, and therefore don't guarantee reproducibility
<LetoThe2nd>
GuestNew118: if you are intentionally willing to sacrifice such, then you can do the AUTOREV dance on a given branch
florian has joined #yocto
<GuestNew118>
LetoThe2nd I understand, thanks for infos :)
gordon1 has joined #yocto
<LetoThe2nd>
GuestNew118: have fun!
river has left #yocto [WeeChat 3.4.1]
Schiller has joined #yocto
<Schiller>
Hello. Is there a file which stores the Buildinformation displayed in the WEB-UI from Buildbot? I have controller and workers running in container and start everything with docker-compose. At the moment I lose all the Buildinformation after i stop the containers.
dgriego has quit [Ping timeout: 255 seconds]
dgriego has joined #yocto
GNUmoon has joined #yocto
Qorin has joined #yocto
dgriego has quit [Ping timeout: 260 seconds]
dgriego has joined #yocto
rfuentess has quit [Remote host closed the connection]
dgriego has quit [Ping timeout: 240 seconds]
dgriego has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
dgriego has quit [Ping timeout: 260 seconds]
dgriego has joined #yocto
<jclsn[m]>
I just realized something odd, which is not clear for me from the docs. We have multiple image recipes, like a core-image, a dev-core-image and a dev-core-image-usb-updater etc. In case of the latter, we require the dev-core-image, which requires the core-image. When building an SDK for the dev-core-image-updater though, many packages are missing in the manifest. Is that normal? I can find those packages if I generate an SDK for the core-image,
<jclsn[m]>
but not in the SDK for the dev-core-image or updater. I had assumed that all those packages would be inherited and also land in the SDK for the updater.
<jclsn[m]>
I would really like to have one SDK to rule them all, instead of building several...
<RP>
jclsn[m]: it really depends how you're making dev-core-image differ from core-image
davidinux has quit [Ping timeout: 256 seconds]
jpuhlman has quit [Ping timeout: 255 seconds]
jpuhlman has joined #yocto
davidinux has joined #yocto
<Qorin>
Hi
<Qorin>
Has anyone worked with efitools recipe from meta-secure-core together with DigiCert ?
<Qorin>
I am using sign-efi-sig-list tool that is built by efitools recipe and the certificates come from digicert.
<Qorin>
I have to setup some environment variables and in the end this is the command that is called `sign-efi-sig-list -t "<some_time>" -e pkcs11 -c "/path/to/cert.pub" -k "private_key_url" PK PK.esl PK.auth`
<Qorin>
the sign-efi-sig-list is available in the recipe-sysroot-native. however when I used this tool from the recipe-sysroot-native I received this error
<Qorin>
.../poky/build/tmp/work/x86_64-linux/openssl-native/1.1.1l-r0/recipe-sysroot-native/usr/lib/engines-1.1/pkcs11.so: cannot open shared object file: No such file or directory
<Qorin>
in the openssl-native work dir, the directory lib/engines1.1 does not exist.
<Qorin>
However in the core2-64-poky-linux/openssl work dir the lib/engines1.1 directory exists with these files:
<Qorin>
- afalg.so
<Qorin>
- capi.so
<Qorin>
- padlock.so
<Qorin>
I tried adding an RDEPEND:${PN}:append = " libp11 libp11-native" in the openssl recipe, but it failed to build due to circular dependency
starblue has quit [Ping timeout: 260 seconds]
rob_w has quit [Quit: Leaving]
starblue has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
te-johan has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
pgowda_ has joined #yocto
<jclsn[m]>
RP: I only append stuff, so I don't know why the packages from the core-image would be missing
tre has joined #yocto
<LetoThe2nd>
is there a direct way to get the expanded list of packages that go into an image without actually building? like the information from the image manifest?
<jclsn[m]>
Ah, the updater image has its own minimal rootfs and thus it is included in the SDK
Schiller has quit [Ping timeout: 252 seconds]
Wouter0100 has joined #yocto
<jclsn[m]>
dropbear is also not compatible with the SDk unfortunately, because it requires openssh which conflicts with dropbear
<jclsn[m]>
The problem is obviously openssh-sftp, which is compatible with dropbear, but not when building the SDK. The SDK somehow requires openssh when having added openssh-sftp.
<jclsn[m]>
RP: Is this a bug? Could a PROVIDES="ssh-server-openssh" in the dropbear recipe or SDK recipe fix it?
<jclsn[m]>
Or does the SDK need some libraries from openssh?
<LetoThe2nd>
qschulz: thx, will give it a try. but turned out that the non-building was actually not a requirement, so the manifest+buildhistory do the trick.
<gordon1>
having an issue with RRECOMMENDS, so there is this recipe smartmontools from meta-openembedded, it has RRECOMMENDS += "s-nail", but no matter what i do it still installs it, i tried adding "s-nail" to BAD_RECOMMENDATIONS or even PACKAGE_EXCLUDE in my local.conf, and if i add it to BBMASK bitbake fails with an error that smartmontools RDEPENDS on it, which it clearly isn't according to the recipe
<gordon1>
file, is there a way to see _why_ exactly certain package is pulled?
<gordon1>
i'm using kirkstone if it matters
<qschulz>
gordon1: bitbake -g <image-recipe> will give you a few dot files expliciting the dependencies between packages
<RP>
jclsn[m]: there is an open bug about some aspect of the openssh/dropbear overlap. I'm not sure we did come up with a good plan for all of that
<RP>
jclsn[m]: dropbear certainly should not PROVIDES openssh though
<jclsn[m]>
RP: Yeah I guess so
<jclsn[m]>
I have kicked out openssh-sftp for now. It is only needed for QtCreator and there are workarounds
<jclsn[m]>
Out of curiosity: I just wonder how much more performant dropbear really is. I could not find any benchmarks or info about the openssh memory footprint
<gordon1>
qschulz: well, it shows me all the dependencies but it doesn't show me why this dependency exists =/
<gordon1>
or i'm not good at interpreting it
<qschulz>
gordon1: at least knowing which package depends on which, you can look into the recipe and try to figure out if it's a dependency you can remove or not (e.g. via BAD_RECOMMENDATIONS or a modified PACKAGECONFIG)
kroon_ has joined #yocto
kroon has quit [Ping timeout: 255 seconds]
<gordon1>
well, that's the problem that i'm having, i already know the recipe that pulls s-nail - smartmontools, and the recipe has _only_ RRECOMMENDS:${PN} += "s-nail" (if i comment out this line it doesn't pull s-nail into resulting image)
<gordon1>
but for some reason this RRECOMMENDS isn't affected by BAD_RECOMMENDATIONS
<qschulz>
gordon1: are you sure it's the ONLY one pulling s-nail is smartmontools?
leon-anavi has quit [Remote host closed the connection]
<qschulz>
that was what I had in mind but I realize I didn't vocalize this idea :)
<qschulz>
gordon1: remember that there's an auto-magic RDEPENDS in packages
<qschulz>
which adds packages of shared libraries used in a given package by using objdump/readelf
<qschulz>
and add them directly without you knowing
<gordon1>
i can comment the line with RRECOMMENDS:${PN} += "s-nail" and add BBMASK += "s-nail" in my local.conf and it does not result in error and bitbake builds the image correctly w/o s-nail
<gordon1>
*can comment the line out from smartmontools.bb
leon-anavi has joined #yocto
<qschulz>
gordon1: ok seems like a pretty solid test and confirmation it's the only one adding s-nail
<gordon1>
i doubt that smartmontools use any kind of shared lib from s-nail since latter one is just mail implementation
<qschulz>
gordon1: which package manager are you uising?
<qschulz>
because deb does not support BAD_RECOMMENDATIONS
<qschulz>
(but you should have gotten a warning when building)
<gordon1>
i think its rpm, gimme a moment
<gordon1>
PACKAGE_CLASSES ?= "package_rpm"
<gordon1>
but i'm building initramfs so i doubt it has package manager there
<qschulz>
gordon1: the rootfs is created by a package manager running on your building machine
<gordon1>
right
<gordon1>
so i guess it's rpm then
<qschulz>
gordon1: which is a different thing than having a package manager on your target
<qschulz>
yup, seems reasonable (you can always check with bitbake-getvar -r <image-recipe> PACKAGE_CLASSES
<qschulz>
tbh, i'm out of ideas where to look for next, so i'll let others chime in
<gordon1>
yep, it's rpm
<gordon1>
i mean i guess i could just make bbappend for smartmontools modifying this RRECOMMENDS, but i'm pretty sure it's not how RRECOMMENDS should behave
<qschulz>
gordon1: BAD_RECOMMENDATIONS should work indeed
<qschulz>
gordon1: check BAD_RECOMMENDATIONS with bitbake-getvar too
kroon__ has joined #yocto
<gordon1>
BAD_RECOMMENDATIONS="s-nail"
<gordon1>
but if i add s-nail to PACKAGE_EXCLUDE should it fail instead of trying to install it?
<gordon1>
because it doesn't for me
kroon_ has quit [Ping timeout: 272 seconds]
<qschulz>
it should except for deb pkg manager
<gordon1>
hmm, it's weird, it shows me following dependency chain:
<gordon1>
i have initramfs that is bundled into the kernel
<gordon1>
so i wonder if it ignores BAD_RECOMMENDATIONS while it's building the image as a dependency for kernel maybe?
<qschulz>
gordon1: that's actually a good question
<qschulz>
I'm building core-image-minimal with smartmontools - s-nail to see if I can reproduce (top of kirkstone branch)
<qschulz>
if it does not, maybe checking that this mechanism works for bundled initramfs is a good idea
<gordon1>
if so i wonder is there a way to specify BAD_RECOMMENDATIONS for an image instaed of local.conf? should it work if i put it into my image's recipe?
<qschulz>
yes
<gordon1>
qschulz: i based my image in core-image-tiny-initramfs if that is important
<gordon1>
so i put BAD_RECOMMENDATIONS = "s-nail" into my image recipe but it didn't help
<qschulz>
gordon1: ahah!
<gordon1>
?
<qschulz>
PACKAGE_INSTALL needs to be used instead of IMAGE_ISNTALL for initramfs images
<qschulz>
maybe BAD_RECOMMENDATIONS does not apply to PACKAGE_INSTALL but only IMAGE_INSTALL?
<gordon1>
oh, hmm
<gordon1>
is there unintended consequences if i'll just replace PACKAGE_INSTALL with IMAGE_INSTALL ?
<qschulz>
gordon1: i think it just won;'t work
<gordon1>
well, i replaced it and it looks like it still complains about s-nail since it's in BBMASK
<jclsn[m]>
I have an issue that a dependency is not landing in the SDK unless I explicitly list. So to be clear: If I list some package explicitly eveerything lands in the SDK, if I only let it get installed as dependency, it still works in the image, but libraries are missing the SDK. Is there something like DEBUGDEPENDS? Haven't found anything
<jclsn[m]>
EXTRA_IMAGEDEEPENDS maybe
<jclsn[m]>
?
<qschulz>
jclsn[m]: the SDK is like a toolchain, minimal stuff by default
<qschulz>
maybe you'd be more interested in eSDK?
Tokamak has quit [Ping timeout: 246 seconds]
<qschulz>
which is like a complete development environment based on an image (IIRC, have never used it)
<jclsn[m]>
qschulz: The eSDK is huge
<jclsn[m]>
I could fix it by listing the package as RDEPENDS, but not sure if that is the right way to do
nemik has quit [Ping timeout: 260 seconds]
michalkotyla has quit [Quit: michalkotyla]
nemik has joined #yocto
<gordon1>
docs don't really explain in details why i must use PACKAGE_INSTALL instead if IMAGE_INSTALL for initramfs, just tell me to =/
<jclsn[m]>
For now we were working okay with the SDK. The eSDK is only needed for devtool afaik
xmn has joined #yocto
<qschulz>
jclsn[m]: the eSDK brings the whole sysroot for an image IIRC
<ptsneves>
gordon1 basically it is to slim it down. Indeed it is not clear.
<qschulz>
the SDK is literally a toolchain, so basically compiler+libc+some other very basic stuff
<qschulz>
the eSDK also happens to have some Yocto specfici tools like devtool
<jclsn[m]>
the SDK also contains the sysroot
<gordon1>
ptsneves: yes, but in what way? have to look at the bbclass code for that i guess
<qschulz>
jclsn[m]: not the whole sysroot, otherwise you wouldn';t complain about the missing package?
<jclsn[m]>
Guess I have to read the docs on SDKs again
<jclsn[m]>
Probably yeah. I think I misread something then
Tokamak has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
<ptsneves>
gordon1 actually the docs mention the difference and even mention the initramfs case.
<jclsn[m]>
qschulz: This is not really clear from the docs
<jclsn[m]>
The Standard SDK provides a cross-development toolchain and libraries tailored to the contents of a specific image.
<jclsn[m]>
The extensible SDK provides a cross-development toolchain and libraries tailored to the contents of a specific image.
<jclsn[m]>
The only difference the docs mention is devtool
<jclsn[m]>
ou would use the Extensible SDK if you want a toolchain experience supplemented with the powerful set of devtool commands tailored for the Yocto Project environment.
<jclsn[m]>
The installed Standard SDK consists of several files and directories. Basically, it contains an SDK environment setup script, some configuration files, and host and target root filesystems to support usage.
* qschulz
shrugs
<qschulz>
I don't use SDKs, so I could bery very much be wrong and shouldn't have said anything
<ptsneves>
jclsn[m] unfortunately many in the yocto community do not use the SDKs and this may lead to fragilities in it. Do you think you can submit a patch for the docs?
<qschulz>
ptsneves: I think the SDK is actually more used than eSDK? but again, just guesses
<ptsneves>
i have 2 data points and they confirm your experience. I have generated some, but besides correctness never used it
tre has quit [Remote host closed the connection]
<jclsn[m]>
ptsneves: No idea what patch that would be. I still don't know what the exact differences are. Quentin says that the standard SDK contains "some" sysroot files. That is not clear enough for me.
<sotaoverride>
ive somehow ended up with modules in /lib/modules for a different kernel, and now get the "disagress about version of symbol module_layout" error. has anyone seen this before? My rootfs updates led to this, and im trying to find a way of fixing it now. clearly the kernel is not on the rootfs or something
<qschulz>
jclsn[m]: opening a bug ticket for the documentation is already great feedback
<ptsneves>
sotaoverride can you paste the whole errror? I assume you get the issue at runtime/boot?
<ptsneves>
jclsn[m] we are not perfect and the project is huge. Honestly i just read the source when i want something not clearly documented. Even so the docs are amazing compared to a few years ago. If they do not suit it is an opportunity to improve
<ptsneves>
can you try modprobe? also is this the result of a module you manually copied?
<sotaoverride>
ptsneves: so I was getting help from rfs613 earlier and he pointed out my kernel is on a vfat, and the modules sit in rootfs. When i do rootfs updates, the modules somehow get in this mismatch state. I tried modprobe too. and the module is just getting installed by the defconfig that comes with the bsp (i think)
<ptsneves>
sotaoverride what matters is that the kernel sources used to build the kernel and your module match.
<ptsneves>
What do you mean rootfs updates?
sakoman has joined #yocto
<sotaoverride>
so I have this python utitliy that does a/b partition style updates. you basically give it an ext4 root filesystem and tell the board to boot from the partition with the new ext4 filesystem
<sotaoverride>
that some how led to this mismatch
<sotaoverride>
which got caught when overlay went missing.
<sotaoverride>
and I wasnt able to modprobe it even
vladest has quit [Quit: vladest]
<ptsneves>
ehhh nice problem you got there. Just one more question, to give you the diagnostics. The kernel is not in the rootfs but in some other partition. The fat you mentioned right?
squid_game has joined #yocto
<qschulz>
sotaoverride: what about having an initramfs in your kernel with the kernel modules in?
<qschulz>
(and pivot/switch root at boot)
<qschulz>
or, just build them in instead of having them as modules?
<ptsneves>
yep. That is actually the only choice to not have issues with fallbacks failing due to kernel mismatch
<sotaoverride>
qschulz: cant you link me to some doc or something that breaks down initramfs. I only know a little about ext4 and how to write them to a parition, run the filesystem resize command and call it a day :P
<sotaoverride>
just link me to something that explains initramfs a little and the pivot/switch idea, or just give like the top line explanation here
<qschulz>
sotaoverride: basically, you insert an initramfs/initrd inside the kernel at compile time of the kernel
<qschulz>
when the kernel will boot, it'll load this initramfs in RAM and mount it as rootfs
<rfs613>
ptsneves, sotaoverride: the issue is that rootfs (containing modules) has gotten updated, while the kenrel+dtb+overlays are on separate partition (VFAT) and did not update. hence the mismatch.
vladest has joined #yocto
<rfs613>
the fix is to eiterh update the VFAT to match, or to revert the rootfs update.
<qschulz>
sotaoverride: but since you don't want the rootfs fully in RAM (very limited in size, and also yuou lose all data between reboots)
<ptsneves>
rfs613 yep, got it.
<rfs613>
let's not make it more complicated by adding initramfs to the mix...
<qschulz>
sotaoverride: you need to mount another filesystem and replace the rootfs with it at runtime, that's what pivot_root/switch_root does
<sotaoverride>
thank you thank you
<qschulz>
the kernel modules would be loaded from the initramfs
<ptsneves>
rfs613 actaull what you suggest breaks the fallback ability. Unless you also have A/B kernel-dtb partition
<qschulz>
and still loaded in the kernel after doing the switch root
<qschulz>
I **think** that's what PC distros do? i don't remember exactly
<qschulz>
that's the theory
kroon__ has quit [Quit: Leaving]
<rfs613>
ptsneves: yes, true, because there is only one VFAT partition while there are two A/B rootfs... but it's not my design to fix ;-)
<qschulz>
I'm not saying it's actually the best idea for you
<qschulz>
and I also have no idea how to implement this in Yocto
<qschulz>
but I know it's possible
<qschulz>
because thatr's one of the ways for doing secure boot
<qschulz>
and I worked a bit on the implementation about 6 years ago
<qschulz>
but the kernel and yocto has changed a lot since :)
<ptsneves>
i would just inline the module and be done with it
<qschulz>
yup same
<ptsneves>
no more initramfs nor fallback issues
<qschulz>
i don't expect embedded platforms with the nouveau driver built-in :D
<qschulz>
so the kernel size should be reasonable
<squid_game>
what is _${PN} on RDEPENDS_${PN} += "bash"?
<ptsneves>
unless you cant do that due to license issues, you just found yourself exra work
<qschulz>
squid_game: PN is for "package name" but it happens to actually be the recipe name
<qschulz>
so if your recipe is named my-recipe_0.5.bb
<rfs613>
ptsneves: compilng the module into kernel was also my first thought, but they use a vendor layer for the kernel, it has a defconfig (not config fragments), so he'd have to clone the defconfig and modify... and then update it it when the vendor does.
<qschulz>
RDEPENDS_${PN} will basically be RDEPENDS_my-recipe
<squid_game>
qschulz, thanks a lot!
<qschulz>
squid_game: the catch being, that the name of the recipe is actually also the name of the main package (by default at least)
<ptsneves>
rfs613 still feels the easiest way out
<qschulz>
squid_game: hence the confusion. recipe vs package is a very important difference (recipe is the input of a build, packages are the output in very very big overview of how bitbake works)
<rfs613>
ptsneves: for a quick test yes, in the long term - they'll need to figure out how to deal with keepng the boot partition in sync wiht rootfs.
kscherer has joined #yocto
<squid_game>
thanks for the explanation
<ptsneves>
rfs613 i politely disagree. Any toil work just inlining the vendor code is much simpler and less error prone than whatever is required to keep the boot partition in sync. I have seen this "toil" and it is programmed into the schedule and manageable
<ptsneves>
as vendor layer upgrades always require integration anyways
<qschulz>
vendor code exists to be removed anyways
<qschulz>
so just ditch it :D
<qschulz>
(only half joking)
bps has quit [Ping timeout: 256 seconds]
sakoman has quit [Quit: Leaving.]
<ptsneves>
qschulz bad vendor integrations cost money and let the bean counters see and pressure sales peoples. If you come up with your own sync solution and it bricks devices in the field it will be your ass on the platter
florian_kc has joined #yocto
<gordon1>
well, i changed class to inherit image instead of inherit core-image, changed PACKAGE_INSTALL to IMAGE_INSTALL but it still completely ignores BAD_RECOMMENDATIONS
<qschulz>
(I was more in favor of removing the vendor layer and only hand pick what you actually need from it)
sakoman has joined #yocto
<gordon1>
is here a particular IMAGE_FEATURE requred for BAD_RECOMMENDATIONS to work?
<qschulz>
gordon1: not that i know. slow PC here, waiting for it to finish building core-image-minimal with smartmontools enabled since I told you about 2 hours ago :D
<qschulz>
gordon1: you can always open a bug entry on our bugzilla
<gordon1>
oh, thanks
<qschulz>
if you continue investigating or not does not matter, it's always nice to know there was a bug and it's fixed some time in the future
<gordon1>
yes i could, just want to make sure it's a bug and not me being dumb
<qschulz>
gordon1: vanilla poky in kirsktone + vanilla meta-openemmebded/meta-oe
<qschulz>
nothing in local.conf except IMAGE_INSTALL:append and BAD_RECOMMENDATIONS
<qschulz>
if it reproduces, it's a bug I'm pretty certain
<gordon1>
yes, that's pretty much that i have + my own small layer with kernel and machine definition
<gordon1>
oh, and a distro, but it pretty much copy-pasted poky-tiny
<qschulz>
shouldn't take too long to test on vanilla everything
<qschulz>
poky + some qemu machine
<qschulz>
and at least we would know for sure
<qschulz>
and even better for the bug report, if it's reproducible on master stil
<qschulz>
l
frieder has quit [Remote host closed the connection]
<gordon1>
yeah, that might be the case
squid_game has quit [Remote host closed the connection]
<rfs613>
ptsneves: in this particular case, it probably makes sense to investigate if the separate VFAT partiton can be eliminated, have the kernel+dtb+overlays on the rootfs (of which there are two A/B copies). That way each one is self contained. As they are using u-boot on arm64, I would not expect any difficulties (there's no CHS limits from a BIOS etc). Just a bit of effort to change the bootcmd to load from
<rfs613>
ext4 rather than FAT, etc.
<qschulz>
rfs613: the issue with the same partition for kernel+rootfs is when you just need to fix something quick in the kernel
<qschulz>
then the whole update is the full rootfs
<qschulz>
pretty demanding on update servers
<rfs613>
qschulz: yeah for development it is a different story
<qschulz>
not even development
<qschulz>
e.g. a security fix for production
<qschulz>
a small one-liner patch in the kernel or even a small fix in the dtb
<qschulz>
and you go from a few MB to a few hundreds of MB (or GB depending on your rootfs)
<qschulz>
anyways :)
<qschulz>
no perfect solution, hence why there are so many
<rfs613>
qschulz: indeed
frieder has joined #yocto
<ptsneves>
like i said. a very interesting issue. Well if the bootloader supports non fat it is also a good choic
GuestNew118 has quit [Ping timeout: 252 seconds]
<jclsn[m]>
qschulz: God, 22 emails from the patch from Steve Sakoman. This is where I really don't understand your approach on sending patches via email....
<ptsneves>
jclsn[m] heh i just disable the digest. It is awful
<sakoman>
jclsn[m]: and don't forget the 14 dunfell patches that followed the kirkstone set :-)
<qschulz>
jclsn[m]: you can disable the sending of mails on lists.yoctoproject.org
<qschulz>
I mean, receiving of mails
<qschulz>
and still be able to send some
<qschulz>
jclsn[m]: also, does not matter to me because I have collapsible threads enabled by default
bps has joined #yocto
bps has joined #yocto
<qschulz>
so it literally takes only one line on my mail client
* JaMa
was happy to receive them and review what's comming
<ptsneves>
qschulz and then dont you lose the ability to see when there are updates?
<JaMa>
better than useless e-mail notification from github that something was changed in some PR
<qschulz>
ptsneves: not sure to understand your question?
<ptsneves>
if everything is collapsed i guess the only line visible in your email client, is the thread start. All others are folded and you do not see them
<qschulz>
ptsneves: yup
<qschulz>
but when I receive an answer to any of the mails of that thread, it pushes the thread at the top of my mailbox
<qschulz>
also, there's alittle arrow next to the first email in the thread, to uncollapse the whole thing and see each mail in the thread
<qschulz>
jclsn[m]: and we say thank you to sakoman for maintaing the lts branches :)
camus has quit [Quit: camus]
<sakoman>
qschulz: you're welcome :-)
<ptsneves>
sakoman Thanks! A task whose fruit is mostly enjoyed by for profits
florian_kc has quit [Ping timeout: 276 seconds]
ptsneves has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 258 seconds]
nemik has joined #yocto
m4ho has quit [Ping timeout: 244 seconds]
m4ho has joined #yocto
m4ho has quit [Ping timeout: 240 seconds]
pgowda_ has quit [Quit: Connection closed for inactivity]
<qschulz>
gordon1: just to be extra super duper sure, you see s-nail INSIDE your rootfs right?
<qschulz>
you're not complaining it gets built?
<qschulz>
(because those are two different things)
<gordon1>
i do complain about it's being built
<qschulz>
ahah!
<qschulz>
then it's normal;
<qschulz>
I mean
<qschulz>
I think
<qschulz>
that's what would make sense to me
<gordon1>
well, the issue is that it doesn't build and i don't care about it so much so i don't want to figure it out so i want to omit it entirely
<qschulz>
because BAD_RECOMMENDATIONS can be modified in an image recipe, and recipes cannot access other recipes' metadata (nor change it)
Qorin has joined #yocto
<qschulz>
it means that in order for bitbake to let the image recipe decide what to include or not, it needs to have created all the packages that might be included in an image
<qschulz>
so a package rrecommends something, means bitbake will build it "just in case
<qschulz>
"
<gordon1>
oh god
<qschulz>
if you don't need it, it'll just not be installed, but still built
<gordon1>
i see now
<gordon1>
so i have to modify the recipe with bbappend for it not to be built?
m4ho has joined #yocto
<qschulz>
for the same reaon that all packages of a recipe are built even if you don't care about them
<qschulz>
gordon1: yup
<gordon1>
i see
<gordon1>
ok, good that i didn't report the bug then
<qschulz>
gordon1: actually, could you still report one?
<qschulz>
but for the documentation
<qschulz>
because this definitely needs to be explicit
<qschulz>
it's not straightforward
<qschulz>
and you're probably not the first one to ask yourself this question
<gordon1>
i could but i don't have an account and it looks like registration is closed up
<qschulz>
(and considering that I took me that long to figure it out, that makes the two of us actually struggling with it... which is not good)
<gordon1>
tried to register one just a moment ago
<qschulz>
gordon1: mmm I don't think it should be the case
<qschulz>
any specific error
<qschulz>
or are you waiting for your confirmation mail or something?
<gordon1>
>Account creation is disabled due to recent spam attacks.
<gordon1>
i could email to the address it tells me to
<gordon1>
but it looks like it will take a while since it's human processed
<qschulz>
halstead: is it ok to reopen the registration for bugzilla?
<qschulz>
halstead: hi :)
<gordon1>
already sent the mail
<qschulz>
same person behind I assume :)
<qschulz>
so "double" ping :)
<gordon1>
i see
florian_kc has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
camus has joined #yocto
TundraMan is now known as marka
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<fray>
trying to help someone, they're getting the PR service error about PRs going backwards. I know there is a switch they can flip so PRs never go backwards, but I can't find it.. anyone point me to it?
<Saur[m]>
@fray: I actually think it is supposed to be enabled by default. Though it definitely doesn't work as I expect. I went looking for that switch a while ago and I found the code that was added to support it. That code was enabled by default, but no switch was actually added to turn it off...
Guest51 has joined #yocto
Guest51 has quit [Client Quit]
Sam47 has joined #yocto
Tokamak has quit [Ping timeout: 255 seconds]
Sam47 has quit [Client Quit]
<fray>
there used to be a setting you could flip that would just always keep the PR going forward... (I'm on Honister BTW)
<Saur[m]>
fray: That's what RP said as well when I asked for this, but the Git logs don't agree. What I can find is commit 379567ee879dcdc09a51f7f1212bde1076147a6f in bitbake. It adds what it calls "no history" mode, which is supposed to prevent the PRs from going backwards. It also enables this mode. However, there is no switch to actually turn it off.
<Saur[m]>
From the wiki page for the PR server:
<Saur[m]>
database wrapper object supports two working modes, "hist: Preserve PR history" and "no_hist: Don't use history (delete old entries from the database)"
<Saur[m]>
currently the server forces the no_hist=True value, forcing no_hist mode.
<shoragan>
fray, which release are they using?
mckoan is now known as mckoan|away
<shoragan>
ah, 3795... is from 2012.
florian_kc has quit [Ping timeout: 240 seconds]
<RP>
Saur[m]: regardless of the git logs, we probably should make this possible
<Saur[m]>
RP: Well, the problem I see is: why are the PRs going backwards when they are not supposed to with the current mode?
<Saur[m]>
I know I started digging into it, but then I of course got side tracked and forgot about it.
frieder has quit [Remote host closed the connection]
<RP>
Saur[m]: I don't remember enough of the details to comment sensibly
<Saur[m]>
No worries.
<fray>
PRs go backwards when developers are making local changes. I would never "disable" the warning in a production environment, but for a single developer it can make sense
<fray>
thing of it this way. I'm developing, initial build is PR=0... I try something (change a kernel config) kernel becomes PR=1... I figure out what I did doesn't make sense, and go back to the origina config.. PR=0, error is kicked off..
<fray>
in a "real" production environmnet.. you would want a PR=2, and force it by making a change..
<fray>
in a "dev" environmnet, you just want the system to say "ya, just make it PR=2 for now"
<halstead>
gordon1: All set. We processed accounts just before your request so there was a delay.
<gordon1>
thanks
florian_kc has joined #yocto
<Saur[m]>
Something else related to PRs going backwards is that it seems to happen way more often with Honister and later. So much so that I had to turn the error into a warning (we don't use package feeds so it should not be a real problem). Typically I often get a gazillion packages with PRs going backwards when setscene is running. And no I have not had time to look into this either yet, which is why I just made it a warning.
<kergoth>
Any use of sstate in development can result in them going backwards. make a cahnge, do a build, drop the change, do another build, it just went backwards.
<kergoth>
I just ignore that qa check entirely during development, just not in our automated builds
<Saur[m]>
kergoth: But according to the (limited) documentation about the no_hist mode indicates that it should still go forward in that case.
<RP>
Saur[m]: kergoth has a good point. pr_serv predates sstate so the docs for prserv wouldn't know anything about this
<Saur[m]>
But obviously it doesn't, so there must be something that I still haven't figured out about how the PR server works.
<Saur[m]>
Hmm, good point.
<RP>
Saur[m]: the key thing is that prserv predates sstate by many years. When we added sstate it probably changed behaviour
<RP>
in fact I'm pretty sure that was what we concluded last time we discussed this
<RP>
kergoth: what a strange world our builds used to be :)
* RP
suspects the lack of sstate and rss would drive people insane now
<Saur[m]>
Well, sstate was there before me, so I don't want to think about a world without it. But the lack of RSS I can definitely relate to, and what a pain it was.
<RP>
Saur[m]: imagine pre sysroots where you coded a do_install and a do_stage for the "sysroot" before sysroots were a thing too :)
<Saur[m]>
la la la I'm going to go debug something la la la
<Saur[m]>
;)
* RP
probably should tell horror stories
<RP>
shouldn't
<Saur[m]>
:)
<Saur[m]>
RP, the next Stephen King
<RP>
fray: so short answer is that sstate changed the behaviour and nobody has unwound this
<RP>
I suspect we're not even sure how you unwind that
<fray>
like hashequiv, prservice really needs to be "built into" sstate IMHO.. they shouldn't be separable..
<fray>
the "how", I don't know
<RP>
fray: that is the opposite of what you said you want above though
<RP>
fray: sstate is likely restoring the PR to a previous point. You want it to always rebuild
Tokamak has joined #yocto
<fray>
I'm saying they're linked..
<fray>
for the "Dev" case, we just need to deal with it..
<fray>
deal with it may be error -> warning.. force PR to increment and thus the package_write... sstate to update (somehow)..
<fray>
again, I have no actual answer..
<fray>
right now we have something that works for the production case (might be somewhat difficult to keep it in sync, but it works)... it's the dev case where "let me know, but I don't care" that we don't have a great answer for..
<fray>
I think I'm going ot tell the person who asked me to move the error to a warning in the buildhistory then.
<fray>
I (think) we all agree it's absolutely an error in the production case.. but could be considered a warning when doing development, unless you are using the packages themselves for on-target updates..
<RP>
fray: that "let me know, I don't care" is pretty much what today's warning is
<RP>
you can make it a warning, error or ignored by the WARN_QA and ERROR_QA settings
florian_kc has quit [Ping timeout: 256 seconds]
<JaMa>
RP: are you sure prserv predates sstate? I think it predates only rss and hashequiv, but not sstate itself
* JaMa
feels old without even looking in mtn history
<jsbronder>
Anyone have DL_DIR on nfs and bind-mounting into docker/podman? Git's new permission checks aren't happy with the way I'm binding and I'm not sure if there's an easy way out.
florian_kc has joined #yocto
prabhakarlad has quit [Quit: Client closed]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
Qorin has quit [Quit: Client closed]
prabhakarlad has joined #yocto
xmn has quit [Quit: ZZZzzz…]
<jsbronder>
Actually adding GIT_DIR=. or --git-dir=. to FETCHCMD_git appears to work.
<jsbronder>
Which is the hack I first used before the git intercept was added.
bps has quit [Ping timeout: 255 seconds]
kscherer has quit [Ping timeout: 250 seconds]
kscherer_ has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
<RP>
JaMa: prserv was written by Intel PRC team iirc
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<RP>
JaMa: looks like sstate was Aug 2010 which is older than I thought, prserv was May 2011
<RP>
JaMa: I guess I was thinking prserv in 2010 and siggen hashes in 2012
bps has joined #yocto
bps has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
Bardon_ has quit [Ping timeout: 272 seconds]
marex has quit [Ping timeout: 256 seconds]
ecdhe has joined #yocto
goliath has quit [Quit: SIGSEGV]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
prabhakarlad has quit [Quit: Client closed]
rber|res has quit [Ping timeout: 256 seconds]
leon-anavi has quit [Quit: Leaving]
rber|res has joined #yocto
warthog9 has quit [Ping timeout: 276 seconds]
warthog9 has joined #yocto
xmn has joined #yocto
Tokamak has quit [Ping timeout: 246 seconds]
bps has quit [Ping timeout: 244 seconds]
Tokamak has joined #yocto
florian_kc has quit [Ping timeout: 258 seconds]
mckoan|away has quit [Ping timeout: 255 seconds]
rber|res has quit [Ping timeout: 255 seconds]
kscherer_ has quit [Quit: Konversation terminated!]