[00:01] done! [00:02] low latency fwt [00:02] ftw* [00:11] igc: i commented - what do you think? [00:16] poolie: can you explain more? [00:17] it seems unfortunate to me that the tests would need to mutate and then restore a library-wide variable [00:17] as opposed to just changing their instance of the tree [00:17] maybe i'm massively confused? [00:18] or apparently you're relying on python looking up the name both instance-wide and class-wide? [00:19] that works, but we really discourage it [00:19] it can be confusing or fragile [00:19] poolie: none of that is new. content-filters are registered library-wide and that was the easiest way to test them [00:19] i don't see anything else accessing WorkingTree._content_filter_stack [00:19] only on particular instances [00:20] poolie: in testing, I need fine control over when filtering is on vs off [00:21] poolie: from memory I need to patch in at the class level ... [00:21] because the tree is implicitly created by branching [00:22] igc: filters are registered, but what about being enabled? [00:22] igc: I mean, say I have two WorkingTree instances [00:22] surely they don't have the same filter stack [00:22] if one tree has eol conversion enabled and the other doesn't [00:23] lifeless: we don't have per tree filtering [00:23] I thought that that was all we had [00:23] igc, so it's a bit weird and likely to break eventually [00:23] i think at least you should add a comment there [00:24] lifeless: we only have global rules (much to my frustration) [00:24] but it's not new code, so you don't need to clean it up to land this [00:24] therefore +1 [00:24] hth [00:24] poolie: it does. I'll submit the next patch after this one lands [00:26] poolie: can you update the review? I'll add the comment to the tests as requested [00:31] k [00:52] james_w: around? [00:54] 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] 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 === KhaZ_ is now known as KhaZ [00:58] ok [02:01] johnf: hi [02:01] jelmer: howdy. Did you see my bzr check question? [02:02] johnf: no [02:02] one sec [02:02] 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] jelmer: ^ [02:04] johnf: sorry, haven't seen that before [02:05] johnf: can you reproduce this somhow with a fresh import? [02:06] 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] johnf: Does reconcile fix it perhaps? [02:07] let me try that [02:08] igc: So I can't get the svn-import to work. How did you run the svn-import? (what parameters) [02:09] igc: I've been figuring it was me, but I'm getting ready to blame bzr-svn :) [02:09] jelmer: nope http://pastie.org/672762 [02:10] tedg: Initially I didn't do an import since we where backing onto svn. I branched it [02:10] tedg: I can't remember. Let me try again and see if that jolts my memory ... [02:11] johnf: ? I'm not sure what you're saying. I'm trying to do an import. [02:11] ahoy oh gurus of bzr land, I come to you in a quest for enlightenment [02:11] tedg: sorry thought you where referring to my problem. Just ignoe me [02:11] oh hi igc [02:12] johnf: Ah, okay. No problem :) [02:12] hi arjenAU [02:12] 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] tedg: I think I used bzr svn-import --all source dest [02:13] 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] jelmer: sounds like a good idea [02:13] igc: Okay, let me try that. I wasn't using --all, I thought you were grabbing one branch. [02:13] tedg: which version of bzr abd bzr-svn do you have? [02:13] and [02:14] bzr plugins will tell you [02:14] the bzr-svn version [02:14] arjenAU: what does bzr missing --theirs-only say? [02:14] igc: 1.0.0dev [02:14] johnf: you'll want to use a new shared repository [02:15] johnf: that i'm missnig one rev. [02:16] arjenAU: does bzr status say you have merges pending? [02:16] nops [02:16] igc: That gets me to an exception: AssertionError: Unable to find direct lhs parent for johnf: nop it seems cleanly committed on both ends, just diverged. so a merge should work I'd say. [02:17] 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] johnf: yep ok [02:18] arjenAU: sounds weird ... [02:18] igc: hehe yea. running 2.0 on jaunty from ppa. [02:19] arjenAU: here's what I'd do ... [02:19] igc: i possibly forgot something, just can't think of what. it look sfine just doesn't fly [02:19] ok listening [02:19] grab a copy of the remote branch locally [02:19] try merging from that copy into your branch [02:19] ahye and pull merge. ok [02:22] arjenAU: I recall some weirdness ages ago where the branch had a change but the working tree wasn't refreshed [02:22] so merge got confused and said nothing to do [02:22] nothing to do still... [02:23] should I try merging the other way? [02:23] 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] well I do have local changes is the ponit [02:24] but not uncommitted [02:24] revert is safe if your local changes are committed [02:24] arjenAU: run 'bzr revision-info' in your local branch [02:24] and with the url of youre remote branch [02:25] also pastebin 'bzr info' for both branches [02:25] url of remote branch where? [02:25] revision-info doesn't accept the bzr+ssh syntax [02:26] 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] tedg: :-) [02:27] Oh my, bzr is using 1.5GB of RAM... [02:28] tedg: trunk has lots of memory improvements thanks to jam [02:28] tedg: if required, you can convert using that (safely) [02:29] I might have to... we'll see. I only have 2GB physical. If it hits swap, it'll never finish :) [02:30] Nope. Error'd out :( [02:31] Hmm, why don't errors generate crash files? [02:31] tedg: if you throw the error in a bzr-svn bug report, jelmer is pretty good at solving them [02:32] I can't imagine this error is very useful: ERROR: Must end write group before releasing write lock on CHKInventoryRepository [02:32] Without even a backtrace. [02:33] That's all I got. [02:33] tedg: if you run with -Derror, you should see a backtrace [02:33] tedg: though it's surprising you didn't get one anyway [02:34] lifeless: revision-info doesn't accept the bzr+ssh syntax [02:35] arjenAU: You'd have to use the '-d' arg. [02:43] lifeless: http://pastebin.org/48867 [02:44] arjenAU: What branch are you merging? [02:45] fullermd: remote into local [02:45] Yeah, but what's 'remote'? [02:45] the one with the url [02:45] There are two URLs, and they're different. [02:45] oh both [02:45] bother sorry [02:45] hang on [02:46] Are you sure you're missing'ing the same branch you're merge'ing? [02:46] indeed apparently not. [02:46] 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] Why can't this information be encoded in to the packaging so that it's known at install? [02:47] It's really annoying that bazaar breaks even when apt is happy. [02:47] fullermd: the plot thicken [02:47] +s [02:48] tedg: I'm going to blame jelmer ;-P [02:48] tedg: what ppa are you using? [02:48] if only for not setting the PPA managers straight [02:48] tedg: ok, I have plenty of memory here. I'll try doing some of the conversion now [02:48] lifeless: http://ppa.launchpad.net/bzr-nightly-ppa/ubuntu [02:49] so, nightly friction [02:49] igc: This is what works for me: $ bzr svn-import --all -Derror inkscape.svn/inkscape inkscape.bzr === sidnei_ is now known as sidnei [02:49] igc: Well, where "works" is generates an out of memory error :) [02:49] 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] lifeless: Sure, but apt should stop bzr from installing then. Or atleast warn me that the others need to be removed. [02:51] tedg: nightlies dont have the right metadata [02:52] tedg: they are pulling trunk, and there isn't a connection between trunk commits changing deps and the apt packaging [02:52] tedg: same issue that bobthebuilder recipes need updating for [02:54] 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] 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] tedg: what does dpkg -l bzr [02:55] show? [02:55] bzr 2.0.0+4766+129 [02:55] so [02:55] dpkg thinks that you still have bzr 2.0.0 on your system [02:55] as I said, metadata mismatch [02:57] lifeless: perhaps this metadata should be derived from something within the bzr tree somehow ? [02:57] SamB_XP_: perhaps [02:57] like, maybe the API version ;-P [02:57] tedg: you shouldn't use nightlies unless you're willing to deal with such mismatches, which will occur [02:58] lifeless: Believe me, I don't want to use nightlies :) [02:58] so why are you? [02:58] lifeless: Because apparently they have memory fixes in them, that might bring down the memory of my import. [02:58] As apparently I don't have enough physical memory. [02:59] tedg: why are you using physical memory anyway ? [02:59] there are significant memory improvements in trunk, thats true [02:59] however igc is doing it now, right?:) [02:59] lifeless: And I'm uninstalling the nightly as we speak :) [02:59] lifeless, tedg: rsynch'ing the inkscape svn repo as we speak [03:03] 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] (website, docs, etc.) [03:03] tedg: sure [03:06] bbiab [03:38] * igc lunch === mwhudson_ is now known as mwhudson [04:01] So.. loggerhead [04:01] better installed from bzr instead of apt? [04:05] MTecknology: hmm, I've never tried installing it :) [04:07] 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] I'm pretty sure you can control that. [04:08] ok, cool [04:08] See the loggerhead.conf.example [04:09] (http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/annotate/head%3A/loggerhead.conf.example) [04:09] thanks :) [04:09] The README has a section on serving it from behind apache, too. [04:11] OH! [04:11] I remember this now... apache proxy [04:21] spiv: what's with the .1 files in there? [04:22] like serve-branches.1 [04:22] No idea. [04:22] man pages! [04:22] Oh, man pages. [04:23] mwhudson_: the readme file? [04:25] MTecknology: no [04:25] mwhudson_: install from repos and use the man page then..? [04:26] MTecknology: i may be missing bits of this conversation, i was updating the firmware on my router [04:28] 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] mwhudson_: I was just wondering whta th .1 files were for in the branch [04:28] MTecknology: the .1 files are source for the man pages (as in the unix comand 'man') [04:28] oh [04:28] mwhudson_: OH! [04:28] LOL [04:29] that's just funny now - I thought you were telling me to look at the man pages [04:29] aaa [04:29] sorry :) [04:29] :P [04:30] 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 === mwhudson_ is now known as mwhudson [05:21] hi spiv? [06:19] How can I remove loggerhead? I ran the setup install but I'd rather run it right from teh directory.. [06:25] loggerhead is acting like it's running correctly, but it seems to be lying [06:43] 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] YES! [06:47] Now.... Is there any way you guys can have loggerhead show commit messages the way launchpad does on the project page? [06:48] 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] hurray.... [07:11] permission errors [07:13] 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] I'm going to need to look at how launchpad does it because this isn't working.... [07:14] Permissions... pah. Yet another pointless attempt to solve a social problem via technical means... [07:15] 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] or can i... use apache permissions to manage directory access (which is already there) and run bzr over http [07:15] fullermd: hm? [07:16] It's uncanny how many problems can be solved by the judicious application of mass murder. [07:16] 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] fullermd: there's good money in that line of work, death-as-enforcement-of-filesystem-permisions [07:17] I like the idea of being able to trust all developers..... [07:17] chmod u+leadpipe colonelmustard. [07:18] I suspect you're setting the setgid bit, not the sticky bit... [07:18] I'd like to manage permissions the same way launchpad does but.... that would be hard [07:19] drwsrws--t 5 shane kalliki-suite 4096 2009-10-27 23:56 .bzr [07:19] The sticky bit is unlikely to do anything useful for you there (and the setuid probably does nothing at all) [07:20] 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] 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] But that's pretty niche stuff. [07:22] I was going for simple [07:22] I was hoping I set permissions once and it just works [07:22] I'm not sure why sticky group isn't working for you, though [07:22] but since you're right that setuid isn't doing jack..... [07:23] that's what we use [07:23] the gid is being retained [07:23] just not the uid [07:23] 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] 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] 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] I just gave her this quizzical look, and said "I know where you live." [07:24] heh [07:25] fullermd: yes, exactly. You don't need elaborate legal structures when the practical consequences are self-evident. [07:25] AfC: can anyone at all touch any repo? [07:25] 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] 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] MTecknology: without explicit permission [07:26] MTecknology: otherwise, fullermd's "I know where you live" kicks in quite admirably [07:26] MTecknology: not to mention `userdel offender` [07:26] hi all [07:27] AfC: I was referring to the repository, like /bzr/repo1 /bzr/repo2 [07:27] fullermd: not sure I'd trust that, even if I believed it, but good to know. Thanks. [07:27] 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] AfC: Each repo will have a different group, but I want the uid to always be the same [07:28] MTecknology: in this case the repository in question is /bzr/java-gnome/hackers/... [07:28] AfC: once uid is retained when a new file is created, I'll be happy and set [07:28] 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] ie /bzr/java-gnome/hackers/andrew/enchant-updates and /bzr/java-gnome/hackers/guillaume/bug-455532-fixes [07:30] 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 ; ) [07:30] MTecknology: bzr doesn't edit files, why do you need the uid kept? [07:30] fullermd: My only other idea is to run it over apache [07:30] lifeless: when a user adds data, the next user can't pull it [07:30] MTecknology: I think what you what is umask, not super special uid magic [07:30] 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] MTecknology: uhm, details please [07:31] lifeless: h on [07:31] http://paste.ubuntu.com/303413/ [07:31] actually... I'm not sure if that is a permission issue anymore [07:33] umask helped a lot [07:35] lifeless: for something like this, do you think running the permissions over http might be better? [07:35] or not really [07:35] MTecknology: well, over http all your users would be the same user [07:36] so have identical access and so forth [07:36] * igc dinner [07:36] MTecknology: that error is on push, in insert_stream [07:36] check that the upload directory (.bzr/repository/upload) has group +w [07:36] lifeless: except that I could make each user authenticate as themselves [07:36] you'll want chmod -R g+w .bzr [07:36] nothing in there [07:36] MTecknology: then it would be the same as ssh, wouldn't it? [07:37] except same user/group on the system [07:37] MTecknology: permissions, not content ;) [07:37] drwsrws--t 2 root kalliki-suite 4096 2009-10-28 02:33 upload [07:37] MTecknology: thats what I said though, 'all your users would be the same user' [07:37] why's that? [07:37] MTecknology: so, is the user getting the error a member of kalliki-suite [07:37] yup [07:38] ok [07:38] check their ~/.bzr.log [07:38] may have more detail [07:39] http://paste.ubuntu.com/303417/ [07:40] oh... it was svn that I remember being able to handle granular permissions [07:40] spiv: nice mail re imports, thanks! [07:40] MTecknology: on the server, the .bzr.log [07:41] http://paste.ubuntu.com/303419/ [07:42] almost 3am again [07:42] I really never can just sit down and hammer something out quick [07:42] Isn't there any documentation to handling groups that access bzr repos? [07:42] MTecknology: its permissions [07:42] I'd have no issues starting fresh [07:42] chmod group write access within the repo [07:43] g+w? [07:43] yes [07:43] same thing [07:44] it was already that way :( [07:44] ls -lR .bzr/repository [07:44] pastebin that [07:45] http://paste.ubuntu.com/303421/ [07:46] root? [07:46] oh... [07:47] MTecknology: and the directory itself [07:47] MTecknology: ls -ld .bzr/repository [07:48] drwsrws--t 7 root kalliki-suite 4096 2009-10-28 02:06 bzr/suite-dev/.bzr/repository/ [07:50] ok [07:50] so [07:50] -rw-rwx--- 1 michael kalliki-suite 181 2009-10-28 02:31 3c29bfe02aba60925bb1e0d04349b994.rix.1864.carpo.jr7tsonnb7.tmp [07:50] is noise from one of the errors [07:51] you can see that its an index that your root user has already written [07:51] lifeless: can I just delete it? [07:52] MTecknology: hell no [07:52] ok [07:52] so, you definitely don't want the s bit set [07:52] thats setuid [07:53] u-s [07:53] or ug-s ? [07:53] on files [07:53] on dirs +s is ok [07:54] the t bit is what is making you get errors [07:54] oh [07:54] "For directories, it prevents unprivi‐ [07:54] 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] for the directory" [07:54] (see man chmod) [07:54] that was the problem......... [07:55] yes [07:55] so, when a different user tries to commit, will there be an issue? [07:55] if one user commits a brand spankin' new repo and another user tries to make a commit over it [07:57] I suppose as long as the group is retained [07:57] lifeless: thanks - I love you [08:02] lifeless: good night [08:03] niht poolie [11:01] hi all === obstriege is now known as obst [11:40] 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] Zero. [11:42] jml: shell scripting to the rescue! ;) [11:43] jml: btw, [11:43] spiv: how is shell scripting going to help? you can't integrate that into bzr very easily ... [11:43] jml: https://code.edge.launchpad.net/~spiv/bzr-pqm/non-local-submission/+merge/13333 [11:43] SamB_XP: it has while loops, bzr has exit codes, ta da! [11:44] SamB_XP: (also, note the wink...) [11:45] but it's not an 0.6 wink ... [11:46] Indeed. Perhaps I should segment my eyelids... [11:46] Until then, I think I'll stick with whole winks. [11:48] spiv, I notice that that patch doesn't change any tests [11:49] jml: true, and I didn't even try running them. I just bashed it into shape enough to solve my immediate problem. [11:50] spiv, heh :) [11:50] (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] I expect the next person (possibly me) that needs this will bash on it again, hopefully touching tests :) [11:53] spiv, I've reviewed your patch, fwiw. [11:54] jml: heh, ta [11:55] Wow, I'd already forgotten most of this patch :) [11:56] I really should extract the config improvements, they'd be handy for writing some kinds of hooks I think. [11:57] Anyway, [11:57] g'night === lamont` is now known as lamont2 === lamont2 is now known as lamont [12:14] When does bazaar lock files? === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === vds1 is now known as vds [14:14] jam: ping [14:15] morning vila [14:15] mornign jam ! [14:21] Mmmm. Morning jam. On toast. [15:22] 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] matkor: http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html [15:30] matkor: You mean upgrading your bzr install or your files? [15:32] Peng_: Yes, thank you === deryck is now known as deryck[lunch] === beuno is now known as beuno-lunch === cjwatson_ is now known as cjwatson === james_w` is now known as james_w [16:52] 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] how do I find out what version of bzr is running on a remote smart server? [17:01] I don't have shell access, but do have bzr+ssh access [17:05] never mind, hacked bzrlib to tell me :-) [17:07] faheem, it is [17:07] if it fails, maybe we can help you and upgrade it in the datacenter === beuno-lunch is now known as beuno === rockstar is now known as rockstar-afk === khmarbaise__ is now known as khmarbaise === deryck[lunch] is now known as deryck === abentley is now known as abentley-lunch === phinze_ is now known as phinze === rockstar-afk is now known as rockstar === abentley-lunch is now known as abentley [18:35] beuno: ok [18:36] thanks [18:38] i'm not clear what this bzr upgrade is for, though. can someone clarify? [18:38] i'm using bzr 2.0.1. just bzr branched mysql repos from lp [18:39] bzr: ERROR: Views are not supported by ; use 'bzr upgrade' to change your tree to a later format. [18:40] that's the error message i get [18:40] 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] Looks like it's the bzr answer to the "staging area" in git [18:48] Or something like it [18:49] faheem: It may be that `view` requires an experimental working tree format [18:52] But it seems to work on Working Tree Format 6 === asac_ is now known as asac [19:04] morning [19:05] awilkins: views will work in 2a [19:05] Morning Ian [19:05] awilkins: it's a bit rough around the edges though - some edge cases don't work frm memory [19:06] e.g. shelve? [19:06] yes, but i'm not sure from what to what the upgrade is. it's not very explicit [19:06] i assume there are repos formats? [19:06] awilkins: for simple stuff, it should be fine [19:06] faheem: Ah, that's an upgrade of repository and working tree to the newer format. For MySQL it could take a while.... [19:07] faheem: MySQL are upgrading soon I believe [19:07] faheem: if you branch in bzr, it keep the source format [19:07] keeps [19:07]