[00:04] Anyone around who is in ~ubuntu-dev and can help me understand your end of CIVS please? [00:05] 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] 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] We had to use LP polls, which...were quite terrible for that. [00:06] Unit193: you for example are currently held I think. Can you confirm that you haven't received anything? [00:06] And should I just ask everyone to opt-in to vote, then? [00:07] I got nothing. [00:08] Unit193: could you try https://civs1.civs.us/cgi-bin/opt_in.pl please? [00:08] with @ubuntu.com since that's the email I have for you [00:09] Email address successfully activated. [00:09] Pending poll invitations: [00:09] Ubuntu Developer Membership Board restaffing [00:10] Thanks! [00:10] I'll give details in the announcement then. [00:10] The trickiest thing is probably to help people understand what alias I am using for them. [00:10] dpocock used it to spam Debian, so that's why we can't have nice things. :/ [00:11] rbasak: Email all the people on hold, using that email address? :P [00:14] I'm concerned I'd have email deliverability problems with that :-/ [00:14] But yeah, I could do that. [00:14] For now I'm just going to send an announcement with an explanation I think. [00:14] Let's see if people can figure it out. If it doesn't work, I can try something else. [00:14] People who struggle to get their ballot should contact me. [00:15] (and I'll note that in the announcement - previous equivalent announcements have always said that anyway) [00:16] ...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] u-d-a@lists.u.c moderation please === cpaelzer_ is now known as cpaelzer [10:38] Hi there! Could a Core Dev please click on those autopkgtests links? https://paste.ubuntu.com/p/tpM6h5y6PP/ [11:01] schopin: doing... [11:03] . [11:03] thanks ginggs ! [11:04] de rien [11:05] rbasak: . [14:43] 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] unsure if this is golang 1.18 related or not [15:01] There have build failures on riscv64 in general recently I belive cjwatson may know more. [15:02] bdmurray: that Go thing is unrelated to anything I've been working on, and I don't know about it [15:02] Doesn't look like a builder-level issue [15:04] Oh, I guess there is a log file which wasn't true with other things. Sorry! [15:05] didrocks: bdmurray: "fatal error: mheap.freeSpanLocked - invalid stack free" this is inside the go runtime. [15:10] 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] didrocks: I'll take a look [15:11] thanks! === rharper_ is now known as rharper [15:52] didrocks: adsys is building successfully on my Unmatched hardware, so I'll restart this build. [15:52] It also built successfully for me in a riscv64 qemu environment. Both builds were done with Go 1.18 [16:01] interesting, let’s see if we just got unlucky [16:06] seb128: uhhhhh exactly how much of Universe is impacted by the dhcompat problem you emailed about? [16:06] 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] (RC bugs and what not) [16:07] continuing to support $ANCIENT dh-compat sounds... a little bit poor. [16:07] (also this is relevant because it'll affect a debhelper backport that's been requested) [16:14] 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] we can maybe get data from the archive rebuild if we are able to grep logs [16:16] 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] i'm with Dimitri on this one, its package overhaul (or removal!) time for incompatible and old dhcompats. [16:27] It should be just a source grep rather than needing to grep logs, shouldn't it? [16:28] 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] fun, AX_COMPARE_VERSION from autoconf thinks python 3.10 is 3.1 [18:12] and comparisons like these don't produce the expected result: AX_COMPARE_VERSION(${PYTHON_VERSION}, [ge], [3.8], [EMBED="--embed"], []) [18:12] in jammy, which is using python 3.10 [18:12] 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] freeradius is a confirmed bug, I'm working on it [18:13] just a heads up [18:13] (I might email the list later) [18:23] autoconf-archive FWIW, not autoconf itself [18:23] AX_* are all separately-distributed add-ons [18:40] indeed [19:05] 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] like very scary [19:06] like i want to SRU them all. [19:26] didrocks is gone, but xypron adsys built fine with a retry [22:30] oh, false alarm about AX_COMPARE_VERSION, the bug was elsewhere [22:30] it was fed 3.1 instead of 3.10 [22:43] xnox, feel free to SRU things as you see fit :)