[00:01] <poolie> done!
[00:02] <poolie> low latency fwt
[00:02] <poolie> ftw*
[00:11] <poolie> igc: i commented - what do you think?
[00:16] <igc> poolie: can you explain more?
[00:17] <poolie> it seems unfortunate to me that the tests would need to mutate and then restore a library-wide variable
[00:17] <poolie> as opposed to just changing their instance of the tree
[00:17] <poolie> maybe i'm massively confused?
[00:18] <poolie> or apparently you're relying on python looking up the name both instance-wide and class-wide?
[00:19] <poolie> that works, but we really discourage it
[00:19] <poolie> it can be confusing or fragile
[00:19] <igc> poolie: none of that is new. content-filters are registered library-wide and that was the easiest way to test them
[00:19] <poolie> i don't see anything else accessing WorkingTree._content_filter_stack
[00:19] <poolie> only on particular instances
[00:20] <igc> poolie: in testing, I need fine control over when filtering is on vs off
[00:21] <igc> poolie: from memory I need to patch in at the class level ...
[00:21] <igc> because the tree is implicitly created by branching
[00:22] <lifeless> igc: filters are registered, but what about being enabled?
[00:22] <lifeless> igc: I mean, say I have two WorkingTree instances
[00:22] <lifeless> surely they don't have the same filter stack
[00:22] <lifeless> if one tree has eol conversion enabled and the other doesn't
[00:23] <igc> lifeless: we don't have per tree filtering
[00:23] <lifeless> I thought that that was all we had
[00:23] <poolie> igc, so it's a bit weird and likely to break eventually
[00:23] <poolie> i think at least you should add a comment there
[00:24] <igc> lifeless: we only have global rules (much to my frustration)
[00:24] <poolie> but it's not new code, so you don't need to clean it up to land this
[00:24] <poolie> therefore +1
[00:24] <poolie> hth
[00:24] <igc> poolie: it does. I'll submit the next patch after this one lands
[00:26] <igc> poolie: can you update the review? I'll add the comment to the tests as requested
[00:31] <poolie> k
[00:52] <lifeless> james_w: around?
[00:54] <lifeless> igc: I must say I'm confused as to why we have global filters only; I was sure we had agreed on an initial locations.conf/bazaar.conf based setup - which doesn't imply global library state at all
[00:56] <igc> lifeless: it never got off the ground. I tried a patch along those lines and the design didn't hold up. I can't remember all the details now
[00:58] <lifeless> ok
[02:01] <jelmer> johnf: hi
[02:01] <johnf> jelmer: howdy. Did you see my bzr check question?
[02:02] <jelmer> johnf: no
[02:02] <johnf> one sec
[02:02] <johnf> johnf: anyone know if there is a solution to this problem when running bzr check "reason: Parent not in inventory." It is from a branch that was originally branched from SVN
[02:04] <johnf> jelmer: ^
[02:04] <jelmer> johnf: sorry, haven't seen that before
[02:05] <jelmer> johnf: can you reproduce this somhow with a fresh import?
[02:06] <johnf> jelmer: problem is we moved on from using SVN as a backend. I suppose I could import and then apply all patches since
[02:06] <jelmer> johnf: Does reconcile fix it perhaps?
[02:07] <johnf> let me try that
[02:08] <tedg> igc: So I can't get the svn-import to work.  How did you run the svn-import?  (what parameters)
[02:09] <tedg> igc: I've been figuring it was me, but I'm getting ready to blame bzr-svn :)
[02:09] <johnf> jelmer: nope http://pastie.org/672762
[02:10] <johnf> tedg: Initially I didn't do an import since we where backing onto svn. I branched it
[02:10] <igc> tedg: I can't remember. Let me try again and see if that jolts my memory ...
[02:11] <tedg> johnf: ?  I'm not sure what you're saying.  I'm trying to do an import.
[02:11] <arjenAU> ahoy oh gurus of bzr land, I come to you in a quest for enlightenment
[02:11] <johnf> tedg: sorry thought you where referring to my problem. Just ignoe me
[02:11] <arjenAU> oh hi igc
[02:12] <tedg> johnf: Ah, okay.  No problem :)
[02:12] <igc> hi arjenAU
[02:12] <arjenAU> so, I have a branch with 2 extra local revisions (committed) and 1 remote revision committed. so pull says branches have diverged. fine. so I merge from the remote branch and it says nothing to do. guh?
[02:12] <igc> tedg: I think I used bzr svn-import --all source dest
[02:13] <jelmer> johnf: You might want to do a clean import using a new version pof bzr-svn and then branch your new work into that
[02:13] <johnf> jelmer: sounds like a good idea
[02:13] <tedg> igc: Okay, let me try that.  I wasn't using --all, I thought you were grabbing one branch.
[02:13] <igc> tedg: which version of bzr abd bzr-svn do you have?
[02:13] <igc> and
[02:14] <igc> bzr plugins will tell you
[02:14] <igc> the bzr-svn version
[02:14] <johnf> arjenAU: what does bzr missing --theirs-only say?
[02:14] <tedg> igc: 1.0.0dev
[02:14] <jelmer> johnf: you'll want to use a new shared repository
[02:15] <arjenAU> johnf: that i'm missnig one rev.
[02:16] <johnf> arjenAU: does bzr status say you have merges pending?
[02:16] <arjenAU> nops
[02:16] <tedg> igc: That gets me to an exception: AssertionError: Unable to find direct lhs parent for <CachingRevisionMetadata for revision 7680, path tags/start/experimental ...
[02:16] <arjenAU> johnf: nop it seems cleanly committed on both ends, just diverged. so a merge should work I'd say.
[02:17] <johnf> arjenAU: ok if "bzr check" says everything is OK then I'm out of ideas and will hand over to a higher power :)
[02:17] <arjenAU> johnf: yep ok
[02:18] <igc> arjenAU: sounds weird ...
[02:18] <arjenAU> igc: hehe yea. running 2.0 on jaunty from ppa.
[02:19] <igc> arjenAU: here's what I'd do ...
[02:19] <arjenAU> igc: i possibly forgot something, just can't think of what. it look sfine just doesn't fly
[02:19] <arjenAU> ok listening
[02:19] <igc> grab a copy of the remote branch locally
[02:19] <igc> try merging from that copy into your branch
[02:19] <arjenAU> ahye and pull merge. ok
[02:22] <igc> arjenAU: I recall some weirdness ages ago where the branch had a change but the working tree wasn't refreshed
[02:22] <igc> so merge got confused and said nothing to do
[02:22] <arjenAU> nothing to do still...
[02:23] <arjenAU> should I try merging the other way?
[02:23] <igc> arjenAU: one way to ensure the tree is in sync with the branch is to 'bzr revert', assuming you have no local changes
[02:24] <arjenAU> well I do have local changes is the ponit
[02:24] <arjenAU> but not uncommitted
[02:24] <igc> revert is safe if your local changes are committed
[02:24] <lifeless> arjenAU: run 'bzr revision-info' in your local branch
[02:24] <lifeless> and with the url of youre remote branch
[02:25] <lifeless> also pastebin 'bzr info' for both branches
[02:25] <arjenAU> url of remote branch where?
[02:25] <arjenAU> revision-info doesn't accept the bzr+ssh syntax
[02:26] <tedg> igc: Okay, it seems that appending part of the svn path helps.  Then it's not looking for the odd repository layout from the CVS import.  It's coping revisions now.  Which means my lap is getting hot from the laptop :)
[02:27] <igc> tedg: :-)
[02:27] <tedg> Oh my, bzr is using 1.5GB of RAM...
[02:28] <igc> tedg: trunk has lots of memory improvements thanks to jam
[02:28] <igc> tedg: if required, you can convert using that (safely)
[02:29] <tedg> I might have to... we'll see.  I only have 2GB physical.  If it hits swap, it'll never finish :)
[02:30] <tedg> Nope.  Error'd out :(
[02:31] <tedg> Hmm, why don't errors generate crash files?
[02:31] <igc> tedg: if you throw the error in a bzr-svn bug report, jelmer is pretty good at solving them
[02:32] <tedg> I can't imagine this error is very useful: ERROR: Must end write group before releasing write lock on CHKInventoryRepository
[02:32] <tedg> Without even a backtrace.
[02:33] <tedg> That's all I got.
[02:33] <igc> tedg: if you run with -Derror, you should see a backtrace
[02:33] <igc> tedg: though it's surprising you didn't get one anyway
[02:34] <arjenAU> lifeless: revision-info doesn't accept the bzr+ssh syntax
[02:35] <fullermd> arjenAU: You'd have to use the '-d' arg.
[02:43] <arjenAU> lifeless: http://pastebin.org/48867
[02:44] <fullermd> arjenAU: What branch are you merging?
[02:45] <arjenAU> fullermd: remote into local
[02:45] <fullermd> Yeah, but what's 'remote'?
[02:45] <arjenAU> the one with the url
[02:45] <fullermd> There are two URLs, and they're different.
[02:45] <arjenAU> oh both
[02:45] <arjenAU> bother sorry
[02:45] <arjenAU> hang on
[02:46] <fullermd> Are you sure you're missing'ing the same branch you're merge'ing?
[02:46] <arjenAU> indeed apparently not.
[02:46] <tedg> igc: Not enough memory to get the backtrace.  Tried to upgrade to nightly, but now bzr-svn won't work because of API version issues.  :(
[02:47] <tedg> Why can't this information be encoded in to the packaging so that it's known at install?
[02:47] <tedg> It's really annoying that bazaar breaks even when apt is happy.
[02:47] <arjenAU> fullermd: the plot thicken
[02:47] <arjenAU> +s
[02:48] <SamB_XP_> tedg: I'm going to blame jelmer ;-P
[02:48] <lifeless> tedg: what ppa are you using?
[02:48] <SamB_XP_> if only for not setting the PPA managers straight
[02:48] <igc> tedg: ok, I have plenty of memory here. I'll try doing some of the conversion now
[02:48] <tedg> lifeless:  http://ppa.launchpad.net/bzr-nightly-ppa/ubuntu
[02:49] <lifeless> so, nightly friction
[02:49] <tedg> igc: This is what works for me: $ bzr svn-import --all -Derror inkscape.svn/inkscape inkscape.bzr
[02:49] <tedg> igc: Well, where "works" is generates an out of memory error :)
[02:49] <arjenAU> ok fullermd lifeless igc the prob came from the fact that we have push, parent and submit branch urls... so it gets confusing.
[02:50] <tedg> lifeless: Sure, but apt should stop bzr from installing then.  Or atleast warn me that the others need to be removed.
[02:51] <lifeless> tedg: nightlies dont have the right metadata
[02:52] <lifeless> tedg: they are pulling trunk, and there isn't a connection between trunk commits changing deps and the apt packaging
[02:52] <lifeless> tedg: same issue that bobthebuilder recipes need updating for
[02:54] <tedg> lifeless: yes, but it seems that the API version is related to the bzr version.  So it would seem that the bzr-svn package in Karmic should have a depends on bzr (= 2.0.0) if it's going to only request and deal with a specific version.
[02:54] <lifeless> tedg: no, the API version is like a soname, it changes when we break things, not when a release is done per se
[02:55] <lifeless> tedg: what does dpkg -l bzr
[02:55] <lifeless> show?
[02:55] <tedg> bzr            2.0.0+4766+129
[02:55] <lifeless> so
[02:55] <lifeless> dpkg thinks that you still have bzr 2.0.0 on your system
[02:55] <lifeless> as I said, metadata mismatch
[02:57] <SamB_XP_> lifeless: perhaps this metadata should be derived from something within the bzr tree somehow ?
[02:57] <lifeless> SamB_XP_: perhaps
[02:57] <SamB_XP_> like, maybe the API version ;-P
[02:57] <lifeless> tedg: you shouldn't use nightlies unless you're willing to deal with such mismatches, which will occur
[02:58] <tedg> lifeless: Believe me, I don't want to use nightlies :)
[02:58] <lifeless> so why are you?
[02:58] <tedg> lifeless: Because apparently they have memory fixes in them, that might bring down the memory of my import.
[02:58] <tedg> As apparently I don't have enough physical memory.
[02:59] <SamB_XP_> tedg: why are you using physical memory anyway ?
[02:59] <lifeless> there are significant memory improvements in trunk, thats true
[02:59] <lifeless> however igc is doing it now, right?:)
[02:59] <tedg> lifeless: And I'm uninstalling the nightly as we speak :)
[02:59] <igc> lifeless, tedg: rsynch'ing the inkscape svn repo as we speak
[03:03] <tedg> igc: If you could casually watch the memory usage as you're running, that'd be helpful.  If I'm close, I'd like to get this working as we're going to have to update with the final release hopefully in a couple days as well as pulling other sub-repos out of the SVN tree.
[03:03] <tedg> (website, docs, etc.)
[03:03] <igc> tedg: sure
[03:06] <igc> bbiab
[03:38]  * igc lunch
[04:01] <MTecknology> So.. loggerhead
[04:01] <MTecknology> better installed from bzr instead of apt?
[04:05] <spiv> MTecknology: hmm, I've never tried installing it :)
[04:07] <MTecknology> spiv: I'm trying to remember this and from what I recall from a year ago you run it and you don't really have control over what it listens to; I want it to run throguh apache..
[04:08] <spiv> I'm pretty sure you can control that.
[04:08] <MTecknology> ok, cool
[04:08] <spiv> See the loggerhead.conf.example
[04:09] <spiv> (http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/annotate/head%3A/loggerhead.conf.example)
[04:09] <MTecknology> thanks :)
[04:09] <spiv> The README has a section on serving it from behind apache, too.
[04:11] <MTecknology> OH!
[04:11] <MTecknology> I remember this now... apache proxy
[04:21] <MTecknology> spiv: what's with the .1 files in there?
[04:22] <MTecknology> like serve-branches.1
[04:22] <spiv> No idea.
[04:22] <mwhudson_> man pages!
[04:22] <spiv> Oh, man pages.
[04:23] <MTecknology> mwhudson_: the readme file?
[04:25] <mwhudson_> MTecknology: no
[04:25] <MTecknology> mwhudson_: install from repos and use the man page then..?
[04:26] <mwhudson_> MTecknology: i may be missing bits of this conversation, i was updating the firmware on my router
[04:28] <MTecknology> mwhudson_: I'm using the head branch of loggerhead and I'm going to have it proxy throuch apache and hopefully make apache use system accounts to log into that (force ssl of course)
[04:28] <MTecknology> mwhudson_: I was just wondering whta th .1 files were for in the branch
[04:28] <mwhudson_> MTecknology: the .1 files are source for the man pages (as in the unix comand 'man')
[04:28] <MTecknology> oh
[04:28] <MTecknology> mwhudson_: OH!
[04:28] <MTecknology> LOL
[04:29] <MTecknology> that's just funny now - I thought you were telling me to look at the man pages
[04:29] <mwhudson_> aaa
[04:29] <mwhudson_> sorry :)
[04:29] <MTecknology> :P
[04:30] <MTecknology> now make ssh work for this other guy I'm trying to help. I'm looking on the server and the permissions are perfect - just not logging in using the key
[05:21] <poolie> hi spiv?
[06:19] <MTecknology> How can I remove loggerhead? I ran the setup install but I'd rather run it right from teh directory..
[06:25] <MTecknology> loggerhead is acting like it's running correctly, but it seems to be lying
[06:43] <MTecknology> I'm getting this error now... I'm getting close :) Unsupported configuration: PasteDeploy not available, but loggerhead appears to be behind a proxy.
[06:45] <MTecknology> YES!
[06:47] <MTecknology> Now.... Is there any way you guys can have loggerhead show commit messages the way launchpad does on the project page?
[06:48] <MTecknology> I know you can view a revision; it just won't let you see all the commit messages in one nice pretty list
[07:10] <MTecknology> hurray....
[07:11] <MTecknology> permission errors
[07:13] <MTecknology> I really with there was an easier way to manage permissions - like the ability to manage permissions over http the way svn lets you...
[07:13] <MTecknology> I'm going to need to look at how launchpad does it because this isn't working....
[07:14] <fullermd> Permissions...   pah.  Yet another pointless attempt to solve a social problem via technical means...
[07:15] <fullermd> You can totally skip worrying about that sort of thing if you just kill off everybody who isn't authorized to access $WHATEVER.
[07:15] <MTecknology> or can i... use apache permissions to manage directory access (which is already there) and run bzr over http
[07:15] <MTecknology> fullermd: hm?
[07:16] <fullermd> It's uncanny how many problems can be solved by the judicious application of mass murder.
[07:16] <MTecknology> fullermd: The group is staying the same because I set the 'sticky bit' on the bzr directory. But that doesn't work because the sticky bit doesn't retain owner
[07:16] <AfC> fullermd: there's good money in that line of work, death-as-enforcement-of-filesystem-permisions
[07:17] <MTecknology> I like the idea of being able to trust all developers.....
[07:17] <fullermd> chmod u+leadpipe colonelmustard.
[07:18] <fullermd> I suspect you're setting the setgid bit, not the sticky bit...
[07:18] <MTecknology> I'd like to manage permissions the same way launchpad does but.... that would be hard
[07:19] <MTecknology> drwsrws--t 5 shane kalliki-suite 4096 2009-10-27 23:56 .bzr
[07:19] <fullermd> The sticky bit is unlikely to do anything useful for you there (and the setuid probably does nothing at all)
[07:20] <awilkins> bzr-migration-docs : not building properly for me ... it leaves the body of the text out of the html page ; what's wrong? Wrong version in my toolchain?
[07:21] <fullermd> Actually, ISTM I've heard of some combinations of VFS patches and config files on some OSen that cause the FS to force user ownership based on setuid dirs...
[07:21] <fullermd> But that's pretty niche stuff.
[07:22] <MTecknology> I was going for simple
[07:22] <MTecknology> I was hoping I set permissions once and it just works
[07:22] <AfC> I'm not sure why sticky group isn't working for you, though
[07:22] <MTecknology> but since you're right that setuid isn't doing jack.....
[07:23] <AfC> that's what we use
[07:23] <MTecknology> the gid is being retained
[07:23] <MTecknology> just not the uid
[07:23] <fullermd> AfC: On a current project, I've actually roped my neighbor into doing some work; by a weird coincidence, she happens to have some experience we can use on this project.
[07:24] <fullermd> In giving her access to some files last week, she was all asking me what sort of legal blahblah I wanted her to sign about not touching unrelated stuff etc.
[07:24] <AfC> shared repository is mode 02775 group "bzr" and we make sure users' umask is 0022 and that they're all in group "bzr". Works like a charm
[07:24] <fullermd> I just gave her this quizzical look, and said "I know where you live."
[07:24] <AfC> heh
[07:25] <AfC> fullermd: yes, exactly. You don't need elaborate legal structures when the practical consequences are self-evident.
[07:25] <MTecknology> AfC: can anyone at all touch any repo?
[07:25] <fullermd> Don't need to worry about umask [for commits in an existing repo], since bzr will handle retaining those perms itself based on...  uh...   not entirely clear.  Either .bzr or .bzr/repository or .bzr/repository/packs...
[07:26] <AfC> MTecknology: you mean any Branch in that Repository? Yes. But it is of course plain courtesy not to mess with other peoples' branches
[07:26] <AfC> MTecknology: without explicit permission
[07:26] <AfC> MTecknology: otherwise, fullermd's "I know where you live" kicks in quite admirably
[07:26] <AfC> MTecknology: not to mention `userdel offender`
[07:26] <vila> hi all
[07:27] <MTecknology> AfC: I was referring to the repository, like /bzr/repo1 /bzr/repo2
[07:27] <AfC> fullermd: not sure I'd trust that, even if I believed it, but good to know. Thanks.
[07:27] <fullermd> There's no problem so big it can't be solved by killing the user off, removing their account, and reporting their REAL income to Internal Revenue.
[07:27]  * fullermd waves at vila.
[07:28] <MTecknology> AfC: Each repo will have a different group, but I want the uid to always be the same
[07:28] <AfC> MTecknology: in this case the repository in question is /bzr/java-gnome/hackers/...
[07:28] <MTecknology> AfC: once uid is retained when a new file is created, I'll be happy and set
[07:28] <fullermd> MTecknology: You're going to have an...  'interesting' time sweet-talking a *nix system into letting you create a file as a user other than yourself...
[07:29] <AfC> ie /bzr/java-gnome/hackers/andrew/enchant-updates and /bzr/java-gnome/hackers/guillaume/bug-455532-fixes
[07:30] <MTecknology> fullermd: this kinda sucks - I need to keep this fine grained because I'll have to deal with people handling touchy info that I won't be able to fight back if they screw around
[07:30]  * fullermd . o O ( cp /bin/sh /tmp/sh ; chmod +s /tmp/sh ; chown root /tmp/sh ; <fun> )
[07:30] <lifeless> MTecknology: bzr doesn't edit files, why do you need the uid kept?
[07:30] <MTecknology> fullermd: My only other idea is to run it over apache
[07:30] <MTecknology> lifeless: when a user adds data, the next user can't pull it
[07:30] <lifeless> MTecknology: I think what you what is umask, not super special uid magic
[07:30] <fullermd> The only way to get the files owned by a single uid is to only have them accessed by a [bzr] process running as that uid.
[07:30] <lifeless> MTecknology: uhm, details please
[07:31] <MTecknology> lifeless: h on
[07:31] <MTecknology> http://paste.ubuntu.com/303413/
[07:31] <MTecknology> actually... I'm not sure if that is a permission issue anymore
[07:33] <MTecknology> umask helped a lot
[07:35] <MTecknology> lifeless: for something like this, do you think running the permissions over http might be better?
[07:35] <MTecknology> or not really
[07:35] <lifeless> MTecknology: well, over http all your users would be the same user
[07:36] <lifeless> so have identical access and so forth
[07:36]  * igc dinner
[07:36] <lifeless> MTecknology: that error is on push, in insert_stream
[07:36] <lifeless> check that the upload directory (.bzr/repository/upload) has group +w
[07:36] <MTecknology> lifeless: except that I could make each user authenticate as themselves
[07:36] <lifeless> you'll want chmod -R g+w .bzr
[07:36] <MTecknology> nothing in there
[07:36] <lifeless> MTecknology: then it would be the same as ssh, wouldn't it?
[07:37] <MTecknology> except same user/group on the system
[07:37] <lifeless> MTecknology: permissions, not content ;)
[07:37] <MTecknology> drwsrws--t 2 root kalliki-suite 4096 2009-10-28 02:33 upload
[07:37] <lifeless> MTecknology: thats what I said though, 'all your users would be the same user'
[07:37] <MTecknology> why's that?
[07:37] <lifeless> MTecknology: so, is the user getting the error a member of kalliki-suite
[07:37] <MTecknology> yup
[07:38] <lifeless> ok
[07:38] <lifeless> check their ~/.bzr.log
[07:38] <lifeless> may have more detail
[07:39] <MTecknology> http://paste.ubuntu.com/303417/
[07:40] <MTecknology> oh... it was svn that I remember being able to handle granular permissions
[07:40] <poolie> spiv: nice mail re imports, thanks!
[07:40] <lifeless> MTecknology: on the server, the .bzr.log
[07:41] <MTecknology> http://paste.ubuntu.com/303419/
[07:42] <MTecknology> almost 3am again
[07:42] <MTecknology> I really never can just sit down and hammer something out quick
[07:42] <MTecknology> Isn't there any documentation to handling groups that access bzr repos?
[07:42] <lifeless> MTecknology: its permissions
[07:42] <MTecknology> I'd have no issues starting fresh
[07:42] <lifeless> chmod group write access within the repo
[07:43] <MTecknology> g+w?
[07:43] <lifeless> yes
[07:43] <MTecknology> same thing
[07:44] <MTecknology> it was already that way :(
[07:44] <lifeless> ls -lR .bzr/repository
[07:44] <lifeless> pastebin that
[07:45] <MTecknology> http://paste.ubuntu.com/303421/
[07:46] <AfC> root?
[07:46] <MTecknology> oh...
[07:47] <lifeless> MTecknology: and the directory itself
[07:47] <lifeless> MTecknology: ls -ld .bzr/repository
[07:48] <MTecknology> drwsrws--t 7 root kalliki-suite 4096 2009-10-28 02:06 bzr/suite-dev/.bzr/repository/
[07:50] <lifeless> ok
[07:50] <lifeless> so
[07:50] <lifeless> -rw-rwx--- 1 michael kalliki-suite  181 2009-10-28 02:31 3c29bfe02aba60925bb1e0d04349b994.rix.1864.carpo.jr7tsonnb7.tmp
[07:50] <lifeless> is noise from one of the errors
[07:51] <lifeless> you can see that its an index that your root user has already written
[07:51] <MTecknology> lifeless: can I just delete it?
[07:52] <lifeless> MTecknology: hell no
[07:52] <MTecknology> ok
[07:52] <lifeless> so, you definitely don't want the s bit set
[07:52] <lifeless> thats setuid
[07:53] <MTecknology> u-s
[07:53] <MTecknology> or ug-s ?
[07:53] <lifeless> on files
[07:53] <lifeless> on dirs +s is ok
[07:54] <lifeless> the t bit is what is making you get errors
[07:54] <MTecknology> oh
[07:54] <lifeless> "For directories, it prevents unprivi‐
[07:54] <lifeless>        leged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag
[07:54] <lifeless>        for  the  directory"
[07:54] <lifeless> (see man chmod)
[07:54] <MTecknology> that was the problem.........
[07:55] <lifeless> yes
[07:55] <MTecknology> so, when a different user tries to commit, will there be an issue?
[07:55] <MTecknology> if one user commits a brand spankin' new repo and another user tries to make a commit over it
[07:57] <MTecknology> I suppose as long as the group is retained
[07:57] <MTecknology> lifeless: thanks - I love you
[08:02] <poolie> lifeless: good night
[08:03] <lifeless> niht poolie
[11:01] <bialix> hi all
[11:40] <jml> Number of times I have run pqm-submit, got an "public branch out of date" error and _not_ wanted to immediately push to the public branch:
[11:40] <jml> Zero.
[11:42] <spiv> jml: shell scripting to the rescue! ;)
[11:43] <spiv> jml: btw,
[11:43] <SamB_XP> spiv: how is shell scripting going to help? you can't integrate that into bzr very easily ...
[11:43] <spiv> jml: https://code.edge.launchpad.net/~spiv/bzr-pqm/non-local-submission/+merge/13333
[11:43] <spiv> SamB_XP: it has while loops, bzr has exit codes, ta da!
[11:44] <spiv> SamB_XP: (also, note the wink...)
[11:45] <SamB_XP> but it's not an 0.6 wink ...
[11:46] <spiv> Indeed.  Perhaps I should segment my eyelids...
[11:46] <spiv> Until then, I think I'll stick with whole winks.
[11:48] <jml> spiv, I notice that that patch doesn't change any tests
[11:49] <spiv> jml: true, and I didn't even try running them.  I just bashed it into shape enough to solve my immediate problem.
[11:50] <jml> spiv, heh :)
[11:50] <spiv> (Which was there were a handful of things in bzr's review queue ready to land that I wanted to send to PQM without mucking about... I guess hacking on bzr-pqm means I failed ;)
[11:51] <spiv> I expect the next person (possibly me) that needs this will bash on it again, hopefully touching tests :)
[11:53] <jml> spiv, I've reviewed your patch, fwiw.
[11:54] <spiv> jml: heh, ta
[11:55] <spiv> Wow, I'd already forgotten most of this patch :)
[11:56] <spiv> I really should extract the config improvements, they'd be handy for writing some kinds of hooks I think.
[11:57] <spiv> Anyway,
[11:57] <spiv> g'night
[12:14] <Bear10> When does bazaar lock files?
[14:14] <vila> jam: ping
[14:15] <jam> morning vila
[14:15] <vila> mornign jam !
[14:21] <awilkins> Mmmm. Morning jam. On toast.
[15:22] <matkor> where is doc explaining what is needed when migrating from 1.x to 2.x ? And what are gains (except being in supported version), and potential pitfalls ? TIA
[15:29] <Peng_> matkor: http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html
[15:30] <Peng_> matkor: You mean upgrading your bzr install or your files?
[15:32] <matkor> Peng_: Yes, thank you
[16:52] <faheem> hi. was running bzr upgrade on the mysql repos from lp. been running overnight and is consuming 1.6G memory. is this normal?
[17:01] <cjwatson> how do I find out what version of bzr is running on a remote smart server?
[17:01] <cjwatson> I don't have shell access, but do have bzr+ssh access
[17:05] <cjwatson> never mind, hacked bzrlib to tell me :-)
[17:07] <beuno-lunch> faheem, it is
[17:07] <beuno-lunch> if it fails, maybe we can help you and upgrade it in the datacenter
[18:35] <faheem> beuno: ok
[18:36] <faheem> thanks
[18:38] <faheem> i'm not clear what this bzr upgrade is for, though. can someone clarify?
[18:38] <faheem> i'm using bzr 2.0.1. just bzr branched mysql repos from lp
[18:39] <faheem> bzr: ERROR: Views are not supported by <WorkingTree4 of /tmp/mysql-server>; use 'bzr upgrade' to change your tree to a later format.
[18:40] <faheem> that's the error message i get
[18:40] <faheem> i think i was trying to do bzr view or some such
[18:47]  * awilkins has never used `bzr view` and only just learned of it's existence
[18:48] <awilkins> Looks like it's the bzr answer to the "staging area" in git
[18:48] <awilkins> Or something like it
[18:49] <awilkins> faheem: It may be that `view` requires an experimental working tree format
[18:52] <awilkins> But it seems to work on Working Tree Format 6
[19:04] <igc> morning
[19:05] <igc> awilkins: views will work in 2a
[19:05] <awilkins> Morning Ian
[19:05] <igc> awilkins: it's a bit rough around the edges though - some edge cases don't work frm memory
[19:06] <igc> e.g. shelve?
[19:06] <faheem> yes, but i'm not sure from what to what the upgrade is. it's not very explicit
[19:06] <faheem> i assume there are repos formats?
[19:06] <igc> awilkins: for simple stuff, it should be fine
[19:06] <awilkins> faheem: Ah, that's an upgrade of repository and working tree to the newer format. For MySQL it could take a while....
[19:07] <igc> faheem: MySQL are upgrading soon I believe
[19:07] <igc> faheem: if you branch in bzr, it keep the source format
[19:07] <igc> keeps
[19:07] <faheem> awilkins: i think it has been running overnight.
[19:07] <faheem> looks relatively close to completion
[19:08] <faheem> how many different active repos formats does bzr have?
[19:08] <awilkins> igc: Looking at the VSS converters I think vss2svn is clearly the best of the bunch... all the ones that depend on SS.exe are hobbled by the privacy of much of the code in the stack
[19:08] <faheem> is bzr view a builtin?
[19:08] <igc> faheem: there's only 1 default at a time
[19:08] <awilkins> igc: It's come on a lot since I last used it - full rewrite :-)
[19:08] <faheem> i recompiled on debian lenny with unstable sources
[19:09] <igc> faheem: for bzr 1.x, it was "pack-0.92"; for bzr 2.x, it's 2a
[19:09] <faheem> didn't ask me for anything for viewing stuff
[19:09] <igc> faheem: bzr view is builtin, but only supported on 2a formats
[19:09] <faheem> igc: how many of these are supporting wrt to conversion?
[19:09] <awilkins> faheem: view is native ; but it's new to me, I've never really had a need for it
[19:09] <igc> faheem: you can forward convert from pack-0.92 to 2a but not go back the other way
[19:10] <faheem> igc, awilkins: i see
[19:10] <faheem> so two formats?
[19:10] <igc> faheem: there were additional formats released over the 1x timeframe but they never became the default
[19:11] <faheem> igc: what happens if a repos is using them?
[19:11] <faheem> i mean wrt conversion?
[19:11] <awilkins> faheem: If your local repository is a different format, it converts revisions on the fly
[19:11] <igc> faheem: and it was messy - some had "rich roots" as needed by bzr-svn while others didin't
[19:11] <awilkins> faheem: This won't work backwards from 2a to 0.92 though
[19:12] <igc> faheem: 2a fixes that mess - everything is "rich root" from now on
[19:12] <awilkins> 2a is a rich-root format, 0.92 is not
[19:12] <faheem>  awilkins,  igc : i see. thanks.
[19:12] <faheem> so you are stablizing on the 2a format?
[19:12] <faheem> any further repos format changes anticipated?
[19:13] <awilkins> On past history, you can expect more optional formats that add performance or features
[19:13] <faheem> is there a history of these changes on the net? just curious.
[19:13] <awilkins> In newer versions of Bazaar... I don't think they'll be backported to 2.0.x series releases
[19:14] <awilkins> faheem: `bzr help formats`
[19:14] <faheem>  awilkins : great! thanks.
[19:15] <awilkins> Looks like that help doc needs a bit of tickling, it's out of date WRT to 2.0.x
[19:18] <igc> faheem: we may introduce another format in the future but that won't happen for at least 12 months
[19:19] <awilkins> what, no 2.1-super-fast-omg-ponies  ??  :P
[19:19] <igc> faheem: if we do, it will be to add new features (and there will be some performance/storage benefits most likely as well)
[19:19] <igc> awilkins: no, not new format in 2.1
[19:20] <awilkins> igc: I think the only thing I really want to see improve right now is nested tree support and packing times
[19:20] <igc> awilkins: nothing public at least - there may be some evolution of the "development" one
[19:21] <awilkins> bzr pack is significantly slower on 2a than the equivalent 1.14-rich-root for a fairly minimal space gain in most of my own cases.
[19:21] <igc> awilkins: can you report a bug with the figures re pack?
[19:22] <igc> awilkins: jam or lifeless will take a look most likely
[19:24] <jam> awilkins: 'bzr pack' on 1.14 rich-root probably had 0 space gains
[19:24] <jam> 'bzr pack' in 2a has huge wins, except we recompress on the fly, and recompress after a conversion
[19:24] <jam> so all the gains have already been 'one'
[19:24] <jam> 'won'
[19:25] <jam> if you give it a couple months, you could see more significant changes
[19:25] <jam> though we certainly could have a "bzr pack --lite" which uses our current 'recompress-on-the-fly' code
[19:26] <awilkins> jam: I think I saw about 100MB -ve delta out of 800M repo size which is definitely smaller, but the packs take a lot longer
[19:26] <jam> (recompress only groups that don't look compressed)
[19:26] <jam> awilkins: well as we are actually doing real work in 2a, I expect the time to go up :)
[19:26] <jam> 'bzr pack' is ~ git repack -a -f
[19:27] <awilkins> jam: It was enough to provoke me to split the repo into mutliple repos (one for each tree) instead of hosting all the trees in a single repository
[19:27] <jam> awilkins: why the need to force repack?
[19:27] <awilkins> jam: Not just forced repacks, autopacks too
[19:27] <jam> (as in, it shouldn't be something that you really need to do)
[19:27] <awilkins> jam: They're noticeably a lot longer
[19:27] <jam> autopacks would be slower than before, but not something I would expect to be noticeable except on major boundaries
[19:28] <jam> the 1 time I've seen it is when I rolled over 1k revisions to repack
[19:28] <faheem> who is the current bzr lead developer? is martin pool still working on it?
[19:28] <awilkins> jam: I might be an opposite corner case ; my trees are not that deep, but they are quite wide in many cases
[19:28] <jam> faheem: poolie is our leader, yes, though he doesn't do quite as much coding as he used to
[19:29] <awilkins> Some of those trees have 1.9GB of text files in them :-)
[19:30] <jam> awilkins: sure, but how much 'churn' do you have in that 2GB?
[19:30] <awilkins> jam: Oh, not a lot, except when a new folder with 150MB of text gets added... but just it's presence in the same repo as other trees seemed to slow down autopacks
[19:31] <awilkins> I know this is all wishywashy with no metrics, but it's an assertion based on 1.14-rich-root autopack times never bothering me enough to go "grr"... and 2a does on occasion.
[19:32] <gioele> will 2.1 be the next stable version or are you adopting a odd-dev/even-stable numbering scheme?
[19:32] <awilkins> Right, time to eat some pizza.... sorry to duck out, back later
[19:32] <jam> gioele: 2.1 will be next stable, 2.1.0b1 is the 'unstable' new release
[19:32] <jam> followed by b2, b3? rc1 then 2.1.0 final
[19:33] <gioele> time based betas?
[19:33] <jam> gioele: yeah, monthly releases
[19:33] <gioele> I see
[19:33] <jam> same as before, we are just labeling them differently now that we hit 2.0
[19:33] <jam> we'll also be doing ~ monthly 2.0.x releases
[19:33] <jam> with only bugfixes
[19:34] <gioele> That seems a very good thing to do. Suggests more stability than the 1.x cycle
[19:35] <gioele> another question: what is the correct way to generate the apidocs? pydoctor refuses to work and "make api-docs" seems no longer supported
[19:36] <jam> gioele: use epydoc < 3.0?
[19:36] <jam> ISTR you filing a bug report about epydoc 3.0 not working
[19:36] <jam> :)
[19:37] <jam> I would guess 'make api-docs' is supposed to be the way to do it, and we just need a patch to ensure compatibility with newer epydoc versions
[19:37] <gioele> jam: that is available only on dapper
[19:37] <mwhudson> gioele: in what way is pydoctor barfing?
[19:38] <jam> ISTR we had to monkeypatch some doc generation tools because they didn't handle some of our formatting
[19:38] <jam> we had a 'foo-bar' in one of our keys that wasn't liked
[19:41] <gioele> mwhudson: I created this .cfg following other bzr plugins: http://pastebin.com/d3c084a79
[19:41] <gioele> then pydoctor quits with Exception: you must pass a package directory to preprocessDirectory
[19:42] <mwhudson> gioele: you don't want the "prependedpackage" bit for bzrlib itself
[19:42] <gioele> mwhudson: even without it complains in the same way
[19:43] <mwhudson> gioele: what commandline are you using?
[19:43] <jam> mwhudson: would it be "packages: bzrlib" and no prependpackage?
[19:43] <gioele> mwhudson: pydoctor -c bzr.cfg --make-html
[19:44] <mwhudson> jam: ah, yes, probably
[19:44] <gioele> jam: yes, that seems to work
[19:44] <mwhudson> ah man, i need to find some time to give pydoctor some love :/
[19:45] <jam> mwhudson: you have 10 minutes starting....
[19:45] <jam> now
[19:45] <jam> :)
[19:48] <gioele> re
[19:51] <mwhudson> dear me, i'd forgotten how slow the rest parser is
[19:51] <mwhudson> "1320/3756 pages written"
[19:54] <gioele> may I suggest this tiny patch to Makefile: http://pastebin.com/d37a5e57a ?
[20:32] <meoblast001> wtf does this mean "This transport does not update the working tree of: bzr+ssh://meoblast@bazaar.launchpad.net/~mysticgalaxies/amethyst-mm/libaaf/. See 'bzr help working-trees' for more information."
[20:39] <luks> meoblast001: that the remote working tree on the server will be out-of-date
[20:39] <luks> but in the case of launchpad, I don't know :)
[20:39] <meoblast001> luks: i just downgraded the new tree to 1.9
[21:25] <nyu> while importing svn into a pristine 1.14-rich-root using bzr 2.0.1: http://pastebin.com/m2f1454f3
[21:25] <poolie> hi jam
[21:25] <nyu> and bzr-svn 1.0.0
[21:25] <jam> hey poolie
[21:31] <thumper> poolie: can I have a call with you soonish?
[21:31] <jam> igc: are you around?
[21:34] <poolie> thumper, yes, i was just going to suggest that
[21:34] <poolie> now works for me
[21:54] <Peng_> jam: Congrats on the releases. :)
[21:56] <jam> yeah, finally
[21:56] <jam> only took me 2 weeks
[21:58] <Peng_> jam: The CHK index thing sounds awesome too. Have I mentioned that I love you? :D
[22:06] <jam> and now that 2.1.0b2 was supposed to be released yesterday...
[22:06] <Peng_> Heh, oops.
[22:07] <Peng_> How current is the code in 2.1.0b1? Is it mostly 2 weeks old?
[22:09] <jam> Peng_: 2.1.0b1 was 'cut' 2 weeks ago
[22:09] <jam> so no changes since then
[22:09] <Peng_> Ah.
[22:09] <jam> just had to get the installers built
[22:09] <jam> and announcements made
[22:09] <jam> 2.1.0b2 will include the StaticTuple stuff
[22:09] <Peng_> When are you going to do 2.1.0b2, then?
[22:10] <jam> I posted to the list
[22:10] <jam> We'll find out
[22:10] <jam> 2.1.0b1 was already 2-weeks behind when it went gold, so it is officially 1 month late
[22:10] <jam> so either we'll release 2.1.0b2 right away to catch up, or wait a month
[22:10] <jam> anyway /me gone
[22:10] <Peng_> jam: See you later. :)
[22:13] <Stavros> hello
[22:13] <Stavros> has anyone managed to push to github with bzr-git?
[22:17] <Stavros> anyone?
[22:20] <Stavros> jelmer?
[22:22] <hno> Download link for 2.1.0b1 is wrong on the home page.. links to /2.0/ instead of /2.1/..
[22:26] <Stavros> is bzr-git also supposed to be able to commit to git branches?
[22:27] <lifeless> jam: do you think chk specific index is a big enough win to be doing another repo format?
[22:27] <lifeless> jam: or are you just tracking down all the memory inefficiencies as aggressively as possible?
[22:27] <lifeless> Stavros: I believe so
[22:28] <Stavros> lifeless: turns out i have to do git+ssh, but then it can't find the repo :/
[22:28] <lifeless> Stavros: the path is from /, not ~
[22:29] <Stavros> oh good, it works
[22:29] <Stavros> what do you mean?
[22:29] <Stavros> oh right
[22:29] <Stavros> so /Stavros instead of :stavro
[22:29] <Stavros> that's how it worked, thanks
[22:29] <Peng_> hno: Eh. I'll send a merge proposal, unless someone else gets to it first.
[22:38] <Peng_> lifeless: ping
[22:38] <lifeless> Peng_: ?
[22:40] <Peng_> lifeless: I'm being pushy, but if you have rights to the website, could you land a trivial patch that fixes a broken link on the homepage? It's kind of bad. :\ https://code.edge.launchpad.net/~mnordhoff/bzr-website/2.1.0b1-link/+merge/14121
[22:40] <lifeless> I'm not entirely sure where the new site is deployed to
[22:40] <lifeless> poolie: ^
[22:41] <hno> heh, not every day I stir up this much over a single digit..
[22:41] <lifeless> Peng_: it would be good if you can also submit a merge to update the docs to note that:
[22:41] <lifeless>  - releasing requires access to deploy a new website
[22:41] <Peng_> hno: :D
[22:41] <lifeless>  - the release manager needs to do this
[22:41] <Peng_> Eh.
[22:41]  * lifeless loathes static websites
[22:42] <lifeless> Peng_: have I misunderstood whats wrong?
[22:42] <Peng_> Yeah, me too. I don't have an anti-static wrist strap.  (Sorry, that was terrible.)
[22:42] <Peng_> lifeless: No.
[22:42] <Peng_> Well, the website *was* deployed. There was just a typo.
[22:42] <hno> hi lifeless btw
[22:42] <lifeless> ok
[22:42] <lifeless> hi hno :)
[22:42] <poolie> you just need to merge it to the branch
[22:43] <poolie> to the bzr-website trunk
[22:43] <poolie> nothing else is required
[22:43] <lifeless> oh ok
[22:43] <lifeless> thats good
[22:43] <poolie> patches to make it dynamic welcome ;)
[22:43] <Peng_> releasing.txt already mentions it:
[22:43] <Peng_> #. Announce on the `Bazaar website <http://bazaar-vcs.org/>`_. This page is edited via the lp:bzr-website branch. (Changes pushed to this branch are refreshed by a cron job on escudero.)
[22:43] <lifeless> Peng_: are you able to push to the trunk ?
[22:44] <lifeless> (and if not, why not :P)
[22:44] <Peng_> lifeless: I'm not a member of ~bzr.
[22:44] <lifeless> hmm, we should fix that
[22:44] <lifeless> nevertheless
[22:45] <Peng_> (That was three lines on my clipboard. How did it get magically converted into one nicely-formatted line?)
[22:45] <Peng_> lifeless: Well, I wouldn't mind joining. I never thought about it before.
[22:48] <lifeless> your branch is pushed
[22:48] <Peng_> lifeless: <3
[22:48] <lifeless> and you should join, I think.
[22:48] <lifeless> poolie: ^
[22:48] <Peng_> I wonder how often the cronjob runs?
[22:52] <poolie> +1
[22:52] <poolie> lifeless: you already merged it to trunk?
[22:52] <poolie> roughly every hour
[22:52] <poolie> this is a great example of why it should be scripted btw
[22:52] <poolie> and why a wiki is no better
[22:53] <lifeless> poolie: yes
[22:54] <lifeless> I'm popping out to get my hair cut; mobile is on.
[23:16] <Peng_> Ah, the website was rebuilt at XX:50:03, which was immediately after the new revision was pushed.
[23:17] <Peng_> So the cronjob runs at least every 10 minutes.
[23:21] <hno> bzr+bzrtools 2.1.0b1 now packaged for Fedora-13/Rawhide.. and 2.0.1 pushed for Fedora-12 which means it should make it into the final release (2.0.0 currently there).
[23:24] <Peng_> Cool. :)
[23:43]  * igc out for a while