[02:05] <xingwozhonghua_> https://launchpadlibrarian.net/710849174/buildlog_ubuntu-focal-amd64.jqtools_20.6.9-1_BUILDING.txt.gz
[02:06] <xingwozhonghua_> “Is the version of debhelper-compat incorrect? How can I determine the required version of debhelper-compat for the build machine?” https://usercontent.irccloud-cdn.com/file/odUYqEuz/image.png
[02:10] <sarnold> xingwozhonghua_: focal's debhelper is version 12.something https://launchpad.net/ubuntu/+source/debhelper -- there's a 13 in -backports. maybe modify your PPA to build with -backports enabled (but then your users need -backports, too) -- or modify your package to use -12. maybe you can find the diff that upgraded it to -13 to see what you need to undo.
[02:49] <cjwatson> Using an earlier debhelper version when I need compatibility with earlier series is usually my favoured approach - it's the simplest by far.  See https://launchpad.net/ubuntu/+source/debhelper to find out what major versions of debhelper are where, and see the "COMPATIBILITY LEVELS" section of "man debhelper" (or "man debhelper-compat-upgrade-checklist" in recent versions) to work out what you'd need 
[02:49] <cjwatson> to undo to drop back to an earlier compat level.
[02:50] <cjwatson> For what appears to be a new package, you can probably just drop back to 12 without much difficulty.
[02:51] <cjwatson> Especially since you have about the simplest possible debian/rules and no other complexity that I can see.
[03:20] <xingwozhonghua_> ok
[03:48] <xingwozhonghua_> https://usercontent.irccloud-cdn.com/file/3OMVQy0Z/image.png
[03:49] <xingwozhonghua_> https://launchpad.net/~chenshijie/+archive/ubuntu/jqtools
[03:49] <xingwozhonghua_> What’s the issue here? Why can’t it be installed?
[04:21] <amurray> xingwozhonghua_: if you look at https://launchpad.net/~chenshijie/+archive/ubuntu/jqtools/+packages you'll see it says that the deb is still pending publication to the ppa
[04:21] <amurray> so you just need to wait a bit longer and try again
[04:22] <xingwozhonghua_> Oh
[09:33] <pelpsi> paulf: You are receiving that error because it seems that you already created an account on Launchpad with that email https://launchpad.net/~pjfloyd
[09:44] <paulf> pelpsi: How go I get past "Yes, log me in" and the OOPS screen? Pasword reset? Delete the account (nothing to lose AFAIK)?
[09:45] <pelpsi> paulf: you can click on `Are you pjfloyd?` and follow the procedure 
[09:47] <paulf> I just get back to Oops if I click on "Yes, log me in"
[09:53] <pelpsi> right, let me check If I can associate your OpenID to your existing account
[10:51] <pelpsi> paulf: Could you retry to login?
[10:52] <paulf> pelpsi looks OK now, thanks
[10:53] <pelpsi> You're very welcome
=== paulf33 is now known as paulf
[20:06] <arraybolt3> Is there a reason I have to be logged into LP to do a search for fix released bugs? Just tried to do a search while not logged in, and it tried to make me log in.
[20:07] <arraybolt3> I don't particularly want to exhume my mile-long password for LP out of KeePassXC and manually type it into my other computer just so I can get to the bug I was trying to help fix on a test system :P I was able to type the bug number into the right spot and it let me in without being logged in.
[20:51] <jugmac00> arraybolt3: I can search for "fix released" bugs even when not logged in, e.g. https://bugs.launchpad.net/launchpad/+bugs?advanced=1 - on the bug view, I just clicked on "advanced search". What exactly is not working for you?
[20:52] <arraybolt3> https://bugs.launchpad.net/ubuntu/+source/tigervnc/ click on Advanced Search, check "Fix Released", click "Search", and it redirected me to a login screen.
[21:21] <cjwatson> I wonder if it's returning a private bug in the internal search and then not properly filtering that, or something.
[21:54] <rbasak> I can reproduce the issue in a private browser window. While logged in I don't see anything obviously private though.
[22:22] <cjwatson> I can imagine it might be something like a task on a private project ...
[22:22] <cjwatson> But I don't have enough access any more to dig :)
[22:46] <tsimonq2> Definitely some kind of fun bug. If I only select Fix Released and Public, makes me log in: 
[22:46] <tsimonq2> https://bugs.launchpad.net/ubuntu/+source/tigervnc/?field.searchtext=&orderby=-importance&field.status%3Alist=FIXRELEASED&field.information_type%3Alist=PUBLIC&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.upstream_target=&field.has_cve.used=&field.omit_dupes.used=&field.omit_
[22:46] <tsimonq2> dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search
[22:46] <tsimonq2> woaaaaah that's bigger than I expected it to be
[22:46] <tsimonq2> my apologies
[23:04] <cjwatson> It's got to be something that wouldn't naturally be filtered out by the (generally well-exercised and -tested) bug search code but that the bug listing page would try to render and result in an Unauthorized exception turning into a redirect to the login page.  Not sure exactly what - something like being assigned to a private team might do it
[23:06] <tsimonq2> It's somewhat comforting that Launchpad errs on the side of privacy, tbh.
[23:07] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/tigervnc/+bug/1929790 has a private team as an assignee
[23:07] -ubottu:#launchpad- Launchpad bug 1929790 in tigervnc (Ubuntu Impish) "Request to backport fix for endianness issue in TigerVNC vncviewer" [Medium, Fix Released]
[23:08] <cjwatson> Might be a possible problem
[23:08] <cjwatson> Oh yeah, Launchpad has a _lot_ of privacy-aware code
[23:09] <cjwatson> I can open that bug just fine without logging in, but I can sort of imagine how it might cause a problem on the listing page.  Or maybe that's a red herring - this is just a hunch.
[23:10] <cjwatson> The bug listing page doesn't show the assignee by default, but it can be configured to do so.  IIRC the listing view does some preloading shenanigans there.
[23:11] <tsimonq2> I'm slightly surprised that the team in question is private... but I can still see the name of it. Could possibly be a placeholder instead, similar to how https://launchpad.net/builders works.
[23:11] <cjwatson> I believe you're allowed to know its name if you have access to an artifact it's linked to, but nothing else about it.
[23:11] <cjwatson> Launchpad calls this "LimitedView" internally.
[23:13] <cjwatson> Anyway, if I were investigating this then I would start by writing a test that invokes the bug listing view anonymously after creating a test bug task in the scope of the listing that has a private team as an assignee.
[23:13] <tsimonq2> I can conceptualize that, okay. On the pre-loading that Launchpad does (assuming this is the problem), perhaps exception handling can be established for LimitedView objects internally. Anyway, I'm just spitballing.