=== Ursinha-bbl is now known as Ursinha
[00:04] <eydaimon> maxb: yes, tree. I mean tree :)
[00:04] <eydaimon> thanks
[00:06] <eydaimon> hmm, how come it doens't work to do that on a remote branch?
[00:16] <maxb> do what?
[00:17]  * maxb uploads lots to the proposed PPA
[00:25]  * maxb looks confused about the bzrtools in the ppa having odd differences compared to the one in sid
[00:33]  * eydaimon wonders what PPA is
[01:07] <maxb> PPA == Personal Package Archive, a Launchpad facility to allow people or teams to have their own Ubuntu package building and distribution facility
[01:28] <eydaimon> "do that" was to do bzr revno --tree
[01:31] <maxb> Most likely the remote branch has no tree
[02:04] <eydaimon>  it does. I went to the branch and ran it
[02:04] <eydaimon> i'm stupid, but not *that* stupid :P
=== Odd_Blok1 is now known as Odd_Bloke
[12:24] <Kamping_Kaiser> aw, no jelmer
[12:24] <Kamping_Kaiser> i still have a diff of his in my bzr-svn branch :/
[12:31] <Kamping_Kaiser> ...
[12:31] <Kamping_Kaiser> speaking of which
[12:31] <Kamping_Kaiser> jelmer: got a moment?
[13:12] <jelmer> Kamping_Kaiser, hi
[13:13] <Kamping_Kaiser> jelmer: hello. http://paste.debian.net/84733/ is a change you left in my bzr branch, is it something you need(ed?) to commit?
[13:21] <jelmer> Kamping_Kaiser: ah, that was the workaround
[13:21] <jelmer> Kamping_Kaiser: that should no longer be necessary, lp:bzr-svn should now cope with that branch
[13:21] <jelmer> Kamping_Kaiser: thanks for checking though
[13:22] <Kamping_Kaiser> jelmer: ah, no problem. i'll revert it out . thanks for looking :)
=== jelmer_ is now known as jelmer
[15:26] <parthm> hello. i am trying to create a branch on my office system but am getting a weird transport error http://pastebin.com/JC2e6JQJ ... i suspect the windata dir is a mount. does anyone know what might be happening? the message is quite generic.
[15:56] <mkanat> Okay, let's say that I have a file path. What's the fastest way to find out which revision it was modified in last before a certain revision?
[15:56] <mkanat> Or, more specifically, I have some log -v output, and I can see that a file was moved from one place to another.
[15:56] <mkanat> I'd also like to know what the revid of the file was at that time, using the CLI.
[16:41] <alkisg> Hi, I've lost 5 "pack" files from a repository: .bzr/repository/obsolete_packs/26c250e9eacd0e32253aee09ed6ea15f.pack .bzr/repository/obsolete_packs/3e0684636f1b84bd93b726886ac33ac8.pack .bzr/repository/obsolete_packs/bdde9237d718da297ea1819ea955695f.pack .bzr/repository/obsolete_packs/ee3c02de21d2ea6dfc116bbbb4d48694.pack .bzr/repository/packs/aabdba7905e54e65ce719f97876569a4.pack
[16:41] <alkisg> No actual data files were lost, and bzr seems to be working fine. Should I be worried about those "pack" files?
[16:43] <fullermd> What do you mean, "lost"?
[16:43] <alkisg> Some hard disk problems, and I was able to copy all the files except for those.
[16:47] <alkisg> Ugh yeah `bzr diff` works but `bzr log` complains about missing files
[16:47] <fullermd> Well, the stuff in obsolete_packs won't matter.  But you're missing one active one, so...
[16:47] <jelmer> alkisg, files under obsolete_packs being lost should usually not be a problem; the one file under packs/ would be an issue
[16:48] <alkisg> Any way to fix it with minimal loss? I don't mind much about the history, it's a personal project...
[16:49] <mkanat> alkisg: You could export the files and create a new project.
[16:49] <mkanat> alkisg: Although somebody else might have a better idea.
[16:49] <mkanat> I mean, create a new branch.
[16:50] <mkanat> alkisg: You don't have any other checkout or branch of that project?
[16:50] <mkanat> (This is one reason why I often use bound branches.)
[16:51] <alkisg> Got it. No, unfortunately, it was somewhat new, I didn't get a chance to back up the bzr data yet
[16:51] <alkisg> But I do have all the project files, so all I'm losing is the changes history...
[16:52] <alkisg> Hmm I'll try to use one of the obsolete packs instead of the lost one, maybe I'll get half of the history back
[17:14] <alkisg> Is there a "bzr unpack" command that would allow me to revert to one of the obsolete_packs ?
[17:14] <alkisg> (file renaming didn't work :))
[17:17] <jelmer> alkisg: No, although you may be able to get it to pick up the obsolete pack files by editing .bzr/repository/pack-names
[17:17] <alkisg> That looks like a binary file to me, I don't know how I could edit it...
[17:18] <jelmer> ah, hmm
[17:18] <alkisg> I tried renaming an older pack to that missing pack, but I got a bzr panic :)
[17:19] <alkisg> OK guys thank you all, I'll just recreate the branch
[17:24] <fullermd> Well, renaming a pack that doesn't have the same stuff would certainly not help anything   :p
[17:26] <alkisg> I tried renaming both the pack + its indices, hoping that all of them would hold a previous state
[17:26] <alkisg> I.e. what are the obsolete-packs for, if there's no way to restore them?
[17:28] <fullermd> Potentially restoring if the new packs are bad in some way.  But changing their name would never be meaningful; if two packs have the same content, they'd already have the same name.
[17:29] <alkisg> "Potentially restoring if the new packs are bad in some way" ==> and how would that restoration be accomplished?
[17:30] <fullermd> Much what jelmer said.
[17:30] <fullermd> But of course the reason they're in obsolete is that things have happened since then, presumably including new commits.  And if those are in the pack file you lost, restoring obsoletes wouldn't be any help.
[17:34] <alkisg> Well, I tried editing pack-names, but it was a binary file, so the only thing I could do was to rename the files instead of changing pack-names :)
[17:34] <alkisg> Anyway, thanks again guys, it's not worth any more time, it wasn't a very big history.
[17:37] <GaryvdM> maxb: Wow - The ppas is looking good. Nice work!
[17:59] <Noldorin> does bzr on windows come with its own distribution of python 2.5.4?
[17:59] <Noldorin> it's not seeming to use my 2.6.5 installation
[18:03] <maxb> GaryvdM: Hi - what's the story regarding qbzr/bzr-explorer on hardy? Dependency hell?
[18:04] <GaryvdM> maxb: They are no longer with compatible with the hardy version of qt
[18:05] <Noldorin> anyone here got bzr-tfs workign?
[18:07] <GaryvdM> maxb: The old versions *should* still work with the latest version of bzr (we only check for a minimum version,) but I've not tested this.
[18:09] <maxb> I think my builds of dulwich on hardy have hung :-(
[19:59] <jelmer> maxb, whoa, a build time of 2.5 hours!?
[20:02] <maxb> jelmer: what, dulwich?
[20:03] <maxb> The tests hung, somehow :-(
[20:03] <jelmer> maxb: I've seen that happen before in the compat tests
[20:03] <maxb> Any hints, or does it remain a myster?
[20:03] <maxb> y
[20:04] <jelmer> All I know is that those particular issues were caused by a bug in dulwich that didn't make it respond as it was expected to.
[20:04] <jelmer> You might want to just skip running the compat tests.
[20:05] <maxb> I was contemplating that.
[20:05] <maxb> It feels like cheating, though
[20:06] <jelmer> Well, the alternative is to check what version of git-core dulwich relies on and backporting that as well..
[20:06] <jelmer> at least, that's my guess
[20:07] <maxb> jelmer: btw, at the moment we have subvertpy 0.7.3 for karmic+lucid, but 0.6.9 for hardy+jaunty, because subvertpy 0.7.3 is broken with Subversion << 1.6 - that's ok for now, from a bzr perspective, right?
[20:07] <maxb> I'll file a proper subvertpy bug later
[20:07] <jelmer> maxb: yes
[20:07] <jelmer> maxb, 0.7.3.1 fixes that
[20:08] <maxb> ah, great
[20:18] <GaryvdM> maxb: There is a newer version of bzr-pipeline that I would like to upload to the ppa. I'm not sure what to do about the missing packaging branches. Should I just create them?
[20:18]  * GaryvdM is aware of ~bzr/bzr-pipeline/lucid-packaging thanks due to your wiki page.
[20:23] <GaryvdM> maxb: It would be great if you were to push what you had for the versions you uploaded to new branches, so that history is not lost.
[21:26] <jared> how can I download code from launchpad without creating a ssh key?
[21:26] <jared> I don't want to upload, just download.
[21:26] <dash> you only need an ssh key to upload, i believe.
[21:26] <dash> so bzr get lp:whatever should work
[21:29] <jared> Permission denied (publickey).
[21:29] <jared> I'm doing "bzr get lp:jade"
[21:30] <jared> I'm trying to get this: https://launchpad.net/jade
[21:31] <jared> sorry I'm a noob, just switched from git
[21:32] <dash> hm. that url should work
[21:32] <dash> do you get an error?
[21:34] <jared> dash: yeah,-> Permission denied (publickey).
[21:34] <dash> hum
[21:34] <jared> I tried cleaning out my known hosts, but no success.
[21:34] <dash> try just 'bzr get lp:jade'
[21:35] <jared> thats what I did
[21:35] <dash> very odd
[21:35] <dash> OTOH i've had my ssh key on launchpad since i started using it
[21:36] <dash> does 'bzr get https://launchpad.net/jade' fail the same way?
[21:37] <jared> that seems to be working...
[21:38] <jared> thank you... that's a bit strange though...
[21:59] <GaryvdM> jared: lp:whatever will map to a bzr+ssh url if bzr launchpad-login is set, and to a http url if it is not.
[22:00] <GaryvdM> the http urls don't require the ssh key.
=== Ursinha is now known as Ursinha-afk
[22:47] <maxb> GaryvdM: I know there are well-established bzr-svn packaging branches, which I'm looking into updating now. For the rest, I wasn't planning on creating new branches where my changes were nothing more than changelog bumps and scripted reversion to source format 1.0
[22:57]  * jelmer is looking forward to build-by-push
[23:01] <maxb> ugh. bzr-builddeb's changelog merge hook is a menace when working with ppa branches
[23:04] <jelmer> maxb: how so?