<qschulz>
wkawka: you say "my config is enabled" and then "trying to load a module", those are not compatible
<qschulz>
I mean, for me "enabled" is "y" in the config option :)
<qschulz>
so, you're building it as a module but it does not work on the target
<mckoan>
qschulz: semanically both are enabled (as static or module)
<qschulz>
I highly suspect you didn't add the appropriate kernel module package to your image
<mckoan>
*semantically
<qschulz>
mckoan: yeah, just realized it's my brain doing the difference but it's not that obvious
<wkawka>
Yes, there was 2 configs first as module and second as enabled (y)
<wkawka>
that like was supposed to be y
<qschulz>
by obvious I mean that people can understand different things
<qschulz>
wkawka: when building as a module, the module will likely be in its own package named something like kernel-modules-leds-gpio or something like that
nemik has quit [Ping timeout: 272 seconds]
<qschulz>
wkawka: you can check by running oe-pkgdata-util list-pkgs -r virtual/kernel (more or less, didn't check the arguments)
<wkawka>
it works already, the problem was that I thought that these configs should be combined, but they didn't
<qschulz>
wkawka: and as mckoan kind of highlighted, just enabling led gpio driver is probably not enough, you'll needd to modify the device tree if there isn't already support for it
<qschulz>
wkawka: I do not follow
nemik has joined #yocto
goliath has joined #yocto
<qschulz>
wkawka: what is the issue right now?
<qschulz>
what are you trying to do, what have you done so far and where are you stuck
<wkawka>
Currently nothing, I'm looking how to set trigger for led
ptsneves has joined #yocto
<wkawka>
It is working as intended
<qschulz>
ah so the question from two hours ago is answered then :)
<qschulz>
wkawka: you'll also discover that the OSS community is a small world hehe
kanavin has quit [Ping timeout: 240 seconds]
florian has joined #yocto
perdmann has quit [Ping timeout: 272 seconds]
perdmann has joined #yocto
Tokamak has quit [Remote host closed the connection]
kanavin has joined #yocto
perdmann has quit [Ping timeout: 244 seconds]
DaxTailor has joined #yocto
perdmann has joined #yocto
davidinux has quit [Ping timeout: 272 seconds]
chep has quit [Read error: Connection reset by peer]
<DaxTailor>
Hello, i'm building a system for an AMD V1000 but got stuck on the MESA radeonsi dri lib. Has someone an idea how to build this lib? Other dri libs are been build (i915_dri.so for example).
chep has joined #yocto
<qschulz>
DaxTailor: did you add r600 to mesa's PACKAGECONFIG?
<DaxTailor>
I tried. This was in mesa.inc, right?
<qschulz>
yes
<DaxTailor>
Build is running now, maybe I was using the wrong bitbake target. Lets wait and hope....
<qschulz>
DaxTailor: bitbake-getvar -r mesa PACKAGECONFIG (or something like tht) should return the value of PACKAGECONFIG for mesa recipe
<qschulz>
at least you wouldn't have to wait super long to see if it made it
<qschulz>
DaxTailor: also, since it's not enabled by default, I wouldn't be super surprised if it's not working anymore and might need some tweaks to the recipe (just so you don't put your full trust in the recipe)
<DaxTailor>
At the end it says ... " gallium r600 ..., looks like the change is in use. Maybe I have to set a -D... for the mesa build system to build this driver.
<qschulz>
DaxTailor: it seems you also need gallium-llvm
berndlaser[m] has left #yocto [#yocto]
perdmann has quit [Ping timeout: 268 seconds]
<qschulz>
nope, nevermind
<qschulz>
DaxTailor: check GALLIUMDRIVERS recipe has r600 in it
perdmann has joined #yocto
<DaxTailor>
Is that a different recipe? The build finished but did not build the driver.
<qschulz>
check also PACKAGECONFIG_CONFARGS variable to see if the -D you are looking for is correctly set
<qschulz>
DaxTailor: no, same mesa.inc
<DaxTailor>
GALLIUMDRIVERS="swrast,i915,iris,crocus,r600,virgl" That was already ther.
<DaxTailor>
I wrote this an now I get an error the LLVM is missing: GALLIUMDRIVERS:append =",radeonsi"
<qschulz>
DaxTailor: ah so you do want radeonsi and not r600
<qschulz>
DaxTailor: so you do need to add gallium-llvm to your PACKAGECONFIG
<DaxTailor>
I'm confused now. glxgears is looking for radeonsi_dri.so, but to enable that I have to set r600. The amdgpu kernel and X11 driver are already working.
<qschulz>
DaxTailor: r600 and radeonsi seems to be different beasts in mesa.inc
<jatedev>
JaMa: both DNS entries resolve to the same IP. The IP does not respond to pings
<rburton>
halstead: ^ hashequiv server down?
<jclsn[m]>
rburton: Yeah, you need to recompile imx-boot to obtain an updated u-boot version. I guess imx-boot is the only image to flash then
<mihai>
afaik u-boot-imx is imx's fork of u-boot
<jclsn[m]>
mihai: I know that
<jclsn[m]>
But it seems that you need to specify a defconfig and .dtb in imx-boot as well. I am just a bit confused for which recipe to write a .bbappend now. It seems kind of redundant if you have to do it for both
Schlumpf has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
Schlumpf has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<mihai>
any tips on getting the spdx output in tag format?
<rburton>
you'll have to post-process it
<mihai>
right, with what? :)
<mihai>
suggestions of existing tools or scripts that can actually do it are welcomed
florian_kc has joined #yocto
xmn has joined #yocto
<JPEW>
mihai: There are a few tools written in several languages... unfortunately, which one is "most" up to date depends on who last updated their favorite language. https://github.com/spdx/tools-java has historically been the most up to date
<JPEW>
But, YMMV on if that can correctly convert the JSON to TagValue.... our SPDX uncovers a few bugs in what the tooling can accept as valid and I'm not sure if they have been fixed yet
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
jmiehe has quit [Ping timeout: 255 seconds]
florian has quit [Quit: Ex-Chat]
<mihai>
JPEW: thanks, I was looking over the python tools converter which only accepts tag or rdf as input, I was trying to stay away from the java one, maybe I'll give that a try
<mihai>
otherwise I'll have to write something up, which I was also trying to avoid :)
ptsneves has quit [Quit: ptsneves]
ptsneves1 has joined #yocto
<JPEW>
The Java one is the one I've had luck with before.... looks like the go one was updated recently as well
nemik has quit [Ping timeout: 268 seconds]
<JPEW>
mihai: You could update the Python tooling to make it better; they take pull requests :)
<halstead>
rburton: The hashserv is responsive again.
<halstead>
RP: It's the max open files issues. Even with the number way up.
<halstead>
We'll have it on it's own server soon. But we will probably need to find the leak too.
kscherer has joined #yocto
<rburton>
RP: release build almost done, green so far
sakoman has joined #yocto
prabhakarlad has joined #yocto
ruslan has quit [Quit: Client closed]
joseogando has joined #yocto
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
seninha has joined #yocto
<RP>
halstead: can we run lsof whilst it is broken, see if we can see what is going on
<RP>
JPEW: anything else we should log?
<JPEW>
RP: Let me check if there are relevent logging messages
<RP>
halstead: what is the limit currently? I'm seeing ~5000 open files in total atm. Not sure if you restarted it yet?
* JPEW
wishes python had more logging levels below DEBUG
joseogando has quit [Ping timeout: 252 seconds]
DaxTailor has quit [Quit: Client closed]
<JPEW>
It might generate a lot of logging data, but we can try passing `--log DEBUG` to the server
<JPEW>
If we can see what the file descriptor are (sockets, etc.) that would be helpful too probably
wkawka has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
<JPEW>
RP: I'm wondering if enabling TCP keep-alive on the server would help; maybe there are clients disappearing without a clean disconnect
<JPEW>
And the socket sticks around waiting for data
Etienne93 has quit [Quit: Client closed]
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
<RP>
JPEW: how long would those stick around for? That seems possible
<JPEW>
I;m not sure how long they would stick around ATM
<JPEW>
RP: Since the server only sends a response to a request from the client, it's _possible_ that the socket would never disappear if it's not closed and the client never sends a response, but I'm not sure
goliath has quit [Quit: SIGSEGV]
<JPEW>
s/client sends a response/client sends a request/
prabhakarlad has joined #yocto
<moto-timo>
qschulz: I have not run rootless podman, no.
<moto-timo>
qschulz: and Fedora since 28 has been progressively more frustrating
<qschulz>
moto-timo: here the issue is that podman complains the volume is mounted with 0:0 uid:gid I think
<qschulz>
then I passed the usual --userns=keep-id
<qschulz>
but then it fails with:
<qschulz>
sudo: unknown user: pokyuser
<qschulz>
sudo: unable to initialize policy plugin
<moto-timo>
the crops containers were designed long before podman existed :(
<qschulz>
moto-timo: like many pieces of sw :)
chep has quit [Read error: Connection reset by peer]
joseogando has joined #yocto
ptsneves has quit [Ping timeout: 268 seconds]
chep has joined #yocto
Bardon_ has joined #yocto
joseogando has quit [Remote host closed the connection]
joseogando has joined #yocto
Bardon has quit [Ping timeout: 240 seconds]
mux[m] has joined #yocto
manuel_ has quit [Ping timeout: 244 seconds]
joseogando has quit [Ping timeout: 252 seconds]
vvn has quit [Quit: WeeChat 3.5]
vvn has joined #yocto
v0n has quit [Quit: WeeChat 3.5]
joseogando has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
<kergoth>
was needed to include all the necessary source files for gcc and libstdc++ for us
nemik has quit [Ping timeout: 272 seconds]
<rburton>
phako[m]: figure out what the crazy script is doing, see if you can override it, or fix it to handle syssroots etc. it's not unknown to just rip out entire custom scripts and replace them with a pkg-config call
nemik has joined #yocto
<kergoth>
yawn
<khem>
rburton: seems a clang bug here its specific to asm files
<rburton>
yeah, definitely
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
DrewMoseley[m] has joined #yocto
<RP>
kergoth: heh, can you guess what my local patch does? :)
<kergoth>
hah, same idea, yours is better integrated though :) sorry for not submitting our backlog sooner!
mckoan is now known as mckoan|away
<kergoth>
trying to fix that now, finally have time between fires
joseogando has quit [Ping timeout: 252 seconds]
warthog9 has quit [Ping timeout: 268 seconds]
warthog9 has joined #yocto
jpuhlman_ has joined #yocto
jpuhlman_ is now known as jpuhlman
jpuhlman is now known as Guest6899
joseogando has joined #yocto
florian_kc has joined #yocto
dtometzki has quit [Read error: Connection reset by peer]
dtometzki has joined #yocto
<RP>
kergoth: sounds good! there are definitely a few things we need to fix like this...
<RP>
kergoth: I'm a little torn on whether I should put kernel_cc in there or not as it ends up duplicating a lot with kernel-devsrc
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
perdmann has quit [Ping timeout: 255 seconds]
perdmann has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
leon-anavi has quit [Quit: Leaving]
nemik has joined #yocto
joseogando has quit [Ping timeout: 252 seconds]
seninha has quit [Ping timeout: 255 seconds]
florian_kc has quit [Ping timeout: 260 seconds]
jatedev has joined #yocto
perdmann has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
seninha has joined #yocto
Tokamak has joined #yocto
florian_kc has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
seninha has quit [Ping timeout: 272 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
florian_kc has quit [Ping timeout: 255 seconds]
jmiehe has quit [Ping timeout: 276 seconds]
<JPEW>
RP: sent the keep-alive patch
seninha has joined #yocto
jatedev has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
perdmann has quit [Ping timeout: 272 seconds]
perdmann has joined #yocto
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
seninha has quit [Quit: Leaving]
seninha has joined #yocto
florian_kc has joined #yocto
amitk_ has quit [Ping timeout: 268 seconds]
<hushmoney>
is there a prescribed method of passing command line arguments to a given task? such as "bitbake foo -c bar bar-args...". i think that i can whitelist an environment var and pass through that but i wanted to check first because that feels a little klunky
<JPEW>
hushmoney: I don't think passing arguments to tasks is allowed
<hushmoney>
thanks, i thought so. it doesn't make sense in most cases. i'm writing a phony convenience task, that's the only reason why i want to do it
joseogando has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
alessioigor has joined #yocto
davidinux has quit [Ping timeout: 268 seconds]
joseogando has quit [Ping timeout: 252 seconds]
alessioigor has quit [Client Quit]
florian_kc has joined #yocto
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
goliath has quit [Quit: SIGSEGV]
jmiehe has joined #yocto
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
joseogando has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
<dl9pf>
RP: I think I have a fix for connman-ncurses. It was ignoring/overwriting CFLAGS, thus also the DEBUG_PREFIX_MAP. Should land soon.
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
Tokamak has quit [Ping timeout: 244 seconds]
Tokamak has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
joseogando has quit [Ping timeout: 252 seconds]
lexano has quit [Quit: Leaving]
lexano has joined #yocto
lexano has quit [Client Quit]
lexano has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<RP>
dl9pf: great, thanks. That sounds like the right kind of fix :)
<RP>
JPEW: great.
<RP>
halstead: could you see if that patch from JPEW helps for hashserv?
<RP>
JPEW: thanks
<RP>
JPEW: I think I can see the hashserv starting to build up ESTABLISHED socket connections as you mentioned FWIW
GNUmoon has joined #yocto
perdmann has quit [Ping timeout: 272 seconds]
perdmann has joined #yocto
<halstead>
RP, JPEW: gladly
kscherer has quit [Quit: Konversation terminated!]
mihai has quit [Quit: Leaving]
perdmann has quit [Ping timeout: 244 seconds]
perdmann has joined #yocto
<JPEW>
RP: ya that makes sense. Hopefully that fixes it
florian_kc has quit [Ping timeout: 260 seconds]
Tokamak has quit [Ping timeout: 244 seconds]
Tokamak has joined #yocto
mvlad has quit [Remote host closed the connection]