[00:03] <shakaran> nice: "Now on revison 436"
[00:17] <maxb> james_w: (if you're around) do you think you might be able to process the debian subversion replacement branches I pushed soon, such that its udd import (hopefully) works again?
[00:22] <shakaran> another question, how I set the locale for translation to Spanish (Argetina), for spanish is es.po, but Argentina uses es_AR.po and my translator user says that he dont see the option for translate his locale
[00:23] <GaryvdM> Hi. https://launchpad.net/qbzr say our latest download is 0.19b1. Is there a way to tell it to rather show a older stable release (0.18.4)?
[00:23] <GaryvdM> *says
[00:24] <wgrant> GaryvdM: No. Yes, this is stupid.
[00:29] <mwhudson> well, you can rename your milestones, maybe...
[00:30] <wgrant> I don't think that will help.
[00:30] <wgrant> It probably works off dates.
[00:31] <mwhudson> i looked at this recently
[00:31] <mwhudson> (well, a month or so ago)
[00:31] <mwhudson> i think it debian-version sorts the milestone names, then puts trunk first
[00:31] <mwhudson> but i forget
[00:32] <mwhudson> it's certainly a bit arbitrary and odd
[00:32]  * mwhudson lunches
[00:32] <wgrant> It sorts series as you say.
[00:32] <wgrant> I'm not sure about milestones.
[00:34] <mwhudson> oh right
[00:34] <mwhudson> series, yes
[00:34] <mwhudson> no possible confusion here
[01:24] <james_w> maxb: yup
[01:38] <maxb> thanks
[02:59] <greg-g> Apport is giving me 500 errors when it tries to upload a crash report, anyone else seeing that?
[03:45] <thumper> greg-g: I've not had any crashes recently, so not seen it sorry
[03:46] <mwhudson> greg-g: it's worked for me a couple of times recently
[07:40] <dickelbeck> losing hope now, and wondering if this is really the right place for my project:  https://answers.launchpad.net/launchpad-registry/+question/105477
[07:40] <dickelbeck> why is this question not showing up as open?
[07:42] <mwhudson> spm: ^^
[07:43] <spm> dickelbeck: oh awesome. that sucks badly for you. :-( gimme 5 mins to finish something, and I'll set that up pronto.
[07:45] <dickelbeck> spm: thank you.  I'm going to bed now, its 1:45 am.
[07:45] <spm> dickelbeck: :-) 6pm here. g'night!
[08:54] <maxb> james_w: Thanks. Could you queue a package-import retry of 'subversion'? I have high hopes it might work this time :-)
[09:36] <shakaran> hi, why does not work launchpad with debhelper 6 for builds with hardy? http://launchpadlibrarian.net/42466760/buildlog_ubuntu-hardy-amd64.tivion_0.0.4-0ubuntu6~hardy_FAILEDTOBUILD.txt.gz
[09:37] <shakaran> he says: dh_clean: Sorry, but 6 is the highest compatibility level supported by this debhelper.
[09:37] <wgrant> shakaran: It looks to me like you in fact require debhelper 7 without depending on it.
[09:38] <wgrant> shakaran: Hardy does not have debhelper 7, but if you adjust your PPA dependencies to 'Backports', you'll get debhelper 7 support.
[09:38] <shakaran> I put debhelper 7 for intrepid, jaunty, karmic and lucid, but the build fails with debhelper 7, then I put debhelper 6 and also it fails, then?
[09:39] <shakaran> how to set backports for control file?
[09:39] <wgrant> shakaran: It's not in the control file. Click 'Edit PPA dependencies' on your PPA page.
[09:41] <shakaran> oh, I see, then, Should I retry the build?
[09:41] <shakaran> pressing https://launchpad.net/~shakaran/+archive/ppa/+build/1590563/+retry ?
[09:42] <wgrant> shakaran: Yes.
[09:44] <shakaran> thanks, now I only wait for new builds (40 min estimated)
[10:15] <shakaran> wgrant: the build works! thanks
[10:18] <wgrant> shakaran: Excellent.
[10:32] <ees1bk> hey tumbleweed are you out there?
[10:36] <tumbleweed> ees1bk: sorry I don't know why you were getting those issues, and I'm tied up right now, try #ubuntu-motu
[11:07] <ees1bk> tumbleweed: after thinking about it, I've decided to make the file modes a definition at the top of the file - that way I can build an insecure variant as a PPA and still have the permissions locked down on the production version.
[11:10] <alopenerp> is there a launchpad administrator here ?
[11:45] <alopenerp> is there any launchpad administrator here ?
[11:48] <maxb> alopenerp: You're usually better off asking a question in LP - or at least mentioning what sort of thing you need such that any admin who may glance at the channel has a better idea of what you might want.
[11:51] <alopenerp> maxb: yes but it's for a private branch (paid subscriptions)
[11:51] <alopenerp> maxb: i'm not sure i want my question to be public
[11:55] <maxb> LOSAs: Is there one of you around to help alopenerp ?
[11:56] <mthaddon> alopenerp: hi
[12:24] <ees1bk> OK.... general question here.
[12:24] <ees1bk> Is every one of the dh_ debian helper scripts incompatible with pbuilder and there (I assume) PPAs?
[12:25] <ees1bk> I'm going through my rules files commenting them out and then retrying a build.
[12:26] <ees1bk> so far I've got rid of calls to dh_testroot, dh_installdeb, dh_installchangelog, dh_gencontrol and dh_md5sums
[12:29] <maxb> You're totally doing it wrong :-(
[12:30] <mgedmin> so, I'm looking at a bug, and I'd like to assign it to a milestone that doesn't exist yet
[12:30] <maxb> Almost every package uses debhelper. In pbuilder, in PPAs, in the distro archives. It's fine.
[12:31] <mgedmin> the milestones ajaxy popup gives me an option to remove a milestone (from this bug, presumably?), but there's nothing about creating new milestones
[12:31] <mgedmin> fun bug, though: every time I click there I get a new (-) icon
[12:31] <mgedmin> seeing four now
[12:35] <wgrant> ees1bk: Why are you removing them?
[12:39] <ees1bk> because each and every one of them is causing the build to bomb out with a permissions issue.
[12:39] <wgrant> You have a problem elsewhere in your package.
[12:40] <ees1bk> the package builds perfectly as either myself or root using debuild.
[12:41] <ees1bk> it's only pbuilder that chokes on it.
[12:41] <wgrant> Have you tried pbuilder or sbuild locally?
[12:42] <wgrant> Right, then it is probably not a problem with Launchpad or pbuilder, since Launchpad does not use pbuilder, and successfully builds 20000 other packages fine.
[12:42] <wgrant> So I would be looking for something strange that your package does.
[12:42] <ees1bk> Yes.... I'm assuming that pbuilder is the prototype for the PPA system and if I could get that to build I'd have found the problem.
[12:42] <ees1bk> Oh.  OK.
[12:43] <wgrant> Launchpad uses a variant of a very old version of sbuild.
[12:43] <ees1bk> ok... the crux of the issue I suspect is that I protect every file with a mode 0660 or mode 0770 file permission.
[12:44] <wgrant> What is the error?
[12:46] <ees1bk> dh_md5sums -i
[12:46] <ees1bk> chown: changing ownership of `debian/wacs/DEBIAN/md5sums': Operation not permitted
[12:46] <ees1bk> dh_md5sums: command returned error code 256
[12:46] <ees1bk> make: *** [binary-indep] Error 1
[12:46] <ees1bk> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[12:46] <ees1bk> pbuilder: Failed autobuilding of package
[12:46] <ees1bk> these occur for almost all the dh_ commands.
[12:49] <ees1bk> OK... so basic principles here.
[12:49] <ees1bk> Do the postinst scripts get run at all during the PPA build process?
[12:51] <ees1bk> I'm currently setting the permissions using the -m option to install in the rules file and then doing the ownership changes in the postinst file.  Do I need to move the permissions stuff to the postinst file too?  Will that help?
[12:56] <alopenerp> LOSAs: anyone here ?
[13:01] <ees1bk> anyone: any thoughts on what I can do to stop these dh_ apps from doing a chown or finding out what they're actually trying for?
[13:10] <Hobbsee> ees1bk: to find out what they're actually before, use 'man dh_whatever'
[13:10] <Hobbsee> s/before/for/
[13:14] <ees1bk> hobbsee:  thanks but that really doesn't help.  It explains what they're supposed to do and makes no mention of why they should be invoking chown, how to stop them doing it, or what they expect to achieve by doing so.  Based on what the manpage says, they should simply be working on files, not playing with permissions and then aborting because they fail.
[13:20] <StevenK> Actually, Debian policy states which permissions and ownership files need to be, so yes, they should play with permissions
[13:22] <ees1bk> And if I have good reasons for disagreeing with that policy, I can't actually build my software?
[13:23] <ees1bk> OK, so here's a dry run on dh_changelog:
[13:23] <ees1bk> dh_installchangelogs -i -k -v Changelog
[13:23] <ees1bk> 	install -o 0 -g 0 -p -m644 debian/changelog debian/wacs/usr/share/doc/wacs/changelog.Debian
[13:23] <ees1bk> install: cannot change ownership of `debian/wacs/usr/share/doc/wacs/changelog.Debian': Operation not permitted
[13:23] <ees1bk> dh_installchangelogs: command returned error code 256
[13:23] <Daviey> Hey, is there an issue publishing on the ppa's atm.  Some of our users are reporting "/Packages.bz2  Hash Sum Mismatch"
[13:24] <StevenK> ees1bk: Are you building on a filesystem that has no concept of permissions, such as vfat?
[13:24] <wgrant> Even so, that should be running in fakeroot, so it shouldn't matter.
[13:24] <wgrant> Are you somehow breaking fakeroot?
[13:24] <ees1bk> the interesting bit here is that it's the chown (which I don't care about since I fix it up in the postinst) that is choaking.
[13:25] <StevenK> You shouldn't be fiddling with permissions in the postinst
[13:25] <ees1bk> wgrant:  it would seem so if an install -o 0 -g 0 is the bit that is breaking.
[13:26] <ees1bk> StevenK: Why not?
[13:26] <StevenK> ees1bk: Because that's bad and completly the wrong way to do it
[13:26] <ees1bk> I can't set them earlier as far as I can see.
[13:26] <StevenK> ees1bk: Sure you can, build under fakeroot
[13:26] <bigjools> Daviey: I've only seen that for people behind proxies
[13:26] <StevenK> dpkg-buildpackage -rfakeroot
[13:27] <wgrant> -rfakeroot is the default now, and LP and pbuilder use it.
[13:27] <ees1bk> running that now....
[13:27] <StevenK> I've not called dpkg-buildpackage directly in ... well, years.
[13:28] <ees1bk> dh_installchangelogs -i -k ChangeLog
[13:28] <ees1bk> install: cannot change ownership of `debian/wacs/usr/share/doc/wacs/changelog.Debian': Operation not permitted
[13:28] <ees1bk> dh_installchangelogs: command returned error code 256
[13:28] <ees1bk> make: *** [wacs] Error 1
[13:28] <ees1bk> Yep, fails in exactly the same way as all the others.
[13:28] <mgedmin> dpkg-buildpackage fails? weeeeird
[13:28] <wgrant> Remove most of the package-specific calls and see what happens. Something in your build is probably breaking fakeroot.
[13:29] <ees1bk> wgrant: What do you mean by that?
[13:29] <wgrant> ees1bk: fakeroot depends at least on values in the FAKEROOTKEY, LD_LIBRARY_PATH and LD_PRELOAD environment variables.
[13:29] <wgrant> possibly others.
[13:29] <Daviey> bigjools: thanks
[13:30] <bigjools> Daviey: let me know if it gets better and if you know which proxy is being annoying
[13:31] <Daviey> bigjools: asking a user now.
[13:31] <bigjools> Daviey: transparent proxies are the worst :/
[13:32] <Daviey> bigjools: I implemented a transparent proxy here :)
[13:32] <ees1bk> LD_LIBRARY_PATH would be the only one I might I have changed.  I'll check when the current dput completes.
[13:33] <bigjools> Daviey: I have no words :
[13:33] <bigjools> :)
[13:34] <Daviey> :P
[13:34] <mgedmin> oh, launchpad... I create a release, it tells me (immediately) that it was "released 15 hours ago"
[13:35] <jml> mgedmin, :(
[13:38]  * mgedmin files a bug, since somebody cares ;)
[13:42] <Daviey> bigjools: he's behind the great proxy wall of china. :/
[13:42] <bigjools> Daviey: *run away* !
[13:43] <Daviey> :(
[13:47] <ees1bk> wgrant: just checked - no not setting LD_LIBRARY_PATH or any of the other similar variables
[13:47] <ees1bk> wgrant: install is /usr/bin/install, chown is /bin/chowm
[13:47] <ees1bk> ^m^n
[13:52] <ees1bk> wgrant: the error is exactly the same whether I call dpkg-buildpackage with -rfakeroot or without - fakeroot appears to be a no-op.
[13:53] <wgrant> ees1bk: As I said earlier, -rfakeroot has been the default for a couple of releases now.
[13:54] <ees1bk> sorry - didn't spot that.
[13:57] <maxb> ees1bk: Fundamentally, the dh_* stuff runs chown because part of its job is to set permissions in the created package. The question you need to answer is "Why does chown fail?"
[13:57] <maxb> Also, you should never ever be building packages as root.
[13:58] <maxb> I do wonder if your problems are in fact because you did, and now have root-owned temporary files in your package build directory
[13:59] <wgrant> That wouldn't explain the same failure occuring on Launchpad.
[13:59] <maxb> ah, true
[14:00] <maxb> ees1bk: So, where's your PPA with the failiures on launchpad?
[14:00] <ees1bk> no, checked that the build dir isn't there.
[14:02] <ees1bk> ppa:beaky/wacs-stable
[14:03] <ees1bk> I'm just exploring one possibility here.  I tidy up all my install related files into a directory called "install".
[14:03] <ees1bk> Thus debian/ is actually a symlink to install/debian.
[14:10] <ees1bk> nope, changed that - rebuild attempted - exactly the same failure as before.
[14:11] <maxb> kfogel: I reckon "Recent problems browsing branches should be fixed." is old news at this point? Shall we drop it?
[14:11] <wgrant> It's been around for more than a month, yeah.
[14:11] <kfogel> maxb: is that in Launchpad Questions or Bugs?
[14:11] <wgrant> The topic.
[14:11] <kfogel> maxb: oh
[14:11] <maxb> kfogel: in the topic
[14:11] <kfogel> the topic
[14:12] <kfogel> sheesh, yeah
[14:12] <kfogel> max, wgrant: thanks
[14:23] <ees1bk> removing the symlinks didn't help.
[14:23] <M7S> Hi. I can't do anything at all on launchpad for the moment, except reading. Everything I do, even trying to log out, results in "Unexpected form data" error.
[14:24] <ees1bk> now removing all the -m arguments to install.
[14:24] <wgrant> M7S: Your browser is blocking the Referer header.
[14:24] <wgrant> Can you whitelist Launchpad, perhaps?
[14:25] <M7S> In adblock?
[14:26] <wgrant> M7S: Probably not. You don't have another extension or setting that prevents your browser from sending a Referer header?
[14:27] <M7S> Don't think so. I'll check what happens if I change browser.
[14:31] <M7S> Right, chromium works as it should.
[14:32] <M7S> Wierd because I started having this problem both from my desktop and my laptop at the same time.
[14:34] <M7S> I used to have noscript installed but I don't have it anymore, perhaps that changed some settings that were not reverted when I removed the extension.
[14:34] <M7S> ?
[14:35] <james_w> maxb: sorry, forgot that bit, requeued
[14:35] <maxb> heh, np
[14:35] <maxb> thanks
[14:38] <ees1bk> d*mn - this is so frustrating.  I've removed ALL the file mode setting from the rules file and STILL I get:
[14:38] <ees1bk> dh_installchangelogs -i -k ChangeLog
[14:38] <ees1bk> install: cannot change ownership of `debian/wacs/usr/share/doc/wacs/changelog.Debian': Operation not permitted
[14:38] <ees1bk> dh_installchangelogs: command returned error code 256
[14:38] <ees1bk> make: *** [wacs] Error 1
[14:38] <ees1bk> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[14:38] <ees1bk> debuild: fatal error at line 1329:
[14:38] <ees1bk> dpkg-buildpackage -rfakeroot -D -us -uc failed
[14:44] <M7S> It seems like I found the setting. It works now. Thanks!
[14:48] <ees1bk> any ideas where else I can look to fix this problem?
[14:56] <kfogel> bigjools: I'm looking at https://answers.edge.launchpad.net/launchpad/+question/105961, which is a typical "Please delete my one PPA so I can rename my user account" question.  It looks like bug #392887 has made recent progress that affects this, but I can't tell what the current status is.  Do you know?
[14:56] <kfogel> bigjools: (And should I just assign the question to you?)
[15:04] <ees1bk> kfogel:  just saw your comments on the bug I've filed.
[15:04] <kfogel> ees1bk: which bug?
[15:05] <ees1bk> I'm really not sure I understand how dh_installchangelog etc trying to do an install -o 0 -g 0 is a bug in my code.
[15:05] <ees1bk> Bug 551579
[15:05] <kfogel> ees1bk: I'm not expert enough to say, but wgrant and/or bigjools here are.
[15:06] <ees1bk> I'm really keen to try and get this fixed.  For more on this package see http://sourceforge.net/blog/
[15:06] <kfogel> ees1bk: there might also be a mailing list or forum where packaging questions are usually taken up?  (That is, if you know of such a forum, then you could raise this there.  I'm not a packaging expert, I'm just trying to steer bugs to the right people today.)
[15:07] <ees1bk> right now I'm focused on trying to get a PPA for this pacakge created.
[15:08] <ees1bk> kfogel:  be a mailing list or forum
[15:08] <kfogel> ees1bk: Understood.  You need to discuss this technical issue with someone who knows more about packaging.  I can't guarantee that such a person is available right now, unfortunately, but ask around?  I think maxb might also know quite a bit about it.  All the people quoted in the IRC conversation in the bug would be appropriate to contact.
[15:08] <ees1bk> OK, any idea where that would be.
[15:08] <kfogel> ees1bk: hmm, let me look
[15:09] <maxb> ees1bk: I reproduced your problem in a local pbuilder, and I agree it's most bizarre.
[15:09] <maxb> Unfortunately I couldn't immediately see the cause
[15:09] <maxb> Something pretty insane and bizarre is going on.
[15:09] <ees1bk> maxb: I've been through all the things I can think of.
[15:10] <james_w> maxb: did you see my questions on https://code.launchpad.net/~maxb/ubuntu/lucid/devscripts/445432/+merge/22200 ?
[15:11] <james_w> and subversion imported correctly, thanks
[15:11] <kfogel> ees1bk: I don't see anything obvious on https://lists.ubuntu.com/ or http://ubuntuforums.org/, but I haven't dived deeply.  I see you and maxb have found each other; he may know of other resources.
[15:11] <ees1bk> maxb: just checking that URL now....
[15:14] <ees1bk> maxb: OK, this is all about lucid.  My build host is currently running intrepid and I was about to upgrade to jaunty.
[15:14] <geser> ees1bk: where can I have a look at the problematic package?
[15:14] <maxb> james_w: I did see the dch questions - I need to write up my thinking on that. I'll try to do so soon.
[15:14] <james_w> maxb: thanks
[15:15] <ees1bk> the "pure" tarball is at https://launchpad.net/wacs; the ppa I'm trying unsuccessfully to build is at ppa:beaky/wacs-stable
[15:16] <ees1bk> All the previous "production" builds and .deb files I've issued have been built with "debuild -us -uc" running as root on my intrepid based Ubuntu server.
[15:17] <maxb> Why as root?
[15:17] <ees1bk> given that launchpad ain't great at handling a package like this that usually ships as about ten .deb files, I was looking to use a PPA instead as a method of distribution.
[15:19] <geser> ees1bk: your debian/rules is wrong
[15:20] <geser> ees1bk: is http://bazaar.launchpad.net/~vcs-imports/wacs/trunk/annotate/head%3A/install/debian/rules the one you used?
[15:21] <ees1bk> maxb: 'cos it worked and made a package that installed.  It took me a long time to get a rules file that built all the various packages and replicated what the RPM .spec file did.
[15:22] <maxb> There's no reason to build packages as root. If you need to, you've written the packaging wrong.
[15:22] <ees1bk> geser:  that is one I created today as an effort to debug things.  It exhibits the fault.
[15:22] <geser> ees1bk: only some targets are guaranteed to be run as root/fakeroot (e.g. install and binary) while others (e.g. build) is only run as a user
[15:23] <ees1bk> maxb: There's no reason to build packages as root. If you need to, you've written the packaging wrong.
[15:24] <ees1bk> maxb:  Errrr... OK, I guess.  During the process of writing the rules file, I basically did what it seemed was needed to get it to work.  root or not wasn't really a concern.  I
[15:24] <maxb> gaaah
[15:24] <ees1bk> I'm now trying to get it "right" because the PPA system seems to demand that and I have very little idea why I'm seeing the failures I am.
[15:25] <maxb> It's all caused by the symlink
[15:25] <geser> ees1bk: does the package need compilatio or calling make (for the upstream Makefile)?
[15:25] <ees1bk> maxb: what, the fact that I've tied up the source tree into an install directory breaks the build system?
[15:26] <maxb> So all of this is a very non-obvious failure mode caused by debian/ being a symlink, and the /usr/bin/install command calling lchown, not chown
[15:26] <maxb> afaise
[15:26] <maxb> * afaics
[15:26] <ees1bk> geser:  it compiles a plug-in module taken from the squid project for authenticating a user
[15:27] <ees1bk> 's password without becoming them.
[15:28] <geser> ees1bk: see http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules for the description of the different targets
[15:28] <ees1bk> maxb: I'
[15:29] <geser> the problem is that your "build" target depends on "binary" which in end wants to change permissions
[15:29] <geser> "The build target must not do anything that might require root privilege."
[15:30] <geser> "The binary targets must be invoked as root" (but fakeroot works too)
[15:30] <ees1bk> geser: but you can't use PAM to authenticate an arbitary user without being root - that's impossible - it just doesn't work.
[15:32] <geser> I seem to got lost. From where does PAM into the play?
[15:34] <ees1bk> geser: the package includes one binary package - wacs-hostauth - the purpose of which is to confirm that a user logging in through the web interface is who they say they are.  This package uses a small setuid root program called pam_auth that uses the PAM library to authenticate as that user and thus verify their credentials.
[15:36] <geser> ees1bk: this has nothing to do with building. The files inside the build debs are usually owned by root and setuid works too, but the whole build runs without root.
[15:38] <ees1bk> maxb: as far as I can see the symlink isn't the whole story - I moved install/debian to debian and edited the rules file to set DEBDIR=`pwd`/debian and attempted a rebuild with debuild -uc -us and I still get:
[15:38] <ees1bk> dh_installchangelogs -i -k ChangeLog
[15:38] <ees1bk> install: cannot change ownership of `debian/wacs/usr/share/doc/wacs/changelog.Debian': Operation not permitted
[15:38] <ees1bk> dh_installchangelogs: command returned error code 256
[15:38] <ees1bk> make: *** [wacs] Error 1
[15:38] <ees1bk> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[15:38] <ees1bk> debuild: fatal error at line 1329:
[15:38] <ees1bk> dpkg-buildpackage -rfakeroot -D -us -uc failed
[15:39] <maxb> hmm
[15:39] <mdz> to whomever implemented this feature, thank you: Bug #549311 also links to the added bug watch (chromium #37722)
[15:40] <geser> ees1bk: as I told you, your targets inside debian/rules are wrong (or try to the things in the wrong order)
[15:40] <ees1bk> geser: ok, I can believe that.  What do you suggest to fix it?
[15:41] <maxb> geser: I'm not convinced that's the immediate problem
[15:41] <maxb> ees1bk: Hmm. perhaps I have completely misinterpreted
[15:41] <ees1bk> the rules file came about mostly from translating what I did in the RPM .spec file.
[15:42] <geser> the "build" targets is only for the "compilation", if you don't have nothing to compile (or don't need to call "make"), you can leave it empty
[15:42] <AndrewGee> Hi. I'm having problems submitting forms on launchpad. Every one says "Unexpected form data". Any ideas?
[15:43] <salgado> AndrewGee, your browser is probably configured to not send referrer information
[15:43] <maxb> Oh I am an idiot
[15:44] <geser> ees1bk: that you get you a step nearer to a build deb (don't know yet if anything else needs fixing)
[15:44] <ees1bk> geser:  I've taken out the build: binary and the build dep from install.
[15:44] <maxb> geser is completely right. The problem is nothing to do with the symlink and everything to do with you running 'installation' phase commands from the build target
[15:44] <AndrewGee> salgado: Do you happen to know how I'd fix that in Firefox?
[15:45] <salgado> AndrewGee, http://www.technipages.com/firefox-enable-disable-referrer.html
[15:45] <AndrewGee> salgado: Thanks :)
[15:48] <ees1bk> OK, commented that bit out..... trying again...
[15:49] <ees1bk> dpkg-source: unrepresentable changes to source
[15:51] <ees1bk> ok, the files I'm playing with are in such a mess now I'm going back to the SVN version.  I've removed the binary: build
[15:51] <ees1bk> dependency and I've removed the install: binary dependency so that should clean that bit up.
[15:52] <ees1bk> checking out, tarring up and having another go.
[16:02] <ees1bk> ok.... this is looking good.
[16:42] <ees1bk> just trying to upload the new package to the PPA now.
[16:49] <ees1bk> ok - for some reason dput has decided not to send the source code tarball.  Any ideas?
[16:51] <ees1bk> Good signature on /vol/www/main/software/wacs-0.8.5/build/wacs/wacs_0.8.5-2.dsc.
[16:51] <ees1bk> Uploading to wacs-stable (via ftp to ppa.launchpad.net):
[16:51] <ees1bk>   wacs_0.8.5-2.dsc: done.
[16:51] <ees1bk>   wacs_0.8.5-2.diff.gz: done.
[16:51] <ees1bk>   wacs_0.8.5-2_source.changes: done.
[16:51] <ees1bk> Successfully uploaded packages.
[16:51] <ees1bk> Not running dinstall.
[16:51] <ees1bk> why no tarball?
[16:56] <geser> debuild tries to guess on the version number if the .orig.tar.gz needs uploading or not
[16:56] <idnar> ees1bk: you're building a -2 version, so it figures the tarball was already uploaded with -1
[16:56] <geser> you can overwrite this with "debuild -S -sa"
[16:59] <ees1bk> ah, ok, it wasn't.  trying again.
[17:00] <ees1bk> tarball now going up - called wacs-0.8.5-2.tar.gz though which will probably decide to cause me grief... :-(
[17:03] <pmatulis> have we gone back to forcing people to use ubuntu-bug again?  i really hate this.  what if i need to report a bug that has nothing to do with a machine i administer?
[17:07] <ees1bk> OK, now waiting for the PPA to have a go at building it.  At which point I'm going to go home; I want to thank all you folks here for the help, advice and suggestions you've given me today.  Hopefully it'll have a positive outcome over the next hour or so!  THANK YOU!
[17:36] <kfogel> james_w: saw your question 106006, handling now
[17:44] <kfogel> james_w: what do you mean by "trace in the DB"?
[17:58] <mtaylor> is there  a way to remove a series target from a bug?
[17:58] <beuno> mtaylor, there is not. You can decline it
[17:59] <mtaylor> beuno: suck
[17:59] <mtaylor> beuno: so there's no way to re-target something
[17:59] <mtaylor> beuno: ah. ok... I think I grok
[18:00] <beuno> mtaylor, yeah, it sucks, I agree  :)
[18:33] <cnd> I'm trying to propose a merge of one of my branches at lp:~chasedouglas/lucid/linux-firmware-nonfree to lp:ubuntu/linux-firmware-nonfree, but I just get an error back about how they aren't mergeable
[18:33] <cnd> I found bug 446716, but I don't understand what's going on or how to resolve this issue
[18:41] <james_w> kfogel: don't know, but LP apparently does.
[18:44] <kfogel> james_w: can you paste the exact error you saw into the question, then?
[18:44] <james_w> I didn't see it, cjwatson did, as I don't have the priveledges to actually make the change
[18:44] <james_w> but it was something like "ubuntu-reviews@ is already registered and associated with ~ubuntu-core-dev"
[18:45] <james_w> I was told this isn't the first time we have needed DB surgery for something like this
[18:47] <cjwatson> "ubuntu-reviews@lists.ubuntu.com is already registered in Launchpad and is associated with Ubuntu Core Development Team."
[18:50] <cjwatson> kfogel: I've added comments to the question with the exact error, and a reference
[18:50] <kfogel> cjwatson: thank you
[20:05] <dickelbeck> Last night Steve finally did https://answers.edge.launchpad.net/launchpad-registry/+question/105477
[20:06] <dickelbeck> what time does he come on duty GMT?
[20:07] <dickelbeck> I need for it to be indexed one final time.
[20:08] <sumanah> doctormo: ping re Ground Control
[20:14] <dickelbeck> spm, you there yet?
[20:15] <doctormo> sumanah: pong re Ground Control
[20:16] <sumanah> doctormo: I have a question about launchpad login in GC.  ok to discuss here?
[20:17] <doctormo> sumanah: It is, I'm fixing it now, so we can talk about it if you like...
[20:17] <sumanah> I'm editing a piece for GNOME Journal that includes a short GC HOWTO, and it says that once you create a new Projects folder, "you can see a button to login to Launchpad. Click the button and enter your Launchpad username and password."  IIUC that's out of date?
[20:19] <sumanah> doctormo: if you have an updated "also login to launchpad in another window" workaround, or if I should just say "once it works again it'll work like this..." then I'd appreciate it
[20:20] <sumanah> doctormo: also, your launchpad profile page points to your old blog
[20:20] <doctormo> Thanks for the update
[20:21] <doctormo> Yes so what it'll do is load up a login window with a webkit frame, you'll login and it'll continue on from there.
[20:21] <sumanah> aha!  ok, if that works, we're golden
[20:21] <doctormo> That's really the best outcome of the very long discussion we've been having with the folks here.
[20:22] <zyga> kiko: hi
[20:23] <sumanah> so once I create a new Projects folder, I see a button to log in to launchpad, I click it, a form appears (in the webkit frame), I enter my user/pass, hit Enter, it logs me in, and I can then see the button to select a project to work on?
[20:24] <sumanah> doctormo: two more questions. 1) is it an https login, and can the user see some indication of that?
[20:24] <doctormo> sumanah: There is a login button on the configuration that appears, because you have to offer register too.
[20:24] <doctormo> sumanah: It is https and no they can't because it's not a web browser and should never have been a web browser.
[20:24] <doctormo> It won't become one either.
[20:24] <sumanah> ok
[20:25] <sumanah> doctormo: and 2) is https://launchpad.net/groundcontrol the best link for people to get more info?
[20:25] <doctormo> Yes
[20:25] <sumanah> "you have to offer register too" - sorry, I don't understand
[20:25] <doctormo> sumanah: My original video of v1.0, with the login and register buttons.
[20:26] <doctormo> That should still appear.
[20:26]  * sumanah looks for video
[20:28]  * sumanah watches http://www.mefeedia.com/watch/28261680
[20:32] <sumanah> doctormo: oh I see, I mean that you can either login to an existing Launchpad account, or register a new one?
[20:32] <sumanah> s/I mean/you mean/
[20:33] <doctormo> sumanah: Right, so there is an "Identify yourself" -> Register of Login button -> webkit window -> (runs through a process with changing icons) -> done
[20:35] <sumanah> doctormo: because I need to be achingly clear in the article: what is the text on the button? is it "Identify Yourself"?
[20:36] <doctormo> sumanah: it is now
[20:37] <sumanah> doctormo: great, thanks!
[20:38] <sumanah> happy hacking & thanks for your help
[20:44] <Penguin> Just made my first debian source package, but how do I update it?
[20:45] <An_Ony_Moose> what's "launchpad karma"?
[20:45] <Penguin> https://help.launchpad.net/YourAccount/Karma
[20:46] <ripps> Hmm... light-themes was updated today, but the bzr repo on launchpad hasn't. Why?
[20:47] <An_Ony_Moose> thanks Penguin :D
[20:48] <Penguin> np
[20:52] <Penguin> I am guessing I update my debian source package by making a .diff.gz from the .orig.tar.gz then applying it to the .tar.gz - is this right?
[20:53] <Penguin> I can't find any info' on the net about how to work with these files on the packaging side.
[21:07] <Aim> screen
[21:08] <Aim> eek
[22:04] <cody-somerville> Ugh!
[22:05] <cody-somerville> Doing on-the-fly conversion from RepositoryFormatKnitPack6RichRoot() to RemoteRepositoryFormat(_network_name='Bazaar repository format 2a (needs bzr 1.16 or later)\n').
[22:05] <cody-somerville> I don't want that!
[22:05] <cody-somerville> Can a losa please help me?
[22:08] <mwhudson> cody-somerville: why do you need a losa to help?
[22:08] <cody-somerville> Because I assume I need someone to delete the repository?
[22:09] <cody-somerville> I want all my branches to be 1.9-rich-root support.
[22:09] <james_w> you can delete the branch in the web UI
[22:09] <mwhudson> there are no shared repositories on launchpad
[22:09] <cody-somerville> Okay, I'll try that.
[22:13] <cody-somerville> kk, ty
[22:14] <lifeless> cody-somerville: why do you want 1.9-rich-root ?
[22:14] <lifeless> cody-somerville: do you like slow performance and pain ?
[22:15] <cody-somerville> I work with ARM systems for a living, so I must.
[22:15] <cody-somerville> The real reason though is need to work with bzr 1.13.1.
[22:18]  * cody-somerville wishes you could still set titles for branches.
[22:18] <cody-somerville> la sigh
[22:35] <beuno> cody-somerville, I removed that, 2 people in the whole wide world used it
[22:36] <cody-somerville> beuno, I'd use it right now for 64 different branches.
[22:37] <beuno> cody-somerville, still 2 uers *wink*
[22:37] <beuno> *users
[22:37] <cody-somerville> These branches would be used by the entire OEM Services business unit at Canonical.
[22:37] <cody-somerville> or sorry, will be
[22:38] <beuno> cody-somerville, and they won't if you can't change the full title?
[22:38] <beuno> you can change it's names
[22:38] <cody-somerville> No, they will regardless. But its going to be harder for them to find what they're looking for.
[22:39] <beuno> cody-somerville, why?  you can give branches names
[22:41] <cody-somerville> a slug, yes.
[22:41] <cody-somerville> However, the name might not be descriptive of what the branch is.
[22:41] <cody-somerville> (nor practical for the name to be more verbose)
[22:42] <cody-somerville> Plus you have lp:~<owner>/<project>/ before the branch name
[22:42] <cody-somerville> (which is useful for copying and pasting and should be kept regardless)
[22:43] <beuno> cody-somerville, and the branch description is is not enough?
[22:43] <cody-somerville> You can't see the branch description from the overview page.
[22:43] <beuno> edit the branch
[22:44] <beuno> I think it's not very well exposed :)
[22:45] <cody-somerville> overview page of all the branches for a project
[22:45] <beuno> right, it is not exposed there
[22:46] <cody-somerville> What really makes this feature useful is when your branches are named using secret codenames ;)
[22:46] <beuno> heh, right
[22:46] <beuno> I still feel that may be solving the problem on the wrong level
[22:46] <beuno> but, OTOH, I'm not Launchpaddy anymore, so, meh
[22:47] <cody-somerville> How else would you solve it?
[22:48] <beuno> I don't know, I'd have to understand the use case
[22:48] <beuno> I suspect it would be exposing the descriptions in the listings, if the branch has one
[22:49] <cody-somerville> I suspect that might work just as well.
[22:52] <lifeless> cody-somerville: why do you need bzr 1.13.1 ?
[22:52] <cody-somerville> Its the version of bzr in jaunty.
[22:53] <lifeless> cody-somerville: we have builds for jaunty of 2.0+
[22:53] <lifeless> cody-somerville: just add the ppa ?
[22:53] <beuno> cody-somerville, file the bug, I'll +1 it  :)
[22:54] <cody-somerville> lifeless, I'll ask IS.
[22:54] <maxb> How would you nicely expose a multiline description in a listing?
[22:54] <lifeless> IS have builds for hardy, so jaunty should be no trouble at all
[22:54] <beuno> maxb, no line breaks, truncating
[22:55] <lifeless> used for launchpad and distro scripting/support
[22:55] <maxb> It feels liable to look ugly where descriptions are not designed for it
[22:56] <beuno> maxb, they could or could not be toggable
[22:57] <beuno> think of what loggerhead does for descriptions
[22:57] <cody-somerville> maxb, http://github.com/ask/
[22:59] <cody-somerville> beuno, lp #552074
[23:08] <wolter> Hi, how do I get my lp:<project name> branch set?
[23:14] <wolter> I have my /main branch, but I cannot manage to create a simple lp:<project> branch..
[23:16] <beuno> wolter, set it as the development focus
[23:26] <cjwatson> mwhudson: any word on that openssh import?  I followed up to the question with a tentative diagnoiss
[23:26] <cjwatson> *diagnosis
[23:27] <mwhudson> cjwatson: oh right no
[23:27] <mwhudson> spm: ping-a-ling
[23:27] <spm> mwhudson: pong-a-long
[23:28] <mwhudson> spm: can you copy the tarball and branch for the openssh import somewhere i can see them?
[23:28] <spm> off crowberry? sure. gimme a bit...
[23:28] <mwhudson> spm: no, escudero
[23:29] <spm> ah yes; that too.
[23:29] <mwhudson> spm: on a slave: bzr branch sftp://hoover@escudero/srv/importd/www/00007270 ~importd/openssh-branch
[23:30] <mwhudson> spm: scp /hoover@escudero:/srv/imports/sources/00007270.tgz ~importd/openssh-tarball.tgz
[23:30] <mwhudson> spm: i think
[23:30] <dickelbeck> spm, any chance I could get you to import our mbox file one last time, if even by begging?  See the question for the reason.
[23:30] <spm> excellent. ta!
[23:30] <spm> dickelbeck: sure.
[23:30] <dickelbeck> you are awesome man.
[23:30] <spm> this is true. alas modesty is not something I've ever become familiar with... ;-)
[23:35] <spm> dickelbeck: ha; just read the request; yeah sure. the file is in the same (remote) place?
[23:36] <spm> mwhudson: so that's ... odd. I've got the bzr branch; but the scp is just staring blankly at me. going nowhere. trying a little debuggery juju
[23:37] <mwhudson> spm: maybe you can use lftp ?
[23:37] <mwhudson> oh probably actually
[23:37] <mwhudson> i think the keys we use only allow sftp
[23:37] <mwhudson> probably not scp or other ssh thingies
[23:37] <spm> doh. yes.
[23:38] <spm> better: Couldn't stat remote file: No such file or directory
[23:39] <mwhudson> maybe it'
[23:39] <mwhudson> s .tar.gz
[23:40] <spm> mwhudson: hrm. nope. I shall stop remotely guessing and go look....
[23:40] <spm> bwhahaah. s/imports/importd/ :-)
[23:40] <mwhudson> spm: which machine are you on?
[23:41] <mwhudson> spm: haha, sorry
[23:41] <spm> copying onto pear
[23:44] <mwhudson> cjwatson: indeed the 'internal' bzr branch is much more up to date
[23:46]  * mwhudson requests a mirror using the api
[23:48] <spm> argh. pear isn't setup for logs syncing. yet. <== yak shaving
[23:49] <mwhudson> cjwatson: the import is up to date now
[23:51] <spm> mwhudson: so the import files are in a 16mb tar.bzr on pear in the ~importd. I'll copy somewhere rsn...
[23:52] <mwhudson> spm: i have (non-sudo) access to pear
[23:52] <mwhudson> spm: so it's ok :)
[23:52] <spm> excellent! even better!
[23:52] <spm> openssh.tar.bz2 is the full set; or openssh-tarball.tar.gz & openssh-branch per reqeust above.
[23:53] <mwhudson> spm: thanks
[23:53] <cjwatson> mwhudson: hooray!  thank you.  I hope it stays that way :-)
[23:53] <cjwatson> mwhudson: could I have done the API mirror update?
[23:53] <mwhudson> cjwatson: yes
[23:53] <cjwatson> how?
[23:54] <mwhudson> cjwatson: for the former point, yeah, i hope so to, do let me know if it doesn't and i'll dig
[23:54] <mwhudson> cjwatson:
[23:54] <mwhudson> >>> l = Launchpad.login_with('mwhudson', 'edge')
[23:54] <mwhudson> >>> b2 = l.branches.getByUniqueName(unique_name='~vcs-imports/openssh/main')
[23:54] <mwhudson> >>> b2.requestMirror()
[23:54] <cjwatson> thanks, noted
[23:55] <dickelbeck> spm: said "just read the request; yeah sure. the file is in the same (remote) place?", I say "yes same name, new contents"
[23:55] <spm> sweet; ta
[23:56] <cjwatson> spm: thanks to you as well; this means I can package openssh 5.4p1 shortly, although it won't be in lucid (not due to this problem, it was too late anyway)
[23:56] <spm> cjwatson: np