<RP>
kanavin_: I just saw your valgrind email. I nearly suggested that on Friday but decided I needed to wait a few days
<kanavin_>
RP: I have a bit more freedom addressing elephants in the room than you do :)
<kanavin_>
it's just alex being alex :D
<kanavin_>
that and I do have a real headache now, so maybe afk would be good for a bit
mbulut has quit [Ping timeout: 265 seconds]
florian_kc has joined #yocto
florian has quit [Ping timeout: 252 seconds]
gportay has joined #yocto
DvorkinDmitry has joined #yocto
gportay has quit [Client Quit]
gportay has joined #yocto
gportay has quit [Ping timeout: 240 seconds]
florian_kc is now known as florian
<qschulz>
is there a way to silence bitbake output entirely except for errors?
<qschulz>
context: trying to use patchtest as b4 prep --check tool, but it needs to output nothing to stderr or stdout when all tests pass
<RP>
qschulz: --quiet option?
<RP>
qschulz: I can't remember exactly what that does tbh
<qschulz>
RP: will check but I doubt bitbake is started from its CLI binary but rather directly from a python module
<RP>
kanavin_, vmeson: would it be worth a call to action in the reproducible builds newsletter on rustdoc or other rust issues?
<RP>
qschulz: in that case you can change the logging levels
<kanavin_>
RP: I think so, we found a workaround for rustdoc (disable llvm lto), but why it affects only rustdoc but none of the other rust executables remains a mystery.
<kanavin_>
the problem is we're on outdated rust. we'd have a much stronger claim if it was confirmed with latest rust release.
<kanavin_>
(it probably is, we just can't claim that)
ehussain has quit [Remote host closed the connection]
ehussain has joined #yocto
<qschulz>
RP: thanks, that was a great hint, it's using Tinfoil AND Knotty and you can "mock" the number of --quiet passed to Knotty :)
<qschulz>
tgamblin: is patchtest to be used only on patches destined for OE-Core?
<qschulz>
specifically test_target_mailing_list() test seems to be checking for anything that shouldn't be sent to OE-Core ML?
<RP>
qschulz: it probably focuses on oe-core atm, generalising it is a future aim
<qschulz>
RP: ah, so maybe too early to try using it with b4 for local checking :)
<RP>
qschulz: well, I like the idea. Can we not skip that test?
<tgamblin>
qschulz: for now, but I am trying to refactor it to be more generic
<qschulz>
RP: I don't know which other tests are expected to run on oe-core only
amitk has joined #yocto
<qschulz>
tgamblin: FYI, I had the idea of using patchtest locally as a per-commit validation check for oe-core, poky, yocto-docs, bitbake
<RP>
qschulz: we could put decorators on the tests or something?
<qschulz>
but that requires a few changes already to patchtest
<RP>
qschulz: we can change patchtest :)
<RP>
qschulz: I would be happy to see the b4 config first before we add this though too
<qschulz>
RP: ok, so no b4 prep --check support initially
<qschulz>
or maybe the one I came up with
<qschulz>
in the first patch
Tyaku has joined #yocto
<tgamblin>
qschulz: yeah, the current iteration is unwieldly - it's very easy to break the entire patchtest logic by changing small things. I am simultaneously trying to fix outstanding bugs in the current iteration and doing a rewrite here: git@github.com:threexc/patchtest2.git
<tgamblin>
the latter isn't going to be ready for a while yet, though
<qschulz>
(checking a patch doesn't touch multiple projects, checking not multiple projects are touched by multiple patches in one patch series)
amitk_ has quit [Ping timeout: 252 seconds]
<qschulz>
tgamblin: I'll send some of the work I've done so far if you want, there's one patch I really dislike but I don't know how to handle properly
<tgamblin>
qschulz: sure, I'm happy to take patches and review what you're not sure about
<qschulz>
Essentially, b4 sends the mbox via stdin to a specified command-line executable
<qschulz>
however, it strips the "From " part of it
<qschulz>
so this fails the patchtest.Mbox parsing (there's an assert there)
<qschulz>
for now I just propagate a boolean (allow_malformed) but this is... yuck
ehussain has quit [Remote host closed the connection]
ehussain has joined #yocto
vvn has quit [Quit: WeeChat 4.5.1]
uartz has joined #yocto
<tgamblin>
qschulz: yeah, that is a problem... it turns out that a lot of the difficulties related to making patchtest work well come from handling mbox formats effectively :)
<tgamblin>
for example, in my refactor, I was trying to make a more robust test for the presence of a commit message on Friday. The rendition that I was working with checked to see if there was any content between the "From:" and "Signed-off-by" lines, but the latter is a bad bound to use if you also want to test for the presence of a signoff
<kanavin_>
RP: feeling light-headed, can't formulate coherent sentences well :)
<kanavin_>
(re contributing to reproducibility report)
<tgamblin>
ideally patchtest's tests should all be more-or-less independent of each other, both so that you aren't doing redundant testing and so that different layers/projects can omit certain ones without missing context
<RP>
kanavin_: probably not a good time to be in front of a computer then! I'll see if vmeson has anything, I probably don't know enough to write it
<qschulz>
tgamblin: aren't you applying the patch locally? Then we should be able to simply extract those individually with git (if not a malformed patch, but then we have bigger issues anyway)?
<tgamblin>
qschulz: yes, but thinking long-term the "does the patch apply?" testing should also be independent of the others. The other tests are looking for content, added/modified/removed files, etc., so it doesn't need to go that far
<qschulz>
tgamblin: I don't think we need to run more tests if the application doesn't work
<qschulz>
and then, you can simply use git tools for that
<qschulz>
which would be much better than trying to parse stuff manually
<qschulz>
(I'm saying that but my b4 prep --check script right now is parsing it essentually manually :) )
<qschulz>
(except that I use lsdiff to identify which files are modified :) )
<tgamblin>
qschulz: maybe. The way patchtest is designed has it report as many results as it can. Even if we go ahead and allow the user to omit certain tests, I'm not sure that stopping immediately when the apply fails is the right approach
<qschulz>
tgamblin: I understand, the pain of maintaining regexp though :/
<tgamblin>
qschulz: absolutely. I've spent a lot of time on regex101 testing out patterns for various tests :(
vvn has joined #yocto
rob_w has quit [Remote host closed the connection]
<Tyaku>
Hello, I have some issue with udev/systemd: I want systematically to get the ethernet interface from platform / DTS at eth0 and the usb-ethernet device at eth1. But on startup I get the reverse order, I try to deal with udev, but doesn't seems to take effect:
<Tyaku>
My bad, just reading it it's possible that I found the problem: SUBSYSTEM is platform for the "physical ethernet"
<Tyaku>
Finally not :/
sgw has quit [Ping timeout: 245 seconds]
sgw has joined #yocto
goliath has quit [Quit: SIGSEGV]
vermaete has joined #yocto
<mckoan>
Tyaku: try udevadm monitor
ehussain has quit [Ping timeout: 252 seconds]
florian has quit [Ping timeout: 252 seconds]
jmd has joined #yocto
<vmeson>
RP: On Rust reproducibility in the r-builds newsletter: sure, it's good to raise the issue and try to motivate people to work on the upstream ticket with Sundeep .
Kubu_work has quit [Quit: Leaving.]
<vmeson>
RP: do you want us to give you a first draft or review something that you put together ?
<qschulz>
tgamblin: there you get to see my ugly code :)
<RP>
vmeson: I'm happy enough for you to submit something :)
<vmeson>
RP: will do, aiming for Wednesday so we can talk about it on Thursday's call.
<RP>
vmeson: you probably don't have long for this months newsletter FWIW
<qschulz>
tgamblin: np, FWIW I don't plan on working on that much than that, so see it as a code dump if anyone wants to do something with it (I can do small changes if necessary, but Yocto won't be on my priority list for a while :/)
<tgamblin>
qschulz: that's fine. I'll need to grab the patches and do some testing with them
frieder has quit [Remote host closed the connection]
frgo has quit [Remote host closed the connection]
frgo has joined #yocto
Kubu_work has joined #yocto
rfuentess has quit [Remote host closed the connection]
<mckoan>
ERROR: qtbase-5.15.13+git-r0 do_fetch: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'git://code.qt.io/qtbase.git;name=qtbase;branch=5.15;protocol=git')
<mckoan>
anyone noticed this?
goliath has joined #yocto
vvn has quit [Quit: WeeChat 4.5.1]
florian has quit [Ping timeout: 248 seconds]
<mckoan>
mckoan: get rid of meta-qt6 that is defining QT_GIT_PROTOCOL (doh)
Chris86 has joined #yocto
mckoan is now known as mckoan|away
<Chris86>
please forgive me if I screw this up. I haven't used IRC for years.
<Chris86>
but I hope you can help me figure out how to get systemd-journal-remote and systemd-journal-gatewayd to build in my zynqmp-oriented rootfs build
<fray>
You need to use a distribution that has systemd enabled. poky-alt for instance.
<fray>
then look in recipes-core/systemd and inspect thef iles to see if the configuration needs to be adjusted for what you want..
<Chris86>
thanks. yes, I'm using poky, and I do get a rootfs with systemd built.
<fray>
poky (default) is sysvinit.. pokyalt-cfg is systemd
<fray>
you can build systemd components in a sysvinit specific environment, but they won't work the way you probably want..
<Chris86>
hm. ok. the init program at boot is systemd. and I start and stop services using systemctl
<Chris86>
the old systemv way of doing things ... seems to still exist, but have very few startup/shutdown scripts. all of the actual config happens by altering systemd service files.
<Chris86>
so I believe my machine uses systemd.
gportay has joined #yocto
<fray>
like I said, just ensure your config is correct. One there, then you can focus on the component itself. Thats the meta/recipes-core/systemd files.
<fray>
those are all of the configuration options that are available
<fray>
if you scroll up a bit you will see 'PACKAGECONFIG' thesse are the default enabled options. You can override that in a .bbappend or in your local.conf via: PACKAGECONFIG:pn-systemd = "replacement values" or PACKAGECONFIG:append:pn-systemd = " additional" (note leading space)
<Chris86>
what I think I may be running into is ths "ENABLE_REMOTE" setting in the meson.build thing.
<Chris86>
I can cause systemd to build, but systemd-journal-gatewayd does not. I see the source files, but they aren't built
<khem>
rburton:sometimes I see this error "ERROR: The file /usr/share/aclocal/glib-2.0.m4 is installed by both glib-2.0 and glib-2.0-initial, aborting"
<khem>
especially with swupdate images
frgo has quit [Remote host closed the connection]
<Chris86>
greping: 'tmp/work/cortexa72-cortexa53-poky-linux/systemd/1_251.8-r0/git/sysusers.d/meson.build:if enable_sysusers and conf.get('ENABLE_REMOTE') == 1 and conf.get('HAVE_MICROHTTPD') == 1'
<khem>
I think packaging aclocal files with initial recipes is useless anyway so perhaps it should be deleted
frgo has joined #yocto
<fray>
Sorry, I don't know.
<Chris86>
Thanks fray. I will verify that I have things set up as you have said
florian has joined #yocto
Kubu_work has quit [Quit: Leaving.]
gportay has quit [Ping timeout: 240 seconds]
jmd has left #yocto [ERC 5.4 (IRC client for GNU Emacs 28.2)]
frgo_ has joined #yocto
<vermaete>
I'm blocked with something....
<vermaete>
I have an Kas project. Latest version of kas.
<vermaete>
Bitbake does work. And is version 2.9.1
<vermaete>
but when running devtool I get this error: