=== beuno_ is now known as beuno [00:57] hi all [01:11] Good morning. [01:57] hi there spiv [02:47] spiv does https://bugs.edge.launchpad.net/bzr/+bug/620684 suggest anything obvious to you? [02:47] Launchpad bug 620684 in Bazaar "ERROR file id "None" is not present in the tree when checking the root entry (affected: 1, heat: 6)" [Undecided,New] [02:50] poolie: huh, no. Strange upgrade, maybe? [03:41] * poolie is writing up a mail of annoyances in ppa updates [04:05] did i just dream that there was a bzr init --standalone option? [04:28] mwhudson: There's a *branch* --standalone. Maybe that's what you're dreaming of? [04:28] fullermd: ah, probably [04:28] Me, I'll stick with dreaming of Cindy Crawford, but... [07:19] GaryvdM: hi, can you tell me which branches you used for your bzr-gtk packages [07:24] nm [08:04] hi all ! [08:05] Wassat? Morning again already?? [08:05] fullermd: yeah, and end of vacations too, wake up NOW :) [08:06] Vacations? Heck, I don't even REMEMBER what those are... [08:06] fullermd: You really should, there are nice places around the world you really should visit while you still can ;) [08:06] That would require leaving home. To say nothing of putting on pants. [08:06] Well. I guess the REALLY nice places don't need the pants... [08:07] fullermd: yup, including the under water world... [08:08] hi vila [08:08] poolie: heya ! [08:09] i'm going to change tack on the ppa and try to get everything just at least working on maverick [08:10] poolie: what isn't working so far ? [08:10] a bunch of litle annoyances [08:10] one being that in the debian bzr packaging, they've cut out python-configobj [08:10] because of a sensible policy that packages should not ship their own copies of libraries [08:11] but that's not packaged on hardy, and it's a little hard to make it work there [08:11] it could all be fixed but it just seems like a time sink [08:12] well, not shipping copies of libraries shouldn't apply if the said libraries aren't available methinks... [08:12] hm, restart required bbib [08:12] Yeah, if we shipped testtools, I could run selftest ;> [08:14] it's completely fixable it's just one thing after another [08:14] separated by long pauses for soyuz to decide [08:14] * fullermd is unpleasantly familiar with such tasks... [08:15] anyhow istm the main thing is to get it all working on lucid [08:15] you might think it would make sense to start with the oldest one and work forward [08:15] but i now think this is probably wrong [08:25] poolie: waitaminute, I thought we modified configobj lightly but enough to not be able to use the stock version no ? [08:25] oh, really? [08:25] that's such a bad idea [08:26] i hadn't heard of that [08:26] IMBW or the changes may just be cosmetic... [08:30] Hi poolie [08:30] poolie: lp:~bzr/bzr-gtk/packaging-$DISTRO [08:31] I may not have push up all my changes yet, as I've not finished the hardy build. Let me push up the rest. [08:32] poolie: I've also merged them with the debian unstable branch :-) [08:32] That's why hardy is failing... [08:32] GaryvdM: got it now [08:34] poolie: hmm, scratch that, if we used a modified version and debian deleted it, we would have heard about bugs [08:34] vila, that's what i thought too [08:34] i don't feel like going to look for trouble there; i have enough already [08:35] poolie: ok, but may be we should file a bug about using our own copy only if none is available [08:36] There is at least one bzr-local change to ours, to improve import speed :/ [08:37] (It imports the 'compiler' module for a feature we never use) [08:37] hm, that's just the kind of thing we wouldn't get bugs about too [08:37] hello spiv, btw, you've been a quiet mouse :) [08:38] hi spiv, I was just seeing your comment in configobj.py :D [08:38] spiv, i we should file a bug against bzr, debian, and ubunut [08:38] and maybe try to send the patch upstream to configobj [08:39] AFAIK we'd run ok with stock configobj, I think most of the other changes that bzr log reports are cosmetic. [08:43] poolie: I've been chipping away at old todo items before they go entirely stale... I'm currently looking at a draft of a LEP about logging (and contemplating how e.g. 'bzr serve' could change to do it better). [08:45] poolie, spiv: even comparing with actual configobj-4.7 (we have a copy of 4.6) I see nothing worth worrying. As spiv said, there is the compiler loading and then 4.7 differs slightly for some errors handling [08:46] vila: that's a relief :) [09:21] * bialix waves at GaryvdM [09:23] Hi bialix. [09:33] hi bialix [09:33] ppas should be all ok once the packager finishes updating [09:33] well, by that i mean the lucid proposed ppa [09:33] hi poolie [09:35] does anybody know which version of bzr-explorer is packaged in ppa and lucid? [09:35] https://edge.launchpad.net/~bzr/+archive/proposed?field.series_filter=lucid has 1.1.0~beta1 [09:35] and lucid itself has [09:36] 1.0.1-0ubuntu1 [09:36] why not 1.0.2...? [09:36] and maverick also has 1.1.0~beta1 [09:37] i don't know [09:37] rhetorical question [09:37] i would guess that nobody updated it [09:37] if it's only bugfixes, it still could go in [09:37] sorry, I've meant maverick [09:37] 1.0.2 has released after lucid [09:37] maverick of course is the one that's coming out in october [09:38] yep [09:38] bialix: https://wiki.ubuntu.com/StableReleaseUpdates [09:38] that's fine then [09:38] * bialix notes [09:38] bialix: It's quite a process to get it updated in an existing release. [09:38] we should do something about the sru policy [09:38] yes, I understand [09:39] spiv it would be nice if you could do that next week [09:39] I'm not ready to force SRU right now [09:39] we'll try to keep the ppa up to date [09:40] bialix: The ppa will have 1.1.0~beta soon. [09:40] GaryvdM: thank you! [09:41] poolie: the latest bzr-explorer, and qbzr are compatible with bzr 2.1.0, so I may as well copy them to the main ppa now. [09:41] ok [09:41] so i think we're now all done [09:42] poolie: what about git, svn loggerhead? [09:43] git has new version for lucid, but not other distros. [09:43] Same for dulwich [09:43] Same for svn [09:44] poolie: I think we still have some way to go. [09:44] GaryvdM: i was wondering if we should have some enlightened lazyness about builds on old distros [09:45] :-) [09:45] i found i was bogging down a lot [09:45] trying to get them all through, and once i focussed on just lucid it was much easier [09:45] I know the feeling. [09:45] it ought to be mechanical but there are proportionally more snags across the old ones [09:45] i'm going to try to get some data on how much people actually use them, or want upgrades there [09:46] both from the download logs, and perhaps we'll see if anyone objects on the list [09:46] poolie: Lets copy for lucid now, and not copy for the others... [09:46] my sense is that people mostly do not stick with old ubuntu releases for a long time (except for lts) [09:46] unless they specifically want the machine not to move very much [09:46] but this is ... wishful thinking :) [09:50] poolie: How come your uploads show as no signer? [09:54] poolie: the reasoning sounds fine, if I want a newer bzr I'm likely already tracking a newer Ubuntu. But even if I track an older Ubuntu *and* I've subscribed to the bzr ppa, I still prefer stability over new features so I may accept fewer updates on the bzr ppa. I.e. we can start proposing an up-to-date ppa for lucid and maverick and update hardy/jaunty/whatever when time permits (including when our process become more automatic) [09:57] I can't remember the name of the plugin to run test suite on each commit, aka poor-man pqm. anyone? [09:58] testrunner [09:59] GaryvdM: i copied the binaries from the main archive; i guess that's why [10:00] poolie: Ah - ok [10:00] poolie: I just read your mail. [10:00] vila, are you talking about maybe having a 2.1, 2.2, etc ppa? [10:01] poolie: This was the frustration I was trying to describe at uds - You described it much better than I could... [10:01] hmm, no I was thinking about just the stable and proposed ones [10:02] i'm just glad it's done; the combination of lags plus tiny failures is so annoying y [10:02] you can't concentrate and just get it done but you can't concentrate on anything else [10:02] or at any rate i can't [10:02] vila: oh you're saying people on hardy may be happy to just stay on 2.0 or whatever? [10:02] i agree [10:02] i agree they may [10:03] I upload, play a game of solitaire, and then go and check if it succeeded. :-0 [10:03] exactly [10:03] nice for 20m, not a good way to spend two days :-{ [10:03] or more :{ [10:04] poolie: yes, they may accept to upgrade to 2.2 later [10:04] err, they may accept that the upgrade is delayed [10:04] poolie: I'm going keep at it though. Next up - for me: bzr-builddeb [10:04] ? [10:04] i think they're all done [10:05] assuming the publisher runns... [10:05] awesome [10:05] poolie: For all distros [10:05] oh, ok [10:05] if you really want to [10:06] wow, launchpadlib pulls in a bunch of stuff [10:06] i think it's used by builddeb [10:06] including a mail server [10:06] strace [10:07] poolie: The other thing is that merging the debian unstable packaging branches as caused more complication, but I think it will make it easier in the long term. Packages for which I did this when I did 2.1 were easier this time round. [10:10] poolie: q about pad.lv: why you've used .lv domain for it? [10:16] it's cheap, and it sounds like "pad love" [10:16] i'm not latvian [10:16] i think spiv is ½ latvian though, or lithuanian [10:19] funny [10:20] good night and good luck! [10:20] Good night [10:20] :-) [13:50] i386 ppa build queue > 4hrs :-( [13:50] vila: Thanks for the review, very much appreciated! [13:52] jelmer: as is your work in this area, you're definitely on something here and I was just wondering if the factory idea shouldn't be pushed even more to clearly define how one create repo/branch/wt for a given format [13:53] jelmer: they are all created from the format or its associated dir so far and without looking into the details, I wonder if we have inherited that from the early days of bzr... [13:54] jelmer: I was quite surprised that you were able to produce such a clean patch there, I would have swear that things were too mixed-up for that... So, well done ! ;) [14:37] vila: Thanks :-) [14:37] vila: History shows there indeed, although I think it's a slightly disconnected problem. [14:38] I'll followup to the branch tonight and see if I can get some of the plugins working with this new API then :-) [14:38] great ! [14:46] jelmer: My I ask you some debian packaging questions? [14:46] GaryvdM, yeah, sure [14:48] jelmer: I would like to submit a patch to the packaging config for qbzr. Should I submit a branch with just the change, or should I also merge the upstream, and update the changelog? [14:49] Making the change, and updating the changelog with out merging upstream feels odd. [14:49] GaryvdM: You should definitely update the changelog to mention what you've fixed [14:50] merging upstream isn't necessary, but you might as well while you're there [14:50] Also one of the changes I want to make is specific to the upstream version (minimum bzr version) [14:51] jelmer: And then push to lp, and send mail to pkg-bazaar-maint@lists.alioth.debian.org ? [14:53] GaryvdM: yep [14:53] Ok :-) [15:19] hi, sorry for noob question but is there a way how to show all modified files since rev x? [15:20] starenka__: bzr status -r x [15:20] neat [15:20] thanks [15:51] garyvdm: re your pretty html table of package versions on the mailing list [15:51] Yhea - sorry about the html. [15:51] I think testtools really wants to be at either 0.9.2 or 0.9.5 [15:52] we probably can't do much about debian unstable, but who would need bugging about maverick? [15:53] ^needing to do a table is a good reason for html email, the mess people make trying to do them is plain text is worse [15:54] mgz: Why not do any thing about debian unstable. We have 2 dd's amongst us! [15:54] well, they're deeper in freeze than ubuntu is I believe [15:55] but sure, jelmer/lifeless, if you can find a way to get the release managers to take the next testtools version, that'd be great [15:56] mgz: I don't think that would be required for sid, only for squeeze. [15:57] yup. [15:58] mgz: Ok - so we should try get sid/mavrick updated to 0.9.5 before updating the others in the ppa. [15:59] Thats ok, because I want to get the more user facing packages updated first. [15:59] great, thanks. === mvo is now known as mvo|undercover [15:59] my busy week is over now so I should be around if you need help with anything [16:04] hi Gary, Martin [16:04] mgz, GaryvdM: Rob is the person to talk to, he's the only maintainer of testtools in Debian. [16:05] thanks jelmer, I'll bug him later. === lamont` is now known as lamont === Ursinha is now known as Ursinha-lunch [16:40] hello [16:40] is 2.2 officially released ? [16:41] yeah [16:42] jelmer, then why does the website state that 2.1 is stable release? [16:43] zyga: That's a good point.. [16:43] jam, vila: ^ === zyga is now known as zyga-afk [16:44] * zyga-afk needs to go away for a few hours :/ [16:44] jelmer: I think we wait for the installers before releasing officially [16:45] jelmer: and also an updated ppa but this should be good now thanks to poolie and garyvdm === ddaa1 is now known as ddaa [16:45] zyga-afk: so 2.2 is really *close* to be officially released === deryck is now known as deryck[lunch] [17:45] I tried doing this --> bzr pull lp:pressflow --remember and got this --> bzr: ERROR: Cannot lock LockDir(lp-70598736:///~pressflow/pressflow/6/.bzr/branchlock): Transport operation not possible: readonly transport [17:45] why? [17:47] MTecknology: bzr info ? [17:48] MTecknology: may be your branch is bound to lp:pressflow ? [17:50] vila: that'd explain it :D [17:50] thanks [18:25] jelmer, what's the latest version of bzr-rebase/rewrite i should use with bzr 2.2.x ? === Ursinha-lunch is now known as Ursinha [18:26] rocky, the latest version f bzr-rewrite (not sure off the top of my head what that is) [18:26] well baseically i need rebase that works with bzr-svn and bzr 2.2.0 [18:26] so what do i get? :) [18:28] jelmer, ^^ [18:29] rocky: as I said, the latest version of bzr-rewrite [18:29] jelmer, oh sorry i misunderstood... the reason i'm asking is because the latest download on http://wiki.bazaar.canonical.com/Rewrite?action=show&redirect=Rebase says it's for bzr 1.13 and higher... hwich makes it seem old [19:09] Is there any easy way to take one branch abd run bzr pull lp:newbranch --remember --ignore-conflicts ? [19:10] The only way I can think of is to move the directory, then grab a fresh copy - but not ideal [19:35] rocky: the APIs it uses haven't changed, so there's no reason to change the minimum bzr version [19:35] k [20:20] I dowloaded two blender branches. How can I visualize when one was forked off and how many commits are different? [20:20] MarcWeber: 'bzr missing' will tell you the differences between the branches. [20:21] 'bzr vis' or 'bzr qlog' can show you a pretty view of the history, if you have the gtk or qt extensions installed [20:22] dash: I prever pretty views :) Are those extensions included in the main source ? [20:22] they're plugins. [20:30] Does bazaar store multiple branches in one directory as git does? [20:31] I have a blender branch on lp I'd like to compare with current unstable. [20:31] MarcWeber: no, it doesn't [20:32] you can use a shared repo so that branches don't have duplicate copies of the revs they have in common [20:32] So I checkout twice and then use diff ../other-dir or such ? or diff lp-url ? [20:33] MarcWeber: sure [20:33] or missing ../other-dir etc? [20:33] yep [20:33] if you start with 'bzr init-repo .' then it'll create a repo in the current directory [20:33] and so checking out a second branch in that dir will only fetch the extra revs [20:34] branch 'lp:~diresu/blender/blender-command-port-002' [20:34] and branch lp:blender [20:41] Can I make a shared repo out of a checked out one? [20:42] MarcWeber: to do that you do init-repo as above, then clone your existing branch into it [20:42] so 'bzr init-repo .; bzr branch mybranch mybranch_new' will do it. [20:43] ( --trees) ? [20:44] if you like :) [21:32] if I do a bzr up -r 123 and then a bzr revno, it shows the head revno, not the one the repo is at. How can I get the revision the repo is at? === Ursinha is now known as Ursinha-bbl [23:18] eydaimon: You don't mean repo, you mean tree. Use bzr revno --tree