ChanServ changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: | Join us or Speak at Yocto Project Summit (2021.11) Nov 30 - Dec 2, more: | Join the community: | IRC logs available at | Having difficulty on the list or with someone on the list, contact YP community mgr ndec
jwillikers has joined #yocto
otavio has quit [Remote host closed the connection]
otavio has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 252 seconds]
sakoman has quit [Quit: Leaving.]
pgowda_ has joined #yocto
jwillikers has quit [Remote host closed the connection]
jmiehe1 has joined #yocto
jmiehe has quit [Ping timeout: 252 seconds]
jmiehe1 is now known as jmiehe
dtometzki has quit [Quit: ZNC 1.8.2 -]
alicef has joined #yocto
<alicef> hello, poky git certification changed ? yesterday I got some invalid certification error on accessing poky
<alicef> fatal: unable to access '': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
pgowda_ has quit [Quit: Connection closed for inactivity]
dtometzki has joined #yocto
landgraf1 is now known as landgraf
landgraf is now known as landgraf1
landgraf1 is now known as landgraf
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
Sion has joined #yocto
alessioigor has quit [Quit: alessioigor]
m4ho has quit [Quit: WeeChat 3.1]
<ndec_> agherzan: sorry about the delay.. I am (now) seeing your request.
m4ho has joined #yocto
manuel1985 has quit [Quit: Leaving]
<JosefHolzmayrThe> yo dudX
goliath has joined #yocto
frieder has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
Dracos-Carazza has joined #yocto
pgowda_ has joined #yocto
Guest54 has joined #yocto
mckoan|away is now known as mckoan
<mckoan> good morning
<mckoan> alicef: and is out of order
<mckoan> ndec_: ^
<JosefHolzmayrThe> mckoan: alicef git clone git:// works for me
zpfvo has joined #yocto
<agherzan> Hey ndec_ , there is no delay. I was just wondering what are cu current ETAs. Thanks
ant__ has quit [Ping timeout: 250 seconds]
<alicef> JosefHolzmayrThe: depend from your ca-signature package I think
<alicef> ca-certificates/now 20210119~18.04.1 dosen't work
<Guest54> Hey guys, just want to ask the pro's here. What IRC client you use? My hexchat does not work anymore because of the certificate issue with libera :)
<Sion> Hello, I use Konverstation
<alicef> Guest54: let's encrypt also changed certification
<JosefHolzmayrThe> Guest54: irccloud, element via bride, irssi. it depends.
<Sion> Konversation* I really need some coffee :)
<JosefHolzmayrThe> *bridge, even
<alicef> deprecating DST Root CA X3
<alicef> you need to trust ISRG Root X1
<JosefHolzmayrThe> alicef: just updated to 20210119~20.04.2 (its a 20.4 box obviously), still no problem here.
<Guest54> This certification stuff is a topic I havn't digged into it yet..
<alicef> maybe is only for 18.04 ?
<JosefHolzmayrThe> alicef: possible
<alicef> also could be that you still are caching new one
rob_w has joined #yocto
<alicef> I'm no certicate expert btw :/
<JosefHolzmayrThe> alicef: also possible.
<JosefHolzmayrThe> neither am i, just poking things and trying.
goz3rr has joined #yocto
<JosefHolzmayrThe> alicef: i'd say asking the admin to verify the cert chain might be a good idea, but it doesn't seem to be a widespread issue at the moment.
<mckoan> alicef: JosefHolzmayrThe: I am on 18.04 and git clone works
<mckoan> git clone git://
<mckoan> Guest54: irssi
<alicef> mckoan: what version of ca-certificates ?
<mckoan> alicef: 20210119~18.04.2
<alicef> maybe is a repo problem ...
<alicef> repo command not repo repository
<mckoan> alicef: update repo too
<mckoan> alicef: no, sorry we are testing git clone only
<alicef> I had to fix it manually with git config --global http.sslverify false
<qschulz> override: there's no version for drivers in the kernel, they are just part of the kernel, so whatever the kernel version is at that time, that's their "version". Also, technically that means almost nothing since you can have a vendor kernel which has a completely different source code for your driver
alicef is now known as alicef_
wooosaii has quit [*.net *.split]
tlwoerner has quit [*.net *.split]
xmn has quit [*.net *.split]
alinucs has quit [*.net *.split]
nerdboy has quit [*.net *.split]
jsandman has quit [*.net *.split]
dlan has quit [*.net *.split]
marka has quit [*.net *.split]
warthog9 has quit [*.net *.split]
tangofoxtrot has quit [*.net *.split]
mcfrisk has quit [*.net *.split]
Tokamak has quit [Ping timeout: 252 seconds]
<user_> Hi team,We want to deploy a HTTPs server in a yecto build system,With libulfius C based protocol. Tried adding Recipes to SDk but while Building complete SDk along with Ulfius,orcania,yder do_compile is failing.Please suggest is there any way to resolve it or any alternate yecto supported http package available.
<JosefHolzmayrThe> user_: the way is to provide proper information and logs and ask concise questions about the points where you are stuck.
<JosefHolzmayrThe> user_: for a bunch of already prepared httpds, see
alinucs has joined #yocto
dlan has joined #yocto
tlwoerner has joined #yocto
xmn has joined #yocto
warthog9 has joined #yocto
mcfrisk has joined #yocto
jsandman has joined #yocto
marka has joined #yocto
wooosaii has joined #yocto
tangofoxtrot has joined #yocto
nerdboy has joined #yocto
leon-anavi has joined #yocto
florian has joined #yocto
xmn has quit [Quit: ZZZzzz…]
lucaceresoli has joined #yocto
kiran_ has quit [Ping timeout: 252 seconds]
<goz3rr> I've recently started running into an issue with building using the crops/poky:ubuntu-20.04 docker container where at one point an rm -rf command gets killed with SIGABRT. If I manually delete the file that is being deleted and run the build again it just fails in the same way on a different file. The only "fix" so far is to delete the entire build
<goz3rr> directory and start a build from scratch
<goz3rr> Exception: subprocess.CalledProcessError: Command '['rm', '-rf', '/workdir/poky/build/tmp/work/colibri_imx6ull-tdx-linux-gnueabi/xpac-image-dev/1.0-r0/rootfs']' died with <Signals.SIGABRT: 6>.
<goz3rr> What would be the best approach to start debugging something like this?
JaMa has joined #yocto
arlen has quit [Ping timeout: 250 seconds]
<ndec_> agherzan: the timeline is (supposed to be) ~1 week for me + TSC to review, then 1 week for AB/members to review.
vd has quit [Ping timeout: 256 seconds]
vd has joined #yocto
<agherzan> Sounds good. That gives me a reference. I understand it is not a commitment. Thanks ndec_
Guest54 has quit [Quit: Client closed]
oobitots has joined #yocto
manuel1985 has joined #yocto
<manuel1985> Hi people. Does anyone know how to delete a directory, but not its contents?
<manuel1985> Sounds weird, I know.
<qschulz> manuel1985: what do you want to do?
<manuel1985> I once ended up being in the seemingly same directory in two terminal windows, showing different content. Took me half a day to realize these were different directories, as they had different inodes. Want to recreate that and teach my team so they won't as well lose half a day like I did.
<manuel1985> Essentially I want to set up a testground. Or demonstrator.
<manuel1985> cannot just `rm` the dir, as it's refusing to do anything unless `--recursive` is given. But with `--recursive`, it obviously removes the content as well.
<manuel1985> IIRC, back then, I could even create new files in the dir not existing anymore.
<qschulz> manuel1985: what about mv?
<qschulz> otherwise yeah, you'll have to dig into inodes and I can't help with that :)
<manuel1985> qschulz: You were right! The trick is not to remove the olddir, but to `mv` it.
<manuel1985> That will blow my teams minds. Am teaching them some unix.
<qschulz> manuel1985: the trick is to close and reopen the terminal when something happens you don't understand :p
<manuel1985> qschulz: `cd ~ && cd -` is my favorite command :) should bind it to an alias
<qschulz> manuel1985: alias isthisreallife='cd "$HOME" && cd -' :)
<manuel1985> qschulz: That's a very suitable name!
Schlumpf has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
mckoan is now known as mckoan|away
<JosefHolzmayrThe> whats so funny about `cd ~ && cd -`?
<qschulz> manuel1985: IIRC, I used to do `cd .` and I think that worked too when the inode is different but in the same place on the fs?
<qschulz> JosefHolzmayrThe: nothing, just discussing how to recover from a directory whose inode has changed while a terminal is in said directory
jwillikers has joined #yocto
<JosefHolzmayrThe> Uhr huh
oobitots has quit [Quit: Client closed]
dmoseley_ has quit [Quit: ZNC 1.8.2 -]
lexano has joined #yocto
dmoseley has joined #yocto
ant__ has joined #yocto
angolini has joined #yocto
dagmcr has quit [Excess Flood]
dagmcr has joined #yocto
<override> back with my CAN driver questions
<override> how can I know for certain what version of CAN driver's running on my board currently ??
<smurray> look in the kernel you're running?
oobitots has joined #yocto
oobitots has quit [Client Quit]
<qschulz> basically, just find the sources of the kernel you are using on your board, with patches applied and that's the current state of your driver
<override> smurray: So tired the modinfo command to figure whats running on the kernel, now how do I figure what version of the driver is on the main/master for the linux repo. Im guessing this repo has the latest and greatest drivers?
Guest3 has joined #yocto
<qschulz> override: there is no such thing as a version for a driver except if it's an out-of-tree driver, which does not seem to be the case for you
<qschulz> override: is the master branch of the kernel
<override> qschulz: sorry missed your relpies from before. So the board vendor I understand might have patched the kernel and all and theres no such version for the driver..
<override> but like can I atleast figure out what was the base version or something they started applying their patches to?
<override> we basicslly just have to grep and look for clues?
<rburton> if you have a kernel tree then the top level Makefile contains the version
<qschulz> override: git remote add upstream && git fetch upstream && git merge-base upstream/master HEAD
<qschulz> that's the kernel base, but then your vendor could have also merged back some branches from upstream
<qschulz> so what rburton said, but they might also have fucked up the whole thing by resolvin merge conflicts like idiots... welcome to vendor BSP world :) (or let's say anything !upstream :) )
Ad0 has joined #yocto
Guest323 has joined #yocto
Guest3 has quit [Ping timeout: 256 seconds]
JaMa has quit [Quit: off]
roussinm has joined #yocto
xmn has joined #yocto
Guest323 has quit [Quit: Client closed]
<override> rburton: where would the tree be getting fetched into? I looked around in the usual workspace and tmp kinda folders
<override> I have no idea what might be a good thing to find . -name for or something for the kernel tree..
jwillikers has quit [Ping timeout: 252 seconds]
<qschulz> override: we talked about preferred_version and preferred-provider yesterday
<qschulz> that's how you find out
<manuel1985> Did some of you ever have a worn-out eMMC? One of our devices has the following kernel panic:
<manuel1985> `mmc extcsd read` reports `0x10`, though, that is wear is in the range of 0% to 10%
<qschulz> manuel1985: imx8m family IIRC?
some_coder23 has joined #yocto
<qschulz> manuel1985: for both wear levels?
<manuel1985> Nope, NVIDIA Jetson TX2
<manuel1985> qschulz
<manuel1985> yes, for both wear levels
sakoman has joined #yocto
<manuel1985> Also wondering why BOTH wear levels are != 0x00, as one is for SLC and the other for MLC IIRC. Thought an eMMC can either be of this or that technology.
<qschulz> manuel1985: no you can have both at the same time
<qschulz> you don't have to set the user area partition to the full size of the emmc
<qschulz> and then you have a mix
<manuel1985> qschulz: I see, thx
<qschulz> though it's a one-time setting, you cannot reduce or increase the size of the user area partition
<qschulz> once set
ant__ has quit [Quit: Leaving]
rob_w has quit [Remote host closed the connection]
Tokamak has joined #yocto
Sion has quit [Ping timeout: 268 seconds]
vd has quit [Ping timeout: 256 seconds]
vd has joined #yocto
Tokamak has quit [Ping timeout: 245 seconds]
Tokamak has joined #yocto
otavio has quit [Ping timeout: 246 seconds]
troth1 has quit [Quit: Leaving.]
otavio has joined #yocto
troth has joined #yocto
tnovotny has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pidge has joined #yocto
kiran has joined #yocto
Schlumpf has quit [Quit: Client closed]
otavio has quit [Ping timeout: 252 seconds]
otavio has joined #yocto
mihai has quit [Quit: Leaving]
manuel1985 has quit [Quit: Leaving]
pidge has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
tnovotny has quit [Quit: Leaving]
davidinux has quit [Ping timeout: 268 seconds]
kpo has joined #yocto
dev1990 has joined #yocto
JaMa has joined #yocto
<kpo> Hello! I'm using yocto for building ARM image for Raspberry PI. Is it possible to utilize bitbake to run unit tests? I've got qmake based project, that can built two executables (based on subdirs template): 'app' and 'tests'. I would like to build 'tests' for host architecture, i.e. x64, run them, and if they pass, build 'app' for ARM and add it to the Image. If running 'tests' fail, then bitbake should fail
JaMa has quit [Client Quit]
leon-anavi has quit [Remote host closed the connection]
yates has joined #yocto
<yates> is there a list of the top-level personnel involved in yocto? i'm giving an internal talk on the Yocto Summit 2021 to my colleagues and thought it would be good to mention some of the key names.
<yates> e.g., rburton, etc?
<yates> i know Khem Raj, but don't know his focus on yocto
<yates> kergoth, tlwoerner, ...
JaMa has joined #yocto
zpfvo has quit [Remote host closed the connection]
<yates> David Reyna, ... etc
<yates> i can see the names, but knowing their role would be nice.
<yates> roles
<kanavin> RP: I am going slightly mad here with sstate hashes where the hash in filename doesn't match the hash printed by bitbake-dumpsig
<kanavin> just wondered if by any chance it's known
<kergoth> yates: I don't have an official role, personally, though I did in the past. Just a developer at siemens disw and contributor when possible. I will be working to change that in the future to attempt to help alleviate rp's massive overload.
<kergoth> won't speak for anyone else, not sure if there's an org chart at htis point
<kanavin> (btw I do have a working mozjs 91.1.0 build now, which uses quite a bit more rust than librsvg :)
<yates> kergoth: ok i understand
<yates> i am including the profile for each presentation which includes the name of the presenter and their involvment - thus i'm realizing such a list of names up front is not necessary
<kergoth> seems to be what's on the site, admittedly minimal
<kergoth> doesn't cover stable branch maintainers or rburton's role, etc
<yates> nice!
<kergoth> maintainers info in the oe-core repo may provide more insight
<yates> i will include these links on a slide - good info
<kanavin> yates, RP is the architect and integrator, khem is in charge of toolchains, Bruce is doing the kernel, I'm maintaining oe-core
<yates> Bruce Schneir?
<kanavin> Bruce Ashfield
<kanavin> then there's Armin doing meta-oe stable maintenance, same khem doing meta-oe integration
xmn has quit [Remote host closed the connection]
<kanavin> Anuj maintans recent releases, Steve Sakoman maintains LTS
<yates> would you mind emailing me the full names (first/last) with roles at, please?
<kanavin> I would
<yates> i don't know some of these people
<kanavin> too much work :)
<yates> ok
xmn has joined #yocto
<kanavin> I'd rather sort out rust issues
<yates> that will keep you busy
<kanavin> you bet it does
<yates> p)
<kanavin> really, who is doing what is not important, the important thing is that your organizations joins YP as a member, and hires people to maintain things
<yates> at least now everyone knows my email and can send me nastygrams about all my stupid questions!
vd has quit [Quit: Client closed]
florian has quit [Quit: Ex-Chat]
vd has joined #yocto
<kanavin> somehow a lot of companies tend to thing YP maintains and develops itself, and they can just take it and all will be fine
<kergoth> That's pretty common with open source projects in general
<kergoth> just look at how much critical infrastructure is nearly unmaintained
<kergoth> comes to mind
<kanavin> it's a failure of market economy, yes
<yates> kergoth: +1, lol
<yates> but it's not funny..
<kergoth> yeah.. one of those laugh so you don't cry kind of things eh.. software sucks
<kergoth> heh
<kergoth> well we do what we can
<RP> kanavin: it is probably hash equivalence
<yates> what about Montana? :)
<kanavin> RP: I've piled up quite a few patches beating rust into shape. One of the more invasive changes is that I made BUILD_SYS/TARGET_SYS strings fully formed - no more omissions or defaults, e.g. BUILD_SYS is now x86_64-oenative-linux-gnu instead of x86_64-linux
<kanavin> makes things a lot simpler with rust
<RP> kanavin: you mean changing project wide outside rust?
<kanavin> RP: yes
<RP> kanavin: that idea fills me with dread
<kanavin> RP: I'll test it with a-full and meta-oe on the AB
<RP> kanavin: I'm reluctant to go changing things like that without a really good reason
<kanavin> there are a few places where absence of -gnu is assumed, I'm fixing those up
<RP> kanavin: back on the hash subject, the difference in calc hash to the one in use is almost certainly due to hash equivalence being involved. I've struggled to see how we can reconcile things
jmiehe has quit [Quit: jmiehe]
jmiehe1 has joined #yocto
jmiehe1 has quit [Client Quit]
<kanavin> RP: I am seeing unnecessary rebuilds of rust-native in different build directories sharing the sstate cache, will check again now why they happen. there are two different siginfo files in the cache, but if you run bitbake-dumpsig on them, it prints same computed task hash at the end
<kanavin> RP: how to check further?
<RP> kanavin: are they for different arm machines? JaMa posted about a hash problem with rust-cross and sigs
<RP> kanavin: sorry, you said native
<RP> kanavin: are you sharing the hashequiv data between the builds?
goliath has joined #yocto
davidinux has joined #yocto
goz3rr has quit [Quit: Client closed]
frieder has quit [Remote host closed the connection]
<kanavin> RP: I'm not sure, I am using the default config for both, so I guess I do.
<kanavin> RP: the issue is, one builds completes, places the populate_sysroot into cache. Then the other build ignores that, and proceeds to rebuild, and also places populate_sysroot into cache. The siginfo files have the same content (as reported by bitbake-dumpsig), but their filenames are different
<khem> RP: I think problem will show up when doing similar machine builds e.g. so perhaps make a copy of qemuarm to qemuarmcopy or something and see if it gets reused
<kanavin> I'm using qemumips64 and qemux86_64
pgowda_ has quit [Quit: Connection closed for inactivity]
Dracos-Carazza has quit [Quit: ZNC 1.8.2 -]
<kanavin> RP: ah, I think I'm not sharing that data, as that is actually the default :) it's different databases in different build directories
<kanavin> I do wonder why the filename and the task hash inside it differ, as I suspect that's why a rebuild is happening, since the file cannot be found from the calculated task hash :-/
<kanavin> I wiped everything and doing a clean build now, first one, then the other
<kanavin> RP: ok, that helped. maybe things in build/cache/ were somehow not right :-/ I'll keep an eye on it.
Dracos-Carazza has joined #yocto
Tokamak has joined #yocto
some_coder23 has quit [Quit: Client closed]
<RP> kanavin: its a non-obvious side effect of the hash equiv changes. I'm not sure what we do to improve usability
ant__ has joined #yocto
kiran has quit [Ping timeout: 246 seconds]
amitk_ has quit [Ping timeout: 245 seconds]
<vmeson> for your amusement, my build of world_on_ a RPi4 of a recentish poky repo is ~ 80% done. It's only slightly slower than the YP autobuilder's arm64 builders.
<RP> vmeson: so we should replace the autobuilder with a cluster of RPi4s ?
<vmeson> RP - heh, let me finish the build and see how the selftests go! ;-)
florian has joined #yocto
<JaMa> vmeson: did you start that build when RPi4 was initially launched? :)
<ant__> RP: hi, I must have missed it, on ubuntu 18.4 bitbake spits
<ant__> return f(*args, **kwds)
<ant__> /usr/lib/python3.6/importlib/ ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
<ant__> return f(*args, **kwds)
<ant__> then loads the cache and runs fine
<RP> ant__: we know, its python itself, not bitbake
<ant__> ok, thx
goliath has quit [Quit: SIGSEGV]
Xagen has quit [Quit: Textual IRC Client:]
<ant__> btw I have converted today IMAGE_FSTYPES:collie
<ant__> :)
artri has joined #yocto
<artri> Good evening folks. I have a customised dunfell image on a device and ifup (busybox really) refuses to bring up any ifs listed in /etc/network/interfaces. It won't even print an error. Anyone has seen this behavior before? Any help is appreciated
florian has quit [Ping timeout: 245 seconds]
sakoman has quit [Quit: Leaving.]
<RP> JPEW: is there an easy way to check what a hash is resolving to from the commandline?
<JPEW> It's been so long I do not remember
<RP> JPEW: fair enough, I'm sure I can hack something up
<RP> JPEW: I'm puzzling about why the autobuilder has built gcc:do_populate_lic for qemux86-64 yet builds pointing at the hashequiv server and sstate are building it
<RP> on the autobuilder I see DEBUG: Task 6259ae8263bd94d454c086f501c37e64c4e83cae806902ca95b4ab513546b273 unihash changed 3bde230c743fc45ab61a065d7a1815fbfa01c4740e4c895af2eb8dc0f684a4ab -> 6259ae8263bd94d454c086f501c37e64c4e83cae806902ca95b4ab513546b273 by server
<RP> so the server changes unihash back to taskhash which seems confused
<JPEW> Ya. There is a command line hashserver client, but I forget what it can do
<JPEW> It would probably be useful to have something that can do more advanced queries for debugging
goliath has joined #yocto
<RP> JPEW: its some kind of weird circular reference. WARNING: Found unihash 3bde230c743fc45ab61a065d7a1815fbfa01c4740e4c895af2eb8dc0f684a4ab in place of 6259ae8263bd94d454c086f501c37e64c4e83cae806902ca95b4ab513546b273 for /home/rpurdie/poky/meta/recipes-devtools/gcc/ from unix:///home/rpurdie/poky/build/hashserve.sock
<RP> JPEW: then later it reports the outhash and gets back the original hash it started with
<RP> JPEW: rerunning the build always repeats the build of the thing though since the 3bde230c object is never created in sstate
* RP will look more tomorrow, have a headache now :(
dev1990 has quit [Quit: Konversation terminated!]
<RP> JPEW: I think the issue is that when we call report_unihash(), taskhash can a unihash we got back from the hashequiv server rather than the original taskhash
<JPEW> RP that sounds like a problem
<RP> JPEW: I'm not sure how/why/where that would happen
* RP will look more tomorrow
artri has quit [Ping timeout: 245 seconds]
sakoman has joined #yocto
florian has joined #yocto
paulg has quit [Quit: Leaving]
florian has quit [Ping timeout: 245 seconds]