qschulz has quit [Remote host closed the connection]
mckoan|away has joined #yocto
qschulz has joined #yocto
vd62 has joined #yocto
vd has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
jmiehe has quit [Quit: jmiehe]
dmoseley has quit [Read error: Connection reset by peer]
dmoseley has joined #yocto
nucatus has joined #yocto
nucatus has quit [Ping timeout: 265 seconds]
pgowda_ has joined #yocto
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
amitk has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
nucatus has quit [Remote host closed the connection]
xmn has quit [Ping timeout: 264 seconds]
xmn_ has joined #yocto
nucatus has joined #yocto
alessioigor has joined #yocto
vd626 has joined #yocto
vd62 has quit [Ping timeout: 256 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
ziga_ has joined #yocto
vd62657 has joined #yocto
vd626 has quit [Ping timeout: 256 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
vd62657 has quit [Quit: Client closed]
vd62657 has joined #yocto
vd626576 has joined #yocto
vd62657 has quit [Ping timeout: 256 seconds]
jmiehe has joined #yocto
vd626576 has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
mvlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
jmiehe has quit [Quit: jmiehe]
alessioigor has quit [Quit: alessioigor]
paulg has quit [Ping timeout: 245 seconds]
alessioigor has joined #yocto
mvlad has quit [Quit: Leaving]
mvlad has joined #yocto
<JosefHolzmayrThe>
yo dudX
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
goliath has joined #yocto
<mihai>
yo
zpfvo has joined #yocto
thierryE_ has joined #yocto
xmn_ has quit [Quit: ZZZzzz…]
mvlad_ has joined #yocto
Lihis_ has joined #yocto
agrue_ has joined #yocto
iokill_ has joined #yocto
chrysh_ has joined #yocto
leon-anavi has joined #yocto
zkrx has quit [Killed (NickServ (GHOST command used by zkrx_))]
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
zkrx has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
agrue has quit [Ping timeout: 260 seconds]
thierryE has quit [Ping timeout: 260 seconds]
thierryE_ is now known as thierryE
jaskij[m] has quit [Ping timeout: 260 seconds]
iokill has quit [Ping timeout: 260 seconds]
Lihis has quit [Ping timeout: 260 seconds]
Chaser has quit [Ping timeout: 260 seconds]
mvlad has quit [Ping timeout: 260 seconds]
hpsy[m] has quit [Ping timeout: 260 seconds]
jmlemetayer[m] has quit [Ping timeout: 260 seconds]
chrysh has quit [Ping timeout: 260 seconds]
zpfvo has quit [Ping timeout: 260 seconds]
Lihis_ is now known as Lihis
RobW has joined #yocto
zpfvo has joined #yocto
Chaser has joined #yocto
rcw has quit [Ping timeout: 260 seconds]
jaskij[m] has joined #yocto
zyga-mbp has joined #yocto
jmlemetayer[m] has joined #yocto
<sveinse>
Is it ok to ask rocko questions? I'm trying to backport a python console app (a command which setuptools installs in bin). I can install it to native with mypkg-native, but it seems its not respecting and installing its RDEPENDS_${PN} installed into the native dir. Any ideas?
hpsy[m] has joined #yocto
mbrothers has joined #yocto
<mbrothers>
Good morning! Quick question, my machine name contains a hyphen ('-'), but it shows up as an underscode ('_') in the tmp/work/ directory. For example, when I build packagegroup-core-boot. I think this is due to the MACHINE_ARCH variable substituting hyphens with underscores in bitbake.conf. Am I right? Or do I still have a reference to the old machine name containing an underscore? (It used, wrongly to
<mbrothers>
have an underscore and I am in the process of refactoring that)
<coldspark29[m]>
qschulz: So I managed to verify the kernel with HABv4 using NXP's guide using the HABv4 keys and certificates. I wrote my own script which automates the process. Now my colleague wants me to sign the ramdisk as well. So I have to include it into the FIT. In NXP's guide you manually concatenate the image binaries and then write the pointers into the IVT and CSF. From what I understand `mkimage` should do this automatically, right? I've been
<coldspark29[m]>
trying to write and .its file. When I follow your guide creating the key.dtb and previously generating the keys with openssl, `mkimage` does complete successfully. When I extract the keys and certificates from `IMG1_1_sha256_2048_65537_v3_usr_crt.pem` and `IMG1_1_sha256_2048_65537_v3_usr_key.pem` and try to use them instead, it doesn't work. Any idea why?
gourve_l has quit [Ping timeout: 252 seconds]
florian has joined #yocto
<qschulz>
sveinse: RDEPENDS does not work for native recipes in rocko (I think it's been recently fixed/added)
<qschulz>
mbrothers: dashes in machine names are indeed replaced by underscores. I had this as well and we never had an underscore in the machine name so you're not in a weird situation
<qschulz>
coldspark29[m]: the initramfs is just another image in the fitimage. Note that you should use signatures for both images AND configurations
<sveinse>
qschulz: apparently. Thanks.
<qschulz>
coldspark29[m]: also make sure that your fitimage is not using @1 in image labels in the fit .its file as this is a security issue (it's been replaced with -1 I think? don't remember)
<sveinse>
I'm also struggeling with that the hashbang is ignored #!/very/long/path/to/my/project/recipe-sysroot-native/usr/bin/python-native/python and it tries to execute the script as a shell script
<qschulz>
why do you have that?
<qschulz>
#! /usr/bin/env python3 should be just fine I assume?
<sveinse>
I tries prefixing it with #!/usr/bin/env and the error seems to indicate that there is a path length limitation, so maybe the long hashbang is the problem
<sveinse>
qschulz: This is how setuptools makes console apps, linking to the proper python
<qschulz>
but this shebang is bad since you cannot guarantee that the path on the system is valid for all people using your layer
<sveinse>
The packages aren't installed globally
<coldspark29[m]>
I am not sure if that is the issue, because it works fine with the keys generated by openssl. I think it is about the key formats. When I look at the keys generated by openssl the header says `-----BEGIN ENCRYPTED PRIVATE KEY-----` whereas the ones generated by the NXP tools say `-----BEGIN RSA PRIVATE KEY-----`, both should be rsa encrypted though afaik
<qschulz>
I know, but if it respects the PATH variables and what not, it should get the python from the recipe-sysroot and not from your system
<sveinse>
then setuptools and native is broken on rocko
<sveinse>
Let me check on hardknott
<qschulz>
I wouldn;'t be surprised, it's been abandoned for 3 years already
<qschulz>
coldspark29[m]: boot your U-Boot on a non-secureboot board
<qschulz>
and then run `setenv verify yes` though that should be the default IIRC. Then load the fitimage, if it works, it works :p
<qschulz>
I've never tried to check the resulting fitimage itb manually outside of U-Boot
<coldspark29[m]>
qschulz: I only have one board and it is already closed.
<qschulz>
coldspark29[m]: don't use @1 but -1 instead, security issue
<qschulz>
coldspark29[m]: also use RSA4096, there's no reason to use 2048 nowadays
<coldspark29[m]>
Like `kernel-1` ?
<coldspark29[m]>
It is the keys my colleague used. I cannot change them anymore
<sveinse>
The hashbang on hardknott is #!/usr/bin/env nativepython3 for console apps
<qschulz>
coldspark29[m]: I think so, it's probably in the docs in U-Boot
<qschulz>
coldspark29[m]: are you using the same keys for signing U-Boot and signing the fitimage?
<sveinse>
Hmm, so how do I do this python thing for rocko?
<qschulz>
coldspark29[m]: IIRC you can also sign your configuration nodes
<coldspark29[m]>
qschulz: Yes
<qschulz>
coldspark29[m]: ok, so it is also possible only 2048 is possible
<coldspark29[m]>
qschulz: I don't even know what those are
<qschulz>
coldspark29[m]: if you can easily reflash your board even if secured, then flash your new U-Boot anyway
<qschulz>
and play from there
<qschulz>
sveinse: upgrade :p ?
<sveinse>
In a devshell under rocko, tmp/hostools/python has higher precedence than the python installed in the sysroot. How do I access the right python?
chrysh_ is now known as chrysh
<coldspark29[m]>
Why would I flash my new U-Boot? I want to sign the FIT
<sveinse>
qschulz: I am working on hardknott too, but legacy systems in production in the field are always fun
<coldspark29[m]>
I don't even have a new U-Boot
<qschulz>
coldspark29[m]: where do you have the dtb with the public key stored then?
<qschulz>
or in other words, how does your U-Boot check your fitimage?
<coldspark29[m]>
It is in the HAB
<coldspark29[m]>
I am verifying the Kernel with the HAB
<qschulz>
I'm sorry, that is not part of the process I explained, can't help
<qschulz>
probably vendor specific too
<coldspark29[m]>
It is the NXP way
<coldspark29[m]>
But the signing of the image should be the same
<qschulz>
It's not because it's the NXP way that it's the correct way
<coldspark29[m]>
Both ways create a FIT image
<qschulz>
I did implement secure boot on a imx6 using the process I explained
<qschulz>
It works
<qschulz>
It's following upstream implementation from U-Boot
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<qschulz>
I imagine you're going to need to patch U-Boot to fetch the key another way
<qschulz>
coldspark29[m]: which is a vendor U-Boot
<coldspark29[m]>
If you go to "Authenticating additional boot images"
<sveinse>
I think my conclusion is that the python setuptools for command-line apps in rocko is broken. I'll have to circumvent this upstream
<qschulz>
sveinse: check in the three years of patches, maybe there's something easy to backport
<coldspark29[m]>
Yeah, I was just hoping I could still generate the FIT with mkimage and just replace the keys. Manually signing the image is quite tedious
<coldspark29[m]>
Anyway, thanks I will figure it out somehow.
<qschulz>
coldspark29[m]: I'm not interested in supporting vendor BSPs :) Also, you probably will receive more help on #u-boot than #yocto for U-boot specific questions though they'll probably not care either about vendor processes :)
<qschulz>
good luck
ramprakash[m] has quit [Quit: You have been kicked for being idle]
hpsy has quit [Quit: Client closed]
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
mbrothers has quit [Ping timeout: 260 seconds]
xmn has joined #yocto
rber|res has joined #yocto
hpsy has joined #yocto
Schlumpf has joined #yocto
<Schlumpf>
Hi, I have a newbie question: What are the .lock files in DL_DIR for?
Guest1290 has joined #yocto
Guest1290 has quit [Client Quit]
<kanavin>
abelloni, you dropped the patch that fixes the failure from your build
Guest747474 has joined #yocto
<abelloni>
That's what I was looking at, yes...
<JosefHolzmayrThe>
Schlumpf: i *think* they lock the file being currently downloaded, e.g. "not yet finished/ready"
<kanavin>
abelloni, you can tweak it to say mipsarch, per khem's suggestion
<abelloni>
I'm going to do that
<kanavin>
cheers
<Guest747474>
Hi! How can I adjust INHIBIT_PACKAGE_STRIP variable in a task depends on my own config files?
<JosefHolzmayrThe>
Guest747474: can you try to rephrase/elaborate the specific problem?
<Schlumpf>
JosefHolzmayrThe: that was my first thought, too. But they stay after the download is complete and the .done file is created.
<kanavin>
abelloni, but yes, it was unrelated to network issues. I'm now helping seccomp upstream to address this properly.
<JosefHolzmayrThe>
Schlumpf: well the .lock filename is just application semantics, so it *might* be that they are just not evaluatied anymore if the .done flag file is existent. but really, just guessing.
<Guest747474>
I have a config file, where there is a DBG=[ on | off ] variable. I want to add | delete debug info in packages using INHIBIT_PACKAGE_STRIP depending on this DBG variable in config. How can I do that?
<JosefHolzmayrThe>
Guest747474: that "config file", is that a bitbake config file like your machine/distro conf, or is it something package/application specific?
<Schlumpf>
JosefHolzmayrThe: OK, thanks.
<JosefHolzmayrThe>
Schlumpf: ahve fun. sorry for not having definitive answers.
Guest747474 has quit [Quit: Client closed]
hpsy has quit [Remote host closed the connection]
mseeber has joined #yocto
hpsy has joined #yocto
mranostaj has quit [Quit: Lost terminal]
paulg has joined #yocto
mseeber has quit [Ping timeout: 245 seconds]
zpfvo has quit [Ping timeout: 265 seconds]
Vonter has joined #yocto
ayankuma has left #yocto [WeeChat 1.9.1]
nucatus has quit [Remote host closed the connection]
Vonter has quit [Ping timeout: 258 seconds]
jwillikers has joined #yocto
nucatus has joined #yocto
zpfvo has joined #yocto
nucatus has quit [Ping timeout: 258 seconds]
<gsalazar__>
Hi, I am trying to cross-compile an openssl version with the SDK but keep bumping into an issue where the compiler prefix is being appended twice and therefore it cannot compile
gsalazar__ is now known as gsalazar
<gsalazar>
I keep getting the compiler as `arm-poky-linux-gnueabi-arm-poky-linux-gnueabi-gcc`
<barath>
I'm trying to debug why one machine's clang sstate hash is different from another and thus rebuilds it. I've come to a point where diffsigs tells me that the runtaskdeps for clang/libcxx_git have changed from `binutils/binutils-cross_2.34.bb:do_populate_sysroot clang/libcxx_git.bb:do_install` to `clang/libcxx_git.bb:do_compile pseudo/pseudo_git.bb:do_populate_sysroot:virtual:native`
<barath>
does that make any sense?
<barath>
these seem completely different
<barath>
note, that's the runtaskdeps having changed for the libcxx_git do_install task
<barath>
It makes no sense because I made a mistake :D it helps comparing the correct siginfo files. I guess there's no script for this that already exists
<gsalazar>
mckoan: by going through the bb file for openssl I figured out what I was doing wrong. I should be using the host as the target. Thanks
whuang0389 has quit [Ping timeout: 256 seconds]
argonautx has joined #yocto
mihai has quit [Ping timeout: 264 seconds]
gourve_l has joined #yocto
mihai has joined #yocto
mihai has quit [Client Quit]
mranostaj has joined #yocto
_wmills has joined #yocto
wmills has quit [Ping timeout: 252 seconds]
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
leon-anavi has quit [Ping timeout: 260 seconds]
leon-anavi has joined #yocto
roussinm has joined #yocto
<qschulz>
barath: diffsigs allows to pass a recipe name and task and it'll take the last two siginfo files IIRC
lucaceresoli has quit [Quit: Leaving]
rsalveti has quit [Read error: Connection reset by peer]
thierryE has quit [Ping timeout: 264 seconds]
pgowda_ has quit [Ping timeout: 264 seconds]
<barath>
qschulz: thanks, that usually doesnt help me though when I try to figure out why machine/PC A doesn't reuse the sstate-cache files generated by machine/PC B, since the diffsigs script doesnt easily find the sstate cache files automatically
<barath>
so I usually have to manually find the sigdata/siginfo files from both machines for some recipe I know has differing hashes, then use diffsigs manually on those two files,then repeat until I reach some endpoint
pgowda_ has joined #yocto
rsalveti has joined #yocto
<barath>
the endpoint I reached now though isn't very helpful... it just tells me that `bzip2/bzip2_1.0.8.bb:do_deploy_source_date_epoch:virtual` has changed hashes, and I can't find any sigdata/siginfo files for that one. so I'll have to dig into what can influence exactly that hash, unless someone here can provide spoilers for that
argonautx has quit [Ping timeout: 260 seconds]
thierryE has joined #yocto
tre has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
kiran has quit [Remote host closed the connection]
kiran has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
zyga-mbp has joined #yocto
nucatus has quit [Ping timeout: 258 seconds]
tnovotny has quit [Quit: Leaving]
florian has joined #yocto
nucatus has joined #yocto
gsalazar has quit [Remote host closed the connection]
pgowda_ has quit [Quit: Connection closed for inactivity]
vd has joined #yocto
zpfvo has quit [Remote host closed the connection]
dev1990 has joined #yocto
manuel1985 has quit [Quit: Leaving]
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
imMute has joined #yocto
<imMute>
suppose I am writing a userspace application that needs access to the headers provided by the linux kernel. is there documentation on how to do that? my google-fu is failing me.
argonautx has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<mckoan>
imMute: generate your meta-toolchain, install and use it
<rburton>
or do you mean you're writing a recipe?
<imMute>
I"m writing a recipe for a userspace application, yes.
argonautx has quit [Ping timeout: 260 seconds]
<vd>
is it correct to have INHERIT += "rm_work" in a distro conf?
Vonter has joined #yocto
<mckoan>
vd: usually it is a setting related to the HOST machine therefore would be better in local.conf, but why not
<rburton>
its syntactically valid, yes
<neverpanic>
Usually you'd have it in a local.conf. It shouldn't be necessary to have rm_work for your project to build successfully, so it should be a choice of whether you have enough disk space on the machine you're using to build
<rburton>
what they said :)
<rburton>
there are times you really don't want it, so i wouldn't enforce it
<rburton>
(if you're changing the packaging code, you really don't want rm_work enabled)
<neverpanic>
That being said, I've seen projects where re-using an existing workdir causes breakage or different outcomes (especially when people are liberal with wildcards), in which case it may be the better option to define it for the distro, if fixing the stuff isn't possible.
mckoan is now known as mckoan|away
Vonter has quit [Ping timeout: 260 seconds]
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
gourve_l has quit [Quit: WeeChat 2.3]
<vd>
hum I see. There always gray areas like these when it comes to distros, because OE-Core distros are also build policy configuration. e.g. you can also see things like TCLIBCAPPEND = "" which isn't necessary for the project to build, but most likely "sane defaults"
florian has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
florian_kc has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
leon-anavi has quit [Quit: Leaving]
whuang0389 has joined #yocto
<whuang0389>
does anyone know if xscreensaver works via xwayland?
florian_kc has quit [Ping timeout: 260 seconds]
<jordemort>
i wiped my sstate and now ostree won't build anymore (hardknott, ostree 2021.1)... it's complaining about the libglnx submodule:
<jordemort>
ERROR: mc:netinstall:ostree-2021.1-r0 do_fetch: gitsm: submodule download failed: FetchError Fetcher failure for URL: 'gitsm://gitlab.gnome.org/GNOME/libglnx.git;protocol=https;name=libglnx;subpath=libglnx;bareclone=1;nobranch=1'. Unable to fetch URL from any source.
<jordemort>
```
<jordemort>
```
<jordemort>
but as far as i can tell, the libglnx repo is still there, and still contains that SHA
<jordemort>
git clone ostree ; git submodule init ; git submodule update all works by hand
<rburton>
that looks a lot like the fetcher bug i fixed not long ago
<smurray>
JosefHolzmayrThe: I didn’t think the slirp config allowed inbound connections, but I’m willing to believe I’m wrong
argonautx has quit [Ping timeout: 260 seconds]
tgamblin has quit [Quit: Leaving]
<JosefHolzmayrThe>
smurray: yeah might be possible. i just though i remember some patch in the last year or so that related to it and hoped anybody could remember it too :P