| xingwozhonghua_ | https://launchpadlibrarian.net/710849174/buildlog_ubuntu-focal-amd64.jqtools_20.6.9-1_BUILDING.txt.gz | 02:05 |
|---|---|---|
| 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:06 |
| 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:10 |
| 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:49 |
| cjwatson | For what appears to be a new package, you can probably just drop back to 12 without much difficulty. | 02:50 |
| cjwatson | Especially since you have about the simplest possible debian/rules and no other complexity that I can see. | 02:51 |
| xingwozhonghua_ | ok | 03:20 |
| xingwozhonghua_ | https://usercontent.irccloud-cdn.com/file/3OMVQy0Z/image.png | 03:48 |
| xingwozhonghua_ | https://launchpad.net/~chenshijie/+archive/ubuntu/jqtools | 03:49 |
| xingwozhonghua_ | What’s the issue here? Why can’t it be installed? | 03:49 |
| 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:21 |
| xingwozhonghua_ | Oh | 04:22 |
| 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:33 |
| 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:44 |
| pelpsi | paulf: you can click on `Are you pjfloyd?` and follow the procedure | 09:45 |
| paulf | I just get back to Oops if I click on "Yes, log me in" | 09:47 |
| pelpsi | right, let me check If I can associate your OpenID to your existing account | 09:53 |
| pelpsi | paulf: Could you retry to login? | 10:51 |
| paulf | pelpsi looks OK now, thanks | 10:52 |
| pelpsi | You're very welcome | 10:53 |
| === paulf33 is now known as paulf | ||
| 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:06 |
| 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:07 |
| 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:51 |
| 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. | 20:52 |
| cjwatson | I wonder if it's returning a private bug in the internal search and then not properly filtering that, or something. | 21:21 |
| rbasak | I can reproduce the issue in a private browser window. While logged in I don't see anything obviously private though. | 21:54 |
| 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:22 |
| 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 | 22:46 |
| 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:04 |
| tsimonq2 | It's somewhat comforting that Launchpad errs on the side of privacy, tbh. | 23:06 |
| 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:07 | |
| cjwatson | Might be a possible problem | 23:08 |
| cjwatson | Oh yeah, Launchpad has a _lot_ of privacy-aware code | 23:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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. | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
