<ngoub>
Everytime I set INIT_MANAGER to systemd, I'm getting: Please ensure that your setting of VIRTUAL-RUNTIME_init_manager (systemd) matches the entries enabled in DISTRO_FEATURES
<rburton>
can you paste what you put in local.conf or your distro
kayterina has quit [Remote host closed the connection]
<ngoub>
I try to add systemd in all DISTRO_FEATURE i can (DISTRO_FEATURES_DEFAULT_append = " systemd" POKY_DEFAULT_DISTRO_FEATURES_append = " systemd") without success
<ngoub>
I can see systemd well set
<ngoub>
it is an issue with the sstate ?
roussinm has joined #yocto
<RP>
it is definitely not sstate
<RP>
much as everyone loves to blame it for everything it isn't at fault
Guest8737 has joined #yocto
<RP>
ngoub: try setting INIT_MANAGER with = instead of ?=
<RP>
ngoub: I suspect you're not overriding the poky setting of it
<Guest8737>
yocto sdk does not install gcc-sanitizers with symlinks. why is that? i can see special target gcc-symlinks but not for the sanitizers
<RP>
Guest8737: probably just needs tweaking, patch welcome
<Guest8737>
RP Looks like I missed that the symlinks requires dev package. Will try to include gcc-sanitizers-dev.
<Tokamak>
effectively, i'm looking at modifying a systemd service file (add a dependency) provided by meta/openssh, but since sshdgenkeys.service is provided as a 'oe-local-files', the devtool patch workflow doesn't seems to support this. What is the yocto way of patching local files provided by other layers (from your own support layer)
<Guest8737>
Do I need to state gcc-sanitizers dev explicitly? Wouldn't it be good if there was a gcc-sanitizers-dev? Now I need to write each dev package one by one.
<Tokamak>
yeaa, thought about that. was hoping there was a yocto way to maintain local files vs relying on systemd (and exposing that on the target image)
<Tokamak>
but that is a way to get things to work baring nothing else
<smurray>
using a the drop-in is cleaner IMO
<smurray>
s/the //
<ngoub>
RP: same with INIT_MANAGER = "systemd"
<Tokamak>
sure, but down the road if i have another local file issue that isn't systemd, there is no clean solution apart from complete file override?
<ezzuldin[m]>
Hello I want to build a Debian rootfs tarball how can I do that with yocto?
<ezzuldin[m]>
Is there any tutorial specific to Debian online?
<smurray>
Tokamak: not that I can think of, but someone else might have an idea
<JPEW>
ezzuldin[m]: You mean building an image with .deb packages, or building something compatible with the "Debian" distro?
<ezzuldin[m]>
Sorry I’m just new to this
<Tokamak>
ezzuldin (not yocto related, but if you are not already, look up debootstrap)
roussinm has joined #yocto
<Tokamak>
thanks smurray. wanted to make sure i wasn't completely overlooking something.
<ezzuldin[m]>
Tokamak: I tried using debootstrap but the tarball isn’t compatible with the app that I want to boot from
<rburton>
ezzuldin[m]: you might want to explain what you're trying to do
<rburton>
yocto doesn't build debian, it builds yocto
<ezzuldin[m]>
This is why I thought yocto might help me sort of customize it more
<rburton>
"it"?
<Tokamak>
deboostrap is how debian builds their iso's / installers. but thats definitely not related at all to yocto. you ahve to provide more details about your situation. you also need to build your app using a cross compiler and sysroot for your target
<ezzuldin[m]>
rburton: The userspace that debootstrap creates
<Tokamak>
smurray. is there a way to patch at the 'install' phase?
<rburton>
you really want to say what you actually want to do
<smurray>
Tokamak: that'd be something you'd need to add in a do_install_append AFAIK
<ezzuldin[m]>
Tokamak: Okay there’s this iOS app that that run Linux distros like Alpine, and it gives the option to import your own rootfs tarball to boot from
<smurray>
Tokamak: I've done modifications with e.g. sed in do_install_append's, never straight up applied a patch
<rburton>
ezzuldin[m]: utm?
<ezzuldin[m]>
I’m trying to get a very minimal rootfs for Debian
<Tokamak>
thank smurray
<ezzuldin[m]>
rburton: iSH is the name
<smurray>
ezzuldin[m]: then Yocto can't help you
<rburton>
debootstrap makes a minimal debian
<smurray>
ezzuldin[m]: look at something like ISAR or debOS, maybe
<rburton>
yeah if you want something almost but not quite debian then ISAR is close
<ezzuldin[m]>
Okay I’ll try that, thanks for the help :)
<qschulz>
i'd also assume that you need to cross-compile with debootstrap too, make sure that is the case
<rburton>
no, iSH is x86 emulation
<rburton>
which is why UTM can be better/faster, as it will run native code
<ezzuldin[m]>
rburton: Yep exactly
<qschulz>
👍
<ezzuldin[m]>
rburton: UTM is slow without a jailbreak
<kanavin>
the problem with those sorta-debian mini-yoctos is that there's a whole zoo of them
<kanavin>
in typical debian style :)
<kanavin>
there's ELBE too, and something else
<ezzuldin[m]>
I tried ELBE too and got the same result as debootstrap
<rburton>
most likely as debootstrap actually makes a pretty minimal rootfs and anything removed would break a dependency
<ezzuldin[m]>
No actually when chroot into the mounted image that debootstrap created everything works well
<ezzuldin[m]>
The problem is when I import the image to iSH
<ezzuldin[m]>
The app accepts the image but as soon as I try to boot, instant crash
<rburton>
i suggest you try either the debian or ish support channels then?
<ezzuldin[m]>
yep I will, thank you
<override>
is there a known/recommended way of going about generating checksum files for atifacts image recipes create?
<rburton>
calling out to sha256sum works quite wel
<override>
thanks
<rburton>
if its an image then you can get the image class to do it for you
<rburton>
IMAGE_FSTYPES = "wic wic.md5sum" will generate the wic image, and checksum it
<override>
nice, so i dont have to do any installs in the recipe for the checksum file, with IMAGE_FSTYPES="wic wic.md5sum"
camus has quit [Quit: camus]
argonautx has quit [Ping timeout: 252 seconds]
rfuentess has quit [Remote host closed the connection]
camus has joined #yocto
florian has quit [Quit: Ex-Chat]
Vonter has joined #yocto
Vonter has quit [Client Quit]
Vonter has joined #yocto
TMoore has joined #yocto
Vonter has quit [Quit: WeeChat 3.2]
<TMoore>
I am getting the error: `WARNING: mc:zyboz7:commdevmgr-1.0+gitAUTOINC+23c40362de-r1 do_fetch: Submodule included by gitsm://gitlab.miv.mentorg.com/communication/CommMgrLib.git;protocol=http refers to relative ssh reference git@gitlab.miv.mentorg.com:misc-tools/nonstd-lite.git. References may fail if not absolute.` yet my submodule definition is
<TMoore>
`git@gitlab.miv.mentorg.com:misc-tools/serial.git`. Can some please tell me how this is considered "relative"? I seem to be missing something.
<TMoore>
Sorry, I copied the wrong submodule definition, but it is essentially the same. The one matching the error is: `git@gitlab.miv.mentorg.com:misc-tools/nonstd-lite.git`
dev1990 has quit [Quit: Konversation terminated!]
Vonter has joined #yocto
<TMoore>
Is it the gitlab groupName (added ":") that is confusing the code?
<Tokamak>
how do i see what packages a specific distro_feature is pulling in?
<Tokamak>
specifically, doing 'bitbake -g 'image-name' produces a massive dot file, but grepping that dot file doesn't actually list wpa-supplicant. in this image, i know wpa-supplicant is installed. this image is apart of a yocto distro that adds wifi to DISTRO_FEATURES. primarily confused around how the heck to properly track package dependencies.
zyga-mbp has quit [Ping timeout: 260 seconds]
<Tokamak>
appologies, scratch the last comment about 'bitbake -g image' not listing wpa-supplicant. human error. I still would love to understand the best way to track dependencies as that dot file is too large to do anything with but grep. what does everyone here do?
florian has joined #yocto
zyga-mbp has joined #yocto
leon-anavi has quit [Quit: Leaving]
<JaMa>
isn't this a bit weird? why are there 2 processes running the same shell task?
<JaMa>
martin 2724830 0.0 0.0 2880 968 ? S 19:27 0:00 /bin/sh /OE/build/luneos-honister/webos-ports/tmp-glibc/work/aarch64-halium-webos-linux/busybox-static/1.34.0-r0/temp/run.do_configure.2724595
<JaMa>
martin 2728116 0.0 0.0 2880 176 ? S 19:27 0:00 /bin/sh /OE/build/luneos-honister/webos-ports/tmp-glibc/work/aarch64-halium-webos-linux/busybox-static/1.34.0-r0/temp/run.do_configure.2724595
vd has quit [Quit: Client closed]
vd has joined #yocto
sakoman has joined #yocto
CosmicPenguin has quit [Ping timeout: 240 seconds]
YogeshSiraswar_ has quit [Ping timeout: 250 seconds]
armpit has quit [Read error: Connection reset by peer]
rsalveti has quit [Ping timeout: 252 seconds]
NishanthMenon_ has quit [Read error: Connection reset by peer]
YogeshSiraswar_ has joined #yocto
armpit has joined #yocto
rsalveti has joined #yocto
CosmicPenguin has joined #yocto
NishanthMenon_ has joined #yocto
<RP>
JaMa: one forked off the other and didn't change the process name?
ngoub has quit [Remote host closed the connection]
tgamblin has quit [Quit: Leaving]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wwilly has quit [Ping timeout: 260 seconds]
gsalazar_ has quit [Ping timeout: 260 seconds]
eduardas has quit [Quit: Konversation terminated!]
wwilly has joined #yocto
florian has quit [Ping timeout: 260 seconds]
ngoub has joined #yocto
ngoub has left #yocto [#yocto]
ngoub has joined #yocto
bizulk has quit [Quit: Client closed]
ngoub has quit [Remote host closed the connection]
ngoub has joined #yocto
ngoub has quit [Remote host closed the connection]
ngoub has joined #yocto
ngoub has quit [Remote host closed the connection]
ngoub has joined #yocto
ngoub has quit [Remote host closed the connection]
otavio has quit [Remote host closed the connection]
Vonter has quit [Ping timeout: 260 seconds]
gourve_l has quit [Ping timeout: 240 seconds]
otavio has joined #yocto
gourve_l has joined #yocto
zyga-mbp has joined #yocto
zyga-mbp has quit [Client Quit]
zyga-mbp has joined #yocto
zyga-mbp has quit [Client Quit]
TMoore has quit [Quit: Client closed]
jmiehe has joined #yocto
gioyik has joined #yocto
jwillikers has quit [Remote host closed the connection]
<RP>
JPEW: we just managed our first build from sstate off the AB using read-only hashequiv :)
<RP>
JPEW: few "minor" glitches we need to fix and some speed issues but it basically works
paulg has quit [Ping timeout: 260 seconds]
<JPEW>
Cool!
<RP>
JPEW: is there a way to tell the code not to attempt to report hashes as the server is read-only?
angolini has quit [Quit: Connection closed for inactivity]
gioyik_ has joined #yocto
* RP
-> Zzzz
gioyik has quit [Ping timeout: 276 seconds]
<JPEW>
RP: I think the recommendation would be to run a local server with the AB hashequiv server as an upstream, but we can discuss it later :)
<fray>
that was always my assumption. local server for the write, remote server r/o