[09:46] <colonolGron> hello, i am new to launchpad and could need some help. i only registered to push a fix
[09:46] <colonolGron> so i got the source made my change but now i am not sure how to push my change. this is what bzr info tells me: http://pastebin.com/d9KsGm8P
[09:46] <colonolGron> but when i use: bzr push lp:~/g-bluehut/ubuntu-terminal-app/myfix" i get a "permission denied"
[09:46] <cjwatson> You have a stray / there.
[09:46] <cjwatson> You need "bzr push lp:~g-bluehut/ubuntu-terminal-app/myfix" - or you can abbreviate that to "bzr push lp:~/ubuntu-terminal-app/myfix" if you like, since bzr/LP knows your own username.
[09:47] <cjwatson> What you can't do is put a slash between the ~ and your username.
[09:47] <colonolGron> oh, i see. thank you cjwatson
[09:48] <cjwatson> you're welcome
[09:49] <colonolGron> the developers of the main branch dont get notified only by this, right? i still have to use "Propose branch for merging" on the website?
[09:51] <cjwatson> Correct.
[10:01] <colonolGron> okay
[16:26] <LocutusOfBorg1> hi, quoting from ubuntu-devel
 the new buildd stack makes the build get stuck
 https://code.launchpad.net/~costamagnagianfranco/+archive/ubuntu/firefox/+build/6224439
[16:29] <LocutusOfBorg1> https://bugs.launchpad.net/launchpad-buildd/+bug/1350435
[16:30] <LocutusOfBorg1> can anybody please have a look?
[16:30] <dobey> oh qemu crashing
[16:31] <dobey> sounds like a qemu bug
[16:31] <cjwatson> I think that needs to be filed as a bug and escalated to qemu upstream
[16:31] <dobey> surprised that didn't just fail though
[16:31] <cjwatson> preferably with a small test case
[16:31] <cjwatson> it should be possible to exercise it locally with qemu-user
[16:31] <cjwatson> since this is just the qemu-user-static from trusty-updates now
[16:31] <dobey> cjwatson: well, i think maybe a bug that the build didn't immediately fail when that happened, too
[16:32] <dobey> but yeah, the qemu crash itself should be reported against qemu
[16:32] <cjwatson> perhaps, but qemu-user-static failures are often hard to recover from because the recovery code gets eaten ...
[16:32] <cjwatson> though the build should time out after a while
[16:33] <cjwatson> you can cancel it if you're more impatient than that
[16:41] <LocutusOfBorg1> nono, I just don't want to steal other people resources
[16:42] <LocutusOfBorg1> I'm not impatient, this build will never succeed unless the bug is fixed
[16:42] <LocutusOfBorg1> and there seems to be a patch
[16:42] <cjwatson> if it can get into trusty-updates, that would get into scalingstack reasonably routinely
[16:43] <LocutusOfBorg1> wonderful
[16:46] <LocutusOfBorg1> the patch is not merged upstream yet
[16:46] <LocutusOfBorg1> Not Applicable, archived
[16:47] <LocutusOfBorg1> out of ideas, upstream seems to have rejected it
[16:59] <infinity> Oh, that "patch" is the SUSE "just pin to a single core" hammer.
[16:59] <infinity> I do think we should use that in production too, I'm just unsure if we should also be shipping it in the distro.
[17:02] <cjwatson> would be slightly unfortunate to have to fork it, although I guess if we can do it in a PPA now it's a bit less unpleasant than having to do it in dak
[17:03] <infinity> cjwatson: Well, it really might be the right thing to ship in the distro too.  Stability has got to trump performance here for most people.
[17:04] <infinity> cjwatson: I know exactly why upstream doesn't want it, it's evil, masks problems, and is the wrong solution to the bug.  But, fixing all the actual bugs is way beyond what we're going to do ourselves.
[17:05] <cjwatson> also way beyond what upstream has said they're prepared to do
[17:06] <infinity> Indeed.  I don't think many people upstream view qemu-user as a sane and viable way to do the things we (and SUSE) do with it.
[17:06] <infinity> For them, it's a one-off "run a binary hackishly" debugging tool.
[17:06] <infinity> And, indeed, I don't view it as a sane and viable solution to our problems either, it's just the solution we have until we get a metric wankton of arm64 kit to run kvm on.
[17:07] <lifeless> I must say thats a new unit to me (pun intended).
[17:10] <infinity> cjwatson: If we can work up a reliable local reproducer, I think I'd be happy to just SRU SUSE's patch in and call it done.
[17:14] <infinity> Anyhow, bedtime for backwards Adam.  Catch you later.
[17:22] <bennabiy> cjwatson: Is there any good documentation on how to setup the launchpad build environment? I would like to set up a local server here as a build server to test recipes before I commit them to launchpad
[17:26]  * bennabiy waves at glebihan 
[17:29] <pulb1> hi guys. got a question: if  i delete a translation from the import queue, will it be deleted in the import queue only or from launchpad as well?
[17:44] <reed> hi folks, I have a lot of spam submitted as bugs on a project, they all seem to be 'security' bugs, private and I cannot reassign them to null-void or do anything with them
[17:44] <reed> they're annoying
[17:44] <reed> example: https://bugs.launchpad.net/openstack-community/+bug/1338072
[17:44] <reed> https://bugs.launchpad.net/openstack-community/+bug/1338071
[17:45] <reed> right... ubot5 got it right :)
[17:47] <cjwatson> bennabiy: That's using a very large sledgehammer to crack a nut.  You can use bzr-builder locally to test recipes (https://help.launchpad.net/Packaging/SourceBuilds/BzrBuilder), and you can use sbuild locally to test-build source packages (https://wiki.ubuntu.com/SimpleSbuild)
[17:47]  * bennabiy likes big tools
[17:47] <cjwatson> bennabiy: It is possible to set it up (https://dev.launchpad.net/Running/LXC, https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally) but it's only worth it if you're actually developing Launchpad itself.
[17:48] <bennabiy> cjwatson: point taken :)
[17:48] <cjwatson> reed: They aren't on your project any more.  The state you describe is the way in which we hide spam bugs.
[17:48] <reed> cjwatson, I see them though
[17:48] <cjwatson> reed: Possibly because you reassigned them to null.
[17:48] <reed> cjwatson, I see them individually and in the count
[17:48] <cjwatson> Contrary to your claim that you couldn't.
[17:49] <reed> cjwatson, I have done nothing to them, they show up as assigned to the community project, where they were filed
[17:49] <reed> let me grab a screenshot
[17:49] <cjwatson> reed: You aren't ~smaffuli?
[17:49] <reed> cjwatson, I am
[17:49] <cjwatson> Both bugs you listed currently only have bug tasks on null-and-void, not on openstack-community, and the activity log shows that you put them there.
[17:50] <cjwatson> Reload harder. :)
[17:51] <cjwatson> I've marked the three bugs from that user as Invalid, though, to make it less likely that they'll show up anywhere.
[17:52] <reed> cjwatson, https://www.dropbox.com/s/c1frjx49fxzdlbl/Screenshot%20from%202014-07-30%2010%3A49%3A26.png
[17:52] <ehoover> did something in the recipe system change/break in the past couple days? (bzr: ERROR: bzrlib.errors.BzrCommandError: Invalid deb-version: {debversion}~daily-201407300231~ubuntu12.04.1: Invalid version string '{debversion}~daily-201407300231~ubuntu12.04.1')
[17:53] <cjwatson> reed: Try https://bugs.launchpad.net/bugs/<bugnum> on each
[17:53] <cjwatson> reed: Honestly, they show up in a sensible state and not on openstack-community for me
[17:53] <cjwatson> ehoover: https://bugs.launchpad.net/launchpad-buildd/+bug/1350430
[17:53] <ehoover> cjwatson: thanks
[17:54] <cjwatson> ehoover: we recently upgraded PPAs to an openstack/trusty-based system, so much newer version of bzr-builder
[17:54] <cjwatson> generally it seems to be an improvement but there are a couple of regressions like this
[17:54] <ehoover> cjwatson: thanks, i'll subscribe to the bug :)
[17:55] <reed> cjwatson, gah, i still see them https://bugs.launchpad.net/openstack-community/+bug/1338073 but not on  https://bugs.launchpad.net/bugs/
[17:55] <cjwatson> guess I need to set up a local reproduction environment for this kind of thing
[17:55] <reed> damn spammers
[17:56] <cjwatson> reed: I can't see that one at all, and it's not one of the ones you listed earlier :)
[17:56] <cjwatson> reed: try making it public and then I'll fix it up for you
[17:56] <reed> cjwatson, I told you there are ~50
[17:56] <cjwatson> reed: you didn't, actually :)
[17:57] <cjwatson> reed: if you could generally just leave these alone and/or report them rather than dealing with them yourself, then that's actually better for us ...
[17:57] <reed> cjwatson, :) ok, I'm telling you now: there are a lot of them, enough to be annoying... let me try to edit
[17:57] <cjwatson> reed: the problem is that if you put them into a state where I can't see them, then I can't help to clean them up and suspend users and such
[17:57] <reed> cjwatson, I have done nothing to them
[17:57] <cjwatson> I suspect you're marking them private before reassigning to null?
[17:57] <cjwatson> somebody is
[17:57] <reed> uhm
[17:59] <reed> the spammer user is ~sksharma872
[18:00] <cjwatson> yes, that user is suspended and all the bugs I can see from them are in the proper hidden state
[18:00] <reed> no, wrong, this is the spammer https://launchpad.net/~tantrikbaba800
[18:00] <reed> so they're hidden but not assigned to null-void
[18:00] <dobey> if they're marked as security bugs then they're private by default probably
[18:00] <cjwatson> ditto, user suspended on 2014-07-06, all visible (to me) bugs in proper state
[18:00] <reed> something went wrong
[18:00] <cjwatson> if you can see them, make them public and we can fix them
[18:01] <cjwatson> I'm pretty certain that you will be able to make them public if you can see them
[18:01] <reed> cjwatson, let me try to make one bug public and I'll show you the error I get
[18:01] <reed> check now: https://bugs.launchpad.net/openstack-community/+bug/1338076
[18:01] <cjwatson> not public AFAICS
[18:02] <dobey> indeed
[18:02] <reed> it reverted back to private
[18:02] <dobey> as ubot5 so helpfully pointed out :)
[18:02] <reed> check again: https://bugs.launchpad.net/openstack-community/+bug/1338076
[18:15] <cjwatson> very peculiar set of state transitions, but I've shunted that off to null now
[18:16] <cjwatson> I wonder if this would be simplified if we had a "mark all user's bugs as spam" control on the account administration page where we suspend accounts
[18:19] <cjwatson> which would mean LP could kill them all without having to (say) give members of ~launchpad access to everyone's security bugs, which I can't see going over too well
[18:23] <dobey> it should would make things eaiser
[18:23] <dobey> easier
[18:23] <reed> cjwatson, that would make sense
[18:27] <reed> cjwatson, now I see what happened! When I try to assign one of those private bugs to dev-null project I get an error but the bug is effectively removed from my list
[18:28] <reed> example: https://bugs.launchpad.net/openstack-community/+bug/1338078
[18:28] <reed> I'm now going to assign it to dev-null
[18:29] <reed> Error: Not Found \n\n Object: , name: u'1338078'
[18:29] <reed> but the bug is removed from my list... which is good enough for me :)
[18:49] <cjwatson> reed: yeah, you have to be a little careful, I've had to ask admins to undo things for me on a couple of occasions when doing that.  I think it's probably a bug that reassigning a private bug task such that you no longer have an access grant doesn't automatically give you a grant
[18:50] <cjwatson> reed: in such cases I guess making it public first and then only privatising it as the last step is the right sequence
[18:50] <reed> cjwatson, thanks
[18:51] <reed> nice, I cleaned up the bloody mess now
[18:51] <reed> woot
[18:52]  * cjwatson goes to invalidate everything
[18:52] <cjwatson> unusually large number of bugs from a single user from this class of spammer
[18:56] <cjwatson> (done)
[20:25] <mcpierce> Hi, all. I have a question about uploading packages for both trusty and precise to a PPA. Is this not possible? I tried this and my package for precise was rejected.
[20:25] <mcpierce> The packages are versioned as 0.7-3trusty and 0.7-3precise, and both use the same source tarball.
[20:26] <dobey> you can only upload the source tarball once. rebuild the source package for the second upload to not include the full source (so it won't include the orig.tar.gz in the upload)
[20:27] <mcpierce> dobey: Is that without the -sa option?
[20:29] <dobey> right, -sa means include all source in the upload
[20:30] <mcpierce> dobey: Hrm, I did a rebuild with "debuild -S -k[mykeyid]" and then dput ppa:qpid/released ../qpid-proton_0.7-3precise_source.changes -- it was rejected for hte same reason as before.
[20:32] <dobey> is it actually the same source tarball? usually it only complains if you're trying to upload a source tarball that is different than the one that's already on the server, but it has the same name
[20:32] <mcpierce> dobey: I just cleaned up to make sure nothing untoward was in the directory and reran the debuild cmdline.
[20:33] <mcpierce> dobey: Yep. Just checked the md5 sum between my trusty and precise machines and it's the same _orig.tar.gz file on both.
[20:34] <mcpierce> dobey: What I'm seeing is: "File qpid-proton_0.7-3precise.debian.tar.gz already exists in Released Qpid packages for Debian, but uploaded version has different contents."
[20:34] <dobey> yes
[20:34] <dobey> so they are not the same file
[20:34] <mcpierce> dobey: I'm noting seeing any exisitng 0.7-3precise source there,t hough. THere's no precise package in the PPA.
[20:35] <dobey> the source was uploaded though
[20:35] <mcpierce> dobey: How do I delete it?
[20:35] <dobey> you can't
[20:35] <mcpierce> dobey: Ugh. There was a previous push of 0.7-3precise, but I deleted it this morning.
[20:35] <dobey> why are you not using the proper upstream tarball for the orig.tar.gz?
[20:35] <mcpierce> dobey: Actually, this is the upstream tarball.
[20:35]  * mcpierce verifies the MD5 sum.
[20:36] <dobey> then why does it have a debian revision and ubuntu series name in the tarball?
[20:36] <dobey> oh the .debian.tar.gz is what it's complaining about
[20:36] <dobey> not the orig.tar.gz
[20:36] <dobey> you can't upload the same version twice
[20:36] <dobey> you need to bump the version
[20:37] <dobey> change it to 0.7-4precise or something
[20:37] <mcpierce> dobey: Ugh, kk. I had hoped that, since I deleted the broken package that I could reuse the release.
[20:37] <dobey> or no, you cannot upload the same version multiple times
[20:37] <mcpierce> dobey: kk, thanks.
[20:38] <dobey> and you should put a ~ prior to the series name, like "0.7-4~precise" instead, so that version comparison will work better
[20:38] <mcpierce> dobey: kk thanks for that.