<r00tkit>
Agree. What concerns me is that, I can perhaps control recipes written by customers, but it is not possible to control external recipes they use. Like tomorrow if meta-oe does not upgrade their Poco recipe, and a new utility I need is available in Poco upstream, it becomes a big headache- unless cust agrees to re-write a custom recipe.
Chocky has quit [Quit: Leaving.]
Chocky has joined #yocto
r00tkit has quit [Quit: Client closed]
Chocky has quit [Quit: Leaving.]
Chocky has joined #yocto
nerdboy has quit [Ping timeout: 255 seconds]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
lexano has quit [Ping timeout: 255 seconds]
<vmeson>
FYI: valgrind 3.22.0 was released last week: I have an update that patches and builds for qx86 ... I need to audit the patches, run ptest, check musl and more . Fun!
qschulz has quit [Read error: Connection reset by peer]
qschulz has joined #yocto
Chocky has quit [Quit: Leaving.]
Chocky has joined #yocto
Chocky has quit [Ping timeout: 264 seconds]
Chocky1 has joined #yocto
Chocky1 has quit [Read error: Connection reset by peer]
Chocky1 has joined #yocto
davidinux has quit [Ping timeout: 264 seconds]
davidinux has joined #yocto
Chocky1 has quit [Quit: Leaving.]
Chocky has joined #yocto
starblue has quit [Ping timeout: 258 seconds]
starblue has joined #yocto
tnovotny has quit [Ping timeout: 252 seconds]
ablu has quit [Ping timeout: 264 seconds]
ablu has joined #yocto
kanavin has quit [Remote host closed the connection]
kanavin has joined #yocto
rber|res has quit [Ping timeout: 264 seconds]
rber|res has joined #yocto
Vonter has joined #yocto
GParker_ has joined #yocto
geoffhp has quit [Ping timeout: 258 seconds]
xmn has quit [Ping timeout: 240 seconds]
xmn has joined #yocto
arisut has quit [Server closed connection]
arisut has joined #yocto
xmn has quit [Ping timeout: 240 seconds]
jclsn has quit [Ping timeout: 245 seconds]
jclsn has joined #yocto
GParker__ has joined #yocto
sotaover1ide has quit [Ping timeout: 240 seconds]
GParker_ has quit [Ping timeout: 255 seconds]
khem has joined #yocto
GParker_ has joined #yocto
GParker__ has quit [Ping timeout: 240 seconds]
ptsneves has quit [Ping timeout: 260 seconds]
Chaser has joined #yocto
sgw has joined #yocto
sgw has quit [Quit: Leaving.]
GParker__ has joined #yocto
GParker_ has quit [Ping timeout: 252 seconds]
sgw has joined #yocto
alessioigor has joined #yocto
Vonter has quit [Ping timeout: 272 seconds]
<warthog9>
I'm assuming it's just me, but did pipermail links all just break badly within the last week or so?
xmn has joined #yocto
sgw has quit [Quit: Leaving.]
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
rob_w has joined #yocto
linfax has joined #yocto
GNUmoon has quit [*.net *.split]
Kubu_work has joined #yocto
frieder has joined #yocto
xmn has quit [Ping timeout: 252 seconds]
leon-anavi has joined #yocto
Daanct12 has joined #yocto
zpfvo has joined #yocto
danlor has joined #yocto
rfuentess has joined #yocto
mvlad has joined #yocto
Daanct12 has quit [Ping timeout: 252 seconds]
Daanct12 has joined #yocto
<LetoThe2nd>
yo dudX
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
khem has quit [Quit: Connection closed for inactivity]
prabhakarlad has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 258 seconds]
<LetoThe2nd>
RP: YAY! I FOUND THE HOLE PUNCH!
<Rich_1234>
at the dentist?
<LetoThe2nd>
Rich_1234: under a stack of sanding paper, actually.
<Rich_1234>
:)
<LetoThe2nd>
Rich_1234: I'll post about the context later today :-)
<RP>
LetoThe2nd: Excellent! What is missing now instead? :)
<LetoThe2nd>
RP: the countersink. but in that case i definitely know where it is, just need to pick it up later.
egueli has joined #yocto
<egueli>
Hi everyone. I started using devtool to manage my kernel source & patches.
<egueli>
I'm testing the use case of extracting the sources with "devtool modify", then upgrade the kernel i.e. use a different upstream commit.
<egueli>
In my kernel .bbappend file I added a SRC="<hash>" line, then i ran "devtool sync linux-qoriq $workspace_path" thinking that it would update/rebase the sources repo in the workspace directory, but instead I get an error like "fatal: Refusing to fetch into current branch refs/heads/devtool of non-bare repository" preceded by a warning "No source
<egueli>
unpacked to S - either the linux-qoriq recipe doesn't use any source or the correct source directory could not be determined".
<egueli>
I'm a bit lost, what does that actually mean and what the fix could be? Or maybe I completely misunderstood how devtool works :)
olani has quit [Server closed connection]
olani has joined #yocto
rber|res has quit [Remote host closed the connection]
ptsneves has joined #yocto
ptsneves has quit [Client Quit]
ptsneves has joined #yocto
rfuentess has quit [Remote host closed the connection]
tnovotny has joined #yocto
Dracos-Carazza has quit [Server closed connection]
<LetoThe2nd>
RP: things one needs to make holes for.
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
egueli has quit [Quit: Client closed]
vladest has quit [Ping timeout: 264 seconds]
<Rich_1234>
LetoThe2nd nice :) beefy holepuncher
prabhakarlad has joined #yocto
dmoseley has quit [Ping timeout: 240 seconds]
dmoseley has joined #yocto
starblue has quit [Ping timeout: 255 seconds]
<kanavin>
RP: I've re-enabled cdn mirror test in a local branch and queued a standalone builder for it to see what happens
danlor has quit [Ping timeout: 250 seconds]
vladest has joined #yocto
starblue has joined #yocto
GParker__ has joined #yocto
GParker_ has quit [Ping timeout: 240 seconds]
<RP>
kanavin: ok, I'm still struggling with the others I was trying to fix :(
<RP>
kanavin: there is something wrong and this may be what we were trying to fix with the work, hard to tell :/
<kanavin>
RP: yes, I've just seen :-( I'm totally available to help if you can think of something.
<RP>
kanavin: I'm open to ideas on how to debug it, I'm at a bit of a loss atm :/
<RP>
kanavin: perhaps focus on the CDN one and we divide and conquer? :)
frosteyes has quit [Server closed connection]
frosteyes has joined #yocto
<kanavin>
RP: I think so. I plan to run the test twice, see what verdict it gives, and take it from there. It's running the x86_64/arm64 builds on top of fresh master now, and I see things are getting rebuilt. The second run should be 100% from previous sstate. I'm also considering adding a 'fail' to sstate populating tasks on purpose, so that they are preserved on the AB for inspection.
<RP>
kanavin: sounds good. I'm pausing the slow 2004 arm worker and going to live debug one of the failures in my patch. See if I can learn why it doesn;t work
<RP>
kanavin: FWIW the "Can't find a task we're supposed to have written out?" message is a bug in runqueue and easily fixed
<kanavin>
RP: right, but doesn't that fix the overall fail?
<RP>
kanavin: no, just fixes the debug output when it fails
mattsm has quit [Server closed connection]
mattsm has joined #yocto
<RP>
kanavin: I think I had the right theory but runall isn't enough as it "masks" deploy_source_date_epoch
amitk_ has quit [Quit: leaving]
<RP>
kanavin: I can reduce the bug down nicely. "bitbake core-image-minimal; bitbake quilt-native -c cleansstate; bitbake core-image-minimal --runall deploy_source_date_epoch" and then wonder why quilt-native do_deploy_source_date_epoch doesn't exist
Chocky has quit [Quit: Leaving.]
Chocky has joined #yocto
<kanavin>
RP: cool, this looks like feasible to track down
<RP>
kanavin: I'd also note the list of things breaking looks very similar to SSTATE_EXCLUDEDEPS_SYSROOT
egueli has joined #yocto
amitk has joined #yocto
<egueli>
How do I keep the channel open indefinitely? I see was disconnected after being ~1h away. Or, how can I get the chat messages before I (re-)join?
<svuorela>
egueli: hexchat, irssi, ... something you run in screen(1) on a remote machine.
<kanavin>
which requires having a remote machine
<svuorela>
the technology underneath this chatplatform is called "IRC" "internet relay chat"
<kanavin>
hexchat is graphical and won't run in a console I think
<egueli>
I was an avid mIRC user ~20 years ago, I guess it's time to pick it up again :)
egueli is now known as egueli-web
egueli has joined #yocto
<egueli>
so I'd just keep the app open to have all messages
<svuorela>
yep.
<svuorela>
Conceptually not much has changen with irc in those 20 years ...
<egueli>
😊 <-- what about emojis? I see a boxed question mark...
<egueli>
oh it's only in the prompt text.
<wmills>
rburton: FYI: Yesterday I ran stock 6.5.10 defconfig on kv260. I get UART and mmc no ethernet,usb,i2c,spi, etc. I will work on getting trimmed zynqmp-extras.cfg sometime this week.
egueli is now known as egueli-AV
<RP>
kanavin: looks like we've also deleted siginfo files when the sstate file still exists on the sstate mirror
danlor has joined #yocto
davidinux has quit [Ping timeout: 264 seconds]
lexano has joined #yocto
davidinux has joined #yocto
<egueli-AV>
I wonder if anyone replied to my message, as I was disconnected for ~1h. I'll copypaste it here
<egueli-AV>
Hi everyone. I started using devtool to manage my kernel source & patches.
<egueli-AV>
In my kernel .bbappend file I added a SRC="<hash>" line, then i ran "devtool sync linux-qoriq $workspace_path" thinking that it would update/rebase the sources repo in the workspace directory, but instead I get an error like "fatal: Refusing to fetch into current branch refs/heads/devtool of non-bare repository" preceded by a warning "No source unpacked to S - either the linux-qoriq recipe
<egueli-AV>
I'm testing the use case of extracting the sources with "devtool modify", then upgrade the kernel i.e. use a different upstream commit.
<egueli-AV>
doesn't use any source or the correct source directory could not be determined".
<egueli-AV>
I'm a bit lost, what does that actually mean and what the fix could be? Or maybe I completely misunderstood how devtool works 😀
egueli-web has quit [Quit: Client closed]
<kanavin>
RP: I was wondering if I should review how sstate management works
zpfvo has quit [Ping timeout: 260 seconds]
leon-anavi has quit [Quit: Leaving]
leon-anavi has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.1.1]
<RP>
kanavin: probably, it is a question of one step at a time. I think this issue is due to a cascade of other previous issues. I'm trying to see if I can get the state where it works, then we can gofomr there
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<RP>
hmm, still breaks after that tweak :/
zpfvo has joined #yocto
ptsneves has quit [Quit: ptsneves]
ptsneves has joined #yocto
Chaser has quit [Ping timeout: 240 seconds]
Chaser has joined #yocto
gls_ has joined #yocto
gls_ has quit [Client Quit]
gls_ has joined #yocto
gls_ has left #yocto [#yocto]
gls_ has joined #yocto
gls_ has left #yocto [#yocto]
mros has joined #yocto
<jclsn>
Anyone here built optee with the custom TA_PUBLIC_KEY before? I tried prepending it to the oe_runmake call, but it doesn't seem to cut it
<jclsn>
Docs say TA_PUBLIC_KEY=/path/to/public_key.pem make all
<jclsn>
In the recipe I used TA_PUBLIC_KEY=${WORKDIR}/rsa2048_pub.pem oe_runmake -C ${S} all
<jclsn>
Does oe_runmake not work this way?
<jclsn>
Ah guess I have to add it to EXTRA_OEMAKE
Minvera has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
vladest has quit [Remote host closed the connection]
davidinux has joined #yocto
Xywzel has joined #yocto
sakman has quit [Quit: Leaving]
rob_w has quit [Ping timeout: 258 seconds]
<Xywzel>
Anyone succesfully made a recipe for systemd mount unit, that has "-" in its mount point? Systemd requires mount unit filename to match with mount point, with '/' replaced with '-' and '-' replaced c-style escape sequence "\x2d". And bitbake doesn't seem to like \ in file names.
michaelo has quit [Server closed connection]
michaelo has joined #yocto
<neverpanic>
Xywzel: Yes, give me a second to look up the solution.
<neverpanic>
Xywzel: var-mnt-grafana\x2ddb.mount
<neverpanic>
(that's for /var/mnt/grafana-db, in case it isn't obvious)
<neverpanic>
Just add more backslashes until it works
<Xywzel>
Okey, so that everywhere from filenames to install instructions and package names for SYSTEMD_PACKAGES variables
chep` has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
xmn has joined #yocto
<neverpanic>
actually, I misread your original question. I never packaged this in bitbake, so maybe it is in fact broken.
ctraven has joined #yocto
sotaoverride has quit [Killed (tantalum.libera.chat (Nickname regained by services))]
ctraven is now known as sotaoverride
sotaover1ide has joined #yocto
<Xywzel>
Yeah, my problem is mostly that the bitbake complains about failing post install step if I rename the files, and if I have the files with \ in name, it seems like some steps read it as it is and others read it as escaped value that needs processing, and then don't find correct files
<rburton>
sounds like a bug...
lexano has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
danlor has quit [Ping timeout: 250 seconds]
vladest has joined #yocto
pabigot has quit [Remote host closed the connection]
prabhakar has joined #yocto
pabigot has joined #yocto
Xagen has joined #yocto
lexano has joined #yocto
Guest8 has joined #yocto
tnovotny has quit [Remote host closed the connection]
<Guest8>
Hello, I am stuck with recipe that has flatbuffers (and flatc) as dependency, flatc is not found when I build the recipe. Recipe is for amd64 qemu. Using mickledore branch.
<Guest8>
Anyone can give a hint? My DEPENDS += "cppzmq flatbuffers flatbuffers-compiler"
<Guest8>
also getting this error: ERROR: Nothing PROVIDES 'flatbuffers-compiler'
sakoman has quit [Ping timeout: 245 seconds]
<JaMa>
Guest8: you need flatbuffers-native
<Guest8>
ok works now, thank you JaMa!
GParker_ has joined #yocto
<JPEW>
RP: I was thinking: buildtools-tarball can probably get away with only having python3-websockets and not sqlalchemy, since you wouldn't run a server that uses sqlalchemy when building (the auto server uses the internal sqlite)
GParker__ has quit [Ping timeout: 240 seconds]
<RP>
JPEW: that would make sense. Does python3-websockets have dependencies not in core?
sakoman has joined #yocto
* JPEW
checks
<JPEW>
No, it just relies on core python
Starfoxxes has quit [Ping timeout: 240 seconds]
<jclsn>
What is wrong about this shell script in a bitbake recipe? http://ix.io/4KZL
GParker__ has joined #yocto
<jclsn>
It works perfectly fine when I run the script on my host
<JPEW>
is declare -a a bashism?
<JPEW>
Also, you need to use $path instead of ${path} because ${path} is expanded as a bitbake variable
<RP>
JPEW: that is probably fair to add to our various prerequisites then
<JPEW>
jclsn: same with uuid, et al
GParker_ has quit [Ping timeout: 255 seconds]
<JPEW>
RP: OK
leon-anavi has quit [Quit: Leaving]
<jclsn>
JPEW: Not sure. It works with bash though
<JPEW>
I would avoid it
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JPEW>
I don't see any reason you need to do it that way anyway, `for i in $(find ...); do` should just as well
<JaMa>
jclsn: install checkbashisms to your host OS
<JaMa>
possible bashism in sign.sh line 2 (declare): declare -a paths=( "$(find ${WORKDIR} -name "*.stripped.elf")" )
<jclsn>
What is a bashism? Isn't his bash?
<jclsn>
*this
<jclsn>
Is it dash?
<JaMa>
it can be dash on ubuntu systems
<JPEW>
jclsn: Bash extends the standard sh to allow more advanced things, colloquially called "bashisms". If you want your script to run in non-bash shells (like bitbake tasks), you shouldn't use bashisms
<kanavin>
RP: I've run the cdn mirror test a few times now, and the first outcome is that something is flaky: objects are reported as missing, and then in the next run they aren't. Hashes remain stable, and I've checked via wget that they are missing on the cdn (at least a few times), but this doesn't completely rule out cdn being non-deterministic.
<JaMa>
bitbake uses /bin/sh which might be bash or dash
<kanavin>
RP: so the plan is to add even more debugging to the test, and see what exactly is being queried from CDN and what the response is.
Starfoxxes has joined #yocto
<jclsn>
JPEW: Yeah, seems that dash does not support arrays at all
<kanavin>
RP: I'm also down with a fever now, will test for covid :-/
<RP>
kanavin: ouch, sorry to hear that :(
<JPEW>
jclsn: Even if it did, you should avoid bashisms in your tasks for maximum compatability
<RP>
kanavin: there may be some propagation time on the CDN, I wonder if that is an issue? Do we know how long we waited for the availability check?
<jclsn>
JPEW: Got it, thank you
<kanavin>
RP: the bizarre part is that objects seem to appear then disappear then appear again (or at least are reported as such - I need to get to the output of wget to rule out possibilities). I checked that in the /srv/... cache they're not present either.
<kanavin>
RP: you can check the top few executions to see it https://autobuilder.yoctoproject.org/typhoon/#/builders/158 - the unstable items are qemuarm64's core-image-sato-sdk:do_create_runtime_spdx and qemux86_64/'s core-image-full-cmdline:do_create_runtime_spdx
<kanavin>
RP: and now I'll be afk for a bit
lexano has quit [Ping timeout: 258 seconds]
<jclsn>
Think I got it now, but bitbake is missing base64. Is there a way to include this?
Xagen has joined #yocto
khem has joined #yocto
<jclsn>
inherit coreutils or something?
<JaMa>
coreutils-native in DEPENDS
<jclsn>
Ah thanks
prabhakarlad has quit [Quit: Client closed]
Guest8 has quit [Quit: Client closed]
<JaMa>
or rather coreutils-native:do_populate_sysroot in do_sign[depends] if it's in the separate task you shared before
lexano has joined #yocto
florian_kc has joined #yocto
Kubu_work has quit [Quit: Leaving.]
linfax has quit [Ping timeout: 240 seconds]
tnovotny has joined #yocto
lexano has quit [Ping timeout: 252 seconds]
GParker__ has quit [Quit: Leaving]
lexano has joined #yocto
ptsneves has quit [Ping timeout: 245 seconds]
rsalveti has joined #yocto
zpfvo has quit [Quit: Leaving.]
florian__ has joined #yocto
mros has quit [Quit: Client closed]
flom84 has joined #yocto
tnovotny has quit [Ping timeout: 245 seconds]
jmd has joined #yocto
flom84 has quit [Remote host closed the connection]
flom84 has joined #yocto
justThanks is now known as justTesting
tlhonmey has joined #yocto
|Xagen has joined #yocto
tlhonmey has quit [Ping timeout: 250 seconds]
Xagen has quit [Ping timeout: 240 seconds]
frieder has quit [Remote host closed the connection]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
khem has quit [Quit: Connection closed for inactivity]
rsalveti has quit [Quit: Connection closed for inactivity]
justTesting is now known as justThanks
mvlad has quit [Remote host closed the connection]
alinucs has quit [Server closed connection]
alinucs has joined #yocto
Starfoxxes has quit [Ping timeout: 264 seconds]
jmd has quit [Remote host closed the connection]
florian__ has quit [Ping timeout: 272 seconds]
goliath has joined #yocto
goliath has quit [Quit: SIGSEGV]
khem has joined #yocto
florian__ has joined #yocto
goliath has joined #yocto
Oxbef has joined #yocto
Oxbef has quit [Client Quit]
|Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Minvera has quit [Ping timeout: 240 seconds]
nullptr has joined #yocto
Kubu_work has quit [Quit: Leaving.]
<nullptr>
Hello, I am trying to install a systemd unit file, this is how my recipe looks followed by the error I am getting- https://bpa.st/4A5Q. The recipe folder is laid out like this: meta-demo/recipes-demo/systemd/hellosystemd_v1.0.bb && meta-demo/recipes-demo/systemd/files/hello.service. In my local.conf file, I have INIT_MANAGER = "systemd",
<nullptr>
IMAGE_INSTALL:append = " hellosystemd" . What is going wrong? Why does the error say Error: Unable to find a match: hellosystemd?
khem has quit [Quit: Connection closed for inactivity]
<rburton>
nullptr: does your DISTRO_FEATURES have systemd in?
<rburton>
(bitbake-getvar DISTRO_FEATURES)
<RP>
jonmason: any idea on the timescale for the armv5 fix?
<rburton>
nullptr: most likely it doesn't so the package doesn't exist because the systemd unit got deleted as systemd isn't being used.