[01:38] <wrinkliez> is there a way to tell how many times a file has been downloaded? or how many hits a ppa gets?
[01:39] <wgrant> wrinkliez: You can see a download count for files you've added to a project.
[01:40] <wgrant> And I've implemented PPA download stats, but I'm not sure if the script is running yet.
[01:40] <wrinkliez> wgrant: i seee...
[01:41] <wgrant> spm: Do you know if any progress has been made on that front?
[01:41] <spm> not offhand, no
[01:44] <wrinkliez> i think im having trouble finding this download count
[01:44] <wrinkliez> :S
[01:44] <wgrant> wrinkliez: https://launchpad.net/PROJECT/+download
[01:52] <wrinkliez> do you have to create that page or something? i got a page not found
[01:53] <wgrant> wrinkliez: Which project?
[01:54] <wrinkliez> not a project, i dont think, but https://launchpad.net/~wrinkliez/+archive/ppasearch
[01:54] <wrinkliez> just a script
[01:55] <wgrant> wrinkliez: That's a PPA. As I said, it's implemented, but not in operation yet.
[01:55] <wrinkliez> oh thats true you said that lol
[01:55] <wrinkliez> cool
[01:56] <wrinkliez> clearly im a nub at this whole schpeal ^.^
[01:57] <wgrant> lamont: Around?
[05:43] <MTecknology> This life long wait to build a package is getting really irritating
[05:43] <MTecknology> what's going on that it's so plugged up - and why is there never any change in priority?
[05:45] <MTecknology> I wish somebody could answer that. :(
[05:51] <wgrant> MTecknology: Why would there be a change in priority?
[05:51] <wgrant> What good would that do?
[05:53] <MTecknology> wgrant: the last I knew (unless it changed) the longer it sits, the higher the priority gets, the more likely it is to get built next - certain pockets and things got higher priorities, so they were more likely to be built first but if a package sat too long it would gain more priority over the other packagebuilds.
[05:53] <MTecknology> the other builds*
[05:54] <spm> over newer ones, yes. not over ones that are of a similar age.
[05:54] <wgrant> MTecknology: The time-based increments have been turned off, since they didn't affect anything.
[05:54] <wgrant> Because all packages had them applied.
[05:54] <MTecknology> oh
[05:54] <wgrant> So it didn't make any different.
[05:54] <wgrant> *difference
[05:54] <MTecknology> makes sense
[05:54] <MTecknology> what about the massive congestion?
[05:55] <wgrant> I think we may have a Python stack rebuild in progress.
[05:55] <wgrant> We should deprioritise that.
[05:56] <MTecknology> When I left work 6 hours ago this package was estimated to be built in 3 hours, it's still estimated for 3 hours - it's been sitting there about 15 horus now.
[05:56] <wgrant> Yes, build farm master overhead is probably well over 100% at the moment.
[05:57] <wgrant> So the estimates will be too low.
[05:58] <MTecknology> So ... super-duper-command stop python-stack --purpose=yay
[05:58] <MTecknology> :D
[05:58] <wgrant> Pretty much.
[05:59] <MTecknology> amd64 queue is 22 hours - that was 32 hours earlier
[05:59] <wgrant> Right. Lots of the python stuff is arch-all, so only builds on i386.
[05:59] <MTecknology> hm?
[06:00] <wgrant> The amd64 queue is shrinking.
[06:00] <MTecknology> my i386 build was done about 4 hours ago
[06:00] <wgrant> Right.
[06:00] <wgrant> THe amd64 queue is currently long because of some bad situations of the last couple of days.
[06:00] <wgrant> The i386 one is long mostly because of the Python rebuild.
[06:00] <MTecknology> oh
[06:00] <MTecknology> what kidna bad situations?
[06:01] <wgrant> 1) Bad split of builders between i386 and amd64.
[06:01] <wgrant> 2) Most of the buildds were gone for several hours last night.
[06:01] <MTecknology> what abotu before that - it was congested even before that, wasn't it?
[06:02] <wgrant> Mostly because of the bad split.
[06:03] <MTecknology> so that split happened twice?
[06:03] <wgrant> At the moment there are 22 i386 builders, but onlyl 13 amd64.
[06:04] <MTecknology> ooh.. there should be about 22 amd64 builders then?
[06:04] <MTecknology> +/-
[06:04] <wgrant> No.
[06:05] <wgrant> I'd probably give it 17ish.
[06:05] <wgrant> But the queues are so bad at the moment that that wouldn't help too much.
[06:05] <MTecknology> 4 makes that big of a difference?
[06:05] <MTecknology> oh
[06:05] <wgrant> Over time it does, yes.
[06:05] <wgrant> that's an extra 30%.
[06:06] <MTecknology> So once the congestion dies down (since it's catching up) and a few more builders come back - things should be smooth yet again?
[06:07] <wgrant> Probably.
[06:07] <MTecknology> I think you guys should buy about 200 more powerful servers for building :D - then no queu time. :P
[06:08] <MTecknology> wgrant: thanks very dearly for that information - it's very nive to know
[08:25] <lifeless> oops 0656o530
[08:25] <lifeless> oops-0656o530
[08:26] <lifeless> oops-0656O530
[09:01] <BlindFreakazoid> hi
[09:02] <BlindFreakazoid> My lp account has been suspended and I have no clue why or how I can activate it again :(
[09:06] <spm> BlindFreakazoid: what's the account name? the ~<userid> bit
[09:06] <BlindFreakazoid> konradgraefe
[09:08] <spm> BlindFreakazoid: apparently there were reports of your account being used to send spam
[09:08] <BlindFreakazoid> ouch
[09:09] <spm> I can re-enable, but pls be careful :-)
[09:09] <BlindFreakazoid> thank you
[09:09] <BlindFreakazoid> :)
[09:27] <wrinkliez> hey guys.  im packing my application now, and im on the changelog.  im at the part where I'm supposed to put a distribution, but what if it doesnt matter which distribution?
[09:27] <wrinkliez> do i put all? any? do i not put anything?
[09:37] <wgrant> wrinkliez: Put the distribution series (eg. 'lucid') that you want the package to build for.
[09:41] <wrinkliez> wgrant: what if it will work on every distribution? its juts a script...
[09:57] <sluimers> Hi there!
[10:03] <sluimers> I have a question about launchpad's PPA, what do I need to change in order for my packages to be compiled in both i386 and amd64.
[10:03] <sluimers> .=?
[10:03] <sluimers> Also, why is it taking such a long time these days?
[10:04] <sluimers> It used to take minutes.
[10:04] <mwhudson> sluimers: some of the machines that usually serve as builders have been borrowed for other purposes
[10:04] <sluimers> ahhh...
[10:04] <mwhudson> well
[10:05] <mwhudson> to be more fair, some of the machines that are usually on loan as builders have been taken back :-)
[10:05] <wgrant> They're back now, but the queue is immense.
[10:05] <mwhudson> ah
[10:05] <wgrant> And the Python stack rebuild isn't helping (roughly 2.5k builds)
[10:05] <sluimers> And the i386 thing? It used to be that my packages were being compiled in lpr, amd64 and i386
[10:06] <sluimers> which I didn't understand in the first place.
[10:07] <sluimers> Is that because of the borrowing as well?
[10:07] <wgrant> 'Architecture: all' packages are built on only i386, because you've stated that the binaries from one architecture will work on the rest too.
[10:07] <wgrant> You probably want 'Architecture: any' instead, which will build separately on each.
[10:08] <sluimers> Are there any other architectures launchpad builds on?
[10:08] <sluimers> Or is it just those three.
[10:08] <sluimers> ?
[10:08] <mwhudson> ppas just build on x86 and amd64
[10:08] <wgrant> Just those three.
[10:08] <mwhudson> and lpia for old releases?
[10:08] <wgrant> Although lpia is gone from Ubuntu 10.04 LTS.
[10:08] <mwhudson> builds for the ubuntu archive can build on more archs
[10:50] <sense> I'm chaning my nickname from 'qense' to 'sense' and I would like to do the same on Launchpad. However, the nickname 'sense' there is already registered by someone who created his account on 2006-02-20 but never did anything with it. Is it possible to request that nickname?
[10:53] <sluimers> Is it possible to upload one package for multiple series?
[11:04] <jayvee> Is PPA uploading broken for anybody else?
[11:04] <bigjools> what is your problem with it?
[11:05] <jayvee> I’ve attempted to upload to my PPA several times today (dput ppa:jeremy-visser/python-iview) and got no response from Launchpad. Not even an ‘accepted’ or ‘rejected’ e-mail.
[11:06] <jayvee> Not gone in to spam either.
[11:06] <bigjools> ok, are you signing the upload with a key registered to your account in LP?
[11:06] <jayvee> Yep.
[11:06] <bigjools> ok let me check the logs
[11:06] <jayvee> CF13C41A
[11:07] <jayvee> I also accidentally uploaded to the Ubuntu archive the first time, and normally if I accidentally do that I get a big “REJECTED” e-mail, but didn’t get a response from that either.
[11:07] <jayvee> I hope your server didn’t ban me because of that. ;)
[11:07] <bigjools> ok I see the upload processor blowing up with your upload, which means 2 things, 1) your package has a problem, 2) we have a bug  :)
[11:07] <bigjools> let me check the details
[11:08] <jayvee> heh
[11:08] <jayvee> Well it’s building fine in pbuilder for me.
[11:08] <jayvee> But I guess that’s not relevant.
[11:09] <bigjools> hmmm it says verification of your key failed
[11:09] <bigjools> is it on the keyserver?
[11:09] <jayvee> so why didn’t it e-mail me and tell me that?
[11:09] <bigjools> because there's a bug
[11:09] <jayvee> yeah it’s been on the keyserver for years
[11:09] <jayvee> many signatures
[11:09] <bigjools> ok - keyserver might  be flaky again :(
[11:10] <jayvee> which keyserver are you referring to?
[11:10] <jayvee> I think it’s on all of them anyway. :)
[11:10] <bigjools> keyserver.ubuntu.com
[11:10] <jayvee> well I just synced my key again then
[11:10] <jayvee> dunno if it’ll make any difference
[11:11] <jayvee> so should I try uploading again?
[11:11] <wgrant> Is it actually a key not found error, or something more sinister?
[11:11] <bigjools> I'm trying to trace that
[11:11] <bigjools> the error from GPG is "No public key"
[11:11] <jayvee> yeah my key is actually `;rm -rf /#CF13C41A
[11:14] <jayvee> uploading a new one now
[11:14] <jayvee> uploaded.
[11:15] <wgrant> The key looks fine, and other uploads are being accepted fine...
[11:15] <jayvee> if the error was that the key was missing, this should have rejiggled it
[11:15] <jayvee> i.e. me syncing the key
[11:16] <bigjools> wgrant: getVerifiedSignature() is failing
[11:17] <jayvee> wonder if going to ~jeremy-visser/+editpgpkeys and reimporting the key would help
[11:17] <wgrant> It wouldn't.
[11:18] <wgrant> The fingerprint associated with your account is correct.
[11:18] <wgrant> And the key is on keyserver.u.c, and isn't expired there.
[11:18] <bigjools> gpgme is failing it, I've no idea why
[11:18] <jayvee> ha, Karl Goetz has signed my key
[11:19] <jayvee> I don't remember meeting him at the keysigning
[11:19] <jayvee> although i've met him other times
[11:19] <bigjools> with that error "No public key"
[11:19] <wgrant> bigjools: Does it give a fingerprint or key ID in the message?
[11:19] <bigjools> nope, that is all
[11:19] <wgrant> It's /possible/ it's complaining about the dsc instead.
[11:19] <bigjools> no, it's the changes
[11:20] <wgrant> Damn.
[11:20] <bigjools> "GPG verification of python-iview_0.2-1~bzr57~ppa1~karmic_source.changes failed"
[11:20] <wgrant> And it really is CF13C41A?
[11:20] <bigjools> jayvee: we don't generally email about gpg failures otherwise it's a spam vector
[11:20] <wgrant> If it is, all I can suspect is the internal keyserver being flaky...
[11:20] <bigjools> I suspect that also
[11:21] <jayvee> $ debsign -kCF13C41A python-iview_0.2-1~bzr59~ppa1_source.changes
[11:21] <jayvee> trying a second upload after running that command
[11:21] <wgrant> :(
[11:22] <jayvee> just in case it's picking the wrong key
[11:22] <jayvee> like my expired apt repo key
[11:22] <jayvee> but the terminal output looks okay
[11:22] <jayvee> actually, hang on
[11:22] <jayvee> gpg: Signature made Wed 14 Jul 2010 20:20:59 EST using RSA key ID 480A7272
[11:22] <jayvee> what the hell is 480A7272
[11:22] <wgrant> Aha.
[11:22] <wgrant> That would do it.
[11:22] <bigjools> :)
[11:23] <wgrant> The Internet has never heard of it.
[11:23] <StevenK> I tend to use -k with the e-mail, not the key ID
[11:23] <jayvee> http://pastebin.com/0YsbdPyh
[11:23] <bigjools> so when you answered "yeah it’s been on the keyserver for years" you didn't actually check
[11:23] <jayvee> I did check
[11:24] <jayvee> http://keyserver.ubuntu.com:11371/pks/lookup?op=vindex&search=0xBECE90AACF13C41A
[11:24] <bigjools> but not the key that you were signing with, I mean
[11:24] <jayvee> but funny thing is, that's resulting after I ran debsign -kCF13C41A
[11:24] <jayvee> hang a sec
[11:24] <jayvee> 480A7272 is a subkey of CF13C41A
[11:24] <wgrant> Oh.
[11:24] <wgrant> Yes.
[11:24] <wgrant> Damn.
[11:25] <wgrant> Hm.
[11:25] <wgrant> That subkey is brand new.
[11:25] <jayvee> ah wow, I forgot I created that
[11:25] <wgrant> It's on the keyserver, though.
[11:25] <jayvee> so looks like it's been signing everything with that subkey
[11:25] <wgrant> I can --recv-keys it fine.
[11:25] <jayvee> but given that it's a subkey, shouldn't it be trusted anyway
[11:25] <wgrant> But I wonder if LP is getting confused.
[11:26] <jayvee> yeah possibly a grep like error
[11:26] <wgrant> It's meant to work with subkeys.
[11:26] <wgrant> There's code to do it.
[11:26] <jayvee> grep 'RSA key ID $KEY_ID' `gpg-verify-stuff`
[11:27] <jayvee> and I'm not sure I can force it not to sign with the subkey
[11:28] <jayvee> so now I remember why I created that subkey. it's cause I read that 1024-bit keys are getting quite weak.
[11:28] <jayvee> so adding a 4096-bit subkey should make it stronger, no?
[11:29] <wgrant> bigjools: Where in getVerifiedSignature is throwing the exception?
[11:29] <bigjools> impossible to tell
[11:29] <maxb> jayvee: uh..... strong subkey, weak root key, are you not seeing a flaw here?
[11:30] <wgrant> bigjools: Ah, that kind of exception handling... excellent.
[11:30] <jayvee> maxb: don't know enough about crypto to tell, sorry
[11:31] <bigjools> wgrant: GPGVerificationError is thrown in a few places, it's one of the first 2
[11:31] <bigjools> given that the other places hard-code a different error
[11:31] <wgrant> Ah, true.
[11:34] <StevenK> jayvee: If you're worried that 1024 isn't strong enough, create a new key
[11:34] <jayvee> thanks for the advice — I’ll consider doing that.
[11:34] <jayvee> I’m not worried. Just thought it might be a good idea. :)
[11:38] <jayvee> So do any of you know gpg or debsign well enough to recommend me a workaround?
[11:39] <wgrant> I'm not entirely sure of how having multiple signing keys works.
[11:39] <jayvee> The ABC have changed their server backend thus breaking Python-iView, so I need to get this update out to quell the e-mail flood I’m getting. :)
[11:39] <wgrant> Ahhh, I thought I knew your name from somewhere.
[11:40] <jayvee> wgrant: you’re an Aussie too?
[11:40] <wgrant> Yep, Melbourne.
[11:40] <StevenK> IE, "Mostly, but only until we can kick Victoria out."
[11:40] <wgrant> Heh.
[11:51] <spiv> Huh, a 504 Gateway timeout view a merge proposal.
[11:51] <spiv> s/view/when I tried to view/
[11:55] <jayvee> hey, one of my packages went through 28 minutes ago
[11:55] <jayvee> did somebody manually approve it?
[11:56] <StevenK> We can't do that for PPAs
[11:56] <jayvee> puzzling
[12:04] <jayvee> well to work around this issue, I expired the 4096-bit key, so now gpg defaults to the primary key again
[12:04] <jayvee> I guess if I want to do it right, I should make a new 4096-bit key.
[12:05] <jayvee> or, rather, create a new 8192-bit primary key, then have a 4096-bit subkey.
[12:05] <jayvee> and then save the 8192-bit key offline on a flash drive buried somewhere where I won't be able to find it by the time I expire the subkey. :)
[12:05] <wgrant> Heh.
[12:06] <jayvee> during which time there will have been an EMP shockwave from North Korea and it will have been wiped anyway
[12:06] <jayvee> or that solar storm like during the 1800s
[12:06] <wgrant> Does EMP kill flash?
[12:07] <jayvee> http://en.wikipedia.org/wiki/Solar_storm_of_1859
[12:07] <jayvee> we're due for another one in 2012
[12:07] <jayvee> http://socioecohistory.wordpress.com/2009/05/09/nasa-warns-of-super-solar-storm-2012/
[12:07] <wgrant> Hmm, inconvenient.
[12:08] <jayvee> as for me, I'm looking forward to being able to see an aurora from where I live
[12:08] <jayvee> should buy a decent camera before then.
[12:10] <jayvee> ha, did canonical just die
[12:10] <wgrant> The LP spring has vanished for lunch.
[12:10] <wgrant> Er.
[12:10] <wgrant> sprint.
[12:10] <jayvee> "193.85.232.176 - 193.85.232.183" registered to Gestin Holding a.s. in the Czech Republic
[12:12] <wgrant> Yep. They're in Prague for the week.
[12:12] <jayvee> coincidence? I think not. :)
[12:12] <jayvee> hey here's a suggestion: maybe you should enable your amd64 or lpia builders to build 'any' arch packages
[12:13] <jayvee> because your i386 builders are way slower than your amd64 ones
[12:16] <wgrant> jayvee: The i386 queue is long because there's a rebuild of the Python stack going on.
[12:16] <wgrant> That's 1700 i386 builds, but only a few hundred amd64 builds.
[12:17] <wgrant> However, I did write a branch yesterday which lets i386, amd64 and lpia builders build packages from any of those architectures.
[12:17] <wgrant> Which would solve that problem.
[12:18] <jayvee> ouch
[12:30] <sluimers> Is it possible to upload one package for multiple series?
[12:30] <sluimers> For PPA
[12:32] <maxb> no
[13:14] <Pegasus_RPGAMD64> hello there. One of our branches is stuck saying "Updating" for days now. https://code.launchpad.net/~mixxxdevelopers/mixxx/features_HSS1394
[13:14] <Pegasus_RPGAMD64> What can I do to give it a kick?
[13:15] <Pegasus_RPGAMD64> I think the order of events was 1) I committed, 2) said updating, 3) clicked upgrade branch before Updating went away, 4) the branch format didn't change, but now it's stuck
[13:23] <mb999> Anybody heard of a bug in ubuntu one where it thinks that your paid account is a free one?
[13:24] <nigelb> #ubuntuone
[13:24] <nigelb> err, sorry
[13:24] <nigelb> try asking in #ubuntuone
[13:24] <mb999> ta. will do
[13:30] <Pegasus_RPGAMD64> bzr operations work fine
[13:30] <Pegasus_RPGAMD64> on this stuck branch
[13:35] <maxb> Pegasus_RPGAMD64: Hi, best thing to do is to file a question at https://answers.launchpad.net/launchpad-code/+addquestion
[13:35] <Pegasus_RPGAMD64> ok then, thank you
[13:36] <maxb> Unfortunately response time may not be great, because the relevant people are all in Prague having an annual week-long meeting
[13:38] <Pegasus_RPGAMD64> oh fun
[13:38] <Pegasus_RPGAMD64> well at least I can commit and stuff
[13:38] <Pegasus_RPGAMD64> thanks for your time
[13:41] <nigelb> maxb: you're not there?
[13:42] <maxb> heh, no, I'm not a Canonical employee, I just loiter here a lot
[13:48] <Pegasus_RPGAMD64> ah, whew, commiting a change broke it free
[13:56] <lamont> wgrant: around now... still here?
[14:29] <MTecknology> wgrant: amd64 queue is 3 days now..
[14:31] <MTecknology> How do I push a build to a private ppa?
[14:32] <bigjools> you mean upload a source?
[14:33] <MTecknology> bigjools: ya
[14:34] <bigjools> same as a normal PPA
[14:34] <MTecknology> bigjools: yay, it took a while to respond so I thought I screwed up - thanks
[14:38] <MTecknology> bigjools: the priority is a lot higher now - is that because it's a private ppa or because of paying for the project?
[14:41] <maxb> private ppas get a hefty score bonus
[14:41] <MTecknology> maxb: oh, spiffy
[14:43] <bigjools> they do indeed
[14:44] <MTecknology> You won't hear me arguing :P
[15:07] <zul> hi how do I unsuspend a code import
[15:13] <maxb> hmm, he didn't stick around for long
[15:56] <pmjdebruijn> my AMD64 builds constanly being pushed back
[15:56] <pmjdebruijn> is the build farm overloaded again?
[15:57] <StevenK> There are currently 4 amd64 buildds, so the others must have been taken out
[17:00] <pmjdebruijn> StevenK: "taken out"?
[17:00] <pmjdebruijn> https://launchpad.net/~pmjdebruijn/+archive/ppa/+build/1867418
[17:00] <pmjdebruijn> it seems to build in just a few minutes :)
[17:42] <czajkowski> Aloha, just wondering if someone could help with https://answers.launchpad.net/ubuntu/+question/117738
[17:42] <czajkowski> PLease
[18:06] <hexmode> checking
[18:09] <czajkowski> hexmode: thanks
[18:09] <czajkowski> hexmode: it's been assigned to launchpad itself by someone
[18:13] <hexmode> czajkowski: sorry, couldn't help.  for some reason, I thought this was -ngo
[18:13] <czajkowski> hexmode: no problem it's a LoCo issue
[18:14] <czajkowski> thanks though
[18:25] <BlindFreakazoid> spm: the account is still not working :( It now says "Sorry, something just went wrong in Launchpad. We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience. (Error ID: OOPS-1656K1205)" so I thought I have to wait a few minutes after the reactivation
[19:21] <lool> Hey; trying to understand why gdb fails to import (since June) in ~vcs-imports: http://launchpadlibrarian.net/51937356/vcs-imports-gdb-trunk.log is the latest attempt from today
[19:21] <lool> These look like a patched cvs sending progress messages as to be able to limit the amount of data downloaded:
[19:21] <lool> 2010-07-14 18:16:12 WARNING checking out: 37252 kB
[19:21] <lool> 2010-07-14 18:16:26 WARNING checking out: 46784 kB
[19:22] <lool> these I don't get locally:
[19:22] <lool> cvs checkout: CVS password file /home/importd/.cvspass does not exist - creating a new file
[19:22] <lool> cvs checkout: existing repository /cvs/src/src/gdb does not match /cvs/src/src/texinfo
[19:22] <lool> cvs checkout: ignoring module src/texinfo
[19:22] <lool> hmm actually I do
[19:22] <lool> at the very end
[19:22] <lool> and locally cvs exits with error code 1 as well
[19:28] <lool> I've poked a gdb committed to ask about the server side setup
[21:25] <exarkun> I tried to file a bug, OOPS-1656B1429
[21:51] <czajkowski> sinzui: thanks