[00:04] <rbasak> Anyone around who is in ~ubuntu-dev and can help me understand your end of CIVS please?
[00:05] <rbasak> I think people need to opt-in to receiving CIVS polls now. I need to make sure I understand what is required in order to specify that in the announcement and avoid confusion.
[00:06] <Unit193> Yes, we ran into that issue last round with the IRCC election, I had spoken to someone from Canonical about the possibility of running an instance of CIVS, but that didn't get anywhere. :/
[00:06] <Unit193> We had to use LP polls, which...were quite terrible for that.
[00:06] <rbasak> Unit193: you for example are currently held I think. Can you confirm that you haven't received anything?
[00:06] <rbasak> And should I just ask everyone to opt-in to vote, then?
[00:07] <Unit193> I got nothing.
[00:08] <rbasak> Unit193: could you try https://civs1.civs.us/cgi-bin/opt_in.pl please?
[00:08] <rbasak> with <username>@ubuntu.com since that's the email I have for you
[00:09] <Unit193> Email address successfully activated.
[00:09] <Unit193> Pending poll invitations:
[00:09] <Unit193> Ubuntu Developer Membership Board restaffing
[00:10] <rbasak> Thanks!
[00:10] <rbasak> I'll give details in the announcement then.
[00:10] <rbasak> The trickiest thing is probably to help people understand what alias I am using for them.
[00:10] <Unit193> dpocock used it to spam Debian, so that's why we can't have nice things. :/
[00:11] <Unit193> rbasak: Email all the people on hold, using that email address? :P
[00:14] <rbasak> I'm concerned I'd have email deliverability problems with that :-/
[00:14] <rbasak> But yeah, I could do that.
[00:14] <rbasak> For now I'm just going to send an announcement with an explanation I think.
[00:14] <rbasak> Let's see if people can figure it out. If it doesn't work, I can try something else.
[00:14] <rbasak> People who struggle to get their ballot should contact me.
[00:15] <rbasak> (and I'll note that in the announcement - previous equivalent announcements have always said that anyway)
[00:16] <Unit193> ...Some of us are a bit stupid and were surprised the first time we got a ballot, weren't expecting to vote. :3
[00:35] <rbasak> u-d-a@lists.u.c moderation please
[10:38] <schopin> Hi there! Could a Core Dev please click on those autopkgtests links? https://paste.ubuntu.com/p/tpM6h5y6PP/
[11:01] <ginggs> schopin: doing...
[11:03] <ginggs> .
[11:03] <schopin> thanks ginggs !
[11:04] <ginggs> de rien
[11:05] <cjwatson> rbasak: .
[14:43] <didrocks> hey xypron! Do you have any idea on this Go build failure on riscv64 only? https://launchpadlibrarian.net/592536294/buildlog_ubuntu-jammy-riscv64.adsys_0.8.3_BUILDING.txt.gz
[14:43] <didrocks> unsure if this is golang 1.18 related or not
[15:01] <bdmurray> There have build failures on riscv64 in general recently I belive cjwatson may know more.
[15:02] <cjwatson> bdmurray: that Go thing is unrelated to anything I've been working on, and I don't know about it
[15:02] <cjwatson> Doesn't look like a builder-level issue
[15:04] <bdmurray> Oh, I guess there is a log file which wasn't true with other things. Sorry!
[15:05] <xypron> didrocks: bdmurray: "fatal error: mheap.freeSpanLocked - invalid stack free" this is inside the go runtime.
[15:10] <didrocks> jawn-smith: can you have a look? It seems it’s Go 1.18 related as last upload is recent on 1.17 and worked (no code change in the part that is now failing) ^
[15:11] <jawn-smith> didrocks: I'll take a look
[15:11] <didrocks> thanks!
[15:52] <jawn-smith> didrocks: adsys is building successfully on my Unmatched hardware, so I'll restart this build.
[15:52] <jawn-smith> It also built successfully for me in a riscv64 qemu environment. Both builds were done with Go 1.18
[16:01] <didrocks> interesting, let’s see if we just got unlucky
[16:06] <teward> seb128: uhhhhh exactly how much of Universe is impacted by the dhcompat problem you emailed about?
[16:06] <teward> I ask because I am pretty sure all these things that are no longer compatible or updated with DH compatibility to later versions are 'unmaintained' in Debian and probably subject to removal/chaos there
[16:06] <teward> (RC bugs and what not)
[16:07] <teward> continuing to support $ANCIENT dh-compat sounds... a little bit poor.
[16:07] <teward> (also this is relevant because it'll affect a debhelper backport that's been requested)
[16:14] <seb128> teward, I don't know, we have like 10 in the desktop set in main which is somehow activelly maintained, so I would say if we already have that number in a small set from main, then number is probably higher in universe
[16:15] <seb128> we can maybe get data from the archive rebuild if we are able to grep logs
[16:16] <teward> actively maintained from a code perspective or a pakaging perspective?  if the *packaging* is unmaintained and not updated its just as bad as bitrot.  just sayinh
[16:18] <teward> i'm with Dimitri on this one, its package overhaul (or removal!) time for incompatible and old dhcompats.
[16:27] <cjwatson> It should be just a source grep rather than needing to grep logs, shouldn't it?
[16:28] <cjwatson> Admittedly slightly complicated by debian/compat vs. modern Build-Depends: debhelper-compat (= X), although the latter doesn't apply to those old debhelper compat versions anyway
[18:11] <ahasenack> fun, AX_COMPARE_VERSION from autoconf thinks python 3.10 is 3.1
[18:12] <ahasenack> and comparisons like these don't produce the expected result: AX_COMPARE_VERSION(${PYTHON_VERSION}, [ge], [3.8], [EMBED="--embed"], [])
[18:12] <ahasenack> in jammy, which is using python 3.10
[18:12] <ahasenack> https://codesearch.debian.net/search?q=AX_COMPARE_VERSION.*python&literal=0 and https://codesearch.debian.net/search?q=AX_COMPARE_VERSION.*python&literal=0 show some hits
[18:12] <ahasenack> freeradius is a confirmed bug, I'm working on it
[18:13] <ahasenack> just a heads up
[18:13] <ahasenack> (I might email the list later)
[18:23] <cjwatson> autoconf-archive FWIW, not autoconf itself
[18:23] <cjwatson> AX_* are all separately-distributed add-ons
[18:40] <ahasenack> indeed
[19:05] <xnox> seb128:  even if compat=5 packages used to build; it's not been known for a couple of years now if they build correctly anymore. so that sounds scary that there are packages in the desktop set, that use compat 5 since precise.
[19:06] <xnox> like very scary
[19:06] <xnox> like i want to SRU them all.
[19:26] <jawn-smith> didrocks is gone, but xypron adsys built fine with a retry
[22:30] <ahasenack> oh, false alarm about AX_COMPARE_VERSION, the bug was elsewhere
[22:30] <ahasenack> it was fed 3.1 instead of 3.10
[22:43] <seb128> xnox, feel free to SRU things as you see fit :)