[09:23] <guiverc> I'm getting "bad bot, go away!" on xubuntu jammy media  (no firefox snap involved); ubiquity fails to install & trying to file bug report
[09:28] <jugmac00> Hi @guiverc, this is a known bug in FireFox - I try to find the bug report where also a workaround is described.
[09:29] <guiverc> if it's http://launchpad.net/bugs/1950073 that applies to firefox as snap; it's supposed to be fixed; but xubuntu doesn't use snap'd version of firefox
[09:33] <jugmac00> I am afraid there is not much that we can do from Launchpad's side.
[09:34] <guiverc> thanks jugmac00 
[09:43]  * guiverc got past issue; thanks jugmac00 for assistance
[09:46] <jugmac00> @guiverc, may you share your solution? So I could help others if they have the same issue.
[09:47] <guiverc> in this case I just switched tab; logged in; switched back & used BACK & refresh to process the login/+decide question again  (may have done it twice.. but got there)
[09:47] <guiverc> (logged in to launchpad)
[09:57] <cjwatson> guiverc: I don't think it's correct that that applies to firefox as a snap.
[09:57] <cjwatson> guiverc: Certainly the upstream bug that I raised didn't.
[09:57] <cjwatson> guiverc: (Because I'm not using firefox as a snap - I'm still running 20.04, where it was a .deb by default, and I haven't changed that.)
[10:00] <cjwatson> guiverc: My understanding was that Mozilla has some kind of out-of-band way to update per-site handling of form autofill behaviour, without requiring client updates (that certainly matches my observations).  But I don't know the details of that mechanism, or how it might fail.
[10:02] <cjwatson> guiverc: Where did you get the idea that snaps were involved?
[10:04] <guiverc> cjwatson, wrong assumption then on my behalf; I'd only experienced on it on Ubuntu jammy where firefox was snap; but not my Lubuntu jammy where it's a deb package... I'd made a wrong assumption for some reason sorry.
[10:08] <guiverc> it explains why getting it ^ with xubuntu broke my 'assumption.
[10:14] <guiverc> a different bug appeared on shutdown; restarted the live system to ubuntu-bug & what I described as workaround ^ didn't work on 2nd, 3rd, but did on 4th try
[11:06] <oerdnj> Hi folks, I have this weird problem with src:fstrm package when built in PPA - it skips i386 architecture for no apparent reason (as it works locally in sbuild).
[11:10] <cjwatson> oerdnj: Building for i386 on >= focal mostly isn't supported any more, with the exception of a specific allowlist maintained by the Ubuntu team.
[11:11] <cjwatson> oerdnj: Do you need it as a dependency of something that is normally still built for i386?
[11:12] <cjwatson> (https://bugs.launchpad.net/launchpad/+bug/1855069 is slightly related.)
[11:42] <oerdnj> @cjwatson: Then I am confused why src:bind9 from the same repository is still built.
[12:04] <oerdnj>       
[12:04] <oerdnj>   ~.
[12:15] <cjwatson> oerdnj: I think bind9 is already in the allowlist
[12:15] <cjwatson> oerdnj: Could you ask vorlon about this?
[12:15] <cjwatson> oerdnj: He does most of the maintenance of that list, I think.  It's designed mainly for Ubuntu itself but hopefully there's some way to make some additional exceptions for PPAs
[12:32] <oerdnj> cjwatson: Thank you for the explanation.  Now, I finally understand what's going on.  I was scratching my head about this for quite a time.  I'll probably just disable i386 from the PPA.
[12:35] <cjwatson> bind9 is probably in the allowlist due to shipping some relatively core libraries
[12:35] <cjwatson> Sorry it's confusing!
[19:07] <cjwatson> Lots of librarian files will be failing to fetch at the moment due to an upgrade in process on the Ceph backend which doesn't seem to be a very smooth process
[19:31] <cjwatson> Back now