[00:15] https://bugs.launchpad.net/ubuntu/+bugs?orderby=datecreated&start=0 sort-order -->> Server error, please contact an administrator. OOPS ID:OOPS-4dc20cec3262c6a32be4b4fc9b99242f [00:15] https://oops.canonical.com/?oopsid=OOPS-4dc20cec3262c6a32be4b4fc9b99242f [00:17] https://bugs.launchpad.net/ubuntu/+bugs?orderby=datecreated&start=0 sort-order -->> Server error, please contact an administrator. OOPS ID:OOPS-e9969ce2b0e63d51cb24515bd91b5853 [00:17] https://oops.canonical.com/?oopsid=OOPS-e9969ce2b0e63d51cb24515bd91b5853 [00:18] check_: That's https://bugs.launchpad.net/launchpad/+bug/1475221. As a workaround, you can log in. [00:18] Ubuntu bug 1475221 in Launchpad itself "Private teams invisible to anonymous users even when they interact with public objects" [High,Triaged] [00:19] i'm not logged in, error on change asc/decnd [00:20] ok thank-you [01:51] is there a way to discover who has visibility on a specific bug? [01:52] I'm curious if a bug that I reported can actually be -seen- by anybody or not -- the "other bug subscribers" list is entirely blank, which I find suspicious [01:52] 1628348 is one of the bugs in question [01:53] sarnold: That's a difficult question. It's not possible to query that directly, because it can reveal information that is private (eg. members of private teams). [01:53] But it's more awkward than it could be. [01:54] oh that is difficult. I hadn't thought about that. [01:54] zero-or-non-zero would be nice though [01:54] It is a rather unfortunate problem. [01:55] But it's generally assumed that projects are configured sensibly such that at least someone can see each information type. [01:55] The only deliberate exception to that is Private in Ubuntu. [01:55] or maybe "six actual human accounts can see this bug, and three of them have been active in the last year"? :) [01:55] sarnold: But if the "Other bug subscribers" list is blank, nobody will have been notified about it, at least. [01:55] So it's not hugely relevant whether anyone can actually *see* it, since they won't have been told about it. [01:55] hah [01:56] sarnold: Which project, and Private or Private Security? [01:56] wgrant: oslo.privsep, private security [01:56] I can use superpowers to check the configuration. [01:58] sarnold: Only the project's registrant can see it, and since he's not in ~oslo-drivers (the new owner), I'm not sure he's involved any more. [01:58] sarnold: Might be worth poking the new owner to fix https://launchpad.net/oslo.privsep/+sharing [01:58] I suppose the OpenStack security team should have Private Seurity access... [01:59] that was my assumption when I filed the bug [01:59] but they're usually pretty quick; I'm not accustomed to an entire day's delay without any response at all, so it seemed worth investigating further [01:59] thanks wgrant, very helpful [02:01] sarnold: We know this is pretty awful if the project is misconfigured, but due to it all being about privacy (and remember that we have all sorts of hybrid projects with both public and private stuff, and even the set of teams that are involved in the private stuff can be sensitive) it's very difficult to safely make the information available to people not involved in the project. [02:01] Luckily most projects are correctly configured. [03:34] do PPAs support Debian releases, and if not, why? === pavlushka is now known as Guest51462 === bpierre_ is now known as bpierre === Guest51462 is now known as pavlushka === ganesh is now known as Guest19253 === Guest19253 is now known as gkadam === davmor2_ is now known as davmor2 [11:28] It's possible to do test livefs builds under my personal namespace using packages out of a PPA, isn't it? [11:30] (If so, how?) [11:32] Laney: you probably want to start with https://launchpad.net/~/+new-livefs and make it look like the existing one [11:33] Laney: then do what ubuntu-cdimage/lib/cdimage/livefs.py does when EXTRA_PPAS is passed [11:37] cjwatson: Alright, so I'm constructing the same API call as livefs.py does [11:37] I'll try it in a bit, thanks for the pointer === pbek_ is now known as pbek [14:08] Hi, I've been trying to copy oracle-java8-installer from lp:~webupd8team to lp:~ts.sch.gr, and I keep getting this error: [14:09] Launchpad encountered an internal error during the following operation: copying a package. It was logged with id OOPS-5b119d68b21cb1c413bd083df2023d4a. Sorry for the inconvenience. [14:09] https://oops.canonical.com/?oopsid=OOPS-5b119d68b21cb1c413bd083df2023d4a [14:09] Any ways around it? It's been that way for months now... [14:09] alkisg: That's https://bugs.launchpad.net/launchpad/+bug/1475358, in which the belief about the current state is that a simple retry should work [14:09] Ubuntu bug 1475358 in Launchpad itself "Racing package copies crash when trying to create duplicate PackageDiffs" [Critical,Triaged] [14:10] alkisg: You might also try only copying a single series at a time, if you're copying more than one [14:10] cjwatson: thank you, I had 3 failed attempts while letting weeks go by each time, but I'll retry a few times now [14:10] It certainly isn't necessary to wait weeks; it's a race within a transaction boundary [14:10] OK, I'll try that one as well (I'm copying multiple series) [14:11] (it just wasn't very important at the time, but now sites refuse to load because of old java version, so I'll try it more :)) [14:11] Thank you very much\ [14:11] It's possible that there remains some corrupted DB state, but I'm reasonably sure we cleared it all out after deploying the most recent partial fix [14:11] And as William said there's a database constraint now that should prevent that [14:12] So actually it shouldn't be possible that there remains some corrupted DB state :) [14:33] * alkisg has two packages pending to be published there, and hopes he just needs to wait more... [14:33] https://launchpad.net/~ts.sch.gr/+archive/ubuntu/ppa/+packages?field.name_filter=java&field.status_filter=published&field.series_filter= [14:46] Yup, waiting did it; copying the 3rd series now... :) === JanC is now known as Guest12605 === JanC_ is now known as JanC === pavlushka is now known as Guest94932 === Guest94932 is now known as pavlushka [19:01] can launchpad automatically pull the packaging from LP git and the source code from a download server and build packages from it? [19:02] no [19:03] well, sort of for snaps i guess, but for debs no [19:03] can the source git be automatically imported then? [19:06] I have the project https://launchpad.net/kdevelop and the source git is git://anongit.kde.org/kdevelop.git [19:06] yes, you can import to bzr automatically [19:06] could that be auto imported and then a recipe be created to build it with our packaging here - https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/kdevelop [19:06] if that won't work, then no, automated imports for git->git are not ready yet [19:07] yes [19:07] can it build a few packages [19:07] well, you'd have to push the packaging to bzr instead of git, to do recipes for bzr with separate source and packaging branches, i think [19:07] oh [19:07] no you can't build multiple source packages from a single source with a recipe [19:07] not a fan of bzr [19:08] humm [19:08] doesnt look like it will work [19:09] can LP be configured to copy certain packages? [19:09] you can manually sync a mirror in git if you prefer [19:10] ie copy the required packages from our CI https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable/ to the project team PPA? [19:10] you can't copy binary packages from somewhere else into LP, no [19:10] if it's an archive in launchpad, yes you can copy from one PPA to another [19:10] but not automatically? [19:10] I know I can copy them manually [19:10] you can't configure it automatically in LP, but you could write a script to do it using the API [19:12] is there an ETA for when working with git will be available? [19:13] you can work with git now. you just can't do git->git automatic imports [19:13] you can clone a repo, add the launchpad remote, and push to launchpad, and it works, though === ddstreet_away is now known as ddstreet [19:51] clivejo: don't have an ETA yet, but I've started preliminary work on git->git imports, design and some initial preparatory refactoring [19:51] clivejo: not promising I'll be working on it continuously as yet, that depends on other priorities [19:52] the initial refactoring is moderately complex in itself, lots of built-in assumptions that code imports will only ever be to bzr === nacc_ is now known as nacc [22:43] hmm' [22:44] I can't do anything with launchpadlib atm [22:44] I'm getting thrown this: [22:44] httplib2.SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) [22:44] any ideas?