[09:59] <cpaelzer> hmm, is https://people.canonical.com/~ubuntu-archive/nbs.html an empty page for everyone - did I miss a change where to find that now?
[10:02] <sil2100> cpaelzer: hm, it looks normal to me!
[10:03] <cpaelzer> interesting, it resited all refreshes - trying other browser and on/off the vpn
[10:03] <cpaelzer> sil2100: works again
[10:04] <cpaelzer> I even had it failing with wget before ...
[10:04] <cpaelzer> maybe the list gets long enough that there are times when it re-runs that breaks it
[10:05] <cpaelzer> the dir listing indicates it was regenerated 3 minutes ago which was the time it failed me (assuming the server times as UK)
[10:06] <sil2100> Could be, that would be quite a race ;)
[10:19] <alkisg> My stock firefox.deb (not snap) in 22.04 stopped loading pages today. The "Refresh profile" command solved the issue. Then a school reported the exact same issue with firefox.deb in 20.04
[10:19] <alkisg> Is there any recent global problem with firefox that I'm not aware of?
[10:21] <schopin> alkisg: https://news.ycombinator.com/item?id=29918121
[10:21] <schopin> it's apparently an issue with the Firefox servers (or their CDN) that triggers a bug in the HTTP/3 implementation
[10:22] <alkisg> Thank you very much schopin, I'll ask my schools to not try to resolve the problem (by deleting all profiles for all their teachers and students!!!) until it's resolved by mozilla
[10:25] <schopin> alkisg: You might want to subscribe to https://bugzilla.mozilla.org/show_bug.cgi?id=1749908 I guess.
[10:25] <alkisg> Will do, thanks again
[19:01] <bdmurray> vorlon: looking at bug 1953224 in the sponsoring queue it looks to me like (and my testing indicates) that our diff, a change to debian/tests/control, is no longer needed. Is there anyway to sort this out other than waiting for a new debian version of auto-multiple-choice?
[19:19] <vorlon> bdmurray: could always revert the changes to debian/test/control, upload, and note in changelog that it should be a sync.  You could try to upload with a version number like 1.5.2-1.1~build1 to make it autosync next time, but the risk there is that someone does something weird with the version of the next Debian upload that we don't predict
[19:22] <seb128> use 1willsync1 for the revision? ;-)
[19:24] <vorlon> that doesn't do anything to the autosyncer, does it?
[19:25] <seb128> I thought it blocked sync when 'ubuntu' was in the revision
[19:25] <seb128> but I could be wrong
[19:29] <vorlon> I don't see anything about that in the auto-sync code
[19:29] <vorlon> er wait sorry I just misread what you wrote
[19:29] <seb128> where is that code?
[19:29] <vorlon> lp:ubuntu-archive-tools auto-sync
[19:29] <vorlon>             if "ubuntu" in current_ver:
[19:29] <seb128> I was just searching for it but I don't remember where it is hosted now
[19:29] <vorlon> so yes
[19:29] <seb128> ah, thanks
[19:40] <bdmurray> So a version number greater than the current one in Jammy but w/o ubuntu in the version name will cause auto-sync to do the right thing?
[19:50] <seb128> correct
[20:48] <toddr> Is it possible to configure my 3rdparty repo (I maintain this repo) in a way that they are also upgraded when switch from 20.04 to 21.10?
[20:49] <toddr> basically I want my 3rdparty repo packages at the same time that ubuntu upgrades
[20:50] <toddr> I'm struggling to find any documentation on how to get this to work
[21:01] <bdmurray> The release upgrade process will comment out third party repos, however a person upgrading can use the "--allow-third-party" switch but that is not 3rd party specific i.e. all of them will be allowed.
[23:28] <bdmurray> mwhudson: Did you say we should hint yorick?
[23:29] <bdmurray> for glibc in focal
[23:31] <mwhudson> bdmurray: yes, it fails with the glibc in -updates too
[23:37] <bdmurray> okay, will do
[23:44] <bdmurray> mwhudson: oh its flaky see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897236