[00:00] <jelmer> vanguard: yep, there's "bzr log" and the release notes (doc/en/release-notes/*.txt)
[00:01] <poolie> the release notes are the main forum for giving credit to people
[00:01] <poolie> what were you planning to work on?
[00:01] <vanguard> i18n
[00:01] <poolie> oh, hi
[00:01] <poolie> excellent
[00:01] <jelmer> vanguard: Are you Martin?
[00:01] <vanguard> jelmer: yep
[00:01] <poolie> also, yet another martin :)
[00:02] <poolie> it may be one of those things that is actually less difficult than people have come to believe
[00:02] <poolie> or not :)
[00:02] <vanguard> I tried i18n on my own projects and found it pretty straightforward
[00:02] <vanguard> but my biggest project was 10k LOC, so bzr is quite different I suppose
[00:04] <jelmer> poolie: are you talking about i18n or the number of Martins ? :)
[00:05] <vanguard> having two people with the same name is not that difficult I guess :-)
[00:06] <poolie> i think there are now about 4
[00:06] <poolie> jelmer, about 4 Martins (or more?) contributing to bzr
[00:06] <poolie> plus a couple commenting
[00:07] <poolie> it seems unusually rich
[00:07] <poolie> counting gz and beuno
[00:07] <beuno> all the smart people are named Martin, yes
[00:09] <vanguard> it is the 234th most popular name in the US apparently (http://www.wolframalpha.com/input/?i=martin)
[00:11] <vanguard> you use spaces in bzr codebase?
[00:11] <poolie> rather than ^i tab characters, yes
[00:11] <poolie> and just generally following PEP8
[00:12] <vanguard> okay, I use tabs everywhere, I just wondered why python did not like my indent :)
[00:19] <jelmer> poolie: I've started using the "bazaar" superproject in Launchpad more and it's been working quite well. The main problem is that there are some subprojects that are inactive, and they clutter up the superproject views.
[00:19] <jelmer> poolie: Do you know if there's anything we could do about that?
[00:20] <jelmer> removing subprojects from the superproject is possible, but probably also suboptimal (makes it harder to find them back later)
[00:25]  * jelmer gets some sleep
[00:26] <vanguard> maybe create a subsuperproject where the abandoned projects go?
[00:50] <bignose> jelmer: my trunk branch, bound to the Subversion repository, doesn't have a ‘subversion.conf’ file.
[00:50] <jelmer> bignose: ~/.bazaar/subversion.conf
[00:50] <bignose> oh, it's a *global* setting? :-(
[00:51] <jelmer> no, that file has per-repository settings
[00:51] <bignose> okay. confusing, but I'll manage
[00:52] <bignose> jelmer: to confirm my interpretation:
[00:52] <jelmer> bignose: you can also set it in ~/.bazaar/locations.conf I think
[00:52] <bignose> jelmer: if I set ‘push_merged_revisions=True’ for the particular repository,
[00:53] <bignose> and then merge and commit in that repository,
[00:53] <bignose> the Subversion repository will get the merged revisions in automatically-created Subversion branches?
[00:53] <jelmer> bignose: yep
[00:54] <jelmer> bignose: (but again, the version in sid is too old for this to work well)
[00:54] <bignose> jelmer: and then, when I remove the branches from svn, the history will show the same afterward?
[00:54] <jelmer> bignose: yep
[01:09] <bignose> jelmer: sounds like a winner. I'll try it today.
[01:10] <bignose> jelmer: ‘push_merged_revisions’, or ‘push-merged-revisions’? or are both spellings equivalent?
[01:11] <jelmer> bignose: push_merged_revisions
[01:12] <bignose> oh, I just saw you saying that it won't work well?
[01:13] <bignose> bzr-svn 1.0.3-1
[01:13] <jelmer> bignose: that's too old, you'll need something from at most 10 days ago
[01:13] <bignose> gah
[01:13] <jelmer> 1.1.0 is due out later this week, if that helps
[01:14] <bignose> I'll need to wait for the next OS release then.
[01:23] <bignose> (the machine where this is being done is pinned at Ubuntu Maverick)
[01:27] <poolie> the next os release after maverick?
[01:27] <poolie> that happened yesterday
[01:27] <bignose> goodie
[01:28] <bignose> but is the ‘bzr-svn’ that jelmer refers to included in that?
[01:29] <poolie>    bzr-svn | 1.0.4+bzr3475-1 | natty/universe | source, all
[01:29] <poolie> i don't know if that's new enough-
[01:29] <poolie> i doubt they updated only 10 days ago
[05:10] <KombuchaKip> How do I add a user to the list of people that have write access to my launchpad hosted bzr branch?
[05:23] <spiv> KombuchaKip: write access on Launchpad is determined by the owner of the branch
[05:23] <spiv> KombuchaKip: so have the branch be owned by a team, and have that user be a member of that team
[05:23] <KombuchaKip> spiv: Right. But if I want to give some others write access?
[05:24] <KombuchaKip> spiv: Hmm, I created a branch already so I would have to move it to the teams...
[05:24] <KombuchaKip> spiv: I have a feeling this is going to create a headache.
[05:25] <spiv> KombuchaKip: If you follow the 'Change branch details' link on the branch's page you can change its owner
[05:25] <KombuchaKip> spiv: You're right! That was easy!
[05:26] <spiv> :)
[06:22] <poolie> hi spiv, i'm back
[06:40] <spiv> poolie: hi, welcome back
[06:52] <vila> hi all, I'm back too ;)
[06:56] <poolie> hi spiv, vila
[07:01] <poolie> spiv does https://bugs.launchpad.net/bzr/+bug/772935 ring any bells for you?
[07:01] <poolie> you commented earlier on one that looks a lot like a dupe
[07:01] <poolie> and generally speaking it looks a bit like some bugs that were thought to be fixed
[07:14] <spiv> poolie: lifeless was asking me about that on #launchpad
[07:15] <spiv> poolie: no particular bells rung.  It's worrying, but it doesn't ring bells more specific than "stacking, maybe?"
[10:39] <jam> hey vila, I just saw this: http://babune.ladeuil.net:24842/job/selftest-windows/413/testReport/
[10:39] <jam> But, it works just fine here on Windows
[10:39] <jam> I wonder if it is an NTFS vs FAT thing?
[10:39] <vila> jam: :) You should revise your belief that "it works on windows because if works on *my* windows" ;)
[10:40] <vila> jam: but, yes, it has failed twice in a row so it's probably an indication that something is wrong
[10:40] <jam> vila: I've never claimed because something works here it works everywhere.
[10:40] <jam> I have the feeling it is something *specific to your machine* that I cannot reproduce
[10:41] <jam> so it isn't strictly that the test is at fault, I'm hesitant to just remove/disable the test
[10:41] <vila> I was wondering if you were able to reproduce it locally but I'm upgrading babune to natty and didn't think it was an urgent one
[10:41] <jam> can you do "os.utime" or your machine and see if it allows anything?
[10:41] <vila> not right now
[10:41] <vila> but
[10:42] <vila> if race conditions in file system accesses... that's something that ring so many bells on babune that I can't even hear you anymore ;)
[10:44] <vila> ntfs vs fat could also be a good lead
[10:44] <vila> jam: can't you just create some fat fs on either an external HD or even USB stick ?
[10:45] <jam> vila: faster for me to just wait for you to upgrade your machine :)
[10:46] <vila> jam: with the upgrade announcing still 1 hour to download the packages, I doubt it
[10:46] <vila> 1h33 even
[10:47] <vila> Is ubuntu.com so heavily loaded that it can't provide more bandwidth ?
[10:47] <jam> vila: less of my personal time, since I can perfectly happily ignore this until next week
[10:49]  * vila too ;)
[11:11] <jam> vila: so in this case "a" is a directory. and I imagine FAT can't set mtime for dirs. I'm happy enough with a try/except OSError there and just skip it on babune
[11:15] <vila> jam: you mean a try/except in the test ?
[11:16] <jam> vila: yep
[11:16] <jam> vila: sending to pqm now unless you object
[11:16] <vila> oh, right, I see the code now
[11:17] <vila> well, if I had objections it would be about using some sort of test feature instead of catching the exception in the test, but I think it's an edge case so, just land
[11:18] <jam> vila: if we have more of these, I'd go for it
[11:18] <jam> but right now, for just 1 test, it isn't worth a Feature
[11:18]  * vila nods
[11:18] <vila> I haven't looked in detail and didn't realize it was a single test
[11:19] <jam> vila: yeah, 1 test permuted 4 times
[11:19] <vila> yup
[11:20] <vila> on the other hand, there may be other ways to update the dir mtime in more portable ways, but again, probably not worth the trouble in this case
[11:21] <jam> vila: I don't know what FAT is giving for mtime anyway, and putting a 10s sleep in there is much worse
[11:21] <vila> yeah, evil++ ;)
[11:21] <jam> (well, a 2+s sleep for FAT granularity)
[11:22]  * jam is thinking we should just go with a 1s timeout to our hash cache, and let FAT people live with the fallout.
[11:22] <jam> It won't be often that they update content 2x in a 2s window from commit
[11:22] <jam> they can always touch things if they need ot
[11:22] <jam> to
[12:01] <vanguard> I am just reading the i18n specs in the wiki and I see _() everywhere. Isn't using the _ as a function against the use of _ as the "last return value" causing problems in the debugger?
[12:04] <vila> vanguard: I don't remember the details but: 1) you're right, that caused problems 2) they were fixed for bzr-gtk
[12:07] <vanguard> so it is save to use _() or should one use something else instead()
[12:07] <vanguard> s/()/?
[12:11] <vila> well... IIRC, the issue was that gettext was injecting '_' aggressively in some dicts, so the issue could come back
[12:12] <vila> and the workaround was to fix it in a way that only modules that needed it were fixed
[12:12] <vila> from a usability pov for devs, I don't have enough experience there to comment
[12:12]  * vila goes for lunch
[13:39] <vanguard> can I somehow set the commit --strict option as a default?
[14:12] <knighthawk> how do I "unbound" a branch?
[14:51] <spiv> knighthawk: 'bzr unbind', or alternatively 'bzr reconfigure' to the state you want instead.
[14:51] <knighthawk> thanks spiv
[15:26] <hrw> hi
[15:27] <hrw>   parent branch: bzr+ssh://bazaar.launchpad.net/~linaro-maintainers/linaro-images/hwpack.natty.linaro-panda/
[15:27] <hrw> 16:26 hrw@home:hwpacks$ bzr push lp:~hrw/linaro-images/hwpack.natty.linaro-panda/use-ubuntu-kernel
[15:27] <hrw> bzr: ERROR: Permission denied: "~hrw/linaro-images/hwpack.natty.linaro-panda/use-ubuntu-kernel/": : Cannot create branch at '/~hrw/linaro-images/hwpack.natty.linaro-panda/use-ubuntu-kernel'
[15:27] <hrw> what I am doing wrong?
[15:27] <jelmer> hrw: there's a slash too many in there as far as I can tell
[15:27] <james_w`> hrw, linaro-images is the project name
[15:27] <james_w`> there can only be one path segment after that
[15:28] <jelmer> hrw: ~username/projectname/branchname is the standard form
[15:28] <james_w`> i.e. replace the last / with a - or something
[15:28] <hrw> ok
[15:29] <hrw> thx
[15:30] <jelmer> jam: still there?
[15:40] <rryan`> hmm, our launchpad repository is now throwing errors on checkout and branch for bazaar 2.1.1
[15:40] <rryan`> http://pastebin.com/Kud2MsqQ
[15:40] <rryan`> should I file a bug as the output suggests or is this something you think is already fixed in a newer version ?
[15:41] <rryan`> (or alternatively, is our repository broken somehow now? it works fine for existing checkouts/branches)
[15:45] <jelmer> I'll give it a try with 2.4, one sec..
[16:04] <spiv> rryan`, jelmer: there's already a bug filed, https://bugs.launchpad.net/bzr/+bug/772935
[16:16] <jelmer> spiv: hey spiv
[16:16] <jelmer> thanks
[16:24] <rryan`> spiv: thanks -- right hand not talking to the left :)
[16:35] <pmatulis> what's the easiest way to change a commit message?
[18:48] <mdke> hi there. is there a way to make "bzr revert" delete unknown files?
[18:48] <vanguard> you can use bzr clean-tree for that
[18:48] <vanguard> try it with `bzr clean-tree --dry-run` if you like
[18:49] <mdke> vanguard: can I give it a path?
[18:49] <vanguard> bzr clean-tree --help offers a list of options, you can delete ignored files, backup files, etc
[18:49] <vanguard> mdke: not sure, try a dry-run in the directory that you want cleaned
[18:51] <mdke> vanguard: doesn't look like it. Still a useful tool though, thanks
[18:51] <vanguard> you can file a bug against it on launchpad.net/bzr if you want that feature added
[18:52] <mdke> vanguard: do you think that it is a sensible feature to request? perhaps it is a design choice
[19:17] <vanguard> mdke: well, you might want to use that to clean out build files, the tree is not really affected by unversioned files, so I think adding this option does not hurt
[22:27] <mhall119> is this a good place to ask questions about the bzrlib api?
[22:28] <mhall119> I want to be able to clear the revision history of a local branch
[22:28] <mhall119> basically I branch from a remote source, then I want to start with a clean revision history, but keep all the files that were under version control
[22:43] <glyph> mhall119: why bother with a plugin for that?  you can just 'bzr export; bzr init; bzr add; bzr commit'
[22:55] <mhall119> I'm not writing a plugin, just a cli program, and I wanted to use bzrlib instead of subprocess.call()