qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
mbulut has quit [Ping timeout: 264 seconds]
pidge has quit [Remote host closed the connection]
davidinux has quit [Ping timeout: 252 seconds]
davidinux has joined #yocto
<khem>
yes
<khem>
abelloni: I see you staged the musl upgrade patch in your master-next branch, but I think you also need to revert the last patch we needed to apply see https://git.yoctoproject.org/poky-contrib/commit/?h=yoe/mut&id=7f3774efc722886833e73cd2b3efdb70f07e72dd
<moto-timo>
khem: well at least one mystery for maturin is pretty obvious
<moto-timo>
khem: so I guess that path was not matching in my `RUSTFLAGS+="--remap-path-prefix=$HOME=/remap-home --remap-path-prefix=$PWD=/remap-pwd"` attempt
<khem>
Hmmm I would say do a build where all build logs are verbose for this and we can have more info to ponder on
<khem>
I think the cc crate might be quite helpful in cross compiling provided we are feeding it right env
<paulg>
I still find myself thinking back to strace with bluetooth 12h later and going WTF?!?
<paulg>
Good to see the crazy patched out.
lthadeus has joined #yocto
amitk has joined #yocto
lthadeus has quit [Ping timeout: 260 seconds]
lthadeus has joined #yocto
<khem>
its needed for decoding AF_BLUETOOTH socket
LocutusOfBorg has quit [Read error: Connection reset by peer]
efeschiyan has quit [Ping timeout: 256 seconds]
<yocton>
khem: paulg: I'd say "debugging AF_BLUETOOTH sockets with strace" is a rare enough event to prevent it being enabled by default no? :)
<khem>
yes perhaps until someone comes with a need next day we disable it
alessioigor has quit [Read error: Connection reset by peer]
alessioigor_ has joined #yocto
efeschiyan has joined #yocto
LocutusOfBorg has joined #yocto
rob_w has joined #yocto
mvlad has joined #yocto
LocutusOfBorg has quit [Read error: Connection reset by peer]
goliath has joined #yocto
geoffhp has quit [Quit: Leaving]
efeschiyan has quit [Read error: Connection reset by peer]
lthadeus has quit [Ping timeout: 246 seconds]
LocutusOfBorg has joined #yocto
efeschiyan has joined #yocto
grma has joined #yocto
belsirk has joined #yocto
rfuentess has quit [Ping timeout: 268 seconds]
mckoan|away is now known as mckoan
radanter has joined #yocto
Tyaku has joined #yocto
<Tyaku>
Hi, I have a dummy question about licensing. When I speak around me about licencing issues, they tell me that there is no problem if the image is encrypted. (Off course..) So I have a big question: Is it legal to encrypt a Linux firmware update image ?
<Tyaku>
I don't know what to say to people around me, when I speak about licence and what we must do. They are good to find "alternatives".
<jdiez>
Tyaku: licenses don't often restrict whether you can encrypt the software or not, it's usually about whether you are allowed to redistribute source/binaries and attribution
mbulut has joined #yocto
<Tyaku>
jdiez: What people say around me: If the firmware is encrypted, nobody know what is inside.
<jdiez>
ah, that sounds like trying to bypass license requirements
<Tyaku>
So.. No licensing obligations. I don't know what to say to this.
<jdiez>
I would strongly advise against that. first, it's a huge liability. and second, even if you distribute the image encrypted, it has to be decrypted by the device at some point
belsirk has quit [Ping timeout: 268 seconds]
<Tyaku>
Thanks
philmd has left #yocto [#yocto]
prabhakarlad has joined #yocto
prabhakar has joined #yocto
<LetoThe2nd>
Tyaku: thats complete bollocks. licensing applies to the content, not to the delivery form.
<LetoThe2nd>
Tyaku: in fact encryption will make legal life even harder, because if you are spotted shipping gplv3 stuff inside the encrypted thing, then you can be forced to provide a way to the end user to update it nonetheless, which means setting up a full process to hand out keys etc.
lthadeus has joined #yocto
<LetoThe2nd>
Tyaku: in a nutshell, feel free to encrypt or not, but it won't change anything about the license of the software. it just makes your life harder. if you care about actual improvement, then look into secure boot, image verifation/signing, OTA (yeah, really!), and eventually means to encrypt some very specific IP on your device. nobody cares about the glibc in there.
xmn has quit [Ping timeout: 276 seconds]
Saur has quit [Ping timeout: 245 seconds]
leon-anavi has joined #yocto
<Tyaku>
Thanks LetoThe2nd
<mcfrisk>
anyone happen to know how to add empty space to wic image, empty space for a partition which systemd repart will create on first boot?
manuel_ has joined #yocto
<mcfrisk>
ah, rtf in poky/scripts/lib/wic/plugins/source/empty.py and "--source empty"
Saur has joined #yocto
<Tyaku>
mcfrisk: I remember that long time ago I ask here how to create a "data" partition of fixed size without FS so that when it is flashed it will not erase the partition. The solution that someone say was to set "fstype=none" in the wic.
<mcfrisk>
Tyaku: thanks, will try that if the "empty" plugin doesn't work
<Tyaku>
Like this the space for the partition is "present", but when the WIC image is flashed it will not "erase" the content of this partition, Then at runtime create the filesystem if not present.
<jdiez>
mcfrisk: how are you configuring systemd to repartition on first boot? (I'm assuming to extend it to the available size)
<mcfrisk>
sadly neither "empty" plugin nor "fstype=none". I can extend the .wic image with "qemu-img resize path_to.wic +2G" and then systemd sees the empty space. just haven't figured out how to do the same with wic configs
florian_kc has joined #yocto
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
Saur_Home32 has quit [Client Quit]
Saur_Home32 has joined #yocto
<abelloni>
khem: the patch is neeed for the elfutils upgrade
<abelloni>
I don't have a musl upgrade because their git repo is dead
<landgraf>
Tyaku: it was my suggestion for different usecase, not the one mcfrisk wants to achieve.
<landgraf>
Tyaku: "none" will create partition but not FS on it. systemd will not be able to extend existing partition in that case.
lthadeus has quit [Remote host closed the connection]
lthadeus has joined #yocto
linfax has quit [Ping timeout: 256 seconds]
yannd has joined #yocto
speeder has quit [Remote host closed the connection]
Minvera has quit [Ping timeout: 256 seconds]
mckoan is now known as mckoan|away
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
alessioigor_ has quit [Quit: alessioigor_]
alessioigor has joined #yocto
Guest97 has joined #yocto
Rich_1234 has quit [Quit: Connection closed]
Guest97 is now known as Rich_1234
camus has quit [Remote host closed the connection]
Kubu_work has joined #yocto
florian_kc has quit [Ping timeout: 256 seconds]
florian has quit [Ping timeout: 264 seconds]
amitk has quit [Ping timeout: 276 seconds]
amitk has joined #yocto
amitk has quit [Ping timeout: 276 seconds]
amitk has joined #yocto
jmd has joined #yocto
lthadeus has quit [Remote host closed the connection]
florian_kc has joined #yocto
florian has joined #yocto
Kubu_work has quit [Quit: Leaving.]
lthadeus has joined #yocto
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
sugarbeet has quit [Ping timeout: 240 seconds]
prabhakarlad has quit [Quit: Client closed]
sugarbeet has joined #yocto
lexano has quit [Ping timeout: 255 seconds]
Dane86 has joined #yocto
<Dane86>
In one of my recipes there is a line like
<Dane86>
Basically I'm trying to include dracut in my build, but just can't figure out how to do it
<smurray>
yeah, it's not going to show up in the image recipe, it'd be whatever specific recipe it applies to
<Dane86>
Added EXTRA_IMAGEDEPENDS += "dracut" to the image recipe, which seems to do something because dracut gets copied to the work directory, but I'm not seeing the dracut dir in the resulting initramfs
<Dane86>
So basically looks like do_install in the dracut recipe is not getting executed
<Dane86>
I'm not sure how yocto differentiates between initramfs and main rootfs with respect to do_install either?
alperak has quit [Quit: Client closed]
pidge has joined #yocto
joekale has joined #yocto
pvogelaar has joined #yocto
lthadeus has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<pvogelaar>
Hi all,
<pvogelaar>
I am having the problem that I want to apply kernel patches dependent on the image or a recipe. e.g. if image-test-123 is the currently build image a certain patch should be applied to the kernel. I know how to do it with different MACHINEs but is there also a way to do it based on the image.
<pvogelaar>
Thanks
Dane86 has quit [Quit: Client closed]
Minvera has joined #yocto
rob_w has quit [Remote host closed the connection]
xmn has joined #yocto
LocutusOfBorg has quit [Ping timeout: 246 seconds]
<rburton>
pvogelaar: there is no way to do that based on the image
<ablu>
pvogelaar: The kernel build cannot get data from the image. It has to be a machine override, distro config tweak or something similar. Probably the best solution is to make the feature configurable at runtime in some way and do the configuration from your image.
<rburton>
pvogelaar: because you can build a kernel without building an image. what configuration then? you can build two images at once but we built the kernel once, what configuration then?
<rburton>
if its a driver then make it a module and you can install it or not
alperak has joined #yocto
alperak has quit [Client Quit]
<pvogelaar>
Thx, I see the problem.
rfuentess has joined #yocto
LocutusOfBorg has joined #yocto
goliath has quit [Quit: SIGSEGV]
Xagen has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
xmn has quit [Ping timeout: 246 seconds]
xmn has joined #yocto
mvlad has quit [Remote host closed the connection]
rfuentess has quit [Ping timeout: 245 seconds]
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
amitk_ has joined #yocto
xmn has quit [Ping timeout: 268 seconds]
xmn has joined #yocto
pvogelaar has quit [Quit: Client closed]
prabhakarlad has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
<khem>
abelloni: this basename removal in musl is unearthing problems in apps in a bunch of them so there will be slew of patches before we apply musl upgrade
<rburton>
thanks musl!
mbulut has quit [Ping timeout: 255 seconds]
mvlad has joined #yocto
<khem>
yeah something musl does have a habit of just opening the lid over stinking stuff it maybe annoying
vladest has quit [Remote host closed the connection]
leon-anavi has quit [Quit: Leaving]
Tyaku has quit [Quit: Lost terminal]
Chaser has quit [Quit: Chaser]
<abelloni>
khem: I'm not sure I get you, you say the removal is an issue but I have patch adding them that you want me to drop
<abelloni>
or you mean I need to drop it if I take the musl upgrade?
<khem>
no, its an issue but it was hidden so far because on glibc everyone indrectly used GNU version of basename and not posix unless apps were aware of and this kept working in some cases ok in some cases perhaps buggy expectations
<khem>
musl change now points it out, it says if you want to use gnu version of basename then say so
Chaser has joined #yocto
vladest has joined #yocto
prabhakarlad has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
radanter has quit [Remote host closed the connection]
Vonter has quit [Ping timeout: 255 seconds]
Vonter has joined #yocto
Estrella_ has quit [Ping timeout: 256 seconds]
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
florian_kc has joined #yocto
Omax has quit [Ping timeout: 256 seconds]
Omax has joined #yocto
goliath has joined #yocto
Chaser has quit [Quit: Chaser]
florian_kc has quit [Ping timeout: 276 seconds]
goliath has quit [Quit: SIGSEGV]
goliath has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
florian_kc has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
amitk_ has quit [Ping timeout: 256 seconds]
amitk has quit [Ping timeout: 276 seconds]
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
roussinm has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
lexano has quit [Ping timeout: 255 seconds]
<roussinm>
khem: I found the culprit, since we upgrade from zeus to kirkstone, X86 was not part of the LLVM_TARGETS_TO_BUILD variable anymore. We were overriding it to only target the target arch.
<khem>
roussinm: hmm I see
<roussinm>
so when I started the build for nativesdk-clang, x86 was not in the avaible triple.
<khem>
right, usually I keep all of them on
goliath has quit [Quit: SIGSEGV]
prabhakarlad has joined #yocto
xmn has quit [Quit: ZZZzzz…]
xmn has joined #yocto
<roussinm>
khem: if I disable LLDB, because it cannot build with swig version (4.0.2) on kirkstone, the installation steps fails. It requires lldb-tblgen in the class-native override. Is that something you tried?
<khem>
hmm lldb is always enabled
<khem>
my testing enables all that llvm/clang brings to table
<khem>
and lldb is definitely has nicer UI
jmd has quit [Remote host closed the connection]
<roussinm>
khem: probably, but I have a compiler error during lldb compilation, I tried updateing swig to 4.1.1 but no luck. So my "quickest" fix was to remove lldb.
alessioigor has quit [Quit: alessioigor]
Dr_Who has quit [Read error: Connection reset by peer]
<kanavin>
Inappropriate is the new Pending
<kanavin>
grrr
<kanavin>
two patches of that kind today
<kanavin>
we should probably discourage 'oe core specific' as the reason, and demand better reasons
<RP>
kanavin: we were always going to struggle with this, just have to push back a bit
<kanavin>
RP: I have meanwhile fixed a ton of corner cases in the printdiff and cdn tests, patches are on the way (tomorrow if no more such cases show up)
<RP>
kanavin: I should have a look at your branch :) thanks
<RP>
kanavin: I guess we knew there were some issues buried in there
<kanavin>
RP: I admit I'm always a bit apprehensive when you 'look at branch' ahead of official submission :)
<roussinm>
khem: the compile error is that: git/lldb/bindings/interfaces.swig:5: Error: Macro '__STDC_LIMIT_MACROS' redefined. Have you seen that before?
mvlad has quit [Remote host closed the connection]
<RP>
kanavin: and I'm not sure https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/fix-printdiff&id=b40342fb6a7db9a05947db88ab5928c8a51bb48c is right. "bitbake wouldn't care if regular dependencies are absent" is not true, hence my previous comments on the depvalid function
<kanavin>
RP: I wasn't sure if rqexe needs that and so moved both
<RP>
kanavin: it may be better just to create the rqexe in duplicate in the printdiff branch for now
<RP>
I hate those progress pieces, complete unmaintainable mess but I was told others would help look after them :/
<RP>
kanavin: and sorry, I don't mean to make you apprehensive, I'm just trying to help. This is really tricky stuff
<kanavin>
RP: the previous comment on the depvalid function pointed out that if something can be fulfilled from sstate, we can't stop there, and need to check if dependencies of the setscene task can be fulfilled too - the new version checks that via looking at self.rqexe.sqdata.sq_deps[t]. I have confirmed that it works properly if e.g. one of the populate_sysroot_setscene things is missing (i.e. build python3-native, then delete
<kanavin>
openssl-native from sstate - printdiff will then report that is missing, and previously it didn't)
<RP>
kanavin: ok, I went more off the commit message than the code change there
<RP>
kanavin: the interesting bit is that some dependencies *can* be skipped
<RP>
e.g. do_package for a do_package_write_rpm from sstate
<RP>
if you are always assuming it can't be skipped, we're ok to go in with the patch as it is probably an improvement on what we have
<RP>
I'm just surprised you can get away without using depvalid() and that is probably because you're not accounting for the ones which can be skipped
pvogelaar has quit [Quit: Client closed]
<kanavin>
RP: that was somewhat tongue in cheek, but I would keep in mind it's 22:39 where I am :) so I would try to avoid opening a 'full review' round if possible now :)
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
<RP>
kanavin: no problem and I'm not saying you need to read these now. I just had a few minutes and you'd mentioned it was all close
<RP>
kanavin: we can just leave things, I just can't promise I'll be able to review promptly
<yudjinn>
hey, hitting an issue with the latest of poky:kirkstone where cpio wont build; I dont have any bbappends hitting this, either:
<yudjinn>
```stdout: Applying patch 0001-Wrong-CRC-with-ASCII-CRC-for-large-files.patch patching file src/copyout.c Hunk #1 FAILED at 34. 1 out of 1 hunk FAILED -- rejects in file src/copyout.c Patch 0001-Wrong-CRC-with-ASCII-CRC-for-large-files.patch does not apply (enforce with -f)```
Guest55 has joined #yocto
goliath has joined #yocto
<RP>
kanavin: I did just see that base-files cdn failure and I can guess the issue there if you want me to and that would be helpful. Or I can keep quiet :)
<kanavin>
RP: thanks, I know exactly what the issue is
<RP>
kanavin: fair enough :)
<kanavin>
that was run as sstate population task, then I added extra things to the cdn test and pushed to the branch, invalidating base-files
<kanavin>
then the cdn test was run against that new revision, failing to find base-files
<RP>
right, it is keyed to the head revision for better or worse :/
<kanavin>
also I messed up the parsing logic of bitbake output, hence those millions of missing item lines, also now fixed
<RP>
kanavin: part of the reason I'm looking at some of this is because I know I'll need multiple review passes over it to get the review right too. This gives my mind time to think about things
<kanavin>
RP: I've retriggered the sstate population, and will run the test then, but it's kinda time to fall into bed as well
<RP>
kanavin: no problem, I didn't mean to cause any issue!
<RP>
kanavin: more just being too eager to get these issues resolved!
* RP
should go and write some reports instead. Much less interesting :/
<kanavin>
RP: yes, me too. Fixing the corner issues has been going on longer than I'd want, but on the other hand I've learned a fair bit about rarely visited corners of oe/bitbake.
sotaoverride is now known as Guest374
Guest2745 is now known as sotaoverride
<RP>
kanavin: having someone else with some knowledge there is helpful
<RP>
I think a second perspective on some of this is also helpful
<kanavin>
RP: yes I get that you want to 'upload' the changes in your head and process them in background :) I came up with at least two good ideas for the fixes today while walking round the lake.
<RP>
I'd not necessarily have done some of the things you have too (which is good)
<RP>
kanavin: exactly
<kanavin>
(one was how to avoid multiple costly glob.glob lookups in the massive nfs-mounted sstate tree, the other was adding the local cache check in addition to cdn cache check, so we can diff them if there are fails)
<kanavin>
the line between work and leisure can be blurred at times...
<RP>
kanavin: having dreams (nightmares?) about libtool is disturbing!
<kanavin>
RP: I also left a one star review for the coffee place we visited. The way they aggressively demanded tips after taking cash and before giving change was not ok.
<kanavin>
RP: thankfully this almost never happens in berlin... maybe second time in 5 years.
<kanavin>
but then I do carefully avoid tourist traps :)
<RP>
kanavin: I wouldn't like that and it sounds like it was justified. Tipping is relatively unusual here
<kanavin>
RP: tipping is not expected here either and I rarely if ever leave any, but here they actually took a 20 euro note on a 13 euro bill, then asked how much they should keep. It's just not ok: the right thing to do is to give full change without questions, then let me leave some discreetly should I so decide.
<kanavin>
RP: ok the new mirror test is running. let's see if it explodes in previously unseen ways, but if it does, I leave it for tomorrow :)
<RP>
kanavin: definitely for tomorrow!
<moto-timo>
khem: glad you highlighted the 'cc' crate, because I think the Makefile is not used at all... all the CC params are being passed in from the build.rs
* moto-timo
tosses another match in the dumpster full of gasoline
<moto-timo>
bzip2 upstream had some nice improvements, but seems to have stalled: https://gitlab.com/bzip2