rbasak | Anyone around who is in ~ubuntu-dev and can help me understand your end of CIVS please? | 00:04 |
---|---|---|
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:05 |
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:06 |
Unit193 | I got nothing. | 00:07 |
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:08 |
Unit193 | Email address successfully activated. | 00:09 |
Unit193 | Pending poll invitations: | 00:09 |
Unit193 | Ubuntu Developer Membership Board restaffing | 00:09 |
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:10 |
Unit193 | rbasak: Email all the people on hold, using that email address? :P | 00:11 |
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:14 |
rbasak | (and I'll note that in the announcement - previous equivalent announcements have always said that anyway) | 00:15 |
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:16 |
rbasak | u-d-a@lists.u.c moderation please | 00:35 |
=== cpaelzer_ is now known as cpaelzer | ||
schopin | Hi there! Could a Core Dev please click on those autopkgtests links? https://paste.ubuntu.com/p/tpM6h5y6PP/ | 10:38 |
ginggs | schopin: doing... | 11:01 |
ginggs | . | 11:03 |
schopin | thanks ginggs ! | 11:03 |
ginggs | de rien | 11:04 |
cjwatson | rbasak: . | 11:05 |
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 | 14:43 |
bdmurray | There have build failures on riscv64 in general recently I belive cjwatson may know more. | 15:01 |
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:02 |
bdmurray | Oh, I guess there is a log file which wasn't true with other things. Sorry! | 15:04 |
xypron | didrocks: bdmurray: "fatal error: mheap.freeSpanLocked - invalid stack free" this is inside the go runtime. | 15:05 |
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:10 |
jawn-smith | didrocks: I'll take a look | 15:11 |
didrocks | thanks! | 15:11 |
=== rharper_ is now known as rharper | ||
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 | 15:52 |
didrocks | interesting, let’s see if we just got unlucky | 16:01 |
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:06 |
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:07 |
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:14 |
seb128 | we can maybe get data from the archive rebuild if we are able to grep logs | 16:15 |
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:16 |
teward | i'm with Dimitri on this one, its package overhaul (or removal!) time for incompatible and old dhcompats. | 16:18 |
cjwatson | It should be just a source grep rather than needing to grep logs, shouldn't it? | 16:27 |
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 | 16:28 |
ahasenack | fun, AX_COMPARE_VERSION from autoconf thinks python 3.10 is 3.1 | 18:11 |
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:12 |
ahasenack | just a heads up | 18:13 |
ahasenack | (I might email the list later) | 18:13 |
cjwatson | autoconf-archive FWIW, not autoconf itself | 18:23 |
cjwatson | AX_* are all separately-distributed add-ons | 18:23 |
ahasenack | indeed | 18:40 |
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:05 |
xnox | like very scary | 19:06 |
xnox | like i want to SRU them all. | 19:06 |
jawn-smith | didrocks is gone, but xypron adsys built fine with a retry | 19:26 |
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:30 |
seb128 | xnox, feel free to SRU things as you see fit :) | 22:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!