<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 :)
<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
<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.
<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
<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? https://github.com/torvalds/linux/tree/master/drivers/net/can
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
<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>
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: https://pastebin.pl/view/528338ee
<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
<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>
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 - https://znc.in]
<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/_bootstrap.py:219: 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__>
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 typhoon.yocto.io:8686
<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/gcc_11.2.bb:do_populate_lic 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