reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
ptsneves has joined #yocto
mckoan_ is now known as mckoan
<mckoan>
good morning
rfuentess has joined #yocto
aduskett has joined #yocto
Kubu_work has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
Jones42 has joined #yocto
rfuentess has joined #yocto
xmn has quit [Quit: ZZZzzz…]
leon-anavi has joined #yocto
<ak77>
morning.
<ak77>
I am looking for a way,... SRC_URI file:// but i need to place it somewhere specific, aka destination dir of local file operation, how to solve this ?
<ak77>
dest, ha?
<ak77>
nvm
sotaoverride has quit [Ping timeout: 252 seconds]
sotaoverride has joined #yocto
olani- has joined #yocto
olani- has quit [Ping timeout: 246 seconds]
olani- has joined #yocto
Guest76 has joined #yocto
florian has joined #yocto
Guest76 has quit [Quit: Client closed]
florian_kc has joined #yocto
cgx has joined #yocto
<ak77>
anyone dealt with rust crates that reference git+https:// instead of crates.io ? hmm. what about if there is a multipackage repository ?
olani- has quit [Remote host closed the connection]
aduskett has quit [Ping timeout: 244 seconds]
aduskett has joined #yocto
aduskett has quit [Client Quit]
aduskett has joined #yocto
aduskett has quit [Client Quit]
Jones42_ has joined #yocto
Jones42 has quit [Ping timeout: 272 seconds]
aduskett has joined #yocto
aduskett has quit [Quit: Konversation terminated!]
sotaoverride has quit [Ping timeout: 246 seconds]
sotaoverride has joined #yocto
<ak77>
ok. that should work. cargo_common.bbclass, adds [patch.*] sections to ${CARGO_HOME}/config ... but only checks for git: in scarthgap and for git: and gitsm: in styhead. do such things get backported ? (scarthgap being LTS)
davidinux1 has joined #yocto
davidinux1 has quit [Quit: WeeChat 4.3.1]
cgx is now known as cglab
olani- has joined #yocto
frieder has joined #yocto
ddee has joined #yocto
testtttt has joined #yocto
Jones42_ is now known as Jones42
<ak77>
yeah. it doesn't ... anyone uses this git:// name=a;dest=a/b for rust multi-package rust repositories ?
testtttt has quit [Quit: Client closed]
cglab has quit [Ping timeout: 256 seconds]
<ak77>
how do I change function when it's set with do_configure[postfuncs] += "cargo_common_do_patch_paths" ? I want to replace this function with my own
pbiel has quit [Remote host closed the connection]
pbiel has joined #yocto
<rburton>
ak77: name your function cargo_common_do_patch_paths
ddee has quit [Quit: Client closed]
sotaoverride has quit [Ping timeout: 265 seconds]
sotaoverride has joined #yocto
davidinux1 has joined #yocto
macpijan has joined #yocto
<macpijan>
Hi. I was trying to gain ownership of the layer added to the index (https://layers.openembedded.org/layerindex) by a former employee. I have access to their e-mail address, but the account is locked and could not recover password. It says I should contact administrator about that. I cannot find on this site to whom I should reach out. Do you guys
<macpijan>
have any hints?
<rburton>
macpijan: i have admin and might be able to help, can you email ross.burton@arm.com the layer name and relevant contact details
<rburton>
ideally from an email address that demonstrates why you should take it over
<macpijan>
Thanks! I'll reach to yo uvia e-mail then.
<LetoThe2nd>
qschulz: unexpected visit of you there :-)
<qschulz>
LetoThe2nd: research for now into what we could be using, but admittedly for a very VERY corner case of update SW
<qschulz>
(which is: initial flashing straight out of factory)
<LetoThe2nd>
qschulz: hehe. been there, done that :-)
<LetoThe2nd>
qschulz: and yeah, its actually a common use case for us, "upon first power on + network connection, install software" but I strongly advise to not do it :-)
<qschulz>
LetoThe2nd: mmmmmm why not :)
<LetoThe2nd>
qschulz: bad user experience. you unpack something and then have to wait minutes or even hours until it is functional.
<qschulz>
LetoThe2nd: to be clear, we're HW+BSP vendors, so essentially our issue is that what we put out of our factory usually needs to be reflashed by the customer in their own production facilities
<qschulz>
so we would essentially only have U-Boot flashed, and then they would boot something from an external storage medium/network that would then flash the eMMC
sakoman has quit [Quit: Leaving.]
<qschulz>
LetoThe2nd: oh yeah, I wouldn't do that for actual users :)
sakoman has joined #yocto
<LetoThe2nd>
qschulz: why not have u-boot plus a provisioning system in an initramfs flashed?
<qschulz>
LetoThe2nd: because we do SoMs
<qschulz>
so we don't know in what it's going to be inserted
<qschulz>
meaning, different DTS+kernel probably
<LetoThe2nd>
qschulz: yeah okay.
<qschulz>
but yes, that's the plan, have them boot an initramfs with *some* SW mechanism that takes some image somewhere and flash it
<qschulz>
So question is: would any existing SW update mechanism support this or should we just make our own
<LetoThe2nd>
qschulz: been there, done that, or at least forms of it.
<qschulz>
while we keep the **actual** SW update to proper SW update mechanisms (i.e. different pieces of SW for initial flash and update)
<LetoThe2nd>
qschulz: there's not much magic in baking an update client plus some clever configuration into an initramfs.
<qschulz>
(I'll NOT roll out my own SW updater, do not worry :) )
<qschulz>
LetoThe2nd: yeah.. that was my thought as well, but if we can actually already make use of an existing SW updater, then we can gather knowledge about it, make maintainance "easier" and also reuse it for actual SW updating
<LetoThe2nd>
qschulz: I've done this as very preliminary PoCs with Mender, but I don't see why it should be hard for SWupdate, rauc, or whatever the standard, main client is.
<qschulz>
RAUC absolutely expects a partition table to already exist
<LetoThe2nd>
meh
<qschulz>
SWUpdate seems to be fine creating one, BUT it expects to generate the SWU file from a build system (though there exists swupdate-generator now for creating the file by hand)
<qschulz>
and also, limited to 4GB because that's the limit of the CPIO format apparently
<qschulz>
and mender I don't know, I'm going through the docs for now :)
<LetoThe2nd>
also kinda meh.
<LetoThe2nd>
qschulz: so well, Mender happily runs as a service without any boot loader or storage integration whatever, and will flash considerably more than 4GB.
<qschulz>
yeah, I've seen you use tarballs, so not limited by the file format of the container for the binaries :)
<LetoThe2nd>
its a slightly unusual but not super niche use case. a customized "Update Module" (that's what we call it) would be required, plus a little beating into initramfs. Beyond that, no problem.
<qschulz>
shoragan: yeah but at that point, what's the benefit of using RAUC at all?
<shoragan>
qschulz, exactly :)
<shoragan>
im my experience, there's not much overlap between the initial factory installation and updates in the field
<qschulz>
yeah that was my gut feeling too
<qschulz>
but you know, **hopes**
<LetoThe2nd>
shoragan: holiday project: let wrap memfault around Mender around RAUC around SWupdate! ;-)
<shoragan>
LetoThe2nd, ahrg :)
<qschulz>
I'll probably end up doing an initramfs with a shell wrapper around bmap-tool and be done with it :D
<LetoThe2nd>
shoragan: there shall be Glühwein involved!
<LetoThe2nd>
qschulz: please not another "its just a shell script" solution.
<shoragan>
qschulz, if you don't trust the factory and need authentication and/or encryption during provisioning, that changes things somewhat and building on an existing updater may be useful.
<qschulz>
shoragan: that's true, BUT
<LetoThe2nd>
shoragan: a.k.a. "please not another shell script"
<qschulz>
we own the factory and it's literally downstairs, and what the customer is actually going to do with their own factory... don't know
<shoragan>
qschulz, for initial provisioning in a trusted environment, I find using fastboot (via USB or Ethernet) very useful, as it needs only a installed bootloader
<qschulz>
the point being to just provide **something**
<qschulz>
if they want something fancy, we could probably do it or they do it themselves
<LetoThe2nd>
qschulz: well, I trust your expertise from hereon :-)
xmn has joined #yocto
<qschulz>
shoragan: yeah I would simply use PXE there :)
<qschulz>
LetoThe2nd: what's wrong with yet-another-shell-script solution????
<qschulz>
I'll make a yet-another-python-module solution instead then
<qschulz>
shoragan: but PXE requires some amount of setup at the client (and a reliable network, etc...)
<qschulz>
so a USB-stick solution is also sometimes the most fool-proof solution
GNUmoon has quit [Ping timeout: 260 seconds]
<shoragan>
qschulz, yes. and fastboot is available on many distros and everywhere else via the android SDK tools
<shoragan>
qschulz, you could also configure only a single RAUC slot for the full eMMC. and a "noop" bootloader. then you get one chance to update from a running initramfs (perhaps from a well-known local webserver)
<qschulz>
shoragan: yeah I have some other ideas as well
<qschulz>
meta-rockchip for example makes use of systemd-repartd on first boot to create the partitions
<qschulz>
before rauc starts
<qschulz>
so that would be an option as well
<shoragan>
qschulz, we use that as well, but only for the secondary rootfs and data partition
<qschulz>
LetoThe2nd: ok so the phrasing is very misleading
<LetoThe2nd>
qschulz: possibly, yes.
<qschulz>
The Mender Client has the ability to run pre- and postinstall scripts, before and after it writes the root filesystem. However, Mender state scripts are more general and useful than pre/postinstall scripts
<qschulz>
To me this means you have two things
<qschulz>
pre- and post-install scripts
<qschulz>
and also state scripts
<qschulz>
state scripts better
<qschulz>
highlighted by "However"
<qschulz>
meaning they are essentially different things
<LetoThe2nd>
hmm. should be something like "Those are provided as Mender state scripts, which additionally..."
ehussain has joined #yocto
<qschulz>
LetoThe2nd: yeah or maybe just don't mention pre-/post-install in there?
<qschulz>
except if those are typical words and you want people to reach this page when they look for that kind of info
Ad0 has joined #yocto
goliath has quit [Quit: SIGSEGV]
macpijan has quit [Ping timeout: 256 seconds]
davidinux1 has joined #yocto
florian_kc has quit [Ping timeout: 265 seconds]
florian has quit [Quit: Ex-Chat]
davidinux1 has quit [Quit: WeeChat 4.3.1]
Starfoxxes has quit [Ping timeout: 252 seconds]
druppy has joined #yocto
davidinux1 has joined #yocto
ehussain has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
davidinux1 has quit [Read error: Connection reset by peer]
sotaoverride has joined #yocto
druppy has quit [Ping timeout: 252 seconds]
Guest60 has quit [Ping timeout: 256 seconds]
Dr_Who has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
mckoan is now known as mckoan|away
jclsn has joined #yocto
davidinux1 has joined #yocto
rfuentess has quit [Ping timeout: 252 seconds]
dgriego has quit [Quit: Bye]
florian_kc has quit [Ping timeout: 255 seconds]
dgriego has joined #yocto
roussinm has joined #yocto
leon-anavi has quit [Quit: Leaving]
Dr_Who has joined #yocto
<roussinm>
Hello, I have a recipe that has about 20 dependencies, and those 20 dependencies are copied to a packagegroup to be installed in a SDK, some of those dependencies are header-only c++ deps, so they have a empty package, but -dev is populated. I was thinking of maybe using .inc file that the recipe and the packagegroup uses, but maybe there is a better way? Also I don't want to install the multiple
<roussinm>
binaries that the recipe installs, only want to share the DEPENDS. It happened a couple times where people added dependencies to the recipe (DEPENDS), but forgot to add the RDEPENDS in the packagroup, so I am trying to consolidate both lists. We are using meta-toolchain-COMPANY to build the sdk.
mattsm has joined #yocto
mattsm has quit [Client Quit]
mattsm has joined #yocto
mattsm has quit [Client Quit]
mattsm has joined #yocto
<mattsm>
is there any support for aarch32 in yocto?
<mattsm>
roussinm: I can build for 32-bit arm for sure, just curious about the right tune or tune_features to generate aarch32 code
<roussinm>
mattsm: Can't you find your cpu in the poky machine includes?
<mattsm>
roussinm: i am on an A55 but I am trying to generate smaller code
<mattsm>
roussinm: so yes the TUNE is there
<roussinm>
mattsm: maybe you can play with the FULL_OPTIMIZATION variable?
<mattsm>
roussinm: yea adding -Os or something there might help but it's still aarch64 ;-)
Vonter has quit [Quit: WeeChat 4.4.3]
<roussinm>
mattsm: ok, so you are using the machine include for cortexa55. You are going to have to create another machine file probably, which will use a 32bit tune, instead of the default 64, like: tune-armv7a
<mattsm>
roussinm: so which tune is for aarch32, that's is what is confusing me ;-)
<usvi>
what is the yocto way of whitespacing here?
druppy has quit [Ping timeout: 248 seconds]
<tgamblin>
rburton: still looking at fixing the numpy reproducibility issue. I've gone so far as to switch from running the sed fixups in do_install:append() to do_compile:append() instead. What I am seeing is that even after I cleaning up any references to TMPDIR in __config__.py entirely, something during do_install() or later injects them again into the version of that file (and the .pyc) that gets deployed...
<tgamblin>
trying to understand where that might be in meson.bbclass or python_mesonpy.bbclass
<tgamblin>
rburton: I'm operating on ${D}${PYTHON_SITEPACKAGES_DIR}/numpy/__config__.py, which I suspect is the wrong one
<rburton>
that should be the right one
<rburton>
check the install log in case something is spitting out errors?
<tgamblin>
hmm. With this current push branch, the __config__.py file doesn't trigger QA, but /usr/lib/python3.13/site-packages/numpy/__pycache__/__config__.cpython-313.pyc still does
<tgamblin>
will do
<tgamblin>
I don't see anything scandalous in the log.do_install file
ptsneves has quit [Ping timeout: 245 seconds]
sotaoverride has quit [Ping timeout: 255 seconds]
sotaoverride has joined #yocto
<tgamblin>
rburton: pushed again to make the sed paths a bit better in do_install:append(). It's really weird to me that the nativepython3 call isn't fixing the issue...
pbiel has quit [Ping timeout: 260 seconds]
<tgamblin>
if I run it manually it definitely corrects the path, but telling the recipe to do so in do_install:append() seems to have no effect
* tgamblin
is going to attribute this to PEBKAC
<tgamblin>
s/corrects the path/corrects the TMPDIR contamination in __config__.cpython-313.pyc/
Kubu_work has quit [Quit: Leaving.]
RP has quit [Quit: Exiting]
RP has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
xmn has quit [Read error: Connection reset by peer]