[02:40] <qnix> Hi...
[02:40] <qnix> what's that: upload rejected: format '3.0 (quilt)' is not permitted in hardy.
[02:40] <qnix> why does format 3.0 quilt rejected?
[02:41] <wgrant> qnix: Hardy's dpkg doesn't support the new source formats.
[02:41] <qnix> well... I have a dpkg backported in my ppa
[02:43] <qnix> that's sad if I have to modify all the debian package for that. everything built fine in my chroot
[02:43] <wgrant> It is whitelisted per series, due to builder restrictions.
[02:43] <wgrant> It has to be extractable before the PPA is introduced to sources.list.
[02:44] <qnix> damn
[02:46] <qnix> Will it work if I convert all my quilt patch into a big dpatch file and remove the debian/source directory?
[02:46] <qnix> I'm not sure what source 3.0 (quilt) implies...
[02:46] <wgrant> qnix: Why not just alter debian/rules to include quilt?
[02:46] <wgrant> But yes, you could.
[02:47] <qnix> include quilt? you mean that I could apply my patch manully with quilt push -a in debian/rules?
[02:49] <wgrant> quilt existed long before 3.0 (quilt). cdbs and dh both have quilt helpers.
[02:50] <qnix> ok, reading a page now, thanks for the hint.
[03:51] <wschaub> (this is for my own local install of launchpad) when you delete a package from your PPA what script runs in the background to actually delete the package files from your ppa?
[03:52] <wschaub> I have scripts running form cron that take care uploading to the ppa and feeding stuff to the build farm but it seems I'm missing running a script that handles this part.
[03:53] <StevenK> wschaub: process-death-row
[03:54] <wschaub> thanks.
[03:55] <wschaub> does that have to be run with a --ppa argument for PPA's or does it just deal with everything with no arguments?
[03:55] <StevenK> The former
[03:56] <wgrant> wschaub: Note that deleted packages will be found by process-death-row as soon as publish-distro has run, but superseded packages will stay around for 24 hours.
[04:21] <wschaub> wgrant: while I'm here I tried to upload util-linux to the PPA and it keeps bombing out saying that there is an invalid section 'base'
[04:22] <wgrant> wschaub: Which series?
[04:22] <wschaub> natty is whats in the changes file.
[04:23] <wschaub> I imagine you just can't use that package in a PPA. I'm not sure how to upload to the main archive though. and even if I did I suspect I would have to find a way to let the main archive know about ports.ubuntu.com anyway and I don't know how to do that either.
[04:24] <wgrant> You can use any package in a PPA.
[04:24] <wgrant> This is a bug in my bootstrapping script.
[04:24] <wschaub> oh, thats good to know.
[04:26] <wschaub> thankfully I made vm snapshots this time around so it should be easy to re-merge your script in without waiting for rocketfuel-setup again.
[04:29] <wgrant> You don't need to rerun it this time.
[04:29] <wgrant> "INSERT INTO section (name) VALUES ('base'), ('debian-installer'), ('virtual');" should do it.
[04:30] <wschaub> Ok I will give that a shot and see how it goes.
[04:51] <wschaub> I think I found a problem with the postinst script for launchpad-buildd btw it seems to not set the permissions on /etc/sudoers.d/buildd to 0440
[04:52] <wschaub> it ends up as 0644 which causes sudo to not read it in
[04:53] <wgrant> That's a fairly new thing which is managed a bit strangely on production (which is partially puppetised). I'm not surprised it doesn't work completely.
[04:55] <wschaub> not sure adding a chmod to postinst is the best place for that but should work for me.
[04:56] <wgrant> None of that should be in any reasonable postinst, but launchpad-buildd is not a very normal package.
[04:57] <wgrant> :(
[05:16] <StevenK> wschaub: Do it properly -- man dh_fixperms
[05:17] <wschaub> will that work for a file that is created by the postinst script?
[05:17] <wschaub> because thats how this file ends up existing.
[05:18] <StevenK> Ah, then you are stuck with chmod in the postinst
[05:19] <wschaub> already done and it works nicely. just added the chmod right after the end of the heredoc that creates it.
[05:34] <wschaub> looks like util-linux 0s building fine now.
[05:34] <wschaub> hoowever I'm running into something else. after I've deleted slrn and bc from my PPA and process-death-row runs and all.
[05:35] <wschaub> if I try and re-upload the same version it complains that that version is already accepted into ubuntu/natty and wont put it back up.
[05:35] <wschaub> so it won't rebuild.
[05:35] <wschaub> how do I force it to rebuild without creating a whole new version?
[05:36] <wgrant> wschaub: You can't upload the same version again. That would be a lie.
[05:39] <wschaub> so how do i change it so that I can re-submit it again? like say for example i wanted to pass different flags to the compiler or something this time around.
[05:39] <wgrant> Add a new changelog entry with dch -i
[05:57] <wschaub> Ok, I have them resubmitted but I have two builders now and it seems like only one of them is getting jobs sent to it though both are set up in auto mode.
[05:57] <wschaub> the first one I added last night seems to get all the jobs while my smartbook just stays idle even though theres more than one package left to build.
[05:59] <wschaub> is that normal? i wouls have assumed any idle builder would get the next build job that was pending.
[06:00] <wschaub> is that not how it works?
[06:03] <wschaub> if I take down the first builder the second one does get jobs.
[06:04] <wschaub> is there any way to set it up so that if I upload say 3 new changes files and I have 3 ilde builders that all 3 will build one of each?
[06:13] <wschaub> doesn't do me a lot of good having my own local launchpad build farm if I can't keep it 100% busy with package builds.
[06:29] <wgrant> wschaub: Ah, there's a rule that says one PPA may not take more than 80% of the builders.
[06:29] <wgrant> Let me find the code.
[06:30] <wgrant> wschaub: Search for num_arch_builders in lib/lp/soyuz/model/buildpackagejob.py
[06:30] <wgrant> wschaub: After fixing that you'll need to restart buildd-manager.
[06:45] <wschaub> f num_arch_builders > 1:
[06:45] <wschaub>             sub_query += """
[06:45] <wschaub> ...
[06:45] <wschaub> just make sure that qury doesnt get run then?
[06:46] <wgrant> eg. by deleting it or s/num_arch_builders > 1/False/
[06:46] <wschaub> Ok.
[07:03] <LLStarks> hi
[07:06] <wschaub> I made the change and restarted launchpad but it seems to be acting exactly the same. (unless There is more than one place in that file I need to change)
[07:06] <wschaub> and I mean totally restarting the entire vm.
[07:07] <wgrant> wschaub: Are the builders all shown in the same category on /builders?
[07:07] <wgrant> ie. do you see a count of 3 for armel official distribution builders?
[07:07] <wschaub> I only have 2 builders.
[07:07] <wschaub> 3 was just an example of how I think it should work.
[07:08] <wschaub> but they are all listed under offical builders.
[07:08] <wschaub> and both on auto.
[07:08] <wgrant> Can you pastebin your buildpackagejob.py diff?
[07:08] <wschaub> i update the changelogs, upload the 3 packages and run the scripts and only one builder is running with 3 jobs in its queue.
[07:09] <wgrant> Both work if you disable the other one?
[07:09] <wschaub> yeah I alerady tested that before the change.
[07:09] <wschaub> I can unplug the network cable from one and in a bit the jobs go to the other builder.
[07:13] <LLStarks> hi is normal for web-viewing of mailing lists on lp to lag days behind the actual mail?
[07:14] <wgrant> LLStarks: There's a significant backlog in the processing queue at the moment. It should be almost caught up now, though.
[07:15] <wgrant> LLStarks: So, no, not normal. But known to have been the case for a week or so now.
[07:15] <wgrant> We've had some very big lists with a lot of mail.
[07:24] <wschaub> http://pastebin.ubuntu.com/605582/
[07:24] <wschaub> it picked up a lot of other things.
[07:24] <wschaub> but you should see the diff for that script in there.
[07:25] <wgrant> You can give it a path to look at, but let's see.
[07:25] <wgrant> Hmm, You're definitely running buildd-manager from that same tree?
[07:28] <wschaub> I can try restarting it again. thats the only launchpad tree on that VM.
[07:29] <wgrant> wschaub: s/logging.INFO/logging.DEBUG/ in lib/lp/builddmaster/manager.py
[07:30] <wgrant> Then watch /var/tmp/development-buildd-manager.log
[07:31] <wschaub> ok
[07:36] <wschaub> I don't think its running at all actually.
[07:38] <wgrant> That could be a problem.
[07:38] <wgrant> Have you run start-dev-soyuz?
[07:38] <wgrant> Or your init script
[07:39] <wschaub> yeah, for some reason it just didnt start though.
[07:39] <wschaub> now that its running it is behaving like I expected.
[07:39] <wschaub> I have 2 builders building packages now.
[07:40] <wschaub> I wish I had more builders to test with but I can have steev do that.
[07:40] <wgrant> Great.
[07:40] <wgrant> Well, if his efika buildd-manager can manage more than two :P
[07:40] <wschaub> heh I hope he has an x86 machine running it as well but I dont know bout that.
[07:41] <wschaub> so will I have to put this in my docs (the patch to that one file) or is that in your branch?
[07:41] <wgrant> It's not in my branch.
[07:41] <wgrant> It's not that relevant.
[07:41] <wschaub> ok then thats what I will do then. thanks.
[07:42] <wgrant> There has been talk about making non-virtual PPAs exempt from that rule.
[07:55] <wschaub> wgrant: I'm guessing you have that fix for packages that are part of base though right?
[07:56] <wgrant> wschaub: That's pushed, yes.
[07:56] <wgrant> wschaub: I missed three sections (base, debian-installer and virtual) from the list.
[08:09] <flyguy97> I just tried to upload a package, it built successfully but said it failed to upload. Here is the log https://launchpadlibrarian.net/71465029/upload_2541554_log.txt, any ideas on what is going on?
[08:10] <wgrant> flyguy97: Which PPA is that?
[08:10] <flyguy97> jason.scheunemann
[08:10] <flyguy97> or jason-scheunemann
[08:12] <wgrant> flyguy97: The files in that tarball are dated May 11.
[08:12] <wgrant> This seems unlikely to be a factual statement.
[08:12] <wgrant> In the orig.tar.gz, that is.
[08:13] <flyguy97> Looks like my system clock is set one day ahead, don't know what happened there
[08:13] <flyguy97> Crazy stuff:)
[08:13] <wgrant> Heh
[08:13] <flyguy97> Thank you for pointing that out!!
[09:09] <mrevell> Morning 'padders
[10:55] <poolie> hi mrevell
[10:55] <mrevell> Howdy poolie
[10:55] <poolie> mrevell, i forget if i said, but i really liked your sprb video
[10:55] <poolie> especially the music and tea
[10:56] <mrevell> poolie, heh :) Thanks. Yeah, I need to reply to your email. I'll sort out the links from the wiki home page but also the permissions problems. I'm not sure why you don't have them.
[10:56] <poolie> oh thanks
[10:57] <poolie> is the wiki config in a branch or something?
[10:57] <poolie> there's another bug that the 'subscribe' button is broken
[10:57] <mrevell> poolie, The permissions are handled by an ACL that joey setup a couple of years back
[10:57] <mrevell> poolie, Ah, I thought huwshimi had fixed the subscribe link
[10:58] <mrevell> poolie, So, I'm actually not really sure how the permissions work but there's a page in the wiki where there's a list of people who have certain permissions and I think only two people have access to edit it. I'll take a look, though,a nd file an RT to fix that, if needed
[11:00] <mrevell> ears burining huwshimi?
[11:00] <mrevell> :)
[13:13] <ochosi> hi, how can i add a link to an upstream bugreport to a bugreport in lp?
[13:19] <wgrant> ochosi: "Also affects project"
[13:20] <ochosi> wgrant: thanks, done.
[13:49] <gnomefreak> ok how do you add an upstream bug link to a LP bug? for some reason neither Also affects distribution and Also affects project doesnt look right. im trying to add an upstream flash bug
[13:50] <wgrant> gnomefreak: Adobe Flash uses JIRA as its bug tracker, which Launchpad does not support.
[13:50] <gnomefreak> wgrant: thanks
[15:44] <fugue88> When I run this command on one system:
[15:44] <fugue88> bzr get lp:~canonical-isd-hackers/canonical-identity-provider/key-registration
[15:44] <fugue88> I get this error:
[15:44] <fugue88> bzr: ERROR: Permission denied: "Cannot create 'lp%3A~canonical-isd-hackers'. Only Bazaar branches are allowed."
[15:44] <fugue88> Other systems work fine.
[15:45] <fugue88> Another person had grabbed this branch (which I had originally created), reconf'd it to lightweight, then to stacked, then to lightweight (at which point he got a local error), did some other revision ops (merge from trunk), then push'd.
[15:46] <fugue88> Any ideas what might be wrong?
[15:47] <fugue88> Strangely, `bzr info` on this other person's copy show some remembered locations refereincing my local filesystem structure.
[15:48] <jelmer> fugue88, hi
[15:48] <awolfson> Hi All. Does anybody knows, when https://bugs.staging.launchpad.net is planned to be back?
[15:48] <jelmer> fugue88: Running that particular "bzr get" command works fine on other systems?
[15:48] <StevenK> awolfson: Staging is still updating, it should hopefully only be another 12 hours or so
[15:49] <jelmer> fugue88, it looks like that branch has an invalid stacked on location (see the web page)
[15:50] <fugue88> jelmer: Yep, I saw that.  Not sure if it's related.  But yes, that exact same "get" works on other systems.
[15:51] <awolfson> StevenK thanks. I guess there is no way to use staging bugs before update finishes? I need to debug a python script that accesses Launchpad bugs
[15:51] <StevenK> awolfson: You could try qastaging instead
[15:53] <awolfson> StevenK, I am getting the same timeout error. Is https://bugs.qastaging.launchpad.net/ the right url to see if I can access bugs from the browser?
[15:54] <jelmer> fugue88, Is this particular system perhaps running an older version of bzr?
[15:54] <jelmer> I'm wondering if the fact that this branch uses a short form (lp:.../) stacked on URL is perhaps the problem
[15:54] <fugue88> jelmer: 2.1.1
[15:54] <fugue88> jelmer: I've also tried a full bzr+ssh url, which yields the *exact* same URL, mentioning what looks like the short version.
[15:55] <StevenK> awolfson: Yes, it is the right URL.
[15:55] <fugue88> Excuse, "the *exact* same erro message,..."
[15:55] <jelmer> fugue88: I mean the stacked on URL, not the URL you specify to "bzr get"
[15:55] <fugue88> Oh...
[15:55] <jelmer> fugue88, the stacked on URL is in the branch configuration (.bzr/branch/branch.conf)
[15:55] <fugue88> hmm...
[15:56] <jelmer> I'm not entirely sure how the branch could end up with that short URL, as we don't write short URLs by default as far as I know
[15:56] <jelmer> fugue88, perhaps whoever changed the branch to be stacked changed the branch configuration manually?
[15:56] <awolfson> StevenK, No luck today. Thank you for help anyway
[15:58] <fugue88> jelmer: No, not manually, but reconfig'd it kinda strangely.  I'll try to have him reconf with a full stacked-on...
[16:01] <NCommander> jcsackett: ping, you around? I'm having some PPA issues :-/
[16:01] <NCommander> https://answers.edge.launchpad.net/launchpad/+question/156901
[16:02] <jcsackett> NCommander: hi. let me take a look.
[16:02] <bigjools> want some help jcsackett? :)
[16:02] <jcsackett> bigjools: probably. :-)
[16:02] <jcsackett> NCommander: as an aside, looks like you might want to update bookmarks away from using the edge subdomain. :-)
[16:03] <NCommander> jcsackett: I'm in ~launchpad-beta-testers (or whatever the group is)
[16:03]  * NCommander wishes there was a better way of de-edging his links
[16:04] <bigjools> jcsackett: we need to look in the uploader log so I just requested a log sync
[16:04] <jcsackett> bigjools: dig. thanks.
[16:06] <NCommander> jcsackett: I just got an accepted and a rejected email
[16:06] <NCommander> (roughly 20 minutes later :-/)
[16:07] <jcsackett> NCommander: huh. bit of a delay, that.
[16:07] <jcsackett> bigjools ^
[16:07] <bigjools> yeah
[16:07] <NCommander> ugh, now I have two builds racing each other2ubuntu4 and 2ubuntu4~bootstrap5
[16:07] <NCommander> UGH
[16:07]  * NCommander hasn't gotten an email for 2ubuntu4 
[16:10] <jcsackett> bigjools: how long do the logs usually take to sync?
[16:11] <NCommander> other accepted email popped up (approx 15 minutes later)
[16:12] <bigjools> jcsackett: not this long usually
[16:12] <jcsackett> NCommander: so, are you still missing any emails, or can we now say you have gotten everything, but much slower than anticipated?
[16:13] <NCommander> jcsackett: yeah, everything is here, but I've never had to wait this long for LP to respond to an upload
[16:13] <jcsackett> NCommander: right. it's clearly taking too long, i'm just trying to narrow down the problem. :-)
[16:14] <jcsackett> "slow" as opposed to "slow, and other stuff."
[16:14] <NCommander> jcsackett: thanks
[16:20] <noodles775> jcsackett: Hi! Do you know the maximum time required to update a merge proposal diff? I thought it was under 5 mins, but I'm still waiting after 10?
[16:21] <noodles775> jcsackett: for reference, here's the MP https://code.launchpad.net/~michael.nelson/canonical-identity-provider/add_otp_form_field/+merge/60507
[16:22] <noodles775> jcsackett: nm, it updated after 12 mins.
[16:23] <jcsackett> noodles775: ok. i'm not sure there is a precise max time. it's done by a regularly running job, but exact times vary depending on load and amount to do.
[16:40] <noodles775> Thanks jcsackett
[16:40] <jcsackett> yw, noodles775.
[18:23] <RedSingularity> lifeless: Is the karma feature being worked on atm?  Reason I ask is because I have noticed that everyones numbers are constantly declining.  I have not seen an increase in a few days.
[18:28] <benste> how can i delete my LP account ?
[18:31] <jcsackett> you can deactivate your account by going to https://launchpad.net/<your-lp-id>/+deactivate-account
[18:31] <jcsackett> benste ^
[18:32] <benste> thanks
[18:32] <benste> -- (I'm still using LP but found a 5y old account on my mail adress which i needed to delete to avoid confusion :-9)
[18:32] <jcsackett> benste: you can also merge that old account with your current one.
[18:33] <benste> how ?
[18:33] <benste> got the link - thanks
[18:33] <jcsackett> benste: you mean you found the merge link?
[18:34] <benste> jcsackett: it was linked on the delete page
[18:34] <jcsackett> benste: excellent.
[18:37] <benste> jcsackett: i know you don't want to loose users - but it might be helpful to add the delete link somewhere on the profile page
[18:37] <jcsackett> benste: it's available via the "change details" control in the sidebar.
[18:38] <jcsackett> i just threw you the direct link b/c i thought that would be faster for your question. :-)
[18:38] <benste> jcsackett: - i'm sorry didn't see this small footer
[18:38] <benste> next time I'll search better :-)
[18:38] <benste> thanks for your support
[18:39] <jcsackett> benste: :-) it could be larger, but the majority of people hitting that page aren't trying to deactivate their account.
[18:39] <benste> hopefully they're not
[20:30] <lifeless> morning
[20:31] <lifeless> RedSingularity: I'm not sure
[20:31] <lifeless> RedSingularity: if the numbers are changing the updater is running
[20:48] <RedSingularity> lifeless: odd.  I have only seen the numbers reducing over the past few days.  On all users, not just a few.  Guess we will have to wait and see...
[20:49] <lifeless> RedSingularity: so for reduction to happen the script has to be running
[20:49] <lifeless> RedSingularity: but I will enquire
[20:49] <RedSingularity> lifeless: no rush.  Just wondering :)