<qschulz>
amahnui[m]: I guess it can be a Python script but you've to be careful about hte Python packages you'll use (the import directive in your script) to use only those in the docs toolchain or ask to add more to the docs toolchain
<amahnui[m]>
So far I'm using the `os` module
mckoan|away is now known as mckoan
<qschulz>
amahnui[m]: that's a core module so that's fine
* RP
realises the alsa-tools failure is a sign of sstate sig issues
<amahnui[m]>
qschulz: okay thank you, is `glob` fine too I might use it too to recursively go through subdirectories.
<amahnui[m]>
* is `glob` module fine too
<RP>
amahnui[m]: glob is fine. We're ok with any ard python librarby
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
<RP>
amahnui[m]: sorry, I was trying to say we're ok with any module that is part of the core standard python library
<amahnui[m]>
RP: Okay thanks I actually understood, I wrote a python script that adds the html tag that's needed and I can edit it to add the css lines too I think, I'm now trying to write a code that will make it recursively go through the folders and add the div tags to the .html files in them
<qschulz>
amahnui[m]: sounds good :)
<RP>
amahnui[m]: that sounds great! :)
* qschulz
hi5 RP
<RP>
:)
<amahnui[m]>
qschulz: RP thanks
<kanavin>
RP: I forwarded the email to our clients
<kanavin>
RP: I'm not sure where to start with the avahi fail, but I can maybe look at alsa repro
<kanavin>
or anything other
<RP>
kanavin: Thanks. I have worked the alsa-tools one out
<RP>
kanavin: it is actually a symptom of a really worrying issue :(
<RP>
I can fix alsa-tools, less sure about the underlying issue
<kanavin>
RP: I thought so, if it came out of the blue :-/
<RP>
kanavin: it was my fix for 8621 which triggered it
<RP>
kanavin: the question is why it then breaks a reproducibility test with the answer being that sstate checksums are broken
<RP>
kanavin: I don't know what to do with the avahi issue either. Not sure if there would be any more data in the failed build directory
<RP>
we probably still have that right now
<kanavin>
RP: is there an open bug for the avahi item?
<kanavin>
RP: I can see if I can do anything with 'avahi-daemon.service: Unexpected error response from GetNameOwner(): Connection terminated' message, at least find where that comes from
<RP>
qemuppc but looks the same as the arm one
<RP>
kanavin: we should save the build directory on the worker in case anything can be gleaned from that
<kanavin>
RP: this has all the looks of an obscure timing race :-/
<RP>
kanavin: if I read that correctly, one of the tests causes avahi to stop/start along with wpa-supplicant. avahi then fails to restart correctly, suggestive of some restart race issue
<kanavin>
RP: thanks
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<kanavin>
RP: yeah, it looks as though avahi gets stuck on restart
camus has quit [Ping timeout: 240 seconds]
<kanavin>
RP: I'll run testimage locally, and if it succeeds, the point where things diverge could be a further clue
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
creich has joined #yocto
creich has quit [Remote host closed the connection]
creich has joined #yocto
camus has joined #yocto
florian has joined #yocto
creich has quit [Client Quit]
camus has quit [Client Quit]
creich has joined #yocto
camus has joined #yocto
creich has quit [Remote host closed the connection]
creich has joined #yocto
<zen_coder>
I have build the meta-toolchain-qt5, but I do not need Qt itself, I only need the dependencies of Qt. How can I adjust the tool chain?
<RP>
kanavin: sounds good, thanks. Finding what triggered the restart and looping it might brute force it
florian has quit [Ping timeout: 248 seconds]
<kanavin>
RP: I think I got somewhere. The problem starts in the dnf tests, which install and deinstall run-postinsts in quick succession, which in turn run 'systemctl daemon-reload'
manuel has quit [Quit: Leaving]
<kanavin>
I think those calls step on each other, and basically dnf tests need to be rewritten to use something that has 'safe' scriptlets or none
<RP>
kanavin: how do they step on each other though? Isn't there some race there which needs to be resolved?
<kanavin>
RP: that's what I am trying to understand. It seems as though 'daemon-reload' operation could be asynchronous.
<RP>
kanavin: that would explain it. Hopefully there may be some what to know when it is complete?
<kanavin>
RP: I'll poke a bit more
mckoan is now known as mckoan|away
<RP>
kanavin: thanks, sounds promising
* RP
notices we have a CVE fix for git we need
<kanavin>
RP: I suspect we should drop 'daemon-reload' operation altogether from the systemd.bbclass. systemctl enable/restart pair should handle any package updates, although systemctl documentation isn't very clear on this.
<kanavin>
RP: I would want to see how fedora/debian handle this
<RP>
kanavin: "daemon-reload won't reload/restart the services themselves, just makes systemd aware of the new configuration"
<RP>
kanavin: that isn't a definitive statement from docs but shows someone thinks it is needed
<RP>
kanavin: it is possible systemd behaviour has changed over time
amitk has quit [Ping timeout: 246 seconds]
faruk has joined #yocto
<faruk>
.
<faruk>
Hello. I want change version of qt from 5.15 to 5.12. I think I should this inside meta-qt5 but I couldn't. How can I do this?
<faruk>
I want compile SDK for Qt environment
<qschulz>
faruk: easiest would be to find a version of meta-qt5 which uses 5.12 instead of 5.15 and stick to it
<qschulz>
otherwise, you'll need to backport older version of ther ecipes (or write them yourself) and set PREFERRED_VERSION_qt5base (and others) to 5.12
<faruk>
I tried change branch version but I couldn't compile. This made me think I was on the wrong track
<qschulz>
faruk: not the bvranch version as there is a compatibility check embedded in layer.conf
<qschulz>
within a same branch, if any is compatible with 5.15
<qschulz>
5.12*
<qschulz>
but it might be difficult without modifying layer.conf manually (to add the currently used version to the compatibility list)
<qschulz>
and that is probably not enough also to make it build
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<faruk>
qschulz: I'm very new at this job. What way should I follow? Do you have any advice?
<qschulz>
faruk: trying to find a commit in the branch of the release you're cuirrently using which points to 5.12 seems like a good first try
<qschulz>
then there might be some more work involved to make it compile
<qschulz>
there's no one-size fits all answer here unfortunately
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<qschulz>
qt is a complex beast so the usual recommendation of "just backport the recipe" might not be the best
<qschulz>
(especially since there's the qmake bbclass and all other include files and whatnot)
<qschulz>
but also, I remember there was one environment variable for enabling logs of different things
<jclsn>
I already read that back and forth
<qschulz>
and that helped me a lot to debug stuff back then
<qschulz>
but that was about 6 years ago
<jclsn>
I already enabled that
<qschulz>
then I cannot help more :)
<jclsn>
Thanks you anyway as always
<jclsn>
Ah seems like eglfs_kms is using the proprietary Broadcom driver and eglfs_kms_egldevice an open source one
<jclsn>
Maybe I should try the proprietary
<agherzan>
@jclsn have you tried khem: 's yoe distro?
<agherzan>
I personally haven't played much with Qt on rpi
<jclsn>
agherzan: I tried the qtbase_%.bbappend from meta-yoe,b ut not the whole distro
<agherzan>
Start with something that works. I'd give yoe a try first
<jclsn>
I think there is just one package missing
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
<jclsn>
I'd rather compare my setup to this .bbappends in the layer than start from scratch
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
florian has joined #yocto
<jclsn>
qschulz: I btw created a ticket for Yocto community work considering the PREMIRRORS bug during the sprint planning yesterday. I will see how my company feels about giving something back. ^^ My boss wasn't present
<qschulz>
jclsn: don't remember an issue with PREMIRRORS, is there a bug report somewhere?
<RP>
kanavin: Just to finish things off, my desk's chair has collapsed :)
* RP
will have to go and weld it back together
florian has quit [Ping timeout: 250 seconds]
WeekendWorm has joined #yocto
<paulg>
just put two unused desktop PCs together and set a cushion on top. :-P
WeekendWorm has quit [Client Quit]
<qschulz>
RP: michaelo[m]: ndec: I don't like that the default docs are pointing to the dev version, anyone against using the latest release instead as defaultand have a "dev" sub-URL (what's the name? docs.yoctoproject.org/dev/) for the master branch?
MisterMongolia has joined #yocto
<qschulz>
why I don't like it: it shows something that isn't released yet and might confuse users. I assume most people aren't using the master branch but the latest release. And if there's a significant change in behavior and variable and they are looking at the docs after that change, they'll try something that does not work
<qschulz>
one perfect example is the variable rename for example
<qschulz>
or during the override syntax change for example
<MisterMongolia>
Howdy! Is there a way to see a human friendly list of task dependencies? If I were to do just `bitbake recipe` what would be the list of tasks in the chronological order which will be executed.
<MisterMongolia>
paulg: Thanks. Can't get the UI to load. As for the `bitbake -g recipe` that gives a global dependency list. Can filter out by the recipe name, but not sure if I'm allowed to trust the print order to be the execution order
sgw has quit [Ping timeout: 260 seconds]
AmarjargalGundja is now known as Amarjargal[m]
<JaMa>
MisterMongolia: bitbake --dry-run is also helpful
faruk has quit [Quit: Leaving]
sgw has joined #yocto
<amahnui[m]>
I think I did it.
<amahnui[m]>
the main issue I am facing now is how to go around the `UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 99: invalid start byte` and the `UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 158: invalid continuation byte` error I get after the script has edited some of the files in the folder containing the versions you sent (0.9 to 3.1.3) and i'm thinking it has to do with the encoding of the html
<amahnui[m]>
`<meta charset="UFT-8">` and it might be stopping it from accepting modifications.
<amahnui[m]>
I tested it in directories that have many subdirectories and contains html and css files as well and it successfully added the codes to them
* amahnui[m]
is just thinking that could be the issue especially as it successfully modifies some of the files before stopping at this error.
<amahnui[m]>
RP qschulz ndec what are your thoughts please
<amahnui[m]>
Can I send the files here so you check it out?
<qschulz>
amahnui[m]: send a patch for yocto-autobuilder-helper git repo
<Saur[m]>
amahnui: RFC = Request For Comments. Typically, if you have an idea about how to solve something, but you are not sure it's the best way to do it, then you can send the patch (or what you have) as an RFC and ask others for tips and ideas.
<jclsn>
qschulz: So there is nothing in MACHINE_EXTRA_IMAGE_INSTALL, but the drivers should be there https://pastebin.com/JzSvKdzU
<amahnui[m]>
Saur: thanks a lot for that I will definitely add that to my patch
Vonter has quit [Quit: WeeChat 3.5]
Vonter has joined #yocto
<jclsn>
qschulz: Damn it
<jclsn>
The problem was that I was using the vc4-kms-v3d instead of vc4-fkms-v3d
<jclsn>
So just an an entry in the config.txt needed to be changed
Vonter has quit [Quit: WeeChat 3.5]
Vonter has joined #yocto
<jclsn>
agherzan: Shouldn't eglfs run with normal kms?
Vonter has quit [Client Quit]
Vonter has joined #yocto
<qschulz>
amahnui[m]: RFC = Request For Comment
<jclsn>
There is also not an option to set this from the local.conf
<qschulz>
amahnui[m]: didn't receive anything from you on the mailing list
<jclsn>
Will just append it. What the heck..
<qschulz>
amahnui[m]: triple check the address is correct
<qschulz>
amahnui[m]: and check that you're also subscribed to the mailing list
<qschulz>
amahnui[m]: ahah! my professional mail address is not subscribed to that one yet so I didn't see it :)
<amahnui[m]>
qschulz: I sent it twice before realising that I was not subscribed to it :)
<amahnui[m]>
* qschulz: I sent the patch twice before realising that I was not subscribed to it :)
<jclsn>
God, for one month I have been searching for this and it was just the wrong dtoverlay... :D
<jclsn>
qschulz: Thanks for the GPU tip. That really brought me there
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
bonalais has joined #yocto
<bonalais>
nick
nemik has quit [Ping timeout: 250 seconds]
bonalais is now known as amahnui
nemik has joined #yocto
florian has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<RP>
qschulz: I'd be ok with changing the default
* RP
thinks we may be nearly ready for rc3. Just an open question of whether to risk any more fixes that are on the list and the question on systemd intermittent issues
<RP>
paulg: I should have gone for the old servers, that would have been much simpler
<paulg>
well, I guess that depends on where it broke and how much welding you've done in the past. :-)
<paulg>
and if you've got a couple old unloved PCs around (I was willing to gamble on that one)
<jclsn>
agherzan: SPI is still not working althoug I have activated it in the config.txt. Do I have to use another kernel that linux-raspberrypi?
<jclsn>
I actually checked whether the needed modules are present and they are, which is weird
<jclsn>
Usually the ADC is listed under /sys/bus/iio, but with the Yocto build there is nothing
<khem>
jclsn: is it enabled in kernel confg and dtb
<khem>
:q
<jclsn>
@khem will check
<jclsn>
I was assuming that the standard Pi kernel is built though
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<jclsn>
Also: The MCP320X module is activated. So I would assume that all necessary dependencies are as well
<khem>
hmm ok then it is some dt overlay issue then
<jclsn>
khem: But the config.txt is identical to the one from my Raspbian installation
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
<jclsn>
ENABLE_SPI_BUS="1" is set. I also tried doing it manually with dtparam=spi=on, which is the same
<jclsn>
I will try to just always load the driver regardless of the overlaay
<jclsn>
see if that makes a difference
<khem>
check lsmod | grep spi_
<jclsn>
Hmm I can only build it as a module. Weird
<jclsn>
lsmod is not installed haha
beneth has quit [Quit: Gateway shutdown]
<jclsn>
coreutils I guess?
<khem>
I think you should include all kernel-modules in image
<paulg>
"cat /proc/modules" perhaps?
<paulg>
in the beginning, I think lsmod was a shell script that did that?
<paulg>
that would be 1990s kind of time frame
<paulg>
<---- old.
<jclsn>
Should be there
<khem>
we do have it in MACHINE_EXTRA_RRECOMMENDS. do you have .ko files in /lib/modules
<vmeson>
There are graphs of the YP patch count and Upstream-Status ... link anyone?
<kanavin>
RP: I wrote a summary to the avahi systemd bug, I'm currently out of ideas how to move forward
PriyanshSingh[m] has joined #yocto
<jclsn>
khem: yes, seems like the .dtbo files are missing on the boot partition
<jclsn>
I have them on the Raspian installation
<jclsn>
I will clean build the kernel. See if that helps
<jclsn>
I think I had a similar issue when I manually built the kernel last time. I thought there was something wrong on my end at let Phil merge it anyway
<jclsn>
So maybe there is a bug in the makefile
<jclsn>
Yeah but why would that be the case for the health sensor and the ADC. Doesn't make sense
<jclsn>
It just assumes that the overlay is there, which it is in the kernel that ships with Raspbian
<jclsn>
But well I won't argue
<khem>
raspbian != yocto and in that article it would have been good to document the platform it assumed perhaps
<jclsn>
Okay
<jclsn>
Sure it assumes Raspian
<jclsn>
But given that the whole overlays folder is ~750kB in size...
* jclsn
shrugs
<khem>
as I said, add the missing ones and send a patch to meta-raspberrypi
* jclsn
said he won't argue
<jclsn>
Okay
<jclsn>
Will make a list
goliath has joined #yocto
<halstead>
amahnui[m]: May I assign the bug to you?
rber|res has quit [Ping timeout: 240 seconds]
<amahnui[m]>
I would like to know the approach you used as what I'm doing is not certain yet and is open for corrections
<amahnui[m]>
* halstead: I would
amahnui has joined #yocto
<jclsn>
khem: Works!
<jclsn>
I will make a PR with the ADC
<jclsn>
Should be enough for now
<halstead>
amahnui[m]: I haven't worked on that bug recently enough to recall. I'm happy to advise.
<jclsn>
It didn't build with the whole list from Raspian, so I guess you have a point
<halstead>
amahnui[m]: One part of the bug is to download the current tarball and modify the files to have headers. Then I can place a new tarball. I'll add that to the bug.
<amahnui[m]>
halstead: I sent a patch here and I really like to get ways to improve it
<amahnui[m]>
It encouters an error when it meets uft-8 encoding so the modification does get completed.
<halstead>
amahnui[m]: I added some information and assigned the bug to you for now.
<halstead>
amahnui[m]: I'm in a maintenance window right now but I can look at your patch after. I'm curious, will we need to run this script more than once?
<amahnui[m]>
But as I said, there is an encoding issue withholding the script from completing the recursion. But if that is fixed then I believe it will go through the whole directory and carry out the modifications
<amahnui[m]>
No there are two scripts, one modifies the .html files while the other modifies the .css files.
<amahnui[m]>
Each of the 2 scripts will be run just once.
florian has quit [Ping timeout: 240 seconds]
jmiehe has joined #yocto
nsbdfl has quit [Ping timeout: 250 seconds]
nsbdfl has joined #yocto
<amahnui[m]>
halstead: I would be very grateful.
florian has joined #yocto
GLumen has quit [Remote host closed the connection]
GLumen has joined #yocto
GLumen has quit [Remote host closed the connection]
GLumen has joined #yocto
florian has quit [Ping timeout: 240 seconds]
Vonter has quit [Ping timeout: 246 seconds]
florian has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
amahnui has quit [Quit: Connection closed for inactivity]
<RP>
khem: I queued a gcc 12 build
<RP>
halstead: my thinking is we'd extract the tarball and then run the script against the output, at least for now
<RP>
halstead: we may or may not choose to update the tarball. ndec also suggested we may want to make the tarball a git repo or branch but I'm not sure you want that sized data being pulled in.out
* RP
wonders if we really still want subversion in core
<RP>
khem: the gcc12 build may fail due to other autobuilder issues :/
<RP>
khem: I'm totally overloaded so I really don't want to do this but I know it will make life simpler if we can get gcc 12 fixed now
goliath has quit [Quit: SIGSEGV]
florian has quit [Ping timeout: 240 seconds]
mvlad has quit [Remote host closed the connection]