kscherer has quit [Quit: Konversation terminated!]
florian_kc has quit [Ping timeout: 240 seconds]
sakoman has quit [Quit: Leaving.]
<PhoenixMage>
Oddly my modules directory doesnt contain all the modules I would have expected
<PhoenixMage>
Seems the busybox getty has a problem with ttyS?
<PhoenixMage>
Replaced with agetty and can now login
goliath has quit [Quit: SIGSEGV]
vmeson has quit [Ping timeout: 260 seconds]
vmeson has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
davidinux has quit [Ping timeout: 268 seconds]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
davidinux has joined #yocto
nemik has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
Tokamak_ has joined #yocto
Tokamak has quit [Ping timeout: 248 seconds]
sakoman has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
<PhoenixMage>
Reading through the docs for kirkstone I saw this "Kernel module tarballs exist for legacy purposes" if module tarballs are legacy, what is the replacement?
amitk has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
Tokamak has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
Tokamak_ has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
Vonter has quit [Ping timeout: 268 seconds]
alessioigor has joined #yocto
<PhoenixMage>
Man, its quiet in here today
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Vonter has joined #yocto
goliath has joined #yocto
alessioigor has quit [Quit: alessioigor]
m4ho has quit [Read error: Connection reset by peer]
alessioigor has joined #yocto
Schlumpf has joined #yocto
m4ho has joined #yocto
rob_w has joined #yocto
<mcfrisk>
hmm, why does packagegroup-base exist if it's not used anywhere? I'm checking runtime test results where parselogs fails due to missing regulatory.db on the image. wifi is enabled in DISTRO_FEATURES but that doesn't bring packagegroup-base-wifi and wireless-regdb-static to images by default.
Schlumpf has quit [Ping timeout: 260 seconds]
rfuentess has joined #yocto
<mcfrisk>
and packagegroup-base-extended is installed to all images by default but that is empty, which triggers compilation of packagegroup-base and all the various recipes via features enabled in DISTRO_FEATURES
<mcfrisk>
so we just compile but don't use by default? Why even compile?
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
gho has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has joined #yocto
mckoan|away is now known as mckoan
manuel1985 has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
manuel1985 has quit [Ping timeout: 260 seconds]
Schlumpf has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
mvlad has joined #yocto
manuel1985 has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
frieder has joined #yocto
nemik has joined #yocto
<Schlumpf>
How to patch a file, which is not in source dir? I have to patch a file by a .bbappend. The original .bb adds some files to workdir, which are not part of the source. If I add a .patch file to my .bbappend, the file to patch is not found. Quilt seems to only patch files in source dir. How can I patch a file in workdir?
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<mcfrisk>
Schlumpf: if the file is generated, you can modify it with a do_install_append() in a .bbappend
<mcfrisk>
Schlumpf: if the file is part of SRC_URI and for example next to the recipe in meta layer, then patching it is tricky, though you can easily remove the original version from the recipe and replace with your version which is next to your .bbappend
<LetoThe2nd>
yo dudX
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<mckoan>
hey LetoThe2nd
<qschulz>
o/
<qschulz>
Schlumpf: have a bbappend with FILESEXTRAPATHS:prepend set correctly and just add your patched file in the directory pointed to by the aforementioned variable
<mckoan>
why meta-java is stuck at ver.8 ?
<mckoan>
why in meta-java OpenJDK is stuck at ver.8 ?
<Schlumpf>
mcfrisk qschulz: Thanks for the answer. The file is part of SRC_URI. My current workaround is to call "patch -p1 < ${WORKDIR}/0001-mute.patch-before-install" in a do_install_prepend(). I wonder what the right approach is. Since I only want to change one line, replacing the whole file might be a bit to much.
<qschulz>
Schlumpf: if you don't want to replace it (which is what *I* would do), at least patch the file in do_patch :)
<mcfrisk>
Schlumpf: you can provide the same file from you meta layer, just prepend the path with FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
Wouter0100 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
zpfvo has joined #yocto
florian has joined #yocto
d-s-e has joined #yocto
<Schlumpf>
qschulz: you are right. do_patch() is the better place. I'll create a do_patch_append().
<Schlumpf>
mcfrisk: Since I only want to change one line in a larger script, I think I will stick to patching instead of replacing the whole file. I think it will be clearer what my layer is doing here.
<Schlumpf>
If I understand you correctly, patching files outside the folder is not intended with on-board tools. Such files are rather replaced. If I want to do it, I have to make something myself.
<rburton>
Schlumpf: can you not patch the thing that generates the file
<RP>
rburton: it sounds like file directly added by SRC_URI
<qschulz>
Schlumpf: yes, IIRC you can also patch the files by giving the appropriate patchdir fetcher argument
<qschulz>
Schlumpf: but from experience, this usually breaks devtool if used incorrectly
florian_kc has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
amelius has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
d-s-e has quit [Ping timeout: 268 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
<mcfrisk>
Schlumpf: in those cases I used sed in a do_install_append() of a .bbappend. This was more reliable to updates than patch files.
<qschulz>
mcfrisk: the risk with using sed is that you don't know when it stops working because the line disappeared or the context around it
<qschulz>
a patch helps with that (though sometimes patches apply in the wrong location but I haven't seen that happen more than once in my lifetime :)
<mcfrisk>
yep there are pros and cons with any approach
<mcfrisk>
oh I've seen so many patches being applied and rebased wrongly. just think of many vendor kernels and their 'mandatory set of patches'
<mcfrisk>
but if use is like changing or adding line systemd service files, patches may be annoyingly strict across updates while a single string replacement is what works.
d-s-e has joined #yocto
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<RP>
I have thought we should have a version of sed which returns the number of replacements
<qschulz>
RP: at least fail on nothing being done?
<RP>
qschulz: yes, that would be better than nothing
meego has joined #yocto
mckoan is now known as mckoan|away
jclsn has joined #yocto
<jclsn>
JPEW: I have been getting SSH fetcher failures with Pyrex lately. Seems to be an issue with mounting the SSH keys into the container. Have you experienced something similar?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
d-s-e has quit [Ping timeout: 260 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
GNUmoon has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
seninha has quit [Remote host closed the connection]
<ramacassis[m]>
is it a good practice if I create a "meta-upgrade" that will only contain these upgraded recipes ? are there other ways ?
<jclsn>
ramacassis[m]: Why not use a .bbappend?
<qschulz>
Tyaku: rburton said a few days ago: you can force a deploy with bitbake myimage --cmd deploy --force
<qschulz>
but in short, either remove all the tmpdir or don't touch ikt
<qschulz>
ramacassis[m]: by upgrading you mean more recent versions of the same recipe or fixing issue in them?
<qschulz>
if it's more recent versions, then we highly recommend you create a new recipe
<qschulz>
some people even go as far as recommending copying the .inc files so that if they get changed in upstream layers you are not impacted by the changes
<ramacassis[m]>
jclsn: because there is a huge gap between my recipe version (dunfell) and the upgraded one (in kirkstone for instance), plus there are new CVE patches and fixes that are useful
zpfvo has quit [Ping timeout: 268 seconds]
<qschulz>
ramacassis[m]: much easier to maintain if you copy the whole recipe
<qschulz>
and also way less confusing
<jclsn>
True
<ramacassis[m]>
so, copy the whole upgraded recipe and files in "meta-upgrade" and write a .bbappend for my own patches and files in "meta-my-software" ?
<ramacassis[m]>
if I have the right philosophy in mind, I should not have a .bb and .bbappend in the same layer
d-s-e has joined #yocto
<qschulz>
ramacassis[m]: up to you, what I used to do is to import the recipe as is from a specific commit and mark is as an importnat in the commit log
<qschulz>
and then make patches on top
<qschulz>
this makes it easier (at least it did for me) for your integrators to deal with layer updates and check if there were patches upstream that are now missing and need to be applied for example
<JPEW>
jclsn: I haven't, how are you mounting them in?
<jclsn>
JPEW: Via the pyrex.ini. It might not be a docker issue, because it just occured without a container.
<jclsn>
I love errors that just occurs spontaneously
<jclsn>
It did occur more often with Pyrex though
<jclsn>
No idea
<JPEW>
Weird. What's the error?
zpfvo has joined #yocto
<JPEW>
jclsn: You can also try to reproduce it manually in the container with the pyrex-shell command, which drops you into a shell in the container
<ramacassis[m]>
qschulz: I see, I wanted to avoid editing the "official" recipe, even it it's copied in my own layer, but you're right the commit log will trace the changes
<ramacassis[m]>
thanks for the feedbacks
<jclsn>
JPEW: Thanks, will first annoy my Devops guy with it. I doubt this is a Docker issue as it just occurs spontaneously. Think our servers are overloaded in some way
<JPEW>
Ya that can happen also
sakoman has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
kscherer has joined #yocto
<jclsn>
How to reduce the number of parallel fetches?
<rburton>
you can't reduce that specifically, BB_NUMBER_THREADS controls the number of parallell tasks
GillesM has joined #yocto
<jclsn>
rburton: Well we are having multiple SSH logins due to a single fetch on our server. It is really weird
<jclsn>
If I reduce the number of threads my build will slowdown, which is counterproductive
<rburton>
what fetcher?
<rburton>
some fetchers will hit the remote more than once
<rburton>
ssh controlmaster for the win, if you are making lots of connections to the same host
<jclsn>
ssh controlmaster?
<jclsn>
The bitbake fetcher I guess
<jclsn>
We are fetching our own repos via SSH
<rburton>
git repos?
<JPEW>
jclsn: What is your git hosting solution?
<jclsn>
JPEW: Gitlab
<jclsn>
rburton: Our Devops colleague just tried a controlmaster config, but it's not being used by bitbake somehow
<JPEW>
jclsn: How did you set that up?
zpfvo has quit [Ping timeout: 260 seconds]
<jclsn>
JPEW: Got it working. Seems like the ~/.ssh/controlmaster directory was missing
DvorkinDmitry has joined #yocto
<DvorkinDmitry>
is there are a way to set ARCH-specific INHERIT for multiconfig in local.conf ?
<JPEW>
DvorkinDmitry: Not in local.conf, you you can do it in the specific multiconfig .conf file
<DvorkinDmitry>
oh! I need to add text into my INHERIT if layer exist or inside the layer. is it possible?
<DvorkinDmitry>
how to do it in specific multiconfig ?
<DvorkinDmitry>
you mean add INHERIT ... into my conf/multiconfig/ARCHx.conf ?
<JPEW>
DvorkinDmitry: Right
<DvorkinDmitry>
well. looks good, but I need it only if LAYER1 and LAYER2 are added. Layer2 is made by me. Can I do it inside Layer2 somehow?
zpfvo has joined #yocto
<JPEW>
DvorkinDmitry: I don't think so
<DvorkinDmitry>
otherwise user should update several configuration files that is not so well
<DvorkinDmitry>
can I do INHERIT:append:myarch += "..." in local.conf?
<JPEW>
DvorkinDmitry: I don't know. I guess that might work? I don't normally think of INHERIT working that way, but maybe it would. You don't need the += with append though :)
<DvorkinDmitry>
thank you. :) I have a habit to use += case dislike additional ' ' before text to add :)
<qschulz>
DvorkinDmitry: this stopped working in recent releases, so better get used to it now :)
<DvorkinDmitry>
oh! thank you!
<jclsn>
Anyway, is bitbake supposed to create so many parallel logins?
<qschulz>
DvorkinDmitry: I don't know how bad of an idea it is and if it's going to work, but you could add an "include conf/multiconfig/layer2.conf" in your multiconfig file
<qschulz>
DvorkinDmitry: include will not fail if it cannot find the file to include
seninha has quit [Ping timeout: 268 seconds]
<qschulz>
the path to give is relative to the root of the layer
<qschulz>
(of the layer the file is located in)
otavio has quit [Read error: Connection reset by peer]
<DvorkinDmitry>
qschulz, interesting! so I can add include ... into my conf/multiconfig/myarch.conf, points to some layer and there will not be a problem if layer will not exist?
<qschulz>
DvorkinDmitry: you do not point to a layer, you point to a file in *a* layer
<qschulz>
if the file is in multiple layers, the first to be found is used
<qschulz>
so make it unique :)
<qschulz>
and the path is relative to the root of the layer the file is in
<qschulz>
(the file that is included in the include directive, not the file which includes the other file)
<DvorkinDmitry>
qschulz, ha! interesting! and layers are checked for the file in the priority order?
<qschulz>
DvorkinDmitry: no, in order of BBPATH AFAIR
<jclsn>
JPEW: Doesn't seem to work in Pyrex, although the ~/.ssh dir is mounted
kris has quit [Remote host closed the connection]
<qschulz>
jclsn: any reason for not using an ssh agent instead of mounting the .ssh dir (which is bad practice security wise)
<qschulz>
jclsn: anyways, I suggest you log into the container and check a simple ssh command there, the permissions of the directory and files, etc.
<qschulz>
I remember Fedora refusing to use my ssh keys because I had the wrong permissions on my .ssh dir and files (too open, had messed up the permission during a backup)
seninha has joined #yocto
<jclsn>
qschulz: Think it didn't work with an agent or I did not get it to work
<JPEW>
You may need to pass the agent socket into pyrex
<JPEW>
jclsn: It's a little hidden, but look at run.envsockproxy in pyrex.ini
zpfvo has quit [Ping timeout: 260 seconds]
<jclsn>
JPEW: Tried that. Doesn't work
<jclsn>
Well, I'll try to fix that tomorrow
<qschulz>
jclsn: -e SSH_AUTH_SOCK -v $SSH_AUTH_SOCK:$SSH_AUTH_SOCK should do IIRC
zpfvo has joined #yocto
Schlumpf has quit [Quit: Ping timeout (120 seconds)]
alessioigor has quit [Quit: alessioigor]
<vvn>
in order to have a "smaller" systemd package for the initrd for example, what's you guys opinion on maintaining two distros versus maintaining a recipe fork like systemd-minimal?
alessioigor has joined #yocto
DvorkinDmitry has quit [Ping timeout: 240 seconds]
rob_w has quit [Remote host closed the connection]
d-s-e has quit [Quit: Konversation terminated!]
zpfvo has quit [Ping timeout: 256 seconds]
Algotech75 has joined #yocto
Algotech has quit [Ping timeout: 255 seconds]
<rburton>
vvn: can you get away with not even using systemd for the initrd?
<rburton>
one of the documented usecases is systemd for the main system but busybox init for initrd
<vvn>
rburton: I could but I actually like systemd as the initrd
zpfvo has joined #yocto
<vvn>
still a bit too fat, but promising still
otavio has joined #yocto
rsalveti has quit [Quit: Connection closed for inactivity]
<rburton>
split the package up into more subpackages and just install the bits you need?
goliath has quit [Quit: SIGSEGV]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<vvn>
rburton: yep this was my question actually, tweaking features from a new distro and playing with INITRAMFS_MULTICONFIG seems simpler, but still more cumbersome than splitting a few packages
* vvn
knows that rburton usually prefers to keep it minimal and avoid multiple distros if possible :-)
manuel_ has quit [Ping timeout: 240 seconds]
rfuentess has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
dmoseley has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 240 seconds]
gho has quit [Quit: Leaving.]
gho has joined #yocto
zpfvo has quit [Quit: Leaving.]
seninha has quit [Ping timeout: 256 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<vvn>
is there a way to specify an alternative name from within an SRC_URI entry directly? e.g. "file://fstab.foo" to override the file "fstab", or does one need append do_install to copy the file manually?
kevinrowland has quit [Quit: Client closed]
Tyaku has quit [Quit: Lost terminal]
<rburton>
your layer with the append can just have fstab
Tokamak has quit [Quit: Tokamak]
KaitoDaumoto has joined #yocto
alessioigor has quit [Quit: alessioigor]
sgw has joined #yocto
PhoenixMage has quit [Ping timeout: 268 seconds]
PhoenixMage has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
Tokamak has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
PhoenixMage has quit [Ping timeout: 256 seconds]
PhoenixMage has joined #yocto
prabhakarlad has quit [Quit: Client closed]
PhoenixMage has quit [Ping timeout: 268 seconds]
PhoenixMage has joined #yocto
frieder has quit [Remote host closed the connection]
amitk has quit [Ping timeout: 268 seconds]
GillesM has quit [Quit: Leaving]
seninha has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
ThomasRoos[m] has joined #yocto
<vvn>
rburton: I guess I should set FILEEXTRAPATHS:prepend := "${THISDIR}/${DISTRO}:" in order to cleanly separate and maintain multiple base-files/<distro>/<machine>/fstab
<rburton>
vvn: it already looks in folders like that already iirc
<rburton>
vvn: do $ bitbake-getvar FILESPATH -r [recipe]
<rburton>
you'll see PN/distro/
<vvn>
rburton: yep but not in distro-machine combinations
prabhakarlad has joined #yocto
<vvn>
rburton: the system is built so that you have a machine layer with distro folders, or a distro layer with machine folders, but not really both together
<vvn>
which makes it a bit hard to maintain distro layers not altering the build (i.e. having them in BBLAYERS without affecting the build if the distro isn't used)
<JPEW>
vvn: Not sure if it helps, but I added support a while ago for each multiconfig to have an independent BBMASK
<JPEW>
So you can mask off layers per-multiconfig
sakoman has quit [Quit: Leaving.]
<khem>
abelloni: can you point to failing build logs for X on rv64
Tokamak has joined #yocto
dmoseley has joined #yocto
mvlad has quit [Remote host closed the connection]
meego has quit [Quit: Leaving...]
<moto-timo>
yocti, tell Crofton to click the button!
<yocti>
moto-timo: The operation succeeded.
<abelloni>
khem: it is a runtime failure, not a build one
DvorkinDmitry has joined #yocto
<abelloni>
core-image-sato doesn't fully work on qemuriscv64
kevinrowland has quit [Quit: Client closed]
florian_kc has quit [Ping timeout: 260 seconds]
<khem>
I usually boot weston image these days so have not seen X11 issue, perhaps I should try it out sometime
<moto-timo>
Or we could burn x11 to the ground forever
<moto-timo>
(at-spi2-core and webkitgtk upgrade grumble grumble)
<moto-timo>
I think this upgrade is going to cause problems.
<moto-timo>
We need to ditch gtk3+, but we need something else (besides sato)
<moto-timo>
Ok, at least I think I have webkitgtk upgrade building
<abelloni>
+& for starting a fire with x11 ;)
<abelloni>
+1
kscherer has quit [Quit: Konversation terminated!]
<rburton>
moto-timo: i should give a custom sway a go again
<DvorkinDmitry>
can anybody give me very simple example how to write smething like image_type_wic.bbclass ?
<moto-timo>
rburton: possibly. I’ll post the wip branch if core-image-sato builds