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:23 |
---|---|---|
jugmac00 | Hi @guiverc, this is a known bug in FireFox - I try to find the bug report where also a workaround is described. | 09:28 |
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:29 |
jugmac00 | I am afraid there is not much that we can do from Launchpad's side. | 09:33 |
guiverc | thanks jugmac00 | 09:34 |
* guiverc got past issue; thanks jugmac00 for assistance | 09:43 | |
jugmac00 | @guiverc, may you share your solution? So I could help others if they have the same issue. | 09:46 |
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:47 |
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.) | 09:57 |
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:00 |
cjwatson | guiverc: Where did you get the idea that snaps were involved? | 10:02 |
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:04 |
guiverc | it explains why getting it ^ with xubuntu broke my 'assumption. | 10:08 |
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 | 10:14 |
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:06 |
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:10 |
cjwatson | oerdnj: Do you need it as a dependency of something that is normally still built for i386? | 11:11 |
cjwatson | (https://bugs.launchpad.net/launchpad/+bug/1855069 is slightly related.) | 11:12 |
oerdnj | @cjwatson: Then I am confused why src:bind9 from the same repository is still built. | 11:42 |
oerdnj | 12:04 | |
oerdnj | ~. | 12:04 |
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:15 |
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:32 |
cjwatson | bind9 is probably in the allowlist due to shipping some relatively core libraries | 12:35 |
cjwatson | Sorry it's confusing! | 12:35 |
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:07 |
cjwatson | Back now | 19:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!