[00:22] <pkgman> wgrant: I have an odd source package rejection problem. Can you help?
[00:23] <wgrant> pkgman: Have you tried using debsign directly, or passing additional signing options to debuild?
[00:24] <pkgman> I take it you read my e-mail then? I couldn't find any examples for using a passphrase file and suppressing gpg-agent via either of those.
[00:25] <wgrant> You can't just use an alternate GNUPGHOME?
[00:26] <pkgman> Would that allow passing through a passphrase file?
[00:28] <wgrant> Or use a gpg wrapper script and use debuild -p<wrapper>
[00:29] <pkgman> I can't find a -p option in the manpage for debuild. What does it do?
[00:30] <pkgman> Or is that the debsign option? That looks plausible.
[00:31] <pkgman> I'll try that tomorrow. But I'm still curious as to what a dpkg-source return value of 9 means and why the package gets rejected.
[00:32] <pkgman> I followed the documented behavior of debsign, or so I thought, and a diff of the dsc and changes files showed no differences aside from checksums and signatures.
[00:33] <wgrant> pkgman: debuild passes most of its options down to dpkg-buildpackage.
[00:33] <wgrant> Which in turn inherits a number of options from debsign, though they're explicitly documented in dpkg-buildpackage's manpage.
[00:41] <cjwatson> pkgman: Launchpad just runs "dpkg-source -sn -x foo.dsc" (on a lucid system, currently); nothing particularly exotic
[00:42] <pkgman> So, if dpkg-source is running, the changes file has already been validated?
[00:42] <cjwatson> Yes
[00:43] <cjwatson> Put the uploaded source somewhere and perhaps we can look at it
[00:43] <pkgman> Can you access a rejected dput upload from today?
[00:44] <wgrant> No, they're deleted.
[00:44] <pkgman> Okay. I'll put the stuff on 4shared right now.
[00:44] <cjwatson> We can see the logs, but they're (curiously) unhelpful.
[00:48] <cjwatson> (FWIW, I would have answered you earlier if you'd stuck around; I was taking the kids to the park when you first asked.)
[00:59] <pkgman> cjwatson: No worries. I work odd hours anyway.
[01:34] <pkgman> I'm back.
[01:41] <pkgman> wgrant: Do you have time to look at my source bundle, or should I wait for cjwatson?
[01:56] <_bjf> StevenK, about? if i wanted to create and run my own version of qastaging is it possible? are the instructions at https://dev.launchpad.net/Running enough or is there more to it?
[02:07] <StevenK> bjf: Why do you want to do that?
[02:07] <bjf> StevenK, i hate life and want to abuse myself
[02:07] <StevenK> Haha
[02:08] <bjf> well, i have a love/hate relationship with qastaging
[02:08] <bjf> i love it when it's there and bitch when it goes down
[02:09] <StevenK> bjf: I would suggest you use lpsetup instead -- that means you can confine LP to its own LXC container
[02:10] <bjf> StevenK, interesting ... will look at that. can i populate it with a reasonable amount of the data (teams/projects/etc.)?
[02:10] <bjf> StevenK, meaining, real teams/projects/etc. from LP data
[02:11] <StevenK> bjf: That's a much harder question.
[02:13] <StevenK> bjf: qastaging tends to mostly hang around, staging will disappear over the weekend as it restores its database
[02:13] <bjf> StevenK, ack, i use it regularly. however, there have been a time or 3 that it's been borked for a week or more
[02:14] <bjf> StevenK, it's also slooooww
[02:14] <bjf> (or seems that way to me)
[02:15] <StevenK> bjf: Yeah, it will be slow :-)
[02:16] <StevenK> bjf: However, it shouldn't be dead for a week or more, we tend to use it for QA and notice when it's dead/misbehaving
[02:18] <bjf> StevenK, yeah, i know, but there really were a time or two ... anyway i had to ask. sounds like it's a pita to populate my own
[02:18] <bjf> StevenK, i have a  good sized system in the Boston DC that i was thinking of using for this
[02:23] <StevenK> bjf: LP is fairly heavyweight -- our prod DB servers have 128GiB of RAM
[02:24] <bjf> StevenK, http://kernel.ubuntu.com/testing/test-results/statler.html
[02:25] <bjf> StevenK, i'm assuming qastaging is a lesser system
[02:26] <StevenK> bjf: qas is spread amogst four machines
[02:26] <bjf> StevenK, ah, thought that might be the case
[02:27] <bjf> StevenK, somewhat related question, has anyone run qas or something similar on an openstack cluster ?
[02:33] <wgrant> bjf: qastaging and staging should rarely be down for more than 24 hours, and never both for more than an hour. We had some unfortunate incidents last week where staging was down for 3 days, but that's the first time in a long while, and qastaging was fine during that.
[02:33] <wgrant> Neither has been down for more than 3 days in several years.
[02:35] <bjf> wgrant, can you refresh my memory. i forgot all about staging. what's the basic diff. between the two? if you were me doing LP dev (creating/modifying) bugs which would you use?
[02:37] <wgrant> bjf: They're pretty similar from an end-user PoV. staging's DB tends to be reset more frequently (every Saturday, unless something goes wrong), but qastaging is moving to a similar schedule.
[09:30] <hlamer> Hi. Maybe somebody is able to explain, what is the problem with this build: https://launchpadlibrarian.net/152013500/buildlog_ubuntu-raring-i386.python-qutepart_1.1.0-1~raring1_FAILEDTOBUILD.txt.gz ?
[09:31] <cjwatson> hlamer: The builder is broken.  Could you provide the https://launchpad.net/.../+build/... link rather than the buildlog?
[09:32] <cjwatson> Actually maybe I can find it ...
[09:32] <cjwatson> Yeah, chindi04
[09:32] <cjwatson> hlamer: I'll deal with it, thanks
[09:33] <hlamer> cjwatson: https://launchpad.net/~hlamer/+archive/enki/+build/5064886
[09:34] <cjwatson> Retried, should be happier on the next builder.  chindi04 is disabled and will be rebuilt
[09:34] <cjwatson> I'll retry the other failures too
[09:34] <hlamer> Ok, thanks!
[09:38] <cjwatson> (done)
[09:47] <czajkowski> cjwatson: we'd be lost without you
[15:21] <scranen> Hi, I got a bit stuck trying to upload stuff to a ppa. We uploaded a new version (let's say from v1 to v2) some time ago, found out there were some horrible mistakes in the packaging procedure and deleted the packages. In the meantime the packaging has been fixed, and we'd like to again submit a new version, going from v1 to v2. Now I'm getting upload errors because product_v2.orig.tar.gz already exists. This is not a file I had
[15:21] <scranen> Advice?
[21:06] <Waka_Flocka> why is my branch empty? lp:~wakaflocka/midori/enhancements
[21:09] <dobey> Waka_Flocka: you haven't pushed anything to it?
[21:10] <Waka_Flocka> how do i push?
[21:10] <dobey> and it's not empty
[21:10] <Waka_Flocka> ah never mind
[21:11] <Waka_Flocka> it says "Working tree "/home/jacolby/midori/" has uncommitted changes (See bzr status). Uncommitted changes will not be pushed.
[21:11] <Waka_Flocka> "
[21:11] <dobey> well yes, you can't push changes that haven't been committed
[21:11] <Waka_Flocka> oh how can i commit, i am a complete starter at this
[21:12] <dobey> you should probably read the bzr tutorials/documentation then
[21:13] <dobey> it doesn't really have anything to do with launchpad directly, aside from the fact that you're hosting code on it