[00:13] <persia> Is there something wonky with bazaar.lp.net today?  I'm not getting the expected revision 61 when clicking for details from https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/netbook.lucid .
[00:15] <mwhudson> persia: that does look pretty wonky
[00:16] <spiv> That's reading at least 7.5 wonks on my finely calibrated wonkometer.
[00:16] <mwhudson> persia: there seems to be some disagreement on how many revisions there are in that branch
[00:16] <wgrant> Impressive.
[00:16] <persia> So this is a problem with the branch, or with the hosting service?
[00:16] <spiv> mwhudson: they look like different ancestries, really
[00:16] <mwhudson> persia, spiv: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/netbook.lucid/.bzr/branch/last-revision looks wrong
[00:16] <spiv> mwhudson: oh, hmm.
[00:17] <mwhudson> there is a bzr bug where the last revno goes wrong
[00:17] <mwhudson> persia: branch
[00:17] <persia> Ah, good.  That's easier to fix.
[00:17] <mwhudson> i think reconcile will fix it
[00:17] <persia> So just reconcile and push?
[00:18] <mwhudson> oh hm
[00:18] <mwhudson> spiv: help persia? i'm on a call :)
[00:19] <spiv> ok
[00:20] <spiv> persia: I'm just confirming that mwhudson's hypothesis is correct
[00:22] <persia> spiv: OK.  I'll arrange for a reconcile and push :)
[00:24] <spiv> persia: thanks.  I think that is almost certainly the issue FWIW
[00:26] <persia> Well, with luck it will be worth at least 7.5 wonks.
[00:26] <spiv> persia: I'd love to know how that branch got to that state, but I think I'm out of luck there...
[00:27] <persia> spiv: Does pulling the branch change the state?  Or is there something more complex involved?
[00:27] <spiv> persia: pulling does change the branch being pulled from, no.
[00:27] <spiv> Er,
[00:27] <persia> For instance, would it be useful to try to get the last committer to perform some actions locally to try to identify how it got that way?
[00:27] <spiv> *does not*
[00:27] <spiv> My typing is terrible today.
[00:27] <persia> So, shouldn't it be possible to check the history to determine how the state was reached from a branch?
[00:28] <spiv> persia: yes, possibly
[00:28] <spiv> We don't record the history of branch states; that would be meta-history if you see what I mean.
[00:28] <spiv> We track mundane things like "revision Y follows revision X" ;)
[00:28] <persia> Aha.  Yes, that might make it tricky to get the state.
[00:30] <spiv> There may be some clues in the code hosting log files, but the server-side logging at the moment is largely useless :/
[00:31] <spiv> Ideally we'd discover that someone with an ancient version of bzr did a push/commit that did that, and thus we could just assume that it's a bug we've fixed ;)
[00:31] <spiv> My guess is some sort of transient issue relating to stacking.
[00:32] <spiv> But I really have no idea.
[00:35] <spiv> persia: actually, one thought that does occur...
[00:35] <spiv> persia: there's a good chance that whoever updated that branch on Launchpad with the wrong revno has a similarly afflicted branch or heavyweight checkout locally.
[00:36] <spiv> persia: which would a) maybe give some clues about the environment that caused it, b) be something to find and fix in case they break it again :)
[00:37] <spiv> Although I'm a little surprised bzr let them override the revno like that... in at least some cases it would require a --overwrite flag to do that.
[00:37] <persia> Right.  Shall I ask them to archive it somewhere, and file a bug for investigation?
[00:37] <spiv> (and if it doesn't that's a whole other bug!)
[00:37] <spiv> persia: maybe ask them to capture their ~/.bzr.log and ~/.bzr.log.old
[00:38] <persia> I'll even ask them to stop by here and say something :)
[00:38] <persia> (debugging by proxy is tricky)
[00:38] <spiv> The branch itself... probably not important, although maybe what the branch.conf says about stacking would be interesting.
[00:38] <spiv> Certainly there's no harm except disk space in archiving it ;)
[00:39] <spiv> I fear there's a good chance that the cause won't be evident in what's left on disk, though :/
[00:39] <spiv> Hopefully I'm wrong.
[00:40] <persia> Indeed.  It would be good to be able to make sure this doesn't happen again.
[00:42] <spiv> Yeah.
[00:42] <spiv> I wonder if setting the append_revisions_only flag in the branch on LP would help?
[00:45] <mwhudson> iirc the bzr bug was something to do with merging into an empty tree
[03:10] <StevenK> Hi. I'm noticing some strange behaviour with edge. Browsing to https://code.edge.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/netbook.lucid gives me the right history for the bzr branch, but clicking revision 61 doesn't give the right information
[03:12] <crimsun> welcome to three hours ago
[03:13] <crimsun> (see http://irclogs.ubuntu.com/2009/12/23/%23launchpad.txt)
[03:21] <mwhudson> StevenK: the branch is busticated somehow
[03:22] <mwhudson> StevenK: all the data is there, so if you branch it and then maybe reconcile it, it'll be ok
[03:22] <StevenK> mwhudson: My copy here is a checkout, I can do it on a bound branch?
[03:23] <mwhudson> hm, don't know
[03:23] <mwhudson> i doubt it would be harmful
[03:23]  * StevenK branches a fresh copy
[03:23] <mwhudson> the damage is (probably) only "cosmetic" in that the revnos are a bit messed up
[03:24] <StevenK> Fixing last revision info 61 => 1424
[03:24] <StevenK> I should just push that into LP?
[03:30] <mwhudson> StevenK: yes, though i guess the scanner won't look at it again until a new revision is pushed
[03:32] <StevenK> mwhudson: I can't push it, there is no new revisions to push
[03:34] <mwhudson> StevenK: you can probably uncommit one revision in your checkout, wait a minute or so for lp to notice and then push from your reconciled branch
[03:35] <StevenK> mwhudson: Hah, nasty.
[03:35] <mwhudson> yeah
[03:38] <spiv> StevenK: I'd love to know how you got your checkout into that state
[03:38] <StevenK> spiv: I have no idea :-/
[03:38]  * spiv nods
[03:38] <spiv> StevenK: care to mail me your ~/.bzr.log and ~/.bzr.log.old, just in case?
[03:39] <StevenK> spiv: From the bound branch?
[03:39] <StevenK> Oh, never mind.
[09:36] <ActionParsnip1> hey guys
[09:36] <JanC> hmpf, don't send launchpad lists mails from the list if my mail address is already somewhere in the recipients headers of a mail?
[09:38] <ActionParsnip1> can someone have a word with the user whom marked my perfectly valid bug as invalid here: https://bugs.launchpad.net/ubuntu/+source/devede/+bug/498890   it was a bug, updates have fixed it yet it was dismissed as invalid
[09:40] <tommytomtom> noodles775: any word on dput and lazy8ledger?
[09:42] <tommytomtom> al-maisan: any word on dput and lazy8ledger?
[09:43] <noodles775> tommytomtom: was that the changes file that didn't have a binary field?
[09:43]  * noodles775 checks log from yesterday - as there were a few upload issues.
[09:43] <wgrant> tommytomtom: Did you see the problems that were mentioned in here about 22 hours ago?
[09:44] <wgrant> Your debian/control file has several problems.
[09:44] <tommytomtom> noodles775:  ok.  how do I get the "binary field".. No I did not see the problems.
 geser: thomas , al-maisan : yay, we can get the exception info on dogfood: Unable to find mandatory field 'binary' in the changes file. http://pastebin.ubuntu.com/344696/
[09:44] <tommytomtom> wgrant:  what do I need to add to the control file?
[09:45] <wgrant> tommytomtom: That control file looks like you've taken it from a binary package. Is that correct?
[09:47] <tommytomtom> wgrant: no, I have deperately contructed it from partially the package-docs on lauchpad and other packages and then finally all the complaints from lintian
[09:47] <wgrant> tommytomtom: The packaging documentation will not lead you to construct a debian/control that looks like that.
[09:47] <tommytomtom> wgrant:  it is you could say, a work of art
[09:48] <wgrant> tommytomtom: Which documentation did you read?
[09:49] <tommytomtom> wgrant: https://wiki.ubuntu.com/PackagingGuide/Basic
[09:49] <tommytomtom> wgrant: is that the correct place for packaging docs?
[09:50] <tommytomtom> wgrant: then of course lintian complained a lot so I made ajustments for lintian
[09:50] <wgrant> tommytomtom: It is. I suggest that you reread https://wiki.ubuntu.com/PackagingGuide/Basic#control.
[09:50] <tommytomtom> wgrant:ok. will do.  Then I will re-submit.
[09:53] <tommytomtom> wgrant: right away I see a problem with the documentation.  it says "Architecture: any" and I tried with that and it did not work.  I had to change to "Architecture: all"
[09:53] <wgrant> tommytomtom: Either is OK.
[09:53] <wgrant> tommytomtom: Look at the list of fields just below.
[09:54] <wgrant> That 'any' didn't work for you is because of larger problems with your control file. Check the explanations of each value to work out which you need.
[09:54] <tommytomtom> wgrant: ok... working...
[10:12] <tommytomtom> wgrant: Ok.  recompiled everything with both dpkg-buildpackage -S and debuild -S .  I used both because dpkg-buildpackage did not create the .asc file.  debuild worked fine but it gave some errors http://pastebin.ubuntu.com/345245/  could you please check to see if the errors are "ignorable"
[10:14] <wgrant> E: lazy8ledger source: no-architecture-field
[10:14] <wgrant> E: lazy8ledger source: package-uses-debhelper-but-lacks-build-depends
[10:14] <wgrant> W: lazy8ledger source: package-lacks-versioned-build-depends-on-debhelper 7
[10:14] <tommytomtom> wgrant:  I know, I dont get it either.  What is wrong??
[10:15] <wgrant> tommytomtom: lintian -Iiv lazy8ledger_2.24-0ubuntu1_source.changes
[10:15] <tommytomtom> Ok. If I add debhelper to the build depends..
[10:16] <wgrant> tommytomtom: If you run lintian like that, it will give you more verbose explanations.
[10:16] <wgrant> But this discussion is probably better suited to #ubuntu-motu, now that the Soyuz bug has been identified.
[10:38] <tommytomtom> wgrant: looks much better now.  I just get a warning on a watch file.  Do most packages have a watch file???
[10:43] <wgrant> tommytomtom: They should, but it's not critical.
[10:43] <tommytomtom> wgrant: where is info on how to do watch files?
[10:45] <wgrant> tommytomtom: https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
[11:02] <tommytomtom> wgrant,al-maisan,noodles775:  YES! it uploaded.  Thanks to all.
[11:02] <al-maisan> tommytomtom: glad it worked out for you in the end :)
[11:03] <wgrant> tommytomtom: Excellent.
[11:24] <noodles775> Great work tommytomtom !
[13:57] <Viper550> I got some code I'm trying to push up, I'm on Windows
[14:26] <t__> hello?
[14:28] <intellectronica> t__: yes?
[14:30] <t__> I have a problem with launchpad
[14:33] <t__> Are you still there? Iḿ new to IRC. (actually just installed it to get some help on launchpad)
[14:37] <salgado> t__, what's up?
[14:37] <t__> My personal information is on the mailarchive
[14:37] <t__> A webmaster from launchpad has to mail the mailarchive to remove it
[15:06] <Guest26922> When trying to push a branch to Launchpad with 'bzr push lp:~hrickards/phpcrypto/trunk' I get bzr: ERROR: Cannot lock LockDir(lp-64802192:///~hrickards/phpcrypto/trunk/.bzr/branchlock): Transport operation not possible: readonly transport  . I've set bzr whoami to 'Harry Rickards <harry@linux.com' and bzr launchpad-login to hrickards. Anyone know what I'm doing wrong?
[15:07] <Guest26922> If I 'ssh hrickards@bazaar.launchpad.net' authentication seems to work fine (I get 'No shells on this server')
[15:10] <beuno> Guest26922, you probably don't have your launchpad-login set
[15:10] <beuno> uhm
[15:10] <beuno> you have
[15:10] <Guest26922> beuno: Yeah
[15:11] <beuno> how odd
[15:11] <beuno> try:
[15:11] <beuno> bzr push bzr+ssh://bazaar.launchpad.net/~hrickards/phpcrypto/trunk
[15:12] <Guest26922> No - I get exactly the same error
[15:12] <beuno> now that is a new one for me
[15:12] <beuno> rockstar, around?
[15:13] <beuno> Guest26922, does break-lock give you the same error?
[15:14] <beuno> aha!
[15:14] <beuno> I know  :)
[15:14] <beuno> it's an import
[15:14] <Guest26922> beuno Just 'bzr break-lock'. No it returns nothing
[15:15] <beuno> Guest26922, do you want the import to continue?   or was this a one time thing?
[15:15] <beuno> you can
[15:15] <beuno> can't write to imports
[15:15] <Guest26922> beuno: Ah, I see. No, it was just a one time thing. How do I stop it?
[15:15] <beuno> Guest26922, just push a new branch to a new location
[15:15] <beuno> delete the current branch
[15:16] <beuno> well
[15:16] <beuno> start by deleting the existing branch
[15:16] <beuno> then push to the same location
[15:16] <beuno> I think that should do it
[15:16] <beuno> (this is confusing, btw, there's a bug here about usability)
[15:16]  * beuno nudges jelmer 
[15:17] <Guest26922> beuno: Thanks! That did it
[15:17] <beuno> Guest26922, happy to hear that
[15:18] <jelmer> beuno: hi
[15:38] <cjohnston> if I deactivated the mailing list for my team, will the mailing list info go away on the LP page?
[18:40] <zekopeko_> hi
[18:41] <zekopeko_> how can i stop new bugs/blueprints/translations being reported in a project? we did some reshuffling so the bugs are now being reported on another page
[18:41] <zekopeko_> i want to keep the old ones
[18:42] <zekopeko_> bugs/bluepr./trans. thatis
[18:44] <zekopeko_> ok figured it out
[19:01] <zekopeko_> is there a simple way to copy a bug from one project to another?
[19:02] <beuno> zekopeko_, you can either move the bug
[19:02] <beuno> or mark it as also affecting the other project
[19:03] <zekopeko_> how to move the bug?
[19:03] <beuno> zekopeko_, click on the edit icon next to the projects' name on the bugtask
[19:03] <beuno> (the yellow block)
[19:04] <zekopeko_> under affects?
[19:04] <beuno> yes
[19:04] <zekopeko_> ok
[19:05] <zekopeko_> what next?
[19:05] <beuno> that should be it
[19:06] <zekopeko_> i don't see anything that says move
[19:06] <zekopeko_> or similar
[19:07] <beuno> zekopeko_, when you click on that
[19:07] <zekopeko_> beuno, http://dl.dropbox.com/u/185055/Screenshot.png
[19:07] <beuno> you punch in the project you want to re-assign it to
[19:07] <playya__> hi
[19:07] <beuno> zekopeko_, no, click on the yellow icon next to "Gloobus"
[19:08] <playya__> i want to reactivate my pgp key becausehas expired
[19:08] <zekopeko_> i still get the same options but on it's own page
[19:09] <playya__> i updated the key and used send-keys to upload it, but launchpad still doesn't accept it
[19:10] <zekopeko_> beuno, http://dl.dropbox.com/u/185055/Screenshot1.png
[19:10] <playya__> maybe i just have to wail longer until lp syncs the keys?
[19:10] <zekopeko_> ^ thats what I see if i click the little icon next to gloobus
[20:23] <lfaraone> Where should I put the bzr branch of a package in LP if I'm the upstream maintainer in Debian and I want to use bzr-bd to build my package?
[20:23] <lfaraone> (where is correct, I mean)
[21:32] <nkinkade> Hi all.  Just to be sure I'm not totally missing something in the docs, exporting to an upstream repository from is limited to upstream bazaar repository, correct?
[21:33] <wgrant> nkinkade: That's right.
[21:33] <nkinkade> wgrant: Thanks for verifying.
[21:33] <wgrant> Although you could probably use bzr-svn to push such a branch back up to a Subversion repository.
[21:35] <nkinkade> Yeah, I was looking at that, but it seems like a bit of back-bending to go svn -> Launchpad <-> bzr-svn -> svn ... or something like that.
[21:36] <nkinkade> Maybe not *too* bad, though.
[21:36] <wgrant> Launchpad will do a bzr-svn import for you.
[21:37] <nkinkade> I'll read up a bit more on bzr-svn.  Thanks.
[23:38]  * wgrant awaits the filing of bug #500000
[23:40] <wgrant> THere we are.
[23:40] <wgrant> Bug #500000
[23:40] <wgrant> Bug #500000
[23:43] <RAOF> aaand it's a duplicate.
[23:43] <wgrant> Haha.
[23:44] <wgrant> 400000 suffered an automatic apport duplicate fate.