Minvera has quit [Remote host closed the connection]
davidinux has quit [Ping timeout: 250 seconds]
GNUmoon has quit [Ping timeout: 258 seconds]
davidinux has joined #yocto
GNUmoon has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
seninha has quit [Remote host closed the connection]
jclsn has quit [Ping timeout: 250 seconds]
jclsn has joined #yocto
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
starblue has quit [*.net *.split]
Haxxa has quit [*.net *.split]
fitzsim has quit [*.net *.split]
skoink[m] has quit [*.net *.split]
MichaelNazzareno has quit [*.net *.split]
jaskij[m] has quit [*.net *.split]
kmaincent[m] has quit [*.net *.split]
hpsy[m] has quit [*.net *.split]
khem has quit [*.net *.split]
T_UNIX[m] has quit [*.net *.split]
rsalveti has quit [*.net *.split]
Ebeneezer_Smooge has quit [*.net *.split]
zwelch has quit [*.net *.split]
barometz has quit [*.net *.split]
u1106 has quit [*.net *.split]
zkrx has quit [*.net *.split]
fleg has quit [*.net *.split]
LocutusOfBorg has quit [*.net *.split]
warthog9 has quit [*.net *.split]
rsalveti has joined #yocto
zwelch has joined #yocto
starblue has joined #yocto
fleg has joined #yocto
T_UNIX[m] has joined #yocto
barometz has joined #yocto
SSmoogen has joined #yocto
warthog9 has joined #yocto
hpsy[m] has joined #yocto
u1106 has joined #yocto
Haxxa has joined #yocto
LocutusOfBorg has joined #yocto
zkrx has joined #yocto
khem has joined #yocto
kmaincent[m] has joined #yocto
MichaelNazzareno has joined #yocto
skoink[m] has joined #yocto
jaskij[m] has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
schtobia has quit [Quit: Bye!]
schtobia has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
alessioigor has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
xmn has quit [Ping timeout: 260 seconds]
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
Schlumpf has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Ping timeout: 246 seconds]
nucatus has joined #yocto
frieder has joined #yocto
frieder has quit [Remote host closed the connection]
frieder has joined #yocto
nucatus has quit [Ping timeout: 264 seconds]
nucatus has joined #yocto
rfuentess has joined #yocto
goliath has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
frieder has quit [Read error: Connection timed out]
zpfvo has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
frieder has joined #yocto
nucatus has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
prabhakarlad has joined #yocto
<Schlumpf>
good morning
zpfvo has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus has joined #yocto
<rfuentess>
morning
manuel_ has joined #yocto
camus has quit [Ping timeout: 246 seconds]
camus has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
ptsneves has joined #yocto
<qschulz>
o/
hcg has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
florian has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
nucatus has joined #yocto
RobertBerger has quit [Ping timeout: 252 seconds]
zhmylove has joined #yocto
Schiller has joined #yocto
Schlumpf has quit [Ping timeout: 244 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
<qschulz>
tlwoerner: o/ We just released a new Rockchip-based module and I'd like some initial support in meta-rockchip layer. I just send a patch for the SoC support for the master branch and was wondering if there's any chance we can have it in kirkstone branch?
zpfvo has joined #yocto
<qschulz>
I don't plan to send support for the board to meta-rockchip until we have decent support upstream, to avoid meta-rockchip becoming a vendored BSP layer
<qschulz>
I'm still catching up with our older module that I still want to have in meta-rockchip, we finally should have a fixed U-Boot for 2023.01 version, so I guess it's for after Langdale :)
<qschulz>
tlwoerner: if we cannot get the SoC support in meta-rockchip kirkstone branch, we'll just carry it locally until next releases, just to know if I should wait a bit before releasing our venmdor BSP layer :)
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<kayterina[m]>
Is there something special when SRC_URI:append:machineA in a native recipe? Because it is read once?
<qschulz>
kayterina[m]: using a machine override in a native recipe shows there is some logic issue
<qschulz>
a native recipe runs on your host, it does not (and should not) have knowledge of the target your're building for
<kayterina[m]>
hm.it is logical.
<qschulz>
since native recipes are re-used for all builds with the same distro, whatever the image or machine you build for, it is essential there's nothing machine specific in it
<qschulz>
kayterina[m]: so, the question is.. what are you tryuing to do so we can maybe advise on a solution :)
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<kayterina[m]>
Correct. So, it is a tool that builds and runs on different machines and there is also a native version to run on pc because target machine has limited powers. I see the patches change some make options dependant on the machine.
<kayterina[m]>
so perhaps it is an override on a do_configure?
<qschulz>
kayterina[m]: is it required at build time or can it be a runtime option, parameter, flag, variable passed to the native version?
<kayterina[m]>
it is required at build time, it removes a lib from the .mk
<kayterina[m]>
some flags and a library
<qschulz>
kayterina[m]: I would go with a different recipe per machine you want to support
<qschulz>
at least a different BPN/PN
<qschulz>
and you'll need to explicit on which "version" of the native recipe a given target recipe depends on
<qschulz>
the proper way would maybe be to take inspiration from what was done for gcc, since it is a native recipe but need to know about the target (because it cross compiles)
<qschulz>
but ideally, modifying the native recipe to have one binary that can be configured via environment variables or parameters would be best
<kayterina[m]>
there is also a hack. The native and target recipe share a patch. A variable is added in an .inc and it gets appended SRC_URI:append I can append that recipe per machine.
<qschulz>
kayterina[m]: that's not going to change the fact that your native recipe does not know about your machine
<kayterina[m]>
Wait, $machine has a value inside the recipe.
<kayterina[m]>
it should not know, but it knows.
<qschulz>
kayterina[m]: check the value of OVERRIDES
<qschulz>
I don't think you have this info there
<kayterina[m]>
I checked with an "echo $MACHINE" inside do_configure. What am I looking at OVERRIDES?
<qschulz>
kayterina[m]: OVERRIDES is the mechanism that allows you to do SRC_URI:append:machineA
<qschulz>
if machineA is not in OVERRIDES, it won't work
<qschulz>
and I highly suspect target machines aren't part of OVERRIDES for native recipes
Schiller has quit [Ping timeout: 244 seconds]
<rburton>
correct, native recipes have no idea what the target is
<qschulz>
kayterina[m]: but if MACHINE is set, you could do something like SRC_URI:append = "${@ 'file://additional.patch" if d.getVar('MACHINE') else ''}" but I'm sure this is a bad idea
<zeddii>
LetoThe2nd. precisely. I always say that wiki pages are where information goes to be lost.
<LetoThe2nd>
zeddii: +1
<zeddii>
tlwoerner. impressive! :)
<tlwoerner>
zeddii: i'll take a poke at updating it post 3.1
<zeddii>
you'd have my thanks!!
<tlwoerner>
maybe it should also make some mention of the kernel mixin?
<tlwoerner>
(for 3.1)
<rburton>
what mixin?
<rburton>
it looks like paul's meta-kernel-mainline is dead
<tlwoerner>
:-(
* tlwoerner
hopes paul is fairing better
pasherring has joined #yocto
alessioigor has quit [Quit: alessioigor]
<Guest13>
trying to get a build using "meta-raspberrypi" kirkstone, but im getting the error "The postinstall intercept hook 'update_mime_database' failed". what could it be caused by?
alessioigor has joined #yocto
<LetoThe2nd>
Guest13: guess thats some package you're pulling in. what are you installing? does it happen for core-image-minimal also?
<Guest13>
yes, it happens when getting "core-image-minimal" build as well.
vladest has joined #yocto
<LetoThe2nd>
Guest13: which layers are involved? what are they pulling into IMAGE_INSTALL, or some form of RDEPENDS? which specific machine are you building for?
landgraf has quit [Ping timeout: 264 seconds]
<Guest13>
using meta-openembedded,qt5,raspberrypi,poky and my layer.
<LetoThe2nd>
Guest13: what happens if you first remove your layer? if it still happends, then does it persist if you remobe meta-qt5?
<Guest13>
meta-qt5 not included in this build. im using meta-poky,openembedded,raspberrypi and my layer.
<LetoThe2nd>
then remove your layer.
<Guest13>
i will remove my layer and try, thank you.
sakoman has joined #yocto
<vvn>
JaMa: I want to make sure I understand what you said yesterday regarding @LGE. In an ideal world, would you rather maintain a single distro and more images or more distros and less images for your products?
<JaMa>
vvn: it depends, having single distro and just multiple images will be best for maintenance, but as mentioned the limitations can restrict you too much (e.g. once different configuration will prefer different gstreamer versions or something like that)
<JaMa>
vvn: but if you have powers to enforce it, then great and I'll envy you
<JaMa>
since then almost everything got MACHINE_ARCH not only "formally" due to some dependency being MACHINE_ARCH (luna-service2 was causing most issues back then), but developer started to use MACHINE variable left and right like mad
kscherer has joined #yocto
<JaMa>
and now even when they complain that adding support for new MACHINE is a lot of work (many #ifdefs need to be duplicated in the code to catch another MACHINE value), it's a bit too late to untangle this mess after 10 years
<tlwoerner>
qschulz: your meta-rockchip patch ended up in my spam folder... grr
<qschulz>
tlwoerner: do you have any information on why?
<vvn>
JaMa: I see. That's what scares me with OE sometimes. It's kinda too flexible so you can actually get something done quick, but it is so hard to keep it in such a way that developers don't hack it too much and thus ensure good maintainance. Especially given the distributed nature of the project, it can quickly become an unmanageable mess.
<tlwoerner>
qschulz: do we know anyone who works at google's gmail team? everything from TI ends up in spam, anything from mediatek ends up there, heck even many of the bootlin emails end up in my spam folder
<tlwoerner>
jonathan cameron's patches and emails end up in my spam folder...
<qschulz>
tlwoerner: I do have a weird mail setup too so I wouldn't put all the blame on Google (for once :D)
<JaMa>
vvn: good compromise might be to start with just separate images and once it gets too restrictive adding new DISTRO which would inherit most of the "base" distro to support some "special" configurations all our DISTROs are depending on each other (with webOS OSE the common root base for all)
<tlwoerner>
but is the project attempting to track the CIP kernels in any way? (as was done with the LTSI kernels)
<qschulz>
tlwoerner: re: "i'm not opposed to meta-rockchip carrying a couple patches for some SoC that doesn't quite have 100% upstream support", our RK3399 module needs 12 patches on top of latest U-Boot which isn't in master branch yet
<tlwoerner>
sounds great!
<qschulz>
for linux-yocto, there are only a few (though I would need to check how the config is handled, we enforce a local defconfig)
<qschulz>
master branch of Yocto* I meant
<qschulz>
Hence why I wanted to wait a bit
<tlwoerner>
config fragments that are added per machine would be ideal
<tlwoerner>
i'm _this_ close to adding some sort of set of rockchip config fragments for configuring a kernel per-machine
Shazam has joined #yocto
<qschulz>
the PX30-based module will have some support in kernel 6.1, for U-Boot it's currently 8 patches on top of 2022.10
<qschulz>
tlwoerner: yeah, I'm really not a fan of config fragments :/
<tlwoerner>
qschulz: i'd be interested to know your thinking on them
<qschulz>
the one thing I don't like is having to maintain a config in different BSPs, e.g. for our Debian image, Buildroot and then Yocto
<tlwoerner>
(we could chat about it at the next happy hour if that's easier, rather than typing a bunch)
<qschulz>
shipping + syncing one every now and then is much easier
<vvn>
JaMa: totally true. Most of the difference are package selections and default configuration files. For the latter I can maybe use a postprocess function and/or have default files in .../images/${PN} for example.
<qschulz>
tlwoerner: conflicting fragments are an issue, because depending on the order in which they are applied, your fragment might be applied but not actually doing anything
<qschulz>
tlwoerner: also creating fragments is difficult, especially when you want to combine them
<vvn>
The override mechanism looks nice for that, but it doesn't justify different distros yet. And I could use multiconfig and OVERRIDES .= ":${BB_CURRENT_MC}" eventually if I do want to use overrides.
<qschulz>
I understand the appeal, and I would really like to like them but the fact that you cannot trust them is a no-go for me.
<zeddii>
you can't trust them ? really ?
* tlwoerner
runs
* zeddii
takes a minute and declines to go any further in the discussion :)
<vvn>
zeddii: I think that qschulz means that fragment-A could set CONFIG_FOO=n then fragment-B (applied after) sets CONFIG_FOO=y and then you end up with FOO being built.
<tlwoerner>
i like that you can pair kernel configs with patches
<vvn>
zeddii: whoops, ignore my message then :)
nemik has quit [Ping timeout: 264 seconds]
<qschulz>
vvn: that was my point yes. But I think we've discussed that already months ago with zeddii and nothing has changed since so not sure there's a point starting the discussion again :)
nemik has joined #yocto
<vvn>
qschulz: I actually thought about providing a full config for the kernel, and only relying on the (sub)machine or distro to override it when necessary, because I don't like to maintain multiple fragments too.
Guest13 has quit [Quit: Client closed]
<tlwoerner>
the automatic setting (or un-setting) of kconfig values based on other values isn't the "fault" of anything we're doing in yocto, that's the way the kconfig langauge works (or doesn't)
<qschulz>
tlwoerner: absolutely! Wasn't implying it was a Yocto issue :)
<tlwoerner>
at the end of configuration there is a sanity step (which you can specify the level of analysis) that goes through and lets you know if settings have changed with respect to (what it believes are) your intentions
<tlwoerner>
so there is a step to catch these changes, if you set the checking level high enough
<vvn>
I wanted to use allmodconfig for meta-ti's beaglebone but that silently didn't work somehow (no additional modules installed despite having kernel-modules in the image). I'm wondering if that's not because of such kconfig ordering.
<vvn>
ho, that'd be interesting to have such setting in a variable that a distro could set to enforce strong kernel config checking
<rburton>
JPEW: can you check that '[OE-core] [PATCH 2/3] create-spdx: Fix "licenseDeclared" shows weird value' does the right thing?
Vonter has quit [Ping timeout: 268 seconds]
<tlwoerner>
qschulz: vvm: in meta/classes-recipe/kernel-yocto.bbclass, towards the top of the file, there are various knobs to setup the *_AUDIT_* levels
<tlwoerner>
KCONF_AUDIT_LEVEL=1 will warn you if you set an option that doesn't make it to the final .config
<tlwoerner>
KMETA_AUDIT_WERROR will turn the warning into a build failure
<vvn>
too bad, meta-ti isn't using kernel-yocto
justache is now known as justHaunted
Vonter has joined #yocto
Guest14 has joined #yocto
manuel_ has quit [Ping timeout: 252 seconds]
<qschulz>
tlwoerner: thanks for the pointers, I'll check that
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
Shazam has quit [Quit: Client closed]
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
Guest14 has quit [Quit: Client closed]
Schiller has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
zpfvo has quit [Quit: Leaving.]
Shazam has joined #yocto
<JPEW>
rburton: ya, I'll look at it later today
rfuentess has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 252 seconds]
zhmylove has quit [Quit: Leaving]
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
Shazam has quit [Quit: Client closed]
prabhakarlad has quit [Ping timeout: 244 seconds]
ptsneves has quit [Read error: Connection reset by peer]
ptsneves has joined #yocto
goliath has quit [Quit: SIGSEGV]
manuel_ has joined #yocto
<vvn>
do you guys usually explicitly set MACHINE/DISTRO_FEATURES or do you usually rely on :append/remove?
<JaMa>
:remove is impossible to undo, so don't use it lightly, if you need many :remove ops, then setting whole value would be preferred
<vvn>
that's a very good point. I guess :remove should preferably used in end user conf such as local.conf or product specify distros.
<vvn>
JaMa: this means that :append and :remove are not interpreted in their order of definitions (i.e. the order of the lines) but :remove's will always be executed *after* the :append's statements by bitbake?
<JaMa>
yes and goog practise is to use some intermediate variable as :remove = "${THINGS_TO_REMOVE}", then you can undo it later by setting THINGS_TO_REMOVE = ""
geoff_ has joined #yocto
<JaMa>
correct, append unlike += is processed later and :remove last
<JaMa>
that's why += replaces ?= while :append doesn't
<vvn>
+= is actually something you cannot undo as well if used on variable flags, e.g. do_image_wic[depends] += "u-boot:do_deploy" in machine confs
<JaMa>
right with flags you would need python to undo as well
<vvn>
-= would solve this, but well
bfcoqg has joined #yocto
kevinrowland has joined #yocto
prabhakarlad has joined #yocto
manuel_ has quit [Ping timeout: 246 seconds]
Minvera has joined #yocto
ptsneves has quit [Remote host closed the connection]
ptsneves has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
ptsneves has quit [Ping timeout: 252 seconds]
Haxxa has joined #yocto
florian_kc has joined #yocto
<vvn>
JaMa: actually the fact that DISTRO_FEATURES is mixed in most PACKAGECONFIGs makes it unrealistic to maintain a single distro for multiple embedded products (you end up compiling support for unnecessary features and pull in dependencies you don't even need).
mvlad has quit [Remote host closed the connection]
<JaMa>
vvn: well as I said it depends how different these configurations are
<JaMa>
our targets were from watches through phones to TVs and car infotainment and DISTRO_FEATURES could be used the same for all, other differences were worse
<JaMa>
or evil BSPs where most a DISTRO was dealing with various issues and limitations of that
florian_kc has quit [Ping timeout: 272 seconds]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
Minvera has quit [Remote host closed the connection]
<vvn>
JaMa: but let's say watch-foo has no sound support, if you keep e.g. alsa and pulseaudio in DISTRO_FEATURES, packages (e.g. qt*) will DEPENDS on alsa-lib even though MACHINE_FEATURES doesn't have alsa. How do you deal with that?
<JaMa>
we would enable it for all, because our target devices have very different form factor, but all of them support sound, wifi, media, ...
<vvn>
well sound might not be the best example in your case, but you see what I mean
<JaMa>
I know what you mean, but still our targets are similar, building image for something like pinecil with the same DISTRO as TV would be different story
<JaMa>
and we do have multiple hierarchical DISTROs
<vvn>
and if a distro uses :machine overrides, then you have to be careful and likely use a different TMPDIR, which kinda comes back to defining different distros in the end :/
<vvn>
JaMa: or actually, is it safe to use the same TMPDIR with something like DISTRO_FEATURES:remove:machine-foo = "feature-foo"?
<JaMa>
DISTRO_FEATURES are for DISTRO to define, they shouldn't be MACHINE specific
<JaMa>
using the same TMPDIR is fine as long as you PACKAGE_ARCHs are set correctly, oe-core/scripts/sstate-diff-machines.sh can help to check for possible issues
<JaMa>
if there are issues like this, then bitbake will still correctly rebuild what changed (based on sstate signatures), but if you're using package feed, then you won't know which "version" you'll fetch from deploy/ipk/arch/foo_bar.ipk
<vvn>
this is what I want to avoid indeed
<JaMa>
if you're just building images and never use package feed, but it's still an issue, which in the end lead to the MACHINE_ARCH being default PACKAGE_ARCH in webOS I mentioned before
<JaMa>
s/package feed, but/package feed, then it's not so bad, but/g
<vvn>
I see the reasoning behind MACHINE_ARCH fix, this makes all packages being in deploy/ipk/<machine>/ instead of <arch> or all for example
<vvn>
thus "easily" avoiding clashes between distros
<JaMa>
between machines
<vvn>
oops yes
<vvn>
at the cost of duplicating a lot of packages and compiling exactly the same thing multiple times
<JaMa>
but that's terrible work around for bad architecture of some components, not realy a fix
<JaMa>
that's why it was supposed to be temporary in 2013 :)
<vvn>
ha ha
<vvn>
it's also tempting to write submachine configs in order to isolate such tweaks, but again it's stupid because you won't share the kernel or other identical MACHINE_ARCH packages
<JaMa>
once you add chromium into the image, the build time of kernel becames irrelevant :)
<vvn>
I did and that's why I'm asking so much about the ideal setup for multiple products. I really wish to reuse qtwebengine, kernels and stuffs like that if possible
<vvn>
even though meta-ti's linux-ti-staging recompiles almost every times...
<vvn>
JaMa: so it's ok in this case to have different PACKAGECONFIG per machine for the same distro?
<JaMa>
no, that's why had to fix it, so that pp has panfrost enabled as well even when it doesn't use in runtime
<vvn>
I see
<vvn>
so that sstate can be reused
<vvn>
thinking that way (doing your best to stick to a single distro), I'm wondering what is the reasoning for removing a distro feature vs keeping them all
<vvn>
(like "ext2", "wiki", or "xattr", ...)
<vvn>
s/wiki/wifi/
<JaMa>
it's union of all the features needed by machines/images it needs to support
<JaMa>
if you're supporting only MACHINEs with very small flash and limited set of possible features (e.g. all headless) then you can remove a lot of them
bfcoqg has quit [Ping timeout: 246 seconds]
<JaMa>
if your target are "embedded" devices which are bigger than average desktop and need to support all latest fancy features, then you'll probably just add more DISTRO_FEATUREs for ML, NFT, ..
<vvn>
JaMa: then if you support both powerful and very limited hardware, then you'll likely need two distros
<JaMa>
yes, it will be easier in such case
<vvn>
I unfortunately have to support this case ha ha
<JaMa>
that's what I was asking at first :)
florian_kc has joined #yocto
<JaMa>
they can still share a lot of .inc files for common parts
<JaMa>
anyway, my builds are now triggered, time for sleep
geoff_ has quit [Remote host closed the connection]
goliath has joined #yocto
<kiwi_29_[m]>
Hello, I have a custom distro make from core-image-minimal and I am NOT using systemd as init system.. For including crontab, I am compiling the cronie recipe, which compiles without issues. However, when I upload the recipe on my package repo and then use apt-get install cronie, then I get these errors The following... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/8c701eef0ae24a7984f17a3ee739635b629068cd>)
<kiwi_29_[m]>
s/make/made/, s/cronie_1/cronie\_1/
<kiwi_29_[m]>
* Hello, I have a custom distro made from core-image-minimal and I am NOT using systemd as init system.. For including crontab, I am compiling the cronie recipe, which compiles without issues. However, when I upload the recipe on my package repo and then use apt-get install cronie, then I get these errors... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/7100c67b58700346e93eb87e9531a293555eca37>)
kscherer has quit [Quit: Konversation terminated!]
<kiwi_29_[m]>
* Hello, I have a custom distro made from core-image-minimal and I am NOT using systemd as init system.. For including crontab, I am compiling the **cronie** recipe, which compiles without issues. However, when I upload the recipe on my package repo and then use apt-get install cronie, then I get these errors... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/9187500b321a8b5c24d7a1c08b47067cc1205c00>)