jwillikers has quit [Remote host closed the connection]
whuang has joined #yocto
<whuang>
is there a variable I can use to refer to python version? for example python3.8, python3.9
<whuang>
there's a recipe that hard codes the python version (export NUMPY_INCLUDE_PATH = "${STAGING_DIR_TARGET}/usr/lib/python3.9/site-packages/numpy/core/include")
<mckoan>
LetoThe2nd: summer holidays are approaching \o/
<LetoThe2nd>
mckoan: somewhat, yes.
Schlumpf has joined #yocto
leon-anavi has quit [Remote host closed the connection]
zpfvo has joined #yocto
tnovotny has joined #yocto
hmw[m] has joined #yocto
leon-anavi has joined #yocto
manuel1985 has joined #yocto
zyga has joined #yocto
goliath has quit [Quit: SIGSEGV]
gioyik has quit [Quit: WeeChat 3.1]
florian has joined #yocto
<qschulz>
morning
<qschulz>
JPEW: I'm not sure your PR works for local builds?
<qschulz>
I think at best your local build will be prefixed with the registry name (which, if it works, is confusing)
<qschulz>
On podman, I think local images are available with the localhost "registry", so if the same can be said for docker, we can just set registry to localhost when doing a local build?
__ad has joined #yocto
__ad has quit [Changing host]
zyga-mbp has joined #yocto
goliath has joined #yocto
Schlumpf has quit [Remote host closed the connection]
Schlumpf has joined #yocto
tnovotny_ has joined #yocto
tnovotny has quit [Read error: Connection reset by peer]
leon-anavi has quit [Quit: Leaving]
leon-anavi has joined #yocto
xmn has quit [Ping timeout: 252 seconds]
vd has quit [Quit: Ping timeout (120 seconds)]
fleg has joined #yocto
<fleg>
hi, I am making a recipe for a CMake-based project, and for some reason while /usr/lib/libmylibrary.so.1.2.3 is packaged correctly, symlink to that file in /usr/lib/libmylibrary.so is split into the -dev package. Is it supposed to work this way, or am I doing something wrong? Thanks in advance for help!
<qschulz>
fleg: that
<qschulz>
's expected
<fleg>
oh, thanks. Is there anything I can do to put those symlinks into the main package, or should I just install the -dev as well on the resulting image?
<qschulz>
fleg: why do you want the .so in your rootfs?
eFfeM has joined #yocto
<fleg>
the application that I'm packaging depends on the .so
<qschulz>
make it depend on the versioned lib if possible (only exception would be if you receive precompiled binaries/libraries)
<fleg>
I will try to do that then, thanks!
<qschulz>
that's the cleanest way to do it
<qschulz>
otherwise, you need to remove the *.so from FILES_${PN}-dev and add it to FILES_${PN} (or another package) IIRC, setting FILES_SOLIBSDEV to "" and adding the two default paths to FILES_${PN} should be enough?
<eFfeM>
Hi, can I enforce that in a specific conf users cannot build a specific image recipe?
<qschulz>
or add the -dev but I don't know what exactly the consequences are
<qschulz>
eFfeM: you could always have a python anonymous function in the image recipe that looks for the current user and fail the parsing
<qschulz>
though, if your user have write access to said image recipe, they can remove it
<eFfeM>
What I want to achieve is that in a conf that allows GPLv3 code it is not possible to accidently buiild a release image (I have a different conf for release images)
<eFfeM>
qschulz: we have a different conf to build release images, but I want to make very sure that things do not get wrong. GPLv3 is to some extend a p.i.t.a.
<eFfeM>
I would love to go without it, but for dev purposes we need gdb
camus has quit [Ping timeout: 252 seconds]
camus1 has joined #yocto
camus1 is now known as camus
<qschulz>
eFfeM: check the content of INCOMPATIBLE_LICENSE from the image recipe?
<fleg>
qschulz, I'll try to go the "depend on the versioned .so instead" route first, if I get stuck there then I'll try the other suggestions. Fortunately I build both the libraries and the application, so it should not be an issue
<qschulz>
fleg: :+1:
<eFfeM>
qschulz: hmm yes that is an idea
<eFfeM>
I'll explore after lunch
<qschulz>
eFfeM: but it's not bulletproof, because you can unset the INCOMPATIBLE_LICENSE per recipe in your conf file or have a package in the whitelist
<qschulz>
best option would be to check into the final manifest with the license of all software included in your image and check if there is a GPLv3 in there
<qschulz>
you might need to enable buildhistory for that, I don't remember
<qschulz>
maybe there's even something built in Yocto/bitbake but I'm not aware of it
florian_kc has joined #yocto
vmeson has quit [Ping timeout: 268 seconds]
jwillikers has joined #yocto
vmeson has joined #yocto
linums has joined #yocto
camus1 has joined #yocto
<linums>
hi
<linums>
I see that every branch brings it's own kernel version + the lts, like hardknott comes with 5.10 and 5.4
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
<linums>
but the libc headers are only present with the version 5.10 on hardknott
<linums>
is it right, or should I not use hardknott for 5.4 kernel?
<qschulz>
linums: in most cases, you can use newer kernel release headers with an older kernel release
<LetoThe2nd>
linums: bruce might probably shed more light on this, but once there is no version selection available you will get the latest of a package, hence run 5.4 kernel and use the 5.10 libc headers.
<linums>
thanks, so it is intentional, so I'll select the kernel version, and nothing more
<LetoThe2nd>
linums: thats what i woould guess.
BCMM has joined #yocto
<eFfeM>
qschulz: yeah I know one can override INCOMPATIBLE_LICENSE, I also considered whitelisting gdb and then exclude it from the release image, but the pain is that gdb requires a newer readine than the one in meta-gplv2 and I cannot select a different version of readline in an image
<LetoThe2nd>
eFfeM: i personally would probably try BBMASK in the distro combined with an automated test on the resulting artifacts.
<eFfeM>
LetoThe2nd: I'm not sure if that would help, I think INCOMPATIBLE_LICENSE is a better mechanism
<LetoThe2nd>
eFfeM: sure, it always depends.
tgamblin has joined #yocto
tgamblin has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
whuang0389 has joined #yocto
override has joined #yocto
<override>
t
<override>
exit
<override>
so the byte for byte image type would be ext3?
<whuang0389>
Hi I'm trying to create a recipe that depends on llvm
<whuang0389>
Im guessing it needs to be llvm-lite but it's looking for a llvm-config file
<JPEW>
override: Ya, any of those file systemd formats (ext3, ext4, etc.) will produce an image you could directly dd into a partition
<whuang0389>
so I have a DEPENDS += "llvm-native", but the llvm-native doesn't get compiled... am I missing something?
<whuang0389>
or should DEPENDS be enough?
<JPEW>
override: If you need a whole disk images (i.e. all the partitions w/ partition table, you need to use wic)
<override>
whuang0389: you could check if its a run time or a build time dependency (RDEPENDS vs DEPENDS). and use oe-pkgdata-util to check youve got the right packages in your build..
<whuang0389>
maybe my understanding of run tim dependency is wrong.. but I believe that it means they are packages that are required to be pulled in when the source is runned on target?
<whuang0389>
if that's the case, I think it'sa build time dependency
<override>
whuang0389: yeah then just make sure the recipe the package added as a depends and just maybe add the llvm-config depency to your recipe too. use the oe-pkagdata-util to find the name for whatever dependency you recipe needs...
<override>
thats just how I was told to do things.. not a yocto know it all by any standard
<whuang0389>
no worries! thanks for some tips!
<override>
prolly a dumb question do distro/machine conf includes from different layers require absolute paths, or is YOCTO smart about them?
<qschulz>
override: relative to (any) layer root dir
<qschulz>
well, relative to the root dir of the layer with the distro/machine conf file
sakoman has joined #yocto
<override>
ok, think thats what I got
<override>
the manual reads The IMAGE_FSTYPES variable's default value now specifies ext4 instead of ext3. I dont see any of these being made for my builds
<override>
are they not made when I have something like IMAGE_FSTYPES += "teziimg" in my machine config?
<override>
im just appending to the IMAGE_FSTYPES varaible, I was expecting this would add fstypes on top of the defaults.. ?
<JPEW>
override: The defaults are probably "weak" so the += might be overriding them
<override>
and since ext4 is supposedly the default would it require something IMAGE_CLASSES_append " image_type_tezi ext5" in my case?
<override>
JPEW: when a varaible is "weak" does _append also overrides it, or just +=
<JPEW>
override: I'm not sure if ext4 is the default
<override>
ive always been curious why we have _append and +=
<JPEW>
override: _append is deferred until the end of parsing, += is immediate
<Xagen>
i can see in toaster that json-c, libevent, libsodium, python, and python3 all built
<Xagen>
the only thing i could think of is that i need to have toaster run the populate_sdk itself, and that it wouldn't work from the cli, but i couldn't find any place to explicitly run populate_sdk
vd has joined #yocto
<vd>
hi all -- after systemd switches root from the initrd, I get a bench of FAILED service, for hardware RNG, network manager, user login management, etc. My guess is an issue with /var. Anyone with a clue?
<whuang0389>
ok so, it turns out I do have llvm-config executable pulled in
<whuang0389>
I think the setup.py file executes llvm-config to determine the llvm version
<whuang0389>
but the setup fails with permission denied...
goliath has quit [Quit: SIGSEGV]
<whuang0389>
is there something I need to do allow the setup file to execute the llvm-config? I can execute it manually myself
eFfeM has quit [Remote host closed the connection]
<rburton>
so, tell your kernel to use ${CC} not gcc
<rburton>
obviously, the standard kernel recipe/classes do this already
<yates>
rburton: in my arch's kernel Makefile, there is this line: libs-y += arch/csky/lib/ $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)
<rburton>
right, so ensure CC is passed
<rburton>
or use the standard kernel classes that do this for you
<rburton>
using kernel.bbclass doesn't mean using linux-yocto
zpfvo has quit [Quit: Leaving.]
Guest44 has joined #yocto
<yates>
i'm confused, but let me dig some more before I ask more stupid questions.
<yates>
thank you, rburton
<yates>
i guess basically i am wondering why yocto isn't already defining CC with the sysroot when this top-level Makefile is run
<rburton>
it is
<rburton>
export CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
* rburton
goes to collapse somewhere
<yates>
then why is "$(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)" returning just "libgcc.a" and not "<some-path-in-sysroot>/libgcc.a"?
<rburton>
because gcc doesn't always give you an absolute path if the result is in the search path
<Guest44>
I have problem generating eSDK for my image.my image usages meta-qt layer which has dependency on python3 where as my application are dependent on python2.i am using python2-mako in my applications and same mako is used by meta-qt as well but they use python3.-mako.
<rburton>
yates: this works for the standard kernels, therefore you're doing something odd or wrong. i suggest you don't write your own kernel recipe but use linux-yocto with a custom config if needed. if you *really* need to write your own recipe then at least inherit kernel.bbclass
<Guest44>
so while generation it tries to install mako-render which is provided by both python packages.My problem is hot disable python3-mako while generation eSDK.
<yates>
rburton: i switched to using my own instead of linux-yocto because there were several complications due to this being for a new architecture which is not fully supported in yocto (yet).
<rburton>
but are you using mainline kernel?
<yates>
yes
<rburton>
so use linux-yocto as that is mainline
<yates>
5.12
<yates>
using linux-yocto pulls in other machinations unique to linux-yocto which do not work with the architecture i am using. i've already spent weeks tracking down those and decided it was better to based our system on mainline non-linux-yocto to remove dependencies on those machinations
<yates>
i resolved a couple, but it was very tedious.
<yates>
rburton: CC is not constructed with a --sysroot option when the top-level arch/<arch>/Makefile runs. i just instrumented it: CC = csky-poky-linux-gcc
<yates>
neither is there a sysroot in KBUILD_CFLAGS
<yates>
not at that time
<yates>
i believe the only time gcc emits just the "libgcc.a" filename is when it can't really find it.
<yates>
i know that a lower level submake has it defined, but that is after the libs-y has been improperly defined
<yates>
so i guess i have to dig and find out what happens between this top-level Makefile and the myriad levels the kernel build system evokes..
<yates>
fun!
* yates
takes a dirt nap...
mckoan is now known as mckoan|away
goliath has joined #yocto
<Xagen>
rburton: did you get a chance to look at my pastebin?
camus1 has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
Guest63 has joined #yocto
Xagen has quit [Quit: Xagen]
Guest63 is now known as Xagen
Guest44 has quit [Quit: Client closed]
vd has quit [Quit: Client closed]
fleg has quit [Remote host closed the connection]
fleg has joined #yocto
Tokamak has quit [Ping timeout: 255 seconds]
<override>
does anyone know what recipe is responsible for making the .json file we see under the deploy folder. its got the blockdevs (partitions and some other stuff defined in it. Not sure if this is some yocto standard way of doing things, or something the vendor pulled off. the .json files looks like this - https://pastebin.ubuntu.com/p/gtYBRqCkf7/
florian_kc has joined #yocto
<yates>
override: perhaps it is an output from "wic"?
<override>
oh, was really hoping I could just add a fs partition to that json file or something
<override>
guess I gotta look up wic
<override>
yates: could you link me to some wic doc or something? Ill try to figure if this is wic generated
<override>
does wic generate any json?
LetoThe2nd has quit [Quit: Connection closed for inactivity]
whuang0389 has quit [Quit: Client closed]
BCMM has quit [Ping timeout: 256 seconds]
amitk_ has joined #yocto
<override>
yates: so I see a image_type.bbclass in a layer, does wic require something along those lines?
<override>
Im just having a hard time finding something to read for wic
<override>
the manual starts talking about partion commands wic supports.. I want an overview of what the heck is it all about even
amitk has quit [Ping timeout: 255 seconds]
xmn has joined #yocto
Guest8 has quit [Quit: Client closed]
<JPEW>
override: Ya, the "Getting started" documentation for wic needs some help
<JPEW>
override: You need to add a ".wic" file system to IMAGE_TYPES as a suffix of the rootfs type you want to embed, e.g. `IMAGE_TYPES += "ext4.wic"`
<JPEW>
override: Ugh, sorry, that's wrong. Just add `wic` to `IMAGE_FSTYPES`
<override>
JPEW: cool ok think my vendor is using something else, but while we are talking wics
<override>
I get the wic to my IMAGE_FSTYPES
<override>
im guessing that is in my maching.conf?
<JPEW>
override: Usually
<override>
then what happens? how do the partions get defined?
<JPEW>
override: The code will search for a .wks file; default file to look for is `"${IMAGE_BASENAME}.${MACHINE}.wks"`
<JPEW>
You can change it by setting the `WKS_FILE` variable
marka has quit [Ping timeout: 255 seconds]
<JPEW>
override: It will search in the `wic` directory of every layer
<override>
ok nice, those were the extension names I was looking for
<override>
Im trying to make sure if my vendor is using wic or something not so standarized..
Tokamak has joined #yocto
<JPEW>
wic is pretty flexible; if they boot from eMMC you can write a wic file to make the image
<override>
eMMC is sd cards and all, right
<override>
Im the worst with these terms
<JPEW>
Can you share the SoC? A lot already have examples you can start with
<override>
im using some som from toradex, let me get u the exact name and all one sec
Guest8 has joined #yocto
<override>
toradex verdin imx8m mini
<override>
they have some easy installer stuff that is throwing me off / has zero docs when it comes to setting up partitions
<JPEW>
Oh, ya. That one should have pretty good support
<Guest8>
Anyone have experience using dmalloc with c++ apps on yocto targets?
<override>
yeah, not sure if I should be too concerned about it right now..
<JPEW>
override: Basically, u-boot is too big and SoC's can't access RAM immediately, so you need a small SPL to initialize RAM, copy u-boot into it and jump to it
<override>
oh, ok. thanks JPEW:
<Tartarus>
Dumb question, but wasn't there some way to make local source archives that included the githash in them?
<JPEW>
Tartarus: BB_GENERATE_MIRROR_TARBALL
<Tartarus>
ie for use cases like where you have a single local source mirror that you use when you start building $whatever and $whichever source branch that might be, get the right glibc git hash archive
<Tartarus>
JPEW: that only gives me git2_sourceware.org.git.glibc.git.tar.gz for example
<JPEW>
Ah, for a specific hash and/or branch?
<Tartarus>
Yeah
<Tartarus>
I have a site.conf I start with for everything and it has a own-mirror / SOURCE_MIRROR_URL in it
<Tartarus>
It's great for everything that's not git, but since I might be on thud or zeus or dunfell or something modern, all of the git stuff isn't a cache hit
<JPEW>
Ya, that's not supported.... we run into the same thing all the time :/
<Tartarus>
Ugh, I thought it used to be
<Tartarus>
Guess it's time for plan B and directories for just the git ones
<Tartarus>
I should probably double check the logic for getting uninative stuff too while I'm at it
<Tartarus>
I think that's caught normally with own-mirrors
<override>
JPEW: you know what WKS_FILE_DEPENDS_append is all about? I think toradex is using the wic image type but its not very out very obvious becuase they define their own image type, which extends wic
<JPEW>
override: If you need to include other items in the disk image (e.g. u-boot or other bootloader), you need to tell bitbake to build them before attempting to run wic
<JPEW>
`WKS_FILE_DEPENDS` does that.... basically "Wic creation depends on these things"
prabhakarlad has quit [Quit: Client closed]
davidinux has quit [Ping timeout: 268 seconds]
<JPEW>
override: Sounds like they are producing a wic file then wrapping an installer around it?
davidinux has joined #yocto
<override>
so this toradex som im working with has a image_type_tezi.bbclass with WKS_FILE_DEPENDS in it. which makes me think toradex is trying to extend the wic image type ... but I cant find a .wks file .. like I see some random ones
<override>
JPEW: im just trying to add another partition to the emmc or what ever the nand memory on the board is called, so I can just dd ext4 images to it, tell uboot to boot from that partion, and call this entire thing a system update
<JPEW>
override: Ya, pretty standard A/B partition stuff :)
<override>
JPEW: yeah it wouldbe been simpler if I didnt have toradex in my way right now
<JPEW>
Sounds like they did their own thing instead.... to bad. But the IMX8M has pretty good support, I'm fairly certain you can get it working
<override>
yeah think theyre extending the basic wic stuff tho
<override>
so if I can file the correct wks file i can just add the swap partion to it
<override>
right now I think it just has the one uboot and one kernel partition
<Tartarus>
JPEW: OK, so locally I'm fixing this by dropping own-mirrors, and having PREMIRRORS_prepend itself in site.conf with stuff like: git://.*/.* ${SOURCE_MIRROR_URL}/${LAYERSERIES_COMPAT_core} \n which evaluates correctly at least. But please tell me if that's still a horrid idea or something :)
<JPEW>
In fact, I'm positive you can get it to work, I've got an IMX8M on my desk that I had booting with wic a few months ago :)
marka has joined #yocto
<override>
nice think I'll ditch whatever image class toradex has setup and just add simple wic to my distro
<Tartarus>
override: Modifying the tezi images is not easy, sadly.
<override>
Tartarus: you know about tezi?
<Tartarus>
Which is a problem if you want to use tezi to in turn flash a production run of toradex stuff
<override>
Im just trying to see if I just went all wic right now. I do a clean wipe of my emmc, then just write a fresh uboot, and kernel partition and swap partition just sits empty for now
<override>
I dont need no tezi then do i?
<JPEW>
override: Hard to say... it really depends on what else they have done
<Tartarus>
It also depends on what you're trying to do, in the end
<override>
if i went wic I'll still be doing everything toradex has done, just not making a tezi image? wic image instead
<override>
where would i run into issues that way?
<Tartarus>
Well, if you're on a toradex SOM, there's important questions
<override>
what might those be
<Tartarus>
Like, are you doing a one-off personal project? Or is this a company thing that'll have 1k units?
<override>
there can be all the units we want for it
<Tartarus>
Are you going to flash them, or is toradex?
<override>
no we are
<override>
like our cm people would
<Tartarus>
OK
<override>
they can just well I can get to that later
<Tartarus>
And you're just now figuring out how they'll do the flashing?
<override>
like ive use these dd scripts in the past ..
<Tartarus>
There's many ways to install, yes, which is why toradex created yet another one, their 'easy installer'.
<override>
yeah im trying to ditch that toradex easy installer stuff myself
<Tartarus>
OK, then yeah, look at the wks that JPEW mentioned
<override>
they use some library that doesnt work on osx for one thing
<override>
easy installer has some universal update utility dependency which doesnt work on osx
<Tartarus>
Then you can shove your product-image.wic.xz inside of installer-image.wic, and write installer-image.wic to SD card and have that boot and uncompress/dd product-image.wic.xz
<override>
so I gotta freakin sit at home with where my ubuntu machines at to be able to flash boards
<override>
Tartarus: yeah thats more or less what im trying to get it. still sounds quite a mouth full - given how I just figured out how wic is a file system type and wks file has the definition for wic
LetoThe2nd has joined #yocto
<Tartarus>
Ah, ok. Yeah, it's all a bit tricky but there's many examples.
<Tartarus>
The hard/ugly part comes when you copy image A in to image B
<Tartarus>
And that's more ugly than hard.
<override>
I dont think I have to take it that far tho
<Tartarus>
You do, it'll suck more than not to read the product-image.wks.xz in to U-Boot and write it out
<Tartarus>
It's doable, yes, but you're better off not I bet.
<Tartarus>
With my U-Boot custodian hat on.
<override>
I just copy to what ever partion Im not booting the kernel from and then just tell uboot to boot from this partion the kernel got copied to
zeddii has quit [Ping timeout: 255 seconds]
<Tartarus>
You may want to explore using fastboot or similar, for flashing, too.
<Tartarus>
Fire up U-Boot, then write the disk image that way.
<override>
oh so like dd wont cut it?
<Tartarus>
Well, dd in Linux? sure
<Tartarus>
That's what you can easily automate, with an installer image
<Tartarus>
There's in-tree examples for that today
<override>
oh crap theres no uboot dd?
<override>
for now I was even then when I get that uboot interupt on boot up
florian_kc has quit [Ping timeout: 252 seconds]
<Tartarus>
There's not "dd" but there is writing, yes
<Tartarus>
but you're limited by your amount of DDR
zeddii has joined #yocto
<Tartarus>
using fastboot or ums to expose the disk / device to the Linux host is probably easier
<override>
fastboot is a uboot utility?
prabhakarlad has joined #yocto
<Tartarus>
fastboot is a protocol supported in a lot of ways/places.
<override>
how would that do things faster with the same amount of ddR?
<LetoThe2nd>
Tartarus: side note: in german "fast" means "almost", which makes this thing named "almost-boot", essentially ;)
<Tartarus>
LetoThe2nd: and in turn, very accurate description of this ;)
<LetoThe2nd>
Tartarus: hi5
<override>
Tartarus: you got a repo or something that I can start looking into. I start trying out JPEW's wic/wks
<override>
LetoThe2nd: thanks for linking me to that distro, machines, images youtube the other day. I still dont know the best way to like include stuff on top of vendors machine/distro, but I got a lot of stuff out of my local.conf
<Tartarus>
override: No, most of the time what I need is in meta-freeescale or meta-freescale-3rdparty
<LetoThe2nd>
override: have fun then.
<Tartarus>
Have you checked meta-freescale-3rdparty for the boad you're using?
<override>
no, ill make sure to look there
<override>
they got some interesting wks files there?
<override>
LetoThe@nd: what am I having fun with again?
<LetoThe2nd>
override: life, the universe and everything, hopefully.
<override>
LetoThe2nd: got it. enjoying all that is the least of my worries. Just his wic stuff and all that keeps me worried.
florian_kc has joined #yocto
zeddii has quit [Ping timeout: 268 seconds]
<override>
why am i seeing .wks files in my build directory?
florian_kc is now known as florian
<JPEW>
override: is your input file a .wks.in file?
linums has quit [Quit: Client closed]
<override>
i have a feeling ... Im still not a hundred percent
<JPEW>
The code will do variable expansion on .wks.in files, so I *think* it writes out the final .wks (with the variables expanded) for reference
<Xagen>
is there a way, through bitbake, to show what a `do_populate_sdk` for a given image would think is available to be added to it?
goliath has quit [Quit: SIGSEGV]
<JPEW>
override: WKS_FILES is a *little* annoying because it stops as soon as it finds one
<JPEW>
It doesn't generate one of each as you might expect :)
<override>
but why is it listing Reference-Minimal-Image.wks
<override>
that file doesnt seem to exist anywhere
<JPEW>
override: Someone added it.... `bitbake -e` can tell you who added it
<JPEW>
override: Ya, I'm not sure?
<override>
JPEW: so like bitbake -e | grep Reference-Minimal-Image should work?
<JPEW>
override: `bitbake -e <image> > env.txt` then look through the file
<JPEW>
It will give the "history" of the variables in a comment above each one so you can see how each was modified
<override>
JPEW: Im getting ERROR: Only one target can be used with the --environment option.
<override>
when I try something like bitbake -e tdx-reference-minimal-image env.txt
<JPEW>
Right, I usually redirect to a file (`> env.txt`) because it is a lot of outputy
<override>
ahh ok.. thanks
<JPEW>
I can see why that might be confusing with the `<>` I put around `image`
<override>
so wis is an image type or a file system type?
zeddii has joined #yocto
<override>
window 20
Nullcast has joined #yocto
<Nullcast>
Hi all, This may be more of an opkg question but that's a Yocto repo so... What's the minimum set of options for installing packages into an offline root tree that's opkg-based? Because --offline-root and --conf still gives me a setup that doesn't see existing packages.
<Nullcast>
Opkg version is 0.4.1 for ref
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
robbawebba has joined #yocto
<override>
is there an image only equivalent for IMAGE_FSTYPES, or am I just terribly confused?
<override>
something with just the kernel and not a complete file system image for istance
<override>
instance*
amitk has joined #yocto
amitk_ has quit [Ping timeout: 255 seconds]
<kergoth>
override: "image only"? i don't know what you mean. an image fs type can be a rootfs type, i.e. ext4, or a disk image, i.e. wic. if all you want is a kernel, don't build an image recipe at all, just bitbake virtual/kernel and use the kernel image in tmp*/deploy/images/
<override>
kergoth: whats the difference between a rootfs and a disk image?
Guest8 has quit [Quit: Client closed]
<Nullcast>
A rootfs is an image(or tree) of / with your standard packages installed on it? It should be a (mostly) complete system.
Nullcast has quit [Quit: Client closed]
<kergoth>
a rootfs is just the root filesystem only, no partition table, etc.
Nullcast has joined #yocto
<override>
kergoth, a disk image can have multiple partitions?
<Nullcast>
I think I found my problem: The copy of opkg on my build server is one I added to my SDK. Apparently it's writing status in a local copy of the SDK sysroot path for /var/lib/opkg and I'm not sure which path option overrides that.g/
<Tartarus>
So, uh, has anyone discussed rpm+zstd in general recently? I ask since I just needed to whack in a closed source rpm that was also using zstd on the inside, and rpm2cpio.sh blew up badly, and then I think since our rpm-native doesn't know zstd I had to drop in zstd -d in the pipe for do_install.
<Tartarus>
Wondering what direction I should take to deal with this if at all, upstream :)
<Tartarus>
(PACKAGECONFIG zstd to rpm?)
<JPEW>
Tartarus: Someone was looking into it, I do not recall who unfortunatley
<Tartarus>
I'll keep an eye on the ML then. Or if they don't show up in a while, feel free to poke me then
<RP>
JPEW, Tartarus: was kanavin
<Tartarus>
Ah, ok, so not a drive-by
<RP>
he is on holiday for a bit
<RP>
Tartarus: basically I think it is due in the next release at which point we might try it again. It was unstable until now
<RP>
our plan is to switch
<Tartarus>
Customer project is dunfell for now, might move up to next LTS
<Tartarus>
Ah, OK. So this particular bit of closed source stuff is ahead of the RPM recommended features anyhow?
<RP>
Tartarus: I think so
BobPungartnik has joined #yocto
<Tartarus>
Makes a bit more sense then, ok
<RP>
Tartarus: I know kanavin did try it and it was all a bit too much of an experiment last time we looked so we were waiting
BobPungartnik has quit [Client Quit]
camus1 has joined #yocto
jwillikers has quit [Remote host closed the connection]
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
LetoThe2nd has quit [Quit: Connection closed for inactivity]