[02:48] <sque> Hello, I am trying to upload a package in my ppa and I got the following email: http://pastebin.mozilla.org/852149
[02:49] <sque> My package is built succesfully and installed in my local setup. And from the email I understand that _dput_ just doesnt upload the .orig.tar.gz file for some reason. Any suggestion
[02:50] <wgrant> sque: How are you building the package for upload? debuild? With which arguments?
[02:51] <sque> debuild -rfakeroot -k<mykey>
[02:51] <sque> and then dput -s ppa:sque/asterisk asterisk_1.8.0-1ppa1_i386.changes
[02:51] <sque> without -s
[02:52] <wgrant> sque: You need to give the the -S option (to only upload source, not binaries, which Launchpad will reject), and the -sa option the first time (to upload the orig.tar.gz)
[02:52] <sque> dput -sa ?
[02:52] <wgrant> sque: Those are both debuild arguments.
[02:52] <sque> a ok
[02:53] <wgrant> They alter the created .changes file, and dput will do what that says.
[02:53] <sque> you were crystal clear
[02:53] <sque> brb
[02:58] <sque> wgrant, ty you are completly right
[02:58] <sque> do I have to delete the previous uploaded files from server?
[02:59] <sque> or just uploading the new .changes will be allright?
[02:59] <wgrant> sque: They were rejected, so there's nothing there to delete.
[02:59] <wgrant> Just upload the new one.
[02:59] <sque> ok I am doing it right now, ty again
[02:59] <wgrant> (dput may need to be given the -f option, if it says it's already uploaded)
[03:01] <sque> no it does not complain
[03:01] <wgrant> Ah, of course, since the new file is *_source.changes, not *_i386.changes.
[03:01] <sque> yes
[03:07] <sque> wgrant, cool it worked https://launchpad.net/~sque/+archive/asterisk/+packages , ty very much
[03:07] <wgrant> sque: Great.
[03:07] <sque> :)
[03:08] <wgrant> And it's already building. Excellent.
[03:08] <sque> I must admit this ppa thing is not that difficult, even for really new comers.
[03:09] <wgrant> Packaging can be a bit difficult to start with.
[03:09] <sque> Yes packaging is VERY difficult, tweaking and changing an existing package is not that difficult
[03:10] <sque> Anyway, ty very must, good nigh
[03:10] <sque> night*
[03:10] <wgrant> Night.
[03:39] <poolie> is there anything in the help wiki about build recipes?
[03:39] <poolie> it's not very easy to find if there is...
[03:39] <poolie> ok https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[03:42] <wgrant> poolie: I believe recipe pages should have help links now.
[03:42] <wgrant> But that might have been caught in the prod rollback.
[03:44] <poolie> mm, i wanted to use it to answer a question about "can i do x"
[03:51] <wgrant> poolie: It didn't answer your question?
[03:52] <poolie> it did once i found it by searching for 'recipe'
[03:52] <poolie> it's not linked from the help homepage or the packaging/soyuz home packe
[03:52] <poolie> *page
[03:53] <wgrant> Ah.
[04:10] <lifeless> wgrant: it wasn't caught in rollback
[04:10] <lifeless> wgrant: we only rolled back one rev
[04:32] <share> why launchpad is slow as hell?
[04:34] <lifeless> right now we're still fixing things from our upgrade to postgres 8.4
[04:34] <lifeless> it caused a number of crucial queries to start performing very badly
[04:35] <lifeless> more generally we have a lot of inefficient code that we're focusing on and fixing at the moment
[04:35] <lifeless> expect continued, substantial improvement over the next 6-12 months.
[04:36] <lifeless> there are some other things like ssl session caches not being shared between apache frontends, but you only notice that when you start a session, not per-page.
[04:41] <share> ok
[04:41] <share> and why do you use referrers or referers or referrals wathever
[04:42] <share> network.http.sendRefererHeader;0
[04:42] <share> network.http.sendSecureXSiteReferrer;false
[04:42] <share> need to set network.http.sendRefererHeader;1
[04:52] <lifeless> its a form of protection against cross site attacks
[08:59] <dev-zero> hi everyone
[08:59] <dev-zero> I uploaded my packages to my PPA but they don't seem to be available and I didn't get a mail nor do they show up on the builds-page
[09:00] <bigjools> dev-zero: https://answers.edge.launchpad.net/soyuz/+faq/227
[09:02] <dev-zero> bigjools: thanks, that's what I've been looking for
[09:02] <bigjools> np
[09:02] <dev-zero> bigjools: but I think I did everything written there
[09:03] <dev-zero> only thing I missed is: I uploaded the signed packages before I registered the key at launchpad
[09:03] <bigjools> that will be a problem :)
[09:03] <dev-zero> probably delete the PPA and re-create it?
[09:04] <bigjools> no, re-upload your package
[09:04] <dev-zero> well, that doesn't work
[09:04] <dev-zero> I get this: "Package has already been uploaded to ppa on ppa.launchpad.net"
[09:04] <dev-zero> it's https://launchpad.net/~dev-zero/+archive/spice btw
[09:04] <wgrant> dev-zero: Pass the -f option to dput.
[09:04] <wgrant> dev-zero: dput stores in a file locally that you've already uploaded that file.
[09:05] <wgrant> Even if it was rejected.
[09:05] <dev-zero> aaah, good :)
[09:05] <wgrant> -f overrides that, forcing it to upload again.
[09:07] <dev-zero> btw, wrt debian package writing: is there a simple way to reduce the list of dependencies? meaning: I filled in libssl-dev for build-time-deps and libssl0.9.8 for the binary package, but I would like to have a macro to say: "depend on the corresponding non-dev packages from the build-time-deps"
[09:09] <wgrant> dev-zero: Have you read the Ubuntu Packaging Guide or the Debian New Maintainers' Guide? The ${shlibs:Depends} expansion variable should do what you want.
[09:10] <dev-zero> wgrant: yes, I did, but it seems I didn't understand the point of the shlibs:Depends macro :)
[09:10] <dev-zero> wgrant: so, during the package process debuild does a ldd and records those libs in the dependencies?
[09:12] <wgrant> dev-zero: Sort of, yeah.
[09:13] <dev-zero> does it also "copy" version specs from Build-Depends?
[09:14] <dev-zero> ... if the soname doesn't reflect the version properly?
[09:14] <wgrant> Not exactly, but library packages should handle that anyway.
[09:14] <wgrant> You don't have to worry about it.
[09:14] <dev-zero> ok
[09:15] <dev-zero> wgrant: thanks and sorry for the slightly OT
[09:48] <dev-zero> hmm, do I have specify that the build server should try to satisfy deps for packages from my PPA?
[09:53] <geser> the buildd will look into your PPA for build dependencies automatically (if you specified them in debian/control)
[09:53] <wgrant> dev-zero: No, that will happen automatically. But it can take up to 10 minutes for built packages to be published.
[09:53] <dev-zero> geser: ah, ok
[09:54] <dev-zero> geser: I thought there was the WAITDEP/DEP-WAIT for that
[09:54] <geser> dev-zero: that's when your build-depend on a package the buildd don't know where to get it (and decides to wait)
[09:55] <dev-zero> and in my case buildd didn't even know the package
[09:55] <dev-zero> ok, got it
[09:58] <geser> wgrant: as you are familiar with the buildd code: shouldn't this build got catched earlier for DEPWAIT (if it would be working; still waiting on the review of the updated regex) instead of going on with installing the other build-dependencies? http://launchpadlibrarian.net/58808116/buildlog_ubuntu-natty-i386.gedit-valencia-plugin_0.3.0-1_FAILEDTOBUILD.txt.gz
[10:04] <wgrant> geser: That's a bit odd.
[10:04] <wgrant> E: Package 'libvala-dev' has no installation candidate
[10:04] <wgrant> libvala-dev is a virtual package provided by:
[10:04] <wgrant> Using  (no default, using first one)
[10:05] <wgrant> So apt says something provides it, but doesn't list anything.
[10:07] <geser> it's currently provided by libvala-0.10-dev and libvala-0.12-dev in natty, but this still doesn't explain why it's not listed in the output
[10:08] <wgrant> Maybe our sbuild doesn't like the new apt.
[10:09] <wgrant> I should really get the unancient sbuild branch merge. But...
[10:30] <EvaLuaTe> hello
[10:30] <EvaLuaTe> how will it approximately take after I upload something to a PPA until it becomes visible on the website?
[10:31] <bigjools> EvaLuaTe: about 5-10 minutes
[10:31] <bigjools> if it doesn't, please read this https://answers.edge.launchpad.net/soyuz/+faq/227
[10:35] <EvaLuaTe> bigjools, ok, thank you
[10:38] <EvaLuaTe> bigjools, what does "Rejected: \n Source/binary (i.e. mixed) uploads are not allowed." ?
[10:38] <bigjools> EvaLuaTe: it means you're uploading a binary .deb with your source, you need to build the package with "debuild -S"
[10:40] <EvaLuaTe> bigjools, ohh, well I have gone through the packaging tutorial but I have noticed that most of it (if not everything) is copied from the debian one, so I thought the package I did for debian would be fine, guess I was wrong though :p
[10:40] <bigjools> this is not a package issue, you're just not uploading source-only
[10:43] <EvaLuaTe> bigjools, ok, so should I just upload the mypackage_source.changes after doing debuild -S?
[10:43] <bigjools> EvaLuaTe: yes, that will work
[10:46] <EvaLuaTe> bigjools, yeah, it worked. The problem was that I built the package just like in debian, with dpkg-buildpackage, instead of debuild -S. Thank you very much for the help!
[10:46] <bigjools> np, good luck :)
[10:47] <wgrant> EvaLuaTe: dpkg-buildpackage works too, but you need -S there as well.
[10:48] <EvaLuaTe> wgrant, ohh, alright. Thanks again
[10:48] <EvaLuaTe> have a nice day!
[10:48] <wgrant> (debuild is just a wrapper around dpkg-buildpackage)
[14:30] <soren> How do I merge two launchpad accounts?
[14:31] <shadeslayer> hi, can a ppa be emptied of all source packages keeping just the binary ones>
[14:31] <bigjools> shadeslayer: no
[14:31] <shadeslayer> ok
[14:31] <shadeslayer> ( i just thought it could be done, because i heard something similar earlier )
[14:31] <soren> Ah, just found it. Google was being unhelpful up until just now.
[14:31] <bigjools> shadeslayer: that would break the GPL
[14:31] <shadeslayer> ah ok
[14:32] <shadeslayer> then i suppose we just need more space :P
[14:32] <bigjools> request and it shall be thine
[14:32] <shadeslayer> yep.... will do tomorrow :)
[16:51] <shtylman> who would I talk to about setting up a private ppa?
[17:00] <bigjools> shtylman: is that a commercial request?
[17:02] <shtylman> bigjools: yes
[17:02] <bigjools> mrevell: are you handling commercial requests?
[17:02] <mrevell> bigjools, I am.
[17:03] <mrevell> shtylman, Hello.
[17:03] <bigjools> mrevell: cool, you have a customer :)
[17:03] <mrevell> shtylman, Hi, do you already have a subscription to Launchpad?
[17:05] <shtylman> mrevell: by subscription do you mean account?
[17:06] <shtylman> if yes.. then yes
[17:06] <mrevell> shtylman, Sorry, no, I mean a commercial subscription, which is available for an annual payment and required for a private PPA. See https://launchpad.net/+tour/join-launchpad#commercial
[17:07] <shtylman> ahh... I guess that is the starting point I was looking for
[17:08] <mrevell> shtylman, Cool :) Ping me here or email commercial@launchpad.net if you have any questions.
[17:09] <shtylman> mrevell: will do... the price listed is per project.. can the project have multiple "mainline" branches.. or is a project the same as other open source projects with one main branch?
[17:09] <shtylman> and are there limits to the number of private ppas? contributors.. etc?
[17:10] <mrevell> shtylman, In Launchpad we have a concept of "series", which are multiple lines of development within the same project, so yes you can have more than one line of development within a commercial project.
[17:10] <shtylman> gotcha
[17:12] <mrevell> shtylman, At this stage, I think we could be a little flexible about the number of private PPAs you have with your subscription. If you could let me know more about your requirements, we can talk more ... perhaps by email or PM/
[17:13] <shadeslayer> https://launchpad.net/~kubuntu-ninjas/+archive/ppa/+build/2047827 and https://launchpad.net/~kubuntu-ninjas/+archive/ppa/+build/2047826 seem stuck to me
[17:13] <shadeslayer> can someone please have a look?
[17:13] <shadeslayer> ive uploaded other packages after that one and they seem to be building fine
[17:14] <bigjools> shadeslayer: looking
[17:14] <shadeslayer> thanks
[17:18] <shadeslayer> bigjools: seems to be working now
[17:18] <shadeslayer> thanks
[17:18] <shadeslayer> must have been stuck in the queue somewhere
[17:20] <bigjools> shadeslayer: I just noticed it's a private PPA.  For those, the source has to be published before it can start building.
[17:20] <bigjools> so you have to wait for the publisher cycle.
[17:20] <shadeslayer> but it doesnt take THAT long
[17:20] <bigjools> yes, it does
[17:20] <bigjools> 10 minutes
[17:20] <shadeslayer> hmm.... i didnt know that.... usually it took less than 5 mins
[17:21] <bigjools> it depends on the load - if there's a lot of stuff to publish it will take longer
[17:21] <shadeslayer> ohk
[17:21] <bigjools> wgrant has a nice speedup that I hope to put in soon
[18:05] <mtaylor> anychance anybody has an IRC bot that will file bugs in on a launchpad project for me already?
[18:18] <om26er> can i do a upload to my ppa for two ubuntu versions with single dput?
[18:32] <MagicFab> flacoste, ping
[18:32] <MagicFab> flacoste, would there be documentation explaining the different permission/access levels requested when using apport-collect ?
[19:10] <flacoste> MagicFab: are you talking about the levels appearing on the oauth token authorization screen?
[19:16] <MagicFab> flacoste, yes, can't seem to find any refs to that
[19:21] <joey> I'm having a problem with APIs where they are doing something they haven't. I'm blocked on some Canonical commercial stuff and lifeless said to ask for some help here. So I am. https://pastebin.canonical.com/39772/
[19:23] <joey> here's the open paste: http://paste.ubuntu.com/532529/
[19:28] <abentley> joey: are you using the 1.0 API?  The devel API is subject to change.
[19:29] <joey> abentley: I've used devel and 1.0 with the same results
[19:29] <joey> abentley: I've used edge, lpnet, and staging with the same results
[19:29] <joey> abentley: I've deleted all my items in .launchpadlib, reauthenticated, and....in between nonce issues.... got the same results
[19:30] <joey> abentley: I've reinstalled launchpadlib and lazr.restfulclient
[19:30] <abentley> joey: And the value you're actually getting is None?
[19:30] <joey> abentley: yes
[19:30] <joey> abentley: although I didn't do the test for it
[19:31] <joey> abentley: I'll test to ensure it's none and not a blank or something
[19:32] <abentley> joey: I thought I saw something recently about changing from KeyErrors to None, but I'm having trouble finding it now.
[19:34] <joey> abentley: well, it's NOT none ....
[19:34] <joey> abentley: NotFound: Object: <canonical.launchpad.systemhomes.WebServiceApplication object at 0x8007510>
[19:34] <joey> abentley: I get that for real projects and also ones that don't exist
[19:34] <joey> obviously with a different obj id
[19:34] <joey> could be the way I'm doing the statement though
[19:35] <abentley> leonardr: Any idea why project = lp.projects[project_name] returns NotFound rather than raising an exception?
[19:35] <joey> abentley: I get it for project, project.name, project.owner
[19:36] <joey> abentley: it worked as is the last time I used it (about 1.5 to 2 weeks ago or so)
[19:36] <leonardr> abentley: "returns NotFound"? what is NotFound, an exception object that doesn't get raised?
[19:37] <abentley> leonardr: It is apparently "NotFound: Object: <canonical.launchpad.systemhomes.WebServiceApplication object at 0x8007510>"
[19:37] <leonardr> abentley: are you writing a pagetest, or using launchpadlib as a client?
[19:37] <joey> leonardr: client
[19:37] <abentley> leonardr: joey is using launchpadlib as a client.
[19:38] <joey> abentley: happy to paste you the full script.
[19:38] <leonardr> abentley, joey: NotFound is an exception object, and canonical.launchpad.systemhomes... refers to an exception raised on the server side
[19:39] <leonardr> if the exception is returned rather than raised, i suspect a version mismatch
[19:39] <leonardr> or an old coding style that needs to be modernized
[19:39] <leonardr> joey: paste me the script
[19:39] <joey> leonardr: https://pastebin.canonical.com/39778/
[19:39] <joey> leonardr: bac created the shell for me about a year ago and I've been customizing it as needed
[19:40] <joey> leonardr: and yes, I've used 1.0 instead of devel with no luck
[19:40] <joey> leonardr: and I've tried edge, lpnet, and staging
[19:41] <leonardr> joey: there's probably some subtle problem with your setup that is resulting in a request going to /foo or /1.0/1.0/foo instead of /1.0/foo
[19:41] <leonardr> add this code and see what requests are made:
[19:41] <leonardr> import httplib2
[19:41] <leonardr> httplib2.debuglevel = 1
[19:41] <joey> k
[19:43] <joey> leonardr: silly question: where does the output go?
[19:43] <leonardr> joey: stdout
[19:43] <MTecknology> Any ideas what's up with this?...  bzr: ERROR: KnitPackRepository('lp-56956304:///~canonical-isd-hackers/drupal-teams/5.x-trunk/.bzr/repository') is not compatible with    CHKInventoryRepository('lp-56956304:///~ubuntu-drupal-devs/drupal-teams/7.x-dev/.bzr/repository') different rich-root support
[19:43]  * joey wrinkles his face. 
[19:43] <leonardr> joey: what are you passing in for service_name?
[19:44] <joey> leonardr: staging presently
[19:44] <leonardr> joey: the string "staging"?
[19:44] <MTecknology> maybe that's a #bzr question..
[19:44] <joey> leonardr:  -s staging from the options which then goes to .uris and becomes the staging root
[19:45] <joey> leonardr: I'm getting no output from the debug option.
[19:46] <leonardr> ok, i'm going to try the script. what's a good sample command line?
[19:46] <leonardr> joey -^
[19:47] <joey> leonardr: ./create-oem-project.py -s staging a98349jdfsfj93r
[19:47] <joey> or some other fictitious project name
[19:47] <joey> leonardr: contrast those results against an existing project
[19:47] <joey> e.g. ./create-oem-project.py -s staging hedly
[19:48] <joey> e.g. ./create-oem-project.py -s staging hedley
[19:51] <leonardr> joey: the script works for me (up to the point where i get Unauthorized), so it's probably a version mismatch. can you run this code?
[19:51] <leonardr> import launchpadlib
[19:51] <leonardr> print launchpadlib.__version__
[19:51] <leonardr> import lazr.restfulclient
[19:51] <leonardr> print lazr.restfulclient.__version__
[19:51] <MTecknology> Can I push something to LP without it being stacked on the primary branch in the project?
[19:52] <joey> abentley: 1.6.1
[19:52] <joey> 0.9.20
[19:53] <abentley> MTecknology: You can explicitly stack it on something else, if you like.  I don't think you can avoid stacking at all.
[19:54] <MTecknology> hm... seems it pushed finally- I guess it decided it'll be nice to me?..
[19:54] <abentley> MTecknology: you can reconfigure --unstacked, though.
[19:54] <MTecknology> thanks
[19:55] <leonardr> joey: i get the problem with the system libraries (which is what you have) but not with the later stuff
[20:00] <joey> leonardr: any idea what approach I should try next?
[20:00] <leonardr> joey, i'm working on it
[21:30] <tgm4883> What happens to a PPA if you delete it/deactivate it? Specifically, what happens from the users perspective if they have that PPA in their sources.list/sources.list.d/?
[21:52] <geser> can some help why I get "ServerNotFoundError: Unable to find the server at lplibrarian.internal" when I try to access the attachments for a certain bug over the LP API?
[21:54] <maxb> geser: My guess would be that private bug attachments over the API only work inside the LP datacentre
[21:55] <maxb> tgm4883: My guess would be that it just starts to 404
[22:00] <geser> maxb: hmm, I've tried grab-attachments (from ubuntu-dev-tools) on some private bugs (apport crashes) and on 3 of them I got the same error (so your guess might by true) but on two other private bugs the script worked
[22:01] <geser> maxb: do you know who might know it if your guess is true?