Haxxa has quit [Remote host closed the connection]
warthog9 has quit [Quit: Leaving]
vthor has quit [Read error: Connection reset by peer]
wojci_ has quit [Ping timeout: 246 seconds]
prabhakalad has quit [Ping timeout: 246 seconds]
Starfoxxes has quit [Ping timeout: 246 seconds]
Starfoxxes has joined #yocto
ablu has joined #yocto
warthog9 has joined #yocto
Haxxa has joined #yocto
Kubu_work has joined #yocto
<mcfrisk_>
wic, another abstraction over bitbake. would need to teach it do python3native, openssl-native etc. generating uki images inside wic plugins seems very hard. no wonder the low level implementation.
Jones42_ is now known as Jones42
alessioigor has joined #yocto
florian has quit [Ping timeout: 255 seconds]
<Dvergatal>
hi is it possible to distinguish package configuration file depending on which image to be installed on? meaning that for initramfs i want to have an original configuration file provided by upstream and on the real rootfs image i would like to have my own
<qschulz>
Dvergatal: if it's a file for which the build configuration of the recipe doesn't change, you can simply have two different packages, one with the file you want in the initramfs, and one for the file you want in the rootfs
<qschulz>
and then you install package-initramfs in your initramfs via IMAGE_INSTALL/PACKAGE_INSTALL/whatever is the appropriate name for the initramfs
<qschulz>
and package-rootfs for the other
<Dvergatal>
unfortunately this is a procps package
<Dvergatal>
wrong
<Dvergatal>
procps-sysctl
<Dvergatal>
containing systctl.conf file
<qschulz>
if there's a name clash (so the file content is different but on the same location, then I think you'd need to generate this file dynamically in some do_package task or something (wild guess)
<qschulz>
Dvergatal: ok, so.. is it a build time change
<Dvergatal>
yeah
<qschulz>
yeah, so not possible with images
<qschulz>
two options
<qschulz>
if the build option only compiles new file, create a separate binary/shared library
prabhakalad has joined #yocto
<qschulz>
then split it into its own package
<qschulz>
and that package can be installed in the initramfs/rootfs but not the other one
<qschulz>
if it's not possible, or the build config changes the content of the binary/shlib of other packages creeated by this recipe
<qschulz>
then you need to use a different distro for the initramfs and the rootfs
<Dvergatal>
qschulz: generally procps contains in recipe directory sysctl.conf but I want to install my own on the normal image
<qschulz>
Dvergatal: Ah wait a sec
<qschulz>
Dvergatal: I don't know how frowned upon what i am going to suggest is, so maybe you'll hear people picking their pitchforks
<qschulz>
Dvergatal: if it's really just one file, you could simply overwrite this file from the initramfs do_rootfs task
<Dvergatal>
ahaaaaa
<Dvergatal>
in do_rootfs?
<qschulz>
I think so, or do_image?
<qschulz>
probably do_rootfs
<Dvergatal>
because currently what I manged is that i have both packages containing it
<qschulz>
what do you mean both packages containing it?
<Dvergatal>
but during do_rootfs of the image i have an error that both packages are containing same file name
<qschulz>
Dvergatal: yup makes sense
<Dvergatal>
I'm talking about RRECOMENDS and BAD_RECOMENDATIONS approach
<qschulz>
that would be a possible approach too yes
<qschulz>
provided you actually have RRECOMMENDS and not RDEPENDS
<Dvergatal>
yes but I do not know how to overwritte this file
<Dvergatal>
because I'm getting this error * check_data_file_clashes: Package procps-sysctl wants to install file /work/build/tmp/default-glibc/work/eg500-welotec-linux/welotec-base-image/1.0/rootfs/etc/sysctl.conf But that file is already provided by package * procps-sysctl-welotec
<qschulz>
Dvergatal: this means that procps-sysctl is still installed, even with BAD_RECOMMENDATIONS
<qschulz>
what's your setup with RRECOMMENDS and BAD_RECOMMENDATIONS
<qschulz>
what do you set those to and where
<Dvergatal>
yes it is because it also contains the binary
<Dvergatal>
the original procps-sysctl contains not only the confioguration file
albeu has joined #yocto
<Dvergatal>
but also some binary and init script
<qschulz>
Dvergatal: and I assume you want to keep everything BUT the systctl.conf :)
<Dvergatal>
and procps-sysctl-welotec contains just this configuration file
<Dvergatal>
qschulz: precisely
<qschulz>
Dvergatal: **if** you
<qschulz>
re the final user of your layer
<Dvergatal>
?
<Dvergatal>
qschulz: I don't understand
<qschulz>
you can just split /etc/sysctl.conf from procps-sysctl into a separate file
<qschulz>
s/file/package/
<qschulz>
e.g. procps-sysctl-conf
<Dvergatal>
mhmmmmmm
<qschulz>
with PACKAGE_BEFORE_PN and FILES:${PN}-sysctl-conf or something like that
lowfi has quit [Ping timeout: 260 seconds]
<Dvergatal>
ok so remove it from procps-sysctl
<Dvergatal>
create additional package containing the configuration file
<qschulz>
then you should add an RRECOMMENDS:${PN}-sysctl += "${PN}-sysctl-conf" to make sure your rootfs brings it in (or manually add it to your IMAGE_INSTALL)
<qschulz>
yup
<Dvergatal>
nice
<Dvergatal>
qschulz: thx
<qschulz>
why i am saying that the condition is you're the final user of your layer, is that by splitting stuff into more packages, if people use your layer and they update blindingly, they'll now have a change of behavior
<qschulz>
becuase the sysctl.conf file won't be installed anymore even though they instlal procps-sysctl package
<qschulz>
it's like breaking an API
<albeu>
Hi! I'm looking in some sstate caching issues. With my team we have a simple shared sstate cache volume which is fed from a build server that build images for 2 different arch and there seems to be some "arch less" task that depend on arch specific task. For example:
<albeu>
sstate:readline::8.2:r0::12:323fc075228069c961c04537ab22558159ea45456355c444c3c888dc71635fb2_fetch.tar.zst.siginfo depends on sstate:readline:core2-64-aerq-linux:8.2:r0:core2-64:12:008ffd98bdf2d1a8b3298f278c86304bfa8fbb97a26229831f3bb099afcad007_recipe_qa.tar.zst.siginfo. But on the build server cache the fetch sstate then used the cortexa53-crypto
<albeu>
version of the recipe_qa task which obviously has a different hash
<qschulz>
by using RDEPENDS:${PN}-sysctl += "${PN}-sysctl-conf", you could fix that by offering backward compatibility
<qschulz>
but that means you wouldn't be able to do what you want to do (i.e. replace one package by another from another recipe) easily
<Dvergatal>
qschulz: yeah this is what I wanted to add
<albeu>
I don't get how it can work if an sstate that is supposed to be arch independent depend on a task that is arch dependent.
Jones42_ has joined #yocto
mvlad has joined #yocto
alessioigor has quit [Remote host closed the connection]
Jones42 has quit [Ping timeout: 264 seconds]
alessioigor has joined #yocto
florian has joined #yocto
<KanjiMonster>
Dvergatal: unless you need to override values from the default /etc/sysctl.conf you could probably also just put your file into e.g. /etc/sysctl.d/ and avoid any file conflicts
ehussain has joined #yocto
Jones42 has joined #yocto
Jones42_ has quit [Read error: Connection reset by peer]
<Dvergatal>
KanjiMonster: thx qschultz solution did the trick
ehussain has quit [Client Quit]
albeu has quit [Quit: Client closed]
Guest51 has joined #yocto
florian_kc has joined #yocto
Guest51 has quit [Quit: Client closed]
jmiehe has joined #yocto
albeu has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
sakoman has quit [Ping timeout: 248 seconds]
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
rber|res has joined #yocto
fabatera has joined #yocto
sakoman has joined #yocto
<albeu>
So looking further I found out that there is special handling in the sstate stuff to make do_fetch "arch less", but later the do_recipe_qa task was added to run before do_fetch which create this issue with the sstate. Could it be that hash equivalence hide this issue because the result of do_fetch doesn't actually depend on the result of the recipe
<albeu>
QA?
<albeu>
I would like to remove the dependency between do_fetch and do_recipe_qa, is there a better way then deltask + addtask?
<fabatera>
Hi all! Is there a better way to patch code that is one level above the source ? (I'm working with third-party code)
<fabatera>
e.g.:
<fabatera>
S = "${WORKDIR}/${PV}/dir1"
<fabatera>
Code to be patched is in ${WORKDIR}/${PV}/dir2
<fabatera>
It works fine like this:
<fabatera>
do_patch(){
<fabatera>
cd ${S}/../
<fabatera>
patch -p1 < ${WORKDIR}/my.patch
<fabatera>
}
<fabatera>
But this way one should do the same for all the other patch files for dir1, otherwise they will be ignored.
<fabatera>
On another experiment, my.patch file had the following but `quilt` can't find the file to be patched. (do_patch above was not implemented)
<qschulz>
fabatera: but why would S be dir1 if there's also source code in dir2?
<fabatera>
qschulz only for convenience. the Makefile and project are in dir1 and it uses somehow dir2. I could change S = "${WORKDIR}/${PV}/, but then would need to adjust do_compile, for example
<fabatera>
qschulz Thanks for the patchdir hint!
sakoman has joined #yocto
Habbie has joined #yocto
gioyik has joined #yocto
sarahn has joined #yocto
dkc has quit [Remote host closed the connection]
<Saur>
fabatera: You can add ;patchdir=.. to the URI for the patch that needs to be applied in ${S}/..
dkc has joined #yocto
gioyik has quit [Ping timeout: 260 seconds]
Guest51 has joined #yocto
gioyik has joined #yocto
gioyik has quit [Ping timeout: 260 seconds]
alessioigor has quit [Remote host closed the connection]
lexano has joined #yocto
gioyik has joined #yocto
gioyik has quit [Ping timeout: 260 seconds]
Guest51 has quit [Ping timeout: 256 seconds]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
kalj has joined #yocto
gioyik has joined #yocto
<fabatera>
Thanks qschulz and Saur! It worked like a charm :)
Guest51 has joined #yocto
kalj has quit [Client Quit]
gioyik has quit [Ping timeout: 260 seconds]
Guest51 has quit [Quit: Client closed]
sugoi has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
jmiehe has quit [Quit: jmiehe]
sugoi has quit [Ping timeout: 260 seconds]
gioyik has joined #yocto
gioyik has quit [Ping timeout: 260 seconds]
Haxxa has quit [Ping timeout: 246 seconds]
albeu has quit [Quit: Client closed]
fabatera has quit [Quit: Client closed]
Haxxa has joined #yocto
gioyik has joined #yocto
gioyik has quit [Ping timeout: 260 seconds]
gioyik has joined #yocto
xantoz has quit [Ping timeout: 248 seconds]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
fabatera has joined #yocto
fabatera has quit [Client Quit]
gioyik has quit [Ping timeout: 260 seconds]
Guest13 has joined #yocto
<Guest13>
hi, more like a linux question instead of yocto: does anyone know any type of tool to control running applications? e.g, i want to apply a profile "plane", and app X, Y, Z will run, network configuratino will apply, etc.. and then i have another profile "rover" and other apps/configuration run. should i create separate images for these?
wojci__ has quit [Ping timeout: 264 seconds]
gioyik has joined #yocto
Xagen has joined #yocto
xmn has joined #yocto
gioyik has quit [Ping timeout: 260 seconds]
<Saur>
Guest13: Sounds like something you would do with systemd targets...
<albeu>
Further diving into my sstate issues I now have 2 sstate file for the same task, one from my local machine, one from the build server. They have a different taskhash but bitbake-diffsigs show no differences except the taskhash. Looking into the singinfo file it turns out that the values in the file_checksum_values array are in a different order :(
<albeu>
Any idea what could be causing this?
<albeu>
This is with scarthgap / bitbake 2.8
rfuentess has quit [Remote host closed the connection]
<RP>
albeu: I suspect they are sorted and it won't be that. hash equivlanence may be at play and more likely to be the cause
<albeu>
I have no hash equivalence enabled
<RP>
albeu: that simplifies things then :)
gioyik has quit [Quit: WeeChat 4.4.1]
<albeu>
It seems like bitbake-diffsigs sort for presentation so it doesn't show there, but the task hash use the underlying data which is sorted differently
<albeu>
The same docker image is used on both side so the host is virtually identical
Kubu_work has quit [Quit: Leaving.]
<albeu>
For background I'm moving from hardknott to scarthgap, I always had 100% sstate match with hardknott, now with scarthgap I get barely 50%
<albeu>
I'm kind of suspecting that some issues have cropped up that are otherwise "hidden" by hash equivalence
<RP>
albeu: do you have the two sig files somewhere I could take a look?
<albeu>
sure, where could I upload them?
<RP>
I think that code did change between those two releases
<RP>
albeu: not sure. Perhaps email to me might be easiest?
<albeu>
These are just the decompressed siginfo as-is
sugoi has joined #yocto
<albeu>
I have to leave now, but if needed I can send you the original compressed file by email later. Thanks for looking into this.
<albeu>
Also as mentioned above I remove the do_fetch -> do_recipe_qa dependency in this build
florian has quit [Quit: Ex-Chat]
sugoi has quit [Ping timeout: 248 seconds]
prabhakalad has quit [Ping timeout: 246 seconds]
prabhakalad has joined #yocto
<RP>
albeu: looking at the code in siggen.py, the checksums definitely are sorted when computing the hash
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #yocto
<RP>
albeu: I think I can see an issue buried in here :/
sakman_ has quit [Remote host closed the connection]
vthor_ is now known as vthor
Guestnorvil has joined #yocto
<Guestnorvil>
hi, im new to yocto an I'm trying to create a basic image for a beagleboardx15
leon-anavi has quit [Quit: Leaving]
<Guestnorvil>
Does anyone has done the same or could give me a quick guide to what to do or look for? please please
jmd has quit [Remote host closed the connection]
mbulut_ has quit [Ping timeout: 252 seconds]
jmd has joined #yocto
Kubu_work has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
Guestnorvil has quit [Quit: Client closed]
ablu has quit [Ping timeout: 246 seconds]
sugoi has joined #yocto
ablu has joined #yocto
Jones42 has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]
florian_kc has joined #yocto
Starfoxxes has quit [Ping timeout: 264 seconds]
<jkale>
Guestnorvil: I would start with meta-ti https://git.yoctoproject.org/meta-ti. the meta-ti-bsp layer has beagle-x15 machine conf file and tells you the other required layers. scarthgap branch for everything.
Shaun has quit [Remote host closed the connection]
Jones42_ has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
Shaun has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
jmd has quit [Remote host closed the connection]
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Habbie has quit [Ping timeout: 246 seconds]
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
olani- has joined #yocto
albeu has quit [Quit: Client closed]
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
albeu has joined #yocto
albeu has quit [Client Quit]
mvlad has quit [Remote host closed the connection]
DvorkinDmitry has joined #yocto
mvlad has joined #yocto
<DvorkinDmitry>
can I do do_image_wic[depends]:remove = "myrecipe:do_deploy" ?
Kubu_work has quit [Quit: Leaving.]
nerdboy has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
mvlad has quit [Remote host closed the connection]