<moto-timo>
JPEW: finally understood it is the phosh:phosh uid:gid and have the PIN set.. but it is unhappy after login so <shrug>
<ram>
@marex I have checked the environment variables and I can see the path and the package is available under the work directory as well. Can I know in which file is the dependency package and the version mentioned?
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
jwillikers has quit [Remote host closed the connection]
tgamblin has quit [Ping timeout: 260 seconds]
jbronder has joined #yocto
jbronder has quit [Client Quit]
tgamblin has joined #yocto
jbronder has joined #yocto
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
jbronder has quit [Quit: WeeChat 3.2]
tgamblin has quit [Read error: Connection reset by peer]
tgamblin has joined #yocto
jbronder has joined #yocto
jsbronder has quit [Quit: WeeChat 2.9]
jbronder is now known as jsbronder
sakoman has quit [Quit: Leaving.]
ram has quit [Quit: Ping timeout (120 seconds)]
bluelightning has quit [Ping timeout: 260 seconds]
camus has joined #yocto
mouser has joined #yocto
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
arlen_ has quit [Ping timeout: 260 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
gioyik has joined #yocto
<mouser>
ls -al
* mouser
sighs and moves back to the right window...
mouser is now known as Ch^W
wooosaiii has joined #yocto
wooosaiiii has quit [Ping timeout: 268 seconds]
bluelightning has joined #yocto
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
lukma has quit [*.net *.split]
Saur has quit [*.net *.split]
aeroraptor has quit [*.net *.split]
mithro has quit [*.net *.split]
twinning[m] has quit [*.net *.split]
rburton has quit [*.net *.split]
aeroraptor has joined #yocto
rburton has joined #yocto
lukma has joined #yocto
gioyik has joined #yocto
Saur has joined #yocto
mithro has joined #yocto
twinning[m] has joined #yocto
ram has joined #yocto
ram has quit [Client Quit]
k4wsys[m] has quit [*.net *.split]
moto-timo has quit [*.net *.split]
kranzo[m] has quit [*.net *.split]
Crofton has quit [*.net *.split]
thierryE has quit [*.net *.split]
meck[m] has quit [*.net *.split]
dwagenk has quit [*.net *.split]
linkliu60 has quit [*.net *.split]
Guest9844 has quit [*.net *.split]
g0hl1n has quit [*.net *.split]
OnkelUlla has quit [*.net *.split]
rfried has quit [*.net *.split]
yocton has quit [*.net *.split]
g0hl1n has joined #yocto
OnkelUlla has joined #yocto
thierryE has joined #yocto
linkliu60 has joined #yocto
override1 has joined #yocto
rfried has joined #yocto
Crofton has joined #yocto
moto-timo has joined #yocto
dwagenk has joined #yocto
kranzo[m] has joined #yocto
meck[m] has joined #yocto
k4wsys[m] has joined #yocto
amitk has joined #yocto
ChanServ has quit [shutting down]
ChanServ has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
gioyik has quit [Quit: WeeChat 3.1]
ThomasD13 has joined #yocto
fleg has joined #yocto
pgowda has joined #yocto
fleg has quit [Remote host closed the connection]
zyga-mbp has joined #yocto
zeddii has quit [Ping timeout: 265 seconds]
fleg has joined #yocto
zeddii has joined #yocto
goliath has joined #yocto
leon-anavi has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<JosefHolzmayr[m]>
yo dudX and mckoans
creich has joined #yocto
zpfvo has joined #yocto
fbre has joined #yocto
rfuentess has joined #yocto
Tyaku has joined #yocto
gsalazar has joined #yocto
goliath has quit [Quit: SIGSEGV]
<RP>
JosefHolzmayr[m]: Good morning!
<JosefHolzmayr[m]>
yo RP
Tyaku has quit [Quit: Lost terminal]
frieder has joined #yocto
mtudan has joined #yocto
mtudan has quit [Client Quit]
xmn has quit [Quit: ZZZzzz…]
yannd has quit [Ping timeout: 268 seconds]
Belsirk has joined #yocto
rfuentess has quit [Ping timeout: 264 seconds]
florian has joined #yocto
yannd has joined #yocto
tnovotny has joined #yocto
behanw has quit [Quit: Connection closed for inactivity]
xmn has joined #yocto
goliath has joined #yocto
<kanavin>
RP: I adjusted the copy to log/oeqa to symlink, but that wasn't picked into master-next?
rfuentess__ has joined #yocto
Belsirk has quit [Read error: Connection reset by peer]
user_123 has quit [Remote host closed the connection]
user_123 has joined #yocto
<ThomasD13>
Hi guys, I have some issues to understand the concept of MULTICONF, image and machine configuration. This is what I assume:
<ThomasD13>
image config: I specify which apps/tools should get deployed in the image file, which holds all I need to boot the linux (kernel, devicetree blob, root fs)
<ThomasD13>
machine configuration: Place to specify which kernel + kernel config + devicetree should be used
<qschulz>
ThomasD13: there's no image config, there are image recipes though (the notion is important because some things apply to configruation files and some others to recipes)
<ThomasD13>
Multiconf: Used to build same packages for different architectures. For example when using an SoC, which has ARM A72, R5, M3, etc...
<RP>
kanavin: sorry, just not got to that yet. master-next has a few more pressing issues :/
<RP>
(as in it is rather broken)
<ThomasD13>
qschulz, okay. Apart from that, is my assumption correct?
* RP
is rather sad the pkgconfig dependency situation has bitrotted so badly
<JosefHolzmayr[m]>
ThomasD13: it is not incorrect, yet very limited.
<ThomasD13>
JosefHolzmayr[m], I try to get the basic idea of what belongs into image recipe and what in machine configuration :)
<fbre>
Hi! Is there a file in sources/poky/meta/classes where the partitions for boot and rootfs are defined? Somehow I think I have seen before there was something like two lines where boot partition and roofs partition was defined for blocksize, partition size etc.
<qschulz>
ThomasD13: machine configuration file for everything that is specific to your HW. So kernel, dtb, bootloader, tunes, architecture,etc... could add specific image filesystem "formats" if they are specific to the machine (e.g. the old sdcard.img IMAGE_FSTYPES that was used for the RPi (among others)
<JosefHolzmayr[m]>
ThomasD13: important fact #1: recipe data is local, configuration data is global. hence, whatever you want to do that affects more than the image content selection or its processing, cannot be in the image recipe. thats the one thing.
<qschulz>
ThomasD13: image recipe is basically the place where you specific a collectiono f packages to install into filesystems and what kind of filesystems you want (that are machine agnostic)
<JosefHolzmayr[m]>
ThomasD13: important fact #2: MACHINE and DISTRO features are orthogonal, or at least should be. the machine config shall define everything that your build really needs to know to work on a specific piece of hardware, and nothing beyond that.
<JosefHolzmayr[m]>
ThomasD13: therefore, everything that affects multiple packages, e.g. defines your ABI/API, should go into the DISTRO
<qschulz>
multiconfig is when you have more than one architecture on your HW (e.g. out-of-SoC MCU, cortex-M something in the SoC, etc...)
<qschulz>
well, I'll let JosefHolzmayr[m] answer you :)
<JosefHolzmayr[m]>
ThomasD13: and important fact #3: multiconfig is primarily used for different machines, but not necessarily to. its more like an "alternative config". so you totally could use it to build a bedig image additional to the standard build.
<JosefHolzmayr[m]>
bdig = debug
gsalazar_ has joined #yocto
<JosefHolzmayr[m]>
qschulz: heh i'm through, feel free to add/correct me.
<qschulz>
JosefHolzmayr[m]: i think we complemented each other's answer so I'm good with that :)
<JosefHolzmayr[m]>
:)
gsalazar has quit [Ping timeout: 246 seconds]
<ThomasD13>
Okay, so for example my vendor is using a image recipe and machine configuration to build a complete image for specific board (I name it "board_1"). There is also a multiconfig, because it builds packages for the R5 and A72. (There is a SoC on the board)
* kanavin
wonders why aren't we seeing use of gtk4 anywhere, yet
<kanavin>
moto-timo, JPEW i assume phosh is also gtk3?
<kanavin>
it's already on it's third major release!
<ThomasD13>
Now I would like to extend this to a second board. "board_2". The SoC is identical, the hardware around alittle bit different. So I need a different kernel and devicetree. Maybe some different apps on the rootfs.
<kanavin>
I though of adding a recipe, but without actual consumers it's not truly verified.
<ThomasD13>
I would guess, I have to declare a second machine configuration, whereas I define the different kernel/devicetree. Maybe also different u-boot config.
<JosefHolzmayr[m]>
ThomasD13: sounds like you actually want a seperate build that shares some layers.
<qschulz>
kanavin: gnome 40 Google tells me?
<ThomasD13>
And I use another image recipe to specify some other apps on the rootfs
<JosefHolzmayr[m]>
ThomasD13: multiconfig theoretically can used to do "i have this build, but, pretty please, can you also build this completely different thing too?"
<kanavin>
qschulz, none of the gnome components we carry in oe-core throw an error
<ThomasD13>
But I don't understand what I have to too with the multiconfig?
<ThomasD13>
*to do
<JosefHolzmayr[m]>
ThomasD13: but that sounds like headaches. multiconfig really shines when you have one target that internally needs preliminary builds with different configurations. if you want a build for something else altogehter (e.g., a different board): create a new machine, set up a new build.
<ThomasD13>
JosefHolzmayr[m], yes, basically yes. Sharing majority of layers, but I need to specify different kernel/dtb
<qschulz>
JosefHolzmayr[m]: you're missing the fact that the current build is already multiconfig because of the Cortex-R5
<qschulz>
ThomasD13: so I think you just need to create a new machine and replace board_1 with board_2 in your multiconfig call/configuration files (don't know how it is setup really, JosefHolzmayr[m] will know more for sure)
<JosefHolzmayr[m]>
qschulz: now, why am i? the new build can totally be multiconfig in itself too. but that shoudn't affect the main build target.
<qschulz>
and create a new image recipe
<ThomasD13>
Exactly. I need somehow the same multiconfig in my new build
<JosefHolzmayr[m]>
ThomasD13: the shared layers can bring the multiconfig.
<JosefHolzmayr[m]>
if you glue everything up, you will end up with headaches because you always kick off the main-master-magic-humonguous build even if you are only modifying one target. what happens when board 3 arrives? board 4? board 20?
<ThomasD13>
Okay, so which is pulling what? I think from JosefHolzmayr[m] rules #1 and #2, the machine.conf is pulling the required image recipe (because machine is global and image is local?)
<JosefHolzmayr[m]>
creating a build for 20 different images on 20 different boards that can only be kicked off in one (because thats what a multiconfig build somewhat implies) sounds ridiculous, right? and so is it, also for 2 baords.
<ThomasD13>
But what does multiconfig exactly do? Is it also global?
<JosefHolzmayr[m]>
ThomasD13: no, a machine config pulls no image. the machine configuration is global for the build. the image uses it.
<ThomasD13>
ah okay
<qschulz>
JosefHolzmayr[m]: My understanding is that ThomasD13 does not want to build all machines at once, but rather build a multiconfig setup with board_2+cortex-r5
<qschulz>
and they currently have board1_+cortex-r5
<JosefHolzmayr[m]>
ThomasD13: now you're getting closer. multiconfig is actually not much more than "give me an additional build in the existing configuration, just let me tweak this handful of variables".
<JosefHolzmayr[m]>
qschulz: nope. they have. board1 = (cortex a + cortex r)
<ThomasD13>
Yes, I dont need to build all machine at once. But I need that everything is build for a single machine at once. So all the packages for R5 and also for A72
<qschulz>
JosefHolzmayr[m]: "There is also a multiconfig, because it builds packages for the R5 and A72. (There is a SoC on the board)"
<JosefHolzmayr[m]>
ThomasD13: see, and thats why you have exactly one build per machine. where each can be multiconfig, or not, depending on the requirements.)
<ThomasD13>
board 1 = (cortex a + cortex r), board 2 = (cortex a + cortex r) but with different kernel/dtb
<qschulz>
But I'll let ThomasD13 explain themselves, no need for me to talk in their behalf :)
<JosefHolzmayr[m]>
qschulz: it leaves a certain leeway for interpretation, of course - but i think i've said everything necessary anyways. need to earn some money now.
<qschulz>
ThomasD13: cortex a in a one machine configuration file, cortex r inb another machine configuration file, then multiconfig for the machine conf of cortex a + machine conf cortex R
<jaskij[m]>
ThomasD13: if I understand you correctly, a slightly hacky way to have all packages "build at once" - with one command - is to just add an image with all the packages.
<ThomasD13>
First of all, thank you all guys for your quick response. I have to reread carefully to understand what you mean.
<jaskij[m]>
My bad, I didn't scroll back far enough
<qschulz>
ThomasD13: a machine conf file is for one arch (well, can be more with multilib but let's not go there, you don't seem to need it and if you can avoid it, do so :) )
<qschulz>
so if you have more than one arch (which is your case), you need a machine conf file per arch (one for cortex A + one for cortex R)
<ThomasD13>
One point to note: I don't want a hack to add fast second machine, and build these two machines with one call
<ThomasD13>
qschulz, okay
<qschulz>
so except if the cortex-R packages need to be different on board_1 than board_2, you can share the same machine for the cortex-R in both multiconfig (the one for board_1 and the other for board_2)
<ThomasD13>
qschulz, sorry you mean "except" or "example" ?
<qschulz>
I meant except
<ThomasD13>
Ok to sum up: It seems my vendor has used multiconfig to build for cortex A and cortex R. Another solution to this case would be to specify a machine configuration each for cortex A and R
<qschulz>
ThomasD13: you already have a machine configuration file for the cortex-A
<qschulz>
so you just have to write your own machine configuration file for the cortex-A in your board_2
<qschulz>
and then replace in the multiconfig bitbake call the cortex-A machine name for board_1 with the one for the cortex-A machine name for board_2
chrfle has joined #yocto
<ThomasD13>
ahhh okay - I think i get closer now :)
<qschulz>
well.. ok. It's not correct to say "machine configuration for cortex-A" but more "everything handled by the cortex-A", including kernel, bootloader, and HW components handled by the kernel running on cortex-A for example
<qschulz>
*"everything that is specific to board_1 and that is handled by the cortex-A"
<ThomasD13>
Maybe the last question, which answer will be "it makes all sense now", or "Ill start from scratch :) ": Is the multiconfig "visible" across different machine configuration?
<qschulz>
visible?
<qschulz>
you mean, do the machine configuration files have knowledge they're used in a multiconfig setup?
<ThomasD13>
Yes
<qschulz>
They shouldn't need to, multiconfig is just saying to bitbake: build that image for that machine conf, and this image for this image conf, and this or that image recipe might use the artifacts from that or this image recipe
<qschulz>
or at least that's my understanding
<ThomasD13>
Okay, thank you very much. I need to sort my thoughts... qschulz do you have paypal or anything? I would be happy to spend you at least a cup of coffee or something, to mess around with an noob like me :)
<fbre>
Hi! I have a boot and a rootfs partition. Do you know which .bb file or class file puts both images in the .wic.gz image file?
<rburton>
whatever WKS_FILE is set to defines the .wks that tells wic what to do
<qschulz>
ThomasD13: my work contract does not allow me to receive donations :) and in any case, happy doing this for free :) Thanks for offering, don't hesitate to talk to your bosses to spend some money on supporting Yocto :) https://www.yoctoproject.org/join/
<qschulz>
fbre: classes/image_types_wic.bbclass is very likely to be the class doing that
<ThomasD13>
Alright, I will talk with my boss in our next meeting ;) Maybe i'll spend myself a little tip
<fbre>
qschulz: I want to change the size of the rootfs partition to something bigger than it actually needs to be. I don't see how the partition size is set in image_types_wic.bbclass
<jaskij[m]>
That table doesn't work on mobile
<fbre>
I suppose it's somehow done via the tool 'parted'
<qschulz>
fbre: very likely something you can set in the WKS_FILE
<jaskij[m]>
fbre: why not throw in a first run expand rootfs script? That way you've got it covered regardless of actual storage size.
<qschulz>
jaskij[m]: because the partition is not the last one in the partition table
<jaskij[m]>
Fair
<fbre>
qschulz: What do you mean with "rootfs script"?
<qschulz>
fbre: it wa jaskij[m] and I assume they were talking about resize2fs or something similar
gsalazar_ is now known as gsalazar
<fbre>
X) aaah, now I've found the location where the partitions are defined: It's in sources/meta-freescale/wic/... where I find a few ...wks.in files which call the tool 'part' for u-boot, /boot and /
<jaskij[m]>
Yup, write a script which expands the rootfs to full media size the first time the device boots. But if rootfs isn't the last partition it's a moot point.
<fbre>
This looks promising to add your suggested parameter --fixed-size there
mckoan is now known as mckoan|away
<fbre>
Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
<fbre>
Currently, fdisk shows this on my device. I want to have mmcblk1p2 a fixed size of 512M to be able to exchange this partition later without touching mmcblk1p3 behind
dtometzki has quit [Read error: Connection reset by peer]
dtometzki has joined #yocto
<fbre>
I guess I have to reimplement wic/imx-imx-bootpart.wks.in in my own meta layer
<fbre>
imx-imx-boot-bootpart.wks.in
<fbre>
Is it possible to overload such wks.in file in my own meta layer?
<fbre>
... by just copying to my meta layer and modify that?
<rburton>
yes
<fbre>
(y) thanx for your help!
<wCPO>
I'm a bit puzzled why skopeo-native is trying to find gpgme on the host ([...]/build/tmp/hosttools/ld: cannot find -lgpgme), I assume it is some kind of bug?
<rburton>
yes
<rburton>
does it depend on gpgme-native though?
<wCPO>
rburton: It depends on gpgme
<rburton>
then yes, bug in the makefiles.
<rburton>
most likely not respecting LDFLAGS which point it at the native sysroot
<wCPO>
rburton: sounds likely. skopeo is a Go program, so very likely some missing/wrong flag
<wCPO>
I backported skopeo-native to hardknott, so could already be fixed. I will investigate
angolini has joined #yocto
<fbre>
hmm.... just copying imx-imx-boot-bootpart.wks.in to sources/my-meta/wic/ doesn't seem to have an effect of the wic.gz file I create with bitbake
<fbre>
(although I added that option --fixed-size 256M)
<fbre>
...to for the boot partition and --fixed-size 512M to the rootfs partition
rfuentess__ is now known as rfuentess
wooosaiii has quit [Remote host closed the connection]
wooosaiii has joined #yocto
<barath>
This is probably a long-shot but... is there something like REQUIRED_VERSION_<pn>? or a DEPENDS which sets the minimum required version of a dependency?
<rburton>
no
<Saur>
barath: There is for runtime dependencies.
<barath>
hm
<barath>
what's it called for runtime dependenceis?
<Saur>
RDEPENDS:${PN} = "foo (>= 1.2.3)"
<barath>
thank you, I didnt know that
<barath>
on a possibly related note, we sometimes have problems with someone screwing up and the PREFERRED_VERSION doesn't actually exist. say, openssl. yocto will then proceed to just pick a "random" version. we've got a hacked branch locally somewhere which will abort the build. is there a more "yoctonic" way of solving that? some QA thing?
<Saur>
It is rarely used as typically when building with bitbake you have control of the layers and what versions the different recipes use.
<barath>
yeah, we have control of those. it'd just be more elegant to have yocto abort instead of us grepping for yocto choosing another version because whatever we specified doesnt exist because someone made a typo or mistake etc
<JosefHolzmayr[m]>
barath: abort, or at least report. yeah, i've seen that too and think an info or warning on such would be nice.
<barath>
it's "reported" in the sense that there's warnings (IIRC) printed about yocto choosing another version, but yeah
<barath>
maybe there's a QA trick I'm not aware of
<barath>
I'm concerned about missing this in automated CIs. shipping an incorrect openssl version can be kind of embarrassing :D
<JosefHolzmayr[m]>
ah there's warnings? nice. but then its up to your CI to actually evaluate the logs ;-)
<barath>
:D sure you could say that... but grep-driven CIs don't sound super robust. if the outputs/what we grep for changes formats, we might never notice
<barath>
I guess we could parse the package manifest, which I assume includes versions. but then you'd have to wait for the entire build to complete before detecting the error.
<JosefHolzmayr[m]>
barath: well, watching the output for two strings ("warning" and "error") almost never hurts in CI
<RP>
barath: there is a open bug to make DEPENDS = "openssl (=X.Y.Z)" work but it hasn't happened as yet
<RP>
barath: we've also talked about making PREFERRED_VERSION mismatches fatal but haven't added any option as yet
<barath>
RP: thank you, I'll look for that
<barath>
Josef Holzmayr (TheYoctoJester): and that's a good point
<fbre>
X) aaaah, I have to add WKS_FILE = "mystuff.wks.in" to my machine.conf file and then bitbake uses my partitioning with --fixed-size
rsalveti has joined #yocto
<ThomasD13>
When I have a variable like this: "KERNEL_CONFIG_FRAGMENTS_append_j7-evm = " ${WORKDIR}/devmem.cfg" ", is "../devmem.cfg" only appended, when machine configuration "j7-evm" is used?
<qschulz>
ThomasD13: yes
<qschulz>
well, machine named j7-evm or if j7-evm is part of MACHINEOVERRIDES
<ThomasD13>
qschulz, thanks that was my next question. If this kind of syntax only applies to machine configuration :)
<vmeson>
kanavin: re: [16:35] <kanavin> RP: I've heard others are working on it? and working and working and working, and no patches are showing up :-/
<vmeson>
if librsvg is slowing you down from trying out phosh, go for it. I'm back from vacation but buried under a stack of email and likely $dayjob oblications.
roussinm has joined #yocto
<ThomasD13>
Has someone an idea how to debug this kind of error, when bitbake does not even start to use "-e" ? https://hastebin.com/uhayiyaxoy.sql
<Wouter0100>
Is there any proper way to "force" a specific username when showing the login prompt? I want someone who hooks up a screen, to only be able to login to a specific user.
<qschulz>
ThomasD13: I assume DEF_TOOLCHAIN_PATH is not defined anywhere
<fullstop>
Just to confirm my suspicions, there is no way to modify a bbclass in a layer?
<rburton>
Wouter0100: don't tell users the other passwords?
<qschulz>
fullstop: you can override it but not use a bbappend mechanism if that's the question
<fullstop>
Right, so I can't extend what is already there -- it must be replaced entirely.
<vmeson>
ThomasD13: there's always strace ....
<ThomasD13>
alright, I'll dig into that :)
<fullstop>
I can work around it, qschulz, thanks for the response.
<Wouter0100>
rburton: I surely won't, but regardless I'd love to let them skip the `username` field if that'd be possible :)
<qschulz>
fullstop: however, I'd highly encourage you to not override it and send a patch upstream so everybody can benefit from it and you don't have to have a forever burden on your shoulders when you'll need to upgrade your layers
<rburton>
Wouter0100: you could just start a bash with the right user on the consoles instead of a login prompt, but that might bite you if you actually need to login as another user
<fullstop>
qschulz: It's not that big of a benefit to others. The process that I have for updating devices executes opkg in an environment which does not have /sbin in PATH, so updating kernel modules fails since depmod fails to execute.
<fullstop>
I can update the environment to include /sbin, but it turns it into a two-step process.
<ThomasD13>
I just copied the vendor's machine configuration and renamed it. But it seems there is a lot *_append_vendorMachineConfig in all these layers :/ Seems to be get complicated
<qschulz>
ThomasD13: use MACHINEOVERRIDES for that ;)
<qschulz>
and... in some cases, it might be a good idea to just include the original machine configuration file instead of copy-pasting it (not that it would help in any way on that specific issue)
<ThomasD13>
qschulz, I'll check what MACHINEOVERRIDES does exactly. This was just my first step to add additional machine config :S
<qschulz>
but yeah, vendor BSPs aren't known to be very easy/nice to work with
<Wouter0100>
rburton: we don't have any other users and sudo is not installed either. We've build our own PAM module for a `management` user to ease up logging in, so we do want PAM - but preferably *only* to the management user. All other users (jncl. root) are disabled on purpose, as we've a different image for testing purpose.
<Wouter0100>
But I'm unable to find any way to do so :(
<qschulz>
Wouter0100: you could print the username right before the input for the user name
<rburton>
Wouter0100: so how are you going to login as management if the consoles are all pre-logged in?
<rburton>
you just need to change what init spawns on the consoles
sakoman has joined #yocto
<Wouter0100>
Oh noh, they're not pre-logged in :P. Sorry I may make it look confusing
<rburton>
so what do you want?
<Wouter0100>
In the login prompt I want to skip the `username` input field and directly go to the next step for authentication (normally a password input field, but in our case the custom PAM module) for the `management` user :D
<rburton>
Wouter0100: you might need to swap to proper getty, but getty can do that
<moto-timo>
JPEW: immediately after login to phosh, it seems to fail because the connection is refused to gsd-media-keys... ring any bells?
<JPEW>
Hmm, no
<JPEW>
Looks like it's trying to talk to gnome-settings-daemon?
Guest46 has quit [Quit: Connection closed]
<moto-timo>
JPEW: right... so maybe the daemon isn't running (or maybe I forgot to install it)
<JPEW>
moto-timo: Ya, missing RDEPENDS probably
Xagen has quit [Remote host closed the connection]
Xagen has joined #yocto
<kanavin>
vmeson, I'll give it a shot
<JaMa>
RP: I think qemu-native is missing ninja-native dependency with your changes in master-next, should I send a patch or do you already have similar somewhere
<RP>
JaMa: I don't have that. I'm a little puzzled why we wouldn't see that on the autobuilder
<JaMa>
here it fails with "ERROR: Cannot find Ninja"
<JaMa>
with no ninja on host, but i don't see it in HOSTTOOLS_NONFATAL so it shouldn't probably matter
<RP>
JaMa: qemu_6.0.0.bb has ninja-native in DEPENDS
<ThomasD13>
Hmm.. I see that DEF_TOOLCHAIN_PATH is set by "toolchain-arm.inc". But nothing in the layers seem to reference that include. How is that possible?
<JaMa>
meta/recipes-devtools/qemu/qemu-native_6.0.0.bb overwrites that DEPENDS
<ThomasD13>
When I create a new machine configuration, do I have to link this somehow to a distribution?
<RP>
JaMa: thanks, I'll queue that
<RP>
JaMa: torn on that layer.conf patch, it is a pain but it does let us fix some of the dependencies
rcw has joined #yocto
<vd>
When you guys do customer versioned releases, what do you use for the version? image PV? multiconfig forcing a few preferred versions? distro version?
<jaskij[m]>
I think I've hit another bug, either in multiconfig or in imx-boot (meta-freescale). I'm doing a multiconfig build and even when building for a non-default config, I'm getting a lack of compatibility error between imx-boot and the default machine.
<jaskij[m]>
changing the `MACHINE ?= "xxx"` line in `local.conf` fixes that error
<jaskij[m]>
even though I'm running bitbake with multiconfig specifying a different machine
ThomasD13 has quit [Ping timeout: 252 seconds]
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
zpfvo has quit [Client Quit]
pgowda has quit [Quit: Connection closed for inactivity]
zpfvo has joined #yocto
zpfvo has quit [Client Quit]
zpfvo has joined #yocto
tnovotny has quit [Quit: Leaving]
frieder has quit [Remote host closed the connection]
whuang0389 has joined #yocto
zpfvo has quit [Quit: Leaving.]
FredO has quit [Quit: Leaving]
<JaMa>
RP: I've included it in my bigger builds to see how badly world is affected, but I kind of like them as the build issues are often relatively clear and easy to fix
<JaMa>
so there might be still enough time for external layers to fix possible fallback
goliath has joined #yocto
<vd>
JPEW: with whisk (or in your setup) what does a customer release version correspond to? the image recipe PV or something else?
<vmeson>
kanavin: that's good, thanks!
florian has quit [Quit: Ex-Chat]
<JaMa>
RP: got another strange ExpansionError in one of my builds, but don't know what exactly causes this (unless it looks really familiar to you): http://dpaste.com//EDB9LJMK7
dev1990 has joined #yocto
rfuentess__ has joined #yocto
Belsirk has quit [Ping timeout: 264 seconds]
jmiehe has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
<Tokamak>
in yocto, is there a way to setup a chroot like environment with all the system files for inspection/modification in a recipe? kinda like a finalize rootfs step?
<rburton>
Tokamak: manual inspection or automated rootfs qa?
<Tokamak>
e.g. i'd like to tweak /etc/passwd after all recipes have injected their accounts (just one use case)
<Tokamak>
automated apart of the build. intended for both qa and actual modification
<rburton>
so, automated
<Tokamak>
yes
<rburton>
you can do whatever you want in ROOTFS_POSTPROCESS_COMMAND
<kergoth>
if you just want to run shell scripts to tweak the rootfs, that's what ROOTFS_POSTPROCESS_COMMAND is for, though it doesn't run in a chroot
<rburton>
but it does run in a pseudo-context so you are 'root'
<Tokamak>
thanks! that covers the passwd use case! will look into this
<rburton>
there's already optional commands available for that which manipulate passwd fwiw
<Tokamak>
is there a chroot mechanism (relying on qemu / binfmt integration) for running configuration scrips for certain packages (firewalld's firewall-cmd is the next on my bucket list)
<rburton>
no but you can run stuff in qemu-user
<rburton>
but if firewall-cmd expects to be able to speak to a running firewalld, then that's not going to work
<Tokamak>
do you have an example of a hook to running qemu-user w/ing yocto?
<rburton>
the postinst intercepts like update_font_cache. they're designed to be executed by package management scripts, but show how to call qemuwrapper
<Tokamak>
true. i'm relatively unfamiliar with firewalld, but there does appear to be a firewall-offline-cmd that might fit this current task at hand :)
marex has quit [Ping timeout: 252 seconds]
<rburton>
and if you're lucky its a script so doesn't need qemu
Belsirk has joined #yocto
<Tokamak>
thanks for the pointer to qemu class -> postinst_intercept
<Tokamak>
thanks for the insight, rburton
rfuentess__ has quit [Ping timeout: 246 seconds]
<RP>
JaMa: something is putting None in the varlist, we should perhaps fix that, then you'd get a better error message
<rburton>
Tokamak: alternatively, you can write a on-first-boot postinst script
rfuentess__ has joined #yocto
Belsirk has quit [Ping timeout: 246 seconds]
<vd>
How can I look up the IMAGE_LINGUAS value for spanish/spain?
<rburton>
es-es
<vd>
thank but where do I look up these values?
<Tokamak>
interesting. nice to know as well!
jmiehe has joined #yocto
florian has quit [Ping timeout: 252 seconds]
Vonter has quit [Ping timeout: 268 seconds]
<JPEW>
vd: whisk doesn't really impose any sort of versioning like that
<JaMa>
RP: definitely helps :) bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: There are recursive references in fetcher variables, likely through SRC_URI
<JaMa>
The variable dependency chain for the failure is: SRCPV -> PV -> SRCPV -> PV -> WORKDIR -> T
Vonter has joined #yocto
<JaMa>
RP: still not clear why lxc from meta-virtualization fails this one in one build, but the same recipe doesn't seem to trigger this in another very similar build
<JaMa>
RP: will let you know when I have some clearer reproducer
yates has joined #yocto
<yates>
basic question: is the do_patch task performed before or after do_configure?
<JaMa>
RP: ok, now it's more clear (of course there is some old junk in meta-qti which doesn't play nice with latest lxc change from meta-virtualization), your bitbake fix is all we need, thanks
<vd>
yates: before, since you want to configure patch sources...
<vd>
patched*
Starfoxxes has quit [Ping timeout: 268 seconds]
florian has joined #yocto
<rburton>
yates: you can look stuff like that up trivially. base.bbclass: addtask configure after do_patch
<vd>
basically specifying a recipe name without semicolon is equivalent to mc:${BB_CURRENT_MC}:pn, correct?
<ant__>
I must evaluate more tags and apply patch accordingly
gioyik has joined #yocto
<ant__>
JaMa, ^ this is the evil enigma2 TV interface :)
<ant__>
soon enigma3 they swear
Belsirk has quit [Ping timeout: 264 seconds]
rfuentess__ has quit [Remote host closed the connection]
rfuentess__ has joined #yocto
<whuang0389>
lol i dont know which email I used to register for the open source summit
<RP>
ant__: python is probably easiest
rfuentess__ has quit [Remote host closed the connection]
rfuentess__ has joined #yocto
rfuentess__ has quit [Remote host closed the connection]
gioyik has quit [Remote host closed the connection]
whuang0389 has quit [Quit: Client closed]
gioyik has joined #yocto
yannd has quit [Ping timeout: 264 seconds]
opello has joined #yocto
<opello>
hi, is there any way to debug why a run.do_install script is suddenly being generated without a function (which shows up in bitbake -e recipe)?
gioyik has quit [Ping timeout: 276 seconds]
<vd>
Is it preferred to customize IMAGE_NAME or IMAGE_BASENAME?
sakoman has quit [Ping timeout: 260 seconds]
florian has quit [Ping timeout: 265 seconds]
gioyik has joined #yocto
FredO has joined #yocto
amitk has quit [Ping timeout: 264 seconds]
sakoman has joined #yocto
leon-anavi has quit [Quit: Leaving]
xmn has joined #yocto
florian has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
florian has quit [Ping timeout: 252 seconds]
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
gioyik has joined #yocto
florian has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
jwillikers has quit [Remote host closed the connection]