[09:08] <danhg> Morning all
[09:09] <czajkowski> aloha :)
[09:37] <czajkowski> any idea why on https://launchpad.net/  the blog posts that are displayed at not the current ones from http://blog.launchpad.net/
[10:02] <mandel> can I have a pointer to a decent way to detect that the revno of the trunk of a project has changed trying not to dos attack lp?
[10:02] <mandel> I want to detect new revisions in order to build windows installers for ubuntuone, which cannot be done by lp atm :)
[10:08] <tumbleweed> mandel: you can see the current tip revision of lp branches through the API. Here's a hacky script I use that daes this: https://code.launchpad.net/~stefanor/ibid/update-branches/+merge/82793
[10:09] <mandel> tumbleweed, that means that if I wanted to do the same I'd have to be pooling every number of mins, right?
[10:09] <tumbleweed> poolie: ^ something like that would be nice in hydrazine
[10:10] <tumbleweed> mandel: if you don't want to poll, how about subscribing to e-mail notifications from the branch?
[10:10] <mandel> tumbleweed, ah, that is a much nicer way to do it :)
[10:11] <mandel> tumbleweed, nice thinking
[12:06] <frathgeber> quick question re the suffix automatically appended to the revision of packages built by the launchpad bzr builder
[12:07] <frathgeber> i.e. the ~oneiric1 bit
[12:08] <frathgeber> i was assuming the final counter 1 would automatically increment if a build was re-triggered while the debian revision of the recipe hadn't changed
[12:10] <frathgeber> e.g. you change the recipe to temporarily merge in a fix from another branch different from the recipe's base branch
[12:11] <frathgeber> since that's only temporary you don't want to change the debian version of the recipe to include the revno of that branch with the fix
[12:12] <frathgeber> so you keep the debian revision {debupstream}+{revno} and now the ppa upload fails since the revno of the main branch hasn't changed
[12:13] <bigjools> frathgeber: you need a +{revno:packaging} in there
[12:13] <bigjools> or whatever your packaging branch is called
[12:14] <frathgeber> bigjools: that's not the packaging branch, but a branch containing a fix that would hopefully get merged into the trunk
[12:15] <frathgeber> so i don't want to include the revno of that branch in the debian revision
[12:15] <bigjools> you need to change the recipe somehow to change the debversion
[12:15] <bigjools> there's no magic bullet :)
[12:16] <frathgeber> ok, so that's by design that this final counter won't automatically increment when there's a new build with the same debian revision?
[12:17] <frathgeber> in other words, it's not possible to upload a package again unless the debian revision changes?
[12:17] <shadeslayer> Hi, one of the packages in the archives has been pending publication quite some while : https://launchpad.net/ubuntu/+source/kdevplatform
[12:18] <shadeslayer> Known issue in the publisher?
[12:22] <bigjools> frathgeber: yes you must increase the version somehow. if you are merging a different branch in the recipe then you need to account for that
[12:23] <frathgeber> ok, thanks. i'm wondering what the purpose of that final counter in the automatically appended suffix is then
[12:24] <frathgeber> is that ever used?
[12:27] <bigjools> frathgeber: yes, it's for uploading the same build to different distro series
[12:27] <bigjools> not sure what the end number is for though
[12:29] <frathgeber> afaik (in debian) it's for exactly that purpose i have i.e. a new package version for the same debversion of the source
[12:29] <bigjools> right
[12:29] <bigjools> I'd ask on #bzr
[12:30] <frathgeber> e.g. because there was a packaging bug etc.
[12:30] <frathgeber> ok, thanks. is that suffix handled by bzr-builder all by itself?
[12:30] <bigjools> my first suggestion covers packaging bugs
[12:31] <bigjools> your situation is changing the recipe to merge/nest a different branch
[12:31] <frathgeber> right
[12:31] <frathgeber> admittedly that's probably a rather unusual situation
[12:31] <bigjools> and you have reached the limits of my knowledge now, but there are clever folk on #bzr :)
[12:32] <frathgeber> hehe, thanks again
[12:59] <shadeslayer> anyone?
[13:01] <rick_h> adeuring: relieved
[13:04] <rick_h> shadeslayer: looking, sec
[13:07] <wgrant> shadeslayer, rick_h: It's in NEW
[13:07] <wgrant> https://launchpad.net/ubuntu/+source/kdevplatform/1.2.81-0ubuntu1
[13:07] <shadeslayer> uh ... because of the so bump?
[13:07] <wgrant> That's the most likely explanation.
[13:08] <wgrant> https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=kdevplatform <- yes
[13:09] <shadeslayer> alright, I'll get someone to let it through :)
[13:09] <rick_h> thanks wgrant
[13:10] <shadeslayer> thanks, somehow I didn't realize it could get stuck in new
[13:10] <wgrant> Any new binary names will do it.
[13:11] <mgz> has the +adddownloadfile changed in the last few months to make it impossible to actually script uploads to it?
[13:11] <mgz> the curl POST that bzr-windows-installers uses to make life slightly less terrible now reports lp refusing all authentication
[13:14] <mgz> I still get prompted for the SSO password, but always get "Application error.  Unauthenticated user POSTing to page that requires authentication."
[13:15] <wgrant> mgz: You were still using basic auth?
[13:15] <mgz> it's not using oauth at least
[13:15] <wgrant> That's been unsupported for about 2 years, and I removed it last week.
[13:16] <wgrant> It would have been working for very few users for about 18 months.
[13:16] <mgz> ha, so its *your* fault :)
[13:16] <wgrant> But I guess it's possible you were one of them.
[13:16] <wgrant> It's always my fault :)
[13:16] <mgz> is updating this script to do the sso dance actually practical... I fear the pain is too great
[13:18] <mgz> are there any docs on how you're meant to script authentical interaction with lp webpages?
[13:18] <mgz> or is it just "use the api"... which I think still doesn't support uploading releases?
[13:18] <wgrant> You're meant to use the API.
[13:18] <wgrant> Which doesn't support file uploads at present, I don't think, right.
[13:18] <mgz> you pain me, sir :)
[13:19] <wgrant> Oh
[13:19] <wgrant> Yes you can, actually
[13:19] <wgrant> I just searched for the wrong thing.
[13:19] <mgz> ha, neat. link?
[13:19] <wgrant> project_release.add_file is the method. I believe there are clients around.
[13:21] <wgrant> mgz: lptools has lp-project-upload
[13:21] <mgz> ta, will take a look
[13:21] <wgrant>     Usage: /usr/bin/lp-project-upload <project name> <version> <tarball> [new milestone] [changelog file] [releasenotes file]
[15:13] <kirkland> bigjools: howdy, around?
[15:13] <bigjools> kirkland: present and somewhat correct
[15:14] <kirkland> bigjools: okay, I chatted briefly with flacoste about this last week
[15:14] <kirkland> bigjools: i'm looking at the launchpad/soyuz/ppabuild/publisher code
[15:14] <kirkland> bigjools: we have a need to push a source package to a private ppa, have it build, and then publish the binaries only (not the source)
[15:15] <kirkland> bigjools: i'm willing to work on a patch to do so, but I don't want to work on it in vain
[15:15] <kirkland> bigjools: i was wondering if you could give me some advice before I'm chin deep in a patch that won't be accepted
[15:15] <kirkland> bigjools: or even just an approach
[15:15] <bigjools> kirkland: ok please come over to #launchpad-dev
[15:16] <kirkland> bigjools: ack wilco
[16:12] <deryck> ah, yay, onward and upward with me.  rick_h you are done sir!
[16:14] <rick_h> deryck: ty sir
[16:14] <deryck> np!
[19:24] <abentley> deryck[lunch]: I relieve you
[19:27] <rsalveti> hey, don't know if this was reported already (that's why I'm asking here first), but it seems that launchpad's blueprint javascript is resizing the whiteboard in a quite annoying way currently
[19:28] <rsalveti> I tried to edit https://blueprints.launchpad.net/linaro-ubuntu/+spec/push-multiarch-changes-for-cross-precise-12.01, and when I hit space it shrinks and expands itself
[19:28] <rsalveti> was able to reproduce that with both firefox and chromium
[19:38] <Ursinha> god, there's some serious stuff going on with lp blueprints
[19:39] <Ursinha> ah, someone reported already
[19:39] <rsalveti> Ursinha: bug?
[19:39] <Ursinha> rsalveti, reported to lp team, not reported a bug
[19:39] <Ursinha> in case, you did
[19:39] <rsalveti> oh, ok, guess just have to wait then :-)
[19:40] <Ursinha> rsalveti, did you search for reported bugs?
[19:40] <rsalveti> Ursinha: no, not yet
[19:40] <Ursinha> if not, it might be nice to report one, than we can just point people there
[19:40] <Ursinha> escalate or whatever
[19:42] <rsalveti> don't need to escalate, whiteboard is broken everywhere :-)
[19:42] <rsalveti> it's quite high/critical anyway
[19:43] <rsalveti> lol, timeout while opening bugs.launchpad.net
[19:44] <rsalveti> Ursinha: bug 919299
[19:44] <rsalveti> seems this is not only happening with blueprints
[19:45] <Ursinha> oops
[19:45] <Ursinha> so it's critical critical
[19:45] <Ursinha> rsalveti, you might want to mark that bug as affecting you too
[19:45] <rsalveti> Ursinha: did it already
[19:46] <Ursinha> rsalveti, ah, cool :) when I looked at the bug it has only the reporter as affected
[19:50] <wgrant> rick_h: ^^
[19:50] <wgrant> Oh
[19:50] <wgrant> You reported it.
[20:02] <rick_h> wgrant: thanks yea, working on it. Will have it later tonight. Have to run atm.