[06:38] <dholbach> hiya
[06:38] <dholbach> somebody just asked "Anyone knows why launchpad is failing to upload 'my' snap to the Ubuntu Store? Well, I have only one login for all my Ubuntu stuff. The error is: Store upload failed: 403 Client Error: Forbidden" - I'm not quite sure what the issue might be. Does anyone have an idea?
[06:40] <wgrant> dholbach: First thing to try is unchecking and rechecking the store upload checkbox on LP, to get new authentication tokens.
[06:40] <wgrant> If that doesn't fix it then we'll have to dig deeper.
[06:41] <dholbach> ok, I'll let them know
[06:41] <dholbach> thanks
[14:11] <aatchison> hello
[14:13] <aatchison> I'm having some build issues with launchpad, and I'm not sure what to do. pbuilder needs an Internet connection in my case, how might I remedy this? I have some ubuntu package build deps and also pip dependencies. I am using dh_virtualenv to create a source package, which seems to be good. How might I accomplish a build with no internet on the ppa farm?
[14:14] <aatchison> Would it be a better approach to build the packages myself and upload to the PPA?
[14:16] <dobey> you need to depend on the binary python packages
[14:20] <aatchison> hmm
[14:21] <aatchison> I'm not sure that I can do that, as not all of them exist as packages
[14:21] <dobey> if they're not available in the ubuntu archive already, you'll need to package them in your PPA
[14:21] <aatchison> ahh
[14:21] <aatchison> ok, crap lol
[14:21] <aatchison> thanks
[14:21] <aatchison> I guess I need to contact some maintainers.
[14:25] <dobey> i'm not sure what all snap builds can access, but you might want to look at packaging as a snap instead of debs. i think the snap builds are a little more lenient there
[14:28] <cjwatson> That's correct, but it depends what you need to achieve.
[14:29] <apollo13> anyone here who can fix my launchpad login? :(
[14:29]  * apollo13 doesn't like to create new email addresses for services
[14:29] <cjwatson> roadmr: ^- I think you helped me last time with somebody who had a confused SSO state
[14:30] <cjwatson> https://oops.canonical.com/?oopsid=OOPS-b32e2f4e37f854e5a7614319da6b1398 is the oops
[14:30] <roadmr> cjwatson: yes, that time there were two SSO accounts and two LP ones, the openid was mismatched
[14:31] <apollo13> I can generate new OOPS if needed :D
[14:31] <roadmr> :)
[14:32] <cjwatson> apollo13: Do you know your LP username?
[14:32] <apollo13> cjwatson: it might have been apollo13 or f.apolloner
[14:32] <apollo13>  (Error ID: OOPS-98fee25e8cb199977fa9a83f2afea2cf)  <-- new oops if it helps
[14:33] <cjwatson> ~apollo13 exists and has the OpenID from that OOPS
[14:33] <apollo13> yeah, apollo13 should be relatively old (or rather recreated)
[14:34] <apollo13> I think I have/had one in 2007 or so
[14:34] <aatchison> hmm
[14:34] <aatchison> I'm actually building snaps and debs
[14:34] <apollo13> what is that snaps thingy? something new canonical is trying to push? :D
[14:35]  * apollo13 has the feeling that we are ending up with more package formats than we need
[14:35] <cjwatson> ~apollo13 is recorded as having been created in July
[14:35] <apollo13> cjwatson: yes, since I deleted the account last time the ubuntu forums got hacked or so :þ
[14:35] <apollo13> and then recreated in july
[14:36] <aatchison> I can upload my own debs correct? What would be the difference between that an packaging the python deps?
[14:37] <aatchison> There is another problem, some of the pip requirements need to use wheel to compile headers for that specific arch
[14:38] <apollo13> aatchison: not sure why you'd need wheel if you need binary stuff, just fetch the sdist and run bdist_ext or whatnot
[14:38] <aatchison> So, I would have to make dsc for all of the pip requirements, and build each one for each arch?
[14:39] <aatchison> Well, I know that I need to compile python bindings I mean
[14:39] <aatchison> for at least one package
[14:39] <apollo13> yes, but how does that have anything to do with wheel?
[14:39] <aatchison> either that or update the upstream package (pocketsphinx)
[14:39] <cjwatson> roadmr: Looks like there's an old ~apollo13-deactivatedaccount hanging around that this is conflicting with
[14:39] <cjwatson> Created in 2005, deactivated in February
[14:40] <aatchison> Wheel compiles locally during pip installation, unless I'm mistaken
[14:40] <cjwatson> Mismatching OpenID with this one of course
[14:40] <wgrant> cjwatson: Bug #1607242
[14:40] <apollo13> cjwatson: oh wow, didn't know that I already was writing ubuntuusers.de at that time -- good old times :d
[14:40] <cjwatson> wgrant: Ah yes, now I remember you filing that
[14:40]  * cjwatson reads
[14:42] <cjwatson> wgrant: In this case A is ~apollo13-deactivatedaccount and B is ~apollo13, right?
[14:42] <wgrant> cjwatson: Correct.
[14:45] <cjwatson> wgrant: Do I then read it correctly that you suggest an admin merge of ~apollo13-deactivatedaccount to ~lp-void in this case?  I'm not sure I see how that clears out the email address
[14:46] <wgrant> cjwatson: Quite, the process was originally very dodgy and is now only quite dodgy: https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/DeleteAccounts?action=diff&rev2=3&rev1=2
[14:47] <cjwatson> Grief
[14:49] <cjwatson> Do we need to check for multiple SSO accounts as well, then?
[14:50] <wgrant> cjwatson: Hm, how is that relevant?
[14:50] <cjwatson> I don't know, but https://wiki.canonical.com/InformationInfrastructure/WebOps/LPHowTo/SSOandLPAccountWoe is linked from that page and suggests it
[14:51] <wgrant> cjwatson: That is only a problem when there are multiple OpenID identifiers on a single LP account; both SSO accounts will advertise the same username.
[14:52] <wgrant> So there are two main options here: fully delete the old LP account, or reactivate it and merge the new one into it.
[14:53] <cjwatson> apollo13: Do you just want the old account back, or are you intentionally aiming for a fresh start?
[14:57] <dobey> aatchison: you can only upload source packages to launchpad
[14:58] <dobey> aatchison: so you'd make appropriate source packages and just specify arch: any or arch: all on the binary packages as appropriate, and launchpad builders will build the binary packages on the appropriate archs in the ppa
[15:22] <apollo13> cjwatson: I am fine either way -- whatever is easier
[15:32] <cjwatson> wgrant: I think we should probably merge the two, then.  Procedure check: ~apollo13-deactivatedaccount/+reviewaccount -> Active, +adminpeoplemerge ~apollo13 into ~apollo13-deactivatedaccount, then once the merge completes rename ~apollo13-deactivatedaccount to ~apollo13?
[15:49] <aatchison> @dobey thanks
[15:50] <aatchison> This approach should work? https://github.com/spotify/dh-virtualenv/issues/112
[15:52] <aatchison> That way I could keep my virtualenvs and include the pip requirements in the same source package I think...
[22:31] <jose> 'ello! anyone around?
[22:31] <jose> getting some oops
[22:36] <tsimonq2> jose: be more specific?
[22:38] <jose> Launchpad oops
[22:38] <tsimonq2> what pages?
[22:38] <tsimonq2> any page that isn't being mean?
[22:43] <jose> when filing a bug, just tried with someone else and it's just oopsing
[22:43] <jose> someone over at IS should be able to take a look at the oops report
[22:46] <cjwatson> jose: you need to tell us the oops id
[22:46] <cjwatson> jose: we can see them but not telepathically
[22:46] <jose> cjwatson:  OOPS-717ad70cf1704bd8a887098f992bd093 is the first one
[22:47] <cjwatson> IllegalTarget: Package rlec not published in Juju Charms Collection
[22:47] <cjwatson> you can't file bugs against non-official branches
[22:47] <jose> let me try again, I had another one but closed the window
[22:47] <jose> just one quick sec
[22:48] <jose> hmm, its not timing out anymore. looks like it's fixed - thanks though!
[22:48] <jose> I changed it and tried to file it against the general project and it would oops as well
[22:48] <cjwatson> bug timeouts are usually transient
[22:48] <jose> good :)
[22:49] <cjwatson> there's a known problem with triggers that ~always goes away in about ten minutes