[02:08] bryceh: so what happened here? https://pastebin.ubuntu.com/p/mFYzYrdY4c/ [02:13] bryceh: I'd expect the result urls to appear here https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic-brian-murray-autopkgtest/?format=plain but I'm not seeing anything [05:13] bdmurray, add the --show-urls option [05:15] without that, it assumes your console supports ansi hyperlinking but many consoles do not. If you run it in gnome-terminal it'll be clickable [05:17] latest terminator might, but not sure, and other terminals are hit and miss === sem2peie- is now known as sem2peie === sem2peie- is now known as sem2peie === sem2peie- is now known as sem2peie [09:17] Is it safe to upload something that you know will get stuck in -proposed due to a transition, but that you also know won't entangle the transition any further and will simply move through once the transition gets unstuck? There's some LXQt work I'd like to be doing that is currently stalled on the (probably soon-to-be-finished) Qt transition, and if it's possible for me to do it before the [09:17] transition finishes, that could possibly be good. [09:55] Skuggen: please see bug 2003835 [09:55] -ubottu:#ubuntu-devel- Bug 2003835 in mysql-8.0 (Ubuntu Jammy) "pymysql.err.OperationalError: caching sha2: Unknown packet for public key: b'-'" [Critical, Confirmed] https://launchpad.net/bugs/2003835 [11:47] rbasak: Ouch. I'll pass it on [11:52] Thanks! [13:14] Greetings everyone! [13:19] I'm looking for a sponsor to review patches attached to https://bugs.launchpad.net/ubuntu/+source/pivy/+bug/2000840 [13:19] -ubottu:#ubuntu-devel- Launchpad bug 2000840 in pivy (Ubuntu) "Exception in pivy cast functions with Python 3.10 (upstream patches)" [Undecided, Confirmed] [13:27] arraybolt3: I think that's fine. If we were very worried about that, I think we would turn off autosyncs [13:51] doko, hi :), will a gcc-10 update to 10.4.0 still happen for focal? https://launchpad.net/ubuntu/+source/gcc-10 - https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa/+packages?field.name_filter=&field.status_filter=published&field.series_filter=focal [14:36] coreycb: hi! ceph FTBFS in the last test rebuild, do you happen to know if this is on anyone's radar? [14:36] https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20221215-lunar-normal-lunar.html#ubuntu-openstack-team [15:52] rbasak: mdeslaur: I have a patch for bug 2003835, which I'll upload there [15:52] -ubottu:#ubuntu-devel- Bug 2003835 in mysql-8.0 (Ubuntu Jammy) "pymysql.err.OperationalError: caching sha2: Unknown packet for public key: b'-'" [Critical, Confirmed] https://launchpad.net/bugs/2003835 [15:52] Skuggen: oh, awesome! [15:53] Skuggen: that's great, I'm having trouble building 8.0.31 to revert, so a patch would be awesome [15:57] Uploaded now. Still needs verification, though (I'm building it now) [15:58] Skuggen: thanks, I'll do some builds too and see if we can test it also [16:58] bryceh: with `--show-urls` the urls appear the same i.e. all-proposed was not added [16:59] bryceh: Also is there anyway to get the PPA autopkgtest result urls? That's a huge pain [17:17] ginggs: I've let icey[m] know about ceph [17:21] coreycb: thanks! [17:40] and got it tossed into the backlog to pick up soon! [17:54] icey[m]: great! [18:06] waveform: Where is your core developer application? ;) [20:09] ddstreet: mapreri: poke on you both. backport bug 2003903 ended up on my radar because "openssl" is one of those dangerous/tricky packages to backport so I asked Security Team what their 2 cents was [20:09] -ubottu:#ubuntu-devel- Bug 2003903 in openssl (Ubuntu) "[BPO] openssl/3.0.5-2ubuntu2 from kinetic" [Undecided, New] https://launchpad.net/bugs/2003903 [20:09] (with mdeslaur suggesting the 3 or 4 commits to 'fix' this problem being SRU'd instead) [20:10] (rather than a version bump due to a lot of other chaos that can happen with a minor openssl bump) [20:14] ddstreet: mapreri: is there any objection to me rejecting this request given the problem that this introduces a security related delta and also could cause *other* things to break hard with other api changes in 3.0.5 vs. 3.0.2 because of historic chaos in OpenSSL changes in microreleases? [20:15] Skuggen: hi! unfortunately it doesn't look like the patch fixed the issue in our test, see the last post in the bug [20:18] teward: looking at the user that opened the bug, I'm also led to believe that's some clueless person requesting this. I agree with mdeslaur there; the OP is reporting a very specific bug, if that's fixed by 3-4 commits that should just be SRU'd (or the sec team pushed to include them in the next openssl sec update). [20:19] mapreri: can we add openssl to our list of blacklisted backports [20:19] i think it is but point still stands [20:19] just like the toolchain stuff it needs to be Security handled for backports, etc. and they have a lot of rules around it [20:19] although… I don't really remember "API changes" in minor releases? at least, not in such X.Y.Z with only Z changing… but my point still stand for sure… [20:20] teward: totally yes. I'd accept openssl in bpo only if that was handled by either the sec team or, say, some actual openssl developer (maybe). [20:20] i'd reject it unless it has Security team support :P [20:20] that's my 2 cents i'll go update the wiki and reply here [20:21] thank you [20:21] mapreri: well, rather ABI changes [20:22] mdeslaur: mhh still? ISTR only dropped private interfaces, but there are plenty of projects embedding copies of libssl headers, so I guess that can cause ABI breakages somewhere. [20:22] yes, that's one thing that happens, the other is changing build options breaks abi [20:23] I've have to go through all the bugs we hit in the past [20:23] *I'd [20:23] mdeslaur: is libressl in the repos too, or just openssl? I forget if we have both [20:23] I don't think we have libressl [20:24] so openssl is the only core ssl library we have then [20:24] mapreri: a lot of software in the archive makes bad assumptions about stuff also [20:24] teward: well, except for the zillion others, like nss, gnutls, etc. :) [20:24] then i'll make a category for "core SSL libraries" (nss, gnutls, openssl, ...) in our blacklist for requesting new backports [20:25] yeah, I wouldn't try put ssl libraries, or glibc, or anything else like that in backports [20:26] yeah we have rules already about compilers and interpreters [20:26] mdeslaur: https://wiki.ubuntu.com/UbuntuBackports#Forbidden_packages [20:26] which glibc is included in [20:26] so i'm appending a new category here [20:26] but of course our imagination in preventing them is nowhere close to those of our "users" [20:26] nice [20:27] mdeslaur: yeah when we revived Backports we discussed and came up with an initial set of blacklisted packages and categories that will never be backported via -backports [20:27] and now that includes core SSL libraries as i indicated, though I added a note that if Ubuntu Security Team asked for the backport to -backports we'd probably allow it) [20:27] "request backport for this, and it's rejected immediately due to FOrbidden" [20:27] teward: "Any addition to the section must first be discussed in the ML and agreed by the current team members." - you might wish to follow this tiny line we decided upon and drop a line the ML :) [20:28] * mapreri totally forgot [20:28] ye i'll email it in [20:28] mapreri: yep, but you and I did have a majority on this. right now it's just us three ;) [20:28] it's easy yep heh [20:28] but Security does have a big say here too ;) [20:29] mapreri: remind me which list that is, because i don't see it defined explicity in policies? [20:29] teward: our? [20:29] yep [20:29] ubuntu-backports@luc [20:29] ack [20:30] * mapreri goes to have dinner o/ [20:38] mapreri: emailed. with a note that you and I were in agreement, and that Security would like to agree as well. needs a moderator to release it :\ [20:38] i blame evil in the network [20:38] teward: released [20:38] but how come you are not in the ML? [20:38] ah, maybe wrong address? [20:39] teward: should I place that address in the list whitelist? :) [20:39] mapreri: @ubuntu.com is probably in it, but my SMTP relay for it is down, so I'm having to use my main domain [20:39] mapreri: yes please. [20:39] because of the chaos of ^^ and @ubuntu.com SMTP crap [20:40] (we had the same problem with Community Council, we just whitelist both for me now xD0 [20:40] added [20:40] mapreri: thank you kindly! [20:40] did a @ubuntu.com "official" SMTP that would let me pass SPF/DKIM pop up yet? [20:41] mapreri: no, and i keep stabbing IS on it via Community Team [20:41] with my CC hat on [20:41] *I* run my own SMTP for some of my applications so I just route it via my SMTP server [20:41] that would be quite nice in 2023… [20:41] GMail will still reject it. [20:41] mapreri: agreed. if i can get roadmr or whomever involved to help get the SSO linkage for 'app passwords' integrated with SMTP on something from IS then that'd be great, but IS hasn't ben willing or able to let anyone else volunteer to assist there [20:42] and they have a ton of crap and not enough cycles [20:42] i'll poke it again next time I get off my lazy butt as a CC issue [20:42] "at least" provide a way for us to add a dkim key like @d.o did, that improved things tremendously (though it's busywork and probably easier to just provide a submission service) [20:42] mapreri: i thought Debian had a full submission service too [20:42] not just a DKIM key [20:42] they do, yes [20:43] though just the dkim thing worked so nicely that I have yet to route my @d.o mails through it lol [20:43] (because for Ubuntu the vast array of @ubuntu.com users are NOT sysadmins with the ability to do DKIM configs) [20:43] mapreri: agreed that'd solve a lot [20:43] but then we need to automate DNS too :P [20:43] same thing, SSO integration [20:43] I'm sure DNS is already well automated within IS [20:44] oh, actually my gmail configuration for @d.o is configured to use mail-submit.debian.org - my own mail server does not yet though. [20:45] well, now off to dinner for real! [20:47] mdeslaur: Damn. I'll take it up with the devs. Probably too late for any more work on it today, though [20:48] Skuggen: ok, I'll continue trying to rebuild 8.0.31 to revert...I'm hitting 6-7 test failures now on 8.0.31 for some reason [21:26] I just gave the sponsorship queue a slight facelift, if you run into any issues just let me know (should publish in about 30 minutes): http://reqorts.qa.ubuntu.com/reports/sponsoring/ [21:37] rbasak, bdmurray Robie, would you like me to do some additional testing to cover apt_btrfs_snapshot.py? [21:38] mruffell: no, its just a variable name change from what I can see [21:38] bdmurray: it's not covered in https://wiki.ubuntu.com/StableReleaseUpdates#ubuntu-release-upgrader_and_python-apt. Do we need to change it? [21:39] It also seems weird to end up with non-deliberate changes like that in SRUs? [21:39] Running pre-build.sh takes a deliberate step [21:41] If it was deliberate, you'd have noted it in the commit message and changelog entry. [21:42] What do you want here Robie this is the second time I've uploaded this. [21:43] Sorry if I missed it in my previous review. I don't think it should be there. [21:45] That seems like a harsh comment to make given that I think we're all agreed that the first upload was objectively buggy/racy. I don't think it's reasonable to push back on legit review issues. I think this issue is also legit, because it's explicitly documented SRU policy that we don't make unrelated changes, and there is no exception documented. [21:48] It's perhaps also worth stating that the code can't be verified "obviously correct" from the diff alone. I could check in more detail, but why am I doing that if it shouldn't be there in the first place? [21:49] For /usr/lib/python3/dist-packages/apt_btrfs_snapshot.py to change, apt-btrfs-snapshot must have been changed via SRU. Let me try locate its LP bug [21:50] Thanks mruffell, but can't we just take out this change? [21:51] Hmm, I am wrong, seems apt-btrfs-snapshot has not changed at all, its still the -release version: https://launchpad.net/ubuntu/+source/apt-btrfs-snapshot/3.5.3 [21:51] There's a new in the queue [21:51] How on earth did this file change then... [21:52] bdmurray: did you run pre-build.sh from a Focal system? [21:52] Or was this on something newer that has /usr/lib/python3/dist-packages/apt_btrfs_snapshot.py different to Focal release pocket [21:53] I did run pre-build.sh on a newer system IIRC the goal is to have fixes in apt_btrfs_snapshot from the release to which you are upgrading [21:54] It seems it was fixed in Hirsute onward: https://bugs.launchpad.net/ubuntu/+source/apt-btrfs-snapshot/+bug/1698977 [21:54] -ubottu:#ubuntu-devel- Launchpad bug 1698977 in apt-btrfs-snapshot (Ubuntu) "ftbfs in artful" [High, Fix Released] [21:55] So you ran it on a Jammy system. ubuntu-release-upgrader is run on a Bionic system to upgrade to Focal, maybe Robie has a point [21:55] (but I do agree its a variable rename and shouldn't change any functionality) [21:56] I think if the file changes, the behaviour that it might affect should be part of the test plan. Even if it changed as a result of an SRU, the release upgrade wouldn't have been tested. That doesn't seem right to me. [21:57] I agree it's just a variable rename, but 1) humans are really bad at spotting typos; and 2) it's not just within the loop, since in Python the variable remains in scope afterwards. So while I agree I can't see a typo, I'd want to see the code exercised in place if it's going to be changed, or some other thought out plan to ensure that a typo doesn't lead to a regression. [21:58] Or, IOW, when I review, I don't look for typos, I look for processes to ensure that typos can't slip past. [22:03] rbasak: Brian just uploaded a new package to the unapproved queue with the hunk removed. [22:03] ack - I just accepted [22:04] If we want to accept those in the future then I'm open to that, but I would like to understand what we're doing to ensure such changes are tested. [22:05] Maybe we need to add a note that ubuntu-release-upgrader needs to be prepared for build on the series it was intended to be used on, since it does blind copying of python scripts [22:14] Greetings everybody! [22:40] Hi, I am not sure but it looks like we have an issue with autopkgtests depenedencies for lunar. I see bbmap and munin regressions under openjdk-8, but those packages use default-jre and this is openjdk-17 [22:42] Also would it be possible to retry https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=armhf&package=munin&trigger=openjdk-8%2F8u362-ga-0buntu1 munin regression. It is caused by some signature fluke, that does not happen at the moment [22:46] vpa1977: clicked [22:47] dbungert: Thank you!!!!! [22:49] uhhhhhhh mapreri ddstreet someone's spamming backports, mod hammer pls? I'll forward this to IS to ban IPs but still [22:52] rbasak: Your concerns regarding apt_btrfs_snapshot.py are reasonable it just hasn't ever come up before in all my time SRU'ing it.