[00:01] GaryvdM: and I can reproduce it. Thanks! [00:01] Yhea [00:02] spiv: I just tested with 1.10 and I was able to reproduce. [00:04] My current hypothesis is that it's to do with which texts are stored as deltas and which are stored as fulltexts in the source repo, which tends to vary in each repo depending on the order things get inserted, etc. [00:06] I better go to bed as it 2am. [00:06] Bye [00:07] spiv: you might like to look at the analysis I did on a bug a month or so back, the one with (IIRC) casper, or apt, or something [00:07] spiv: where there were references to ghosts and $stuff [00:07] spiv: I wrote a tool to rewrite things, but you'd want to id root cause etc [00:08] lifeless: thanks, I'll take a look [00:08] GaryvdM: good night [00:15] GaryvdM: I like the throbber :) [00:16] GaryvdM: I'm also very happy to hear you aren't opposed to threads used carefully :) [00:17] hello markh [00:17] hi poolie - good trip? [00:17] you back now, right? [00:17] yes, great [00:17] and yes, i just got home [00:17] well, a couple of hours ago [00:18] excellent [00:18] heh - well - I'm sure you aren't quite feeling excellent yet! [00:18] i got an upgrade on the way back, so i'm reasonably ok [00:18] will probably fade later [00:20] poolie: welcome back [00:20] hello spiv [00:21] how was your week? [00:23] Pretty good. Quiet :) [00:25] Hi markh [00:25] what did you get up to in bzr? [00:26] Re: threads - If we want responsiveness when looking at remote branch - we are going to need threads. [00:27] GaryvdM: I understand that well - Lukas is vehemently opposed though [00:27] ie, gone so far as to say he would *refuse* to accept patches that had threads [00:28] for bzr-eclipse? [00:28] Yhea - I read that. [00:28] qbzr [00:28] poolie: for background, I had a patch that used a single background thread to talk to bzr, while the main thread was doing *only* GUI work. [00:28] that kept the gui alive even while bzr blocked [00:29] there were never 2 threads hitting bzrlib [00:30] markh: I think we should merge threadless into trunk now. What do you think? [00:30] this was only for things like building the list of changed files - not actually doing the final commit or whatever the "real" operation is [00:31] Readonly commands [00:31] GaryvdM: I agree for sure. I'm trying hard not to step on Lukas's toes though - possibly a little too hard [00:31] its a shame he hasn't commented on anything he might like on the branch [00:32] I haven't heard from him since I posted the threadless version [00:36] ok - Really going home now. [00:43] Huh, the problem that garyvdm's hitting appears to be that the initial push is stacked, but subsequent pushes aren't. [00:43] Hence the subsequent pushes are understandably upset about missing data. [00:44] I guess this is a bad interaction with the way Launchpad tries to make the client auto-enable stacking. [01:30] I think I have a fix for GaryvdM's bug for pushing to a new stacked LP branch. [01:32] Yes, it worked. BzrDir cloning-format logic is such a mess. [01:33] oh my yes [01:33] mwhudson: this has probably affected LP devs a lot, although upgrading the local format to a stacking-capable format works around it I think. [01:34] the cloning format mess has certainly affected _me_ a lot! [01:34] mwhudson: :) [01:34] * spiv sees what the test suite thinks of his patch [01:46] spiv, can we catch up on the phone when it's convenient? [01:47] poolie: sure. How about now, or otherwise just after lunch? [01:47] Now might be better if you're likely to fade. === mark1 is now known as markh [01:50] i'm just going to have lunch now, maybe after that? [01:51] Sure. [01:54] spiv: btw, i reported https://bugs.edge.launchpad.net/bzr/+bug/291046 a while ago [01:54] Launchpad bug 291046 in bzr "pushing branch6/packs5 to location with default stacking policy creates broken branch" [Undecided,New] [01:54] spiv: i think that might be what you've just rediscovered? [01:55] unless https://bugs.edge.launchpad.net/bzr/+bug/259275 has just reappeared somehow [01:55] Launchpad bug 259275 in bzr "pushing a non-stacking format into a non-repo bzrdir with a default stacking policy creates broken branch" [Critical,Fix released] [01:55] Given a bzr repo that's at revision 82, but I want to do a compile of the source as at revision 77. How do I revert the code back to that revision? [01:58] Jerub: bzr revert -r 77 will do it, i think [01:58] mwhudson: thanks! that worked. [02:10] * spiv wonders why running "./bzr --no-plugins selftest" just failed with plugins/svn in the traceback... [02:16] :) [02:28] spiv: https://bugs.launchpad.net/bugs/307988 - did you end up writing up stuff re central mail? [btw I'm on leave :)] [02:28] Launchpad bug 307988 in bzr-email "Central repository email?" [Undecided,Invalid] [02:35] mwhudson: those sound suspiciously similar. [02:35] lifeless: not yet, but I intend to [02:40] spiv: :) if you could reply to that bug then, I would appreciate that. [03:30] hi all [03:38] hello ian [03:49] poolie: when your formats email said "the following needn't block merges", were you implying bb:tweak by that? [04:09] yes [04:09] or rather, that they were optional but suggested changes [04:57] hi! i'm getting (after recent bzr pull of bzr) bzr: ERROR: The API for "" is not compatible with "(1, 9, 0)". It supports versions "(1, 11, 0)" to "(1, 11, 0)". [04:57] anybody get any ideas? [04:59] stewart: It's probably due to a plugin asking for a the 1.9 bzrlib API [04:59] bzr-svn is a common culprit [04:59] spiv: ahh.. ok, thanks! [05:00] any ideas on Revision {stewart@flamingspork.com-20081121160607-n6gdlt013spuo54r} not present in "table.h-20080625052902-61bbthtf22shh0p6-550". [05:00] https://code.launchpad.net/~stewart-flamingspork/drizzle/nofrm-dev2 [05:01] Probably a stacking-related bug :( [05:02] any way to push without stacking? [05:02] 1.10 is better at catching those errors sooner, and I'm about to send a patch that looks like it might fix the main cause. [05:03] that'd be good... [05:03] so probably a problem tha lp is using 1.7.1 [05:03] Not to Launchpad, afaik. But if you upgrade your source repository and branch with "bzr upgrade --1.6" and push a new branch that should avoid the bug, I think. [05:04] (Or you could re-use the existing LP branch by using a tool like lftp to recursively delete sftp://bazaar.launchpad.net/~stewart-flamingspork/drizzle/nofrm-dev2/.bzr and re-push to that with --use-existing-dir) [05:08] stewart: actually, the offending bugs are entirely client-side :( [05:08] fun === Mario__ is now known as pygi [06:50] how do you show a shelf with the new builtin stuff? [07:05] hi all [07:06] hello. [07:51] jml: unshelve --dry-run [07:51] lifeless: if there are conflicts, it doesn't show you anything useful. [07:51] in those cases, it would be useful to see the contents of the shelf, rather than the merge results. [07:52] (which are reverted in case of a dry run) [07:52] jml: bug a file [07:53] ok. === AfC is now known as AfC|run [08:50] * igc dinner [08:57] in a lightweight checkout, is there a way to remove all files that aren't in version control? [08:58] jml: bzr clean-tree doesn't work there? [08:58] RAOF: it does something different [08:59] RAOF: I don't want to delete all of the files that show up in "unknown" [08:59] RAOF: I want to delete all my *~ and *.pyc files and the like [09:01] RAOF: essentially, remake my tree from the branch. [09:02] Aaah. Because you've added those files to .bzrignore. Of course! [09:03] bzr ls --ignored | xargs rm? === AfC|run is now known as AfC [09:07] jml: bzr clean-tree --ignored ? [09:08] spiv: thanks. [09:08] * spiv -> food [09:31] hi mvo [10:40] hi all [10:41] can bzr replay, replay commits from unrelated branches (standalone branches) ? === jszakmeister is now known as jszakmeister|awa === mark1 is now known as markh [13:22] asabil: I'd think so [13:22] LarstiQ: it didn't seem to work, so I gave up [13:22] ok [13:28] is "--fixes" supposed to be used for bzr.dev when comitting? [13:55] awilkins: I don't think there's a policy either way. [13:56] Odd_Bloke: I'm not sure how it works, it seems to require a tag [13:58] Does Bundle Buggy support PGP/MIME? [13:59] (or not care at all?) [14:00] awilkins: You'll want --fixes lp:123456 I think. [14:02] Neato [14:03] Bugtrackers are namespaced. [14:08] Oh crap, used the wrong mail address [14:08] jam: ping [14:08] vila: is it urgent? [14:08] I'm around, but having breakfast, etc. [14:09] just ping me back when you have a couple of quarters available [14:10] jam: but if you can update your mysql branches meanwhile.. feel free :) [14:10] awilkins: BB can process such mail, but I dunno if it validates it. [14:11] At least, I think. [14:11] vila: I'll at least pull in mysql-6.0 which tends to include most of the other stuff [14:12] should be enough, I'd like your help to understand which revisions are taken into account on a particular content conflict but you may well already have all the needed revisions [14:22] Peng_: That's rather what I expected - just as long as PGP/MIME doesn't choke it, I can use it [14:26] awilkins: Lots of people on the list use PGP.. If "This is a multi-part message in MIME format." means it's PGP/MIME, then it definitely works. === maxb is now known as Guest20139 === Guest20139 is now known as maxb [17:03] hi! i got a stack trace when running bzr push: http://pastebin.com/m32a4c395 . Then i ran bzr push again and it worked [17:03] is this a known bug? [17:04] sven_, it has been reported, yes. An autopacking error [17:04] waht version of bzr are you using? [17:05] beuno, ok, thanks. i'm using bzr 1.10. added version and plugins to paste: http://pastebin.com/d3d4e0032 [17:06] beuno, do you know any details? is it safe to just ignore the failure and push again? [17:07] sven_, well, I'm actually not sure if it shouldn't be fixed by now... [17:07] sven_, can you file a bug anyway? [17:07] it should be safe though, if the second push was succesful [17:07] Pushing again should always be safe, at least. [17:07] beuno, ok, will file a bug [17:07] fullermd, beuno, ok, that's reassuring :-) [17:12] http://pastebin.ca/1286019 [17:13] why does bzr need dbus? [17:13] HAL integration for monitoring network events? [17:14] Kobaz, my guess is that you have the plugin installed? [17:17] oh [17:17] maybe [17:17] ii bzr-dbus 0.1~bzr36-3 D-Bus announcements plugin for Bazaar [17:17] mmm === jrydberg_ is now known as jrydberg [17:20] Kobaz: 'xhost +localhost' under your regular login maybe ? [17:22] well i dont need dbus stuff, so i guess i'll just axe it out [17:25] is there a way to get bzr to save bzr+http passwords? [17:26] bzr pull [17:26] Using saved parent location: bzr+https://markm@bzr.local/bzr/myproject/usrLocalLibrary/trunk/ [17:26] HTTPS markm@bzr.local, Realm: 'Bazaar Repository' password: [17:44] Kobaz: maybe this helps: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#id24 [17:46] k === mark1 is now known as markh [18:04] Kobaz: Amanica was right, authentication.conf should address your problem, did you find it ? [18:05] err, did you *solve* your problem ? [18:16] Hrmm. Can `bzr rebase` cause problems between repositories? Are there any gotchas I should be aware of? [18:16] I just rebased my changes against someone else's tree and noticed that the rebased revisions have the same IDs as the original ones. [18:16] but, don't they have different parents? [18:17] wouldn't that cause issues? *confused* [18:19] The rebased revs shouldn't have the same ID's... [18:23] Hrmm, I may have run bzr log from the wrong dir. :p [18:23] can't reproduce that. I *thought* that sounded fishy. [18:26] Kobaz: thats fixed in bzr-dbus upstream, just the debian package hasn't caught up [18:28] AmanicA: hi [18:34] k [18:34] vila: i just removed bzr-dbus... that fixed it... heh [18:36] Kobaz: I kind of doubt that provides passwords but.. If you say so :) [18:37] bialix: hi чувак [18:38] LOL @ vila [18:39] oh [18:39] vila: oooh [18:39] the autheitcation stuff [18:41] i'm all confuzzeled [18:41] okay now i'm good, well i was confuzzeleded [18:44] so where it says [myprojects] [18:44] do i really use [myprojects], in the authentication.conf... or do i name it the project namer [18:46] never mind [18:46] scrolling down helps... [18:48] i wrote out an authentication.conf... but bzr doesn't even open it [18:59] oh [18:59] does bzr diff really have to obey the file locks set by bzr commit? [19:00] it's a read-only operation [19:00] with subversion i always go around diffing everything while i'm in the middle of a commit [19:01] Kobaz, how about bzr commit --show-diff? [19:01] Kobaz: its a bug on windows only, we will fix it but yes, it does need to obey the file lock [19:02] lifeless: i'm on linux [19:02] Kobaz: oh, hmm, ah yes. [19:02] beuno: hmm, that's good, but i would still want to be able to view individual file diffs... i like working with smaller units [19:02] Kobaz: it will be locked out there in that case as well :( [19:03] Kobaz: same cause, same fix when we get it done [19:03] you might like gcommit [19:03] lifeless: ah, so the fix will allow diffing on commit-in-progress files? [19:03] (or qcommit!) [19:04] Kobaz: roughly yes ;) [19:04] yay [19:04] so, why would it need to obey the file lock? [19:04] What would the fix be? [19:05] when you're in the editor for bzr commit, nothing is changing, the diff is a read-only operation, linux has no restrictions on reading files that are "in use" [19:06] windows on the other hand is a pita with file locking... not sure how you would fix it there [19:07] While you're in the editor, the repo is in the middle of a commit.. [19:07] Even if nothing is happening *right then*, there's still a half-completed commit sitting around. [19:08] but at that time... the repo is in a consistant state [19:08] since nothing has been written of the commit yet [19:09] I'm not sure how true that actually is. [19:10] the entities in question should only be locked for reading when the actual commit is taking place (ie: done with the editor, the files are being added) [19:10] it makes sense to lock them for writing, but not for reading [19:12] theoretically, i see no harm in allowing reading operations during the commit message editing... but then again i don't know all the internals of bzr... but what's your objection to not having a read-lock [19:12] Write locks as a rule lock out readers :p [19:12] it depends on the system [19:13] Every locking formalism that comes readily to mind? [19:13] Hmm, ISTM while the editor is open, the upload file has been created, but it's empty. [19:13] like for database transactions. you will have several different types of locks... you will have read commited (read/write lock), read uncommited (write lock), and others [19:13] Writing changes things. Changes tend to lead to inconsistencies. Reading during inconsistencies is Bad(tm). [19:13] But then, I was just testing with a tiny test repo. [19:13] It's probably not inconsistent at that point. [19:13] Peng_: exactly [19:13] At least in pack repos. [19:14] Kobaz: I imagine that's why lifeless said it *could* be fixed. ;) [19:14] yeah [19:14] I've never paid attention; bzr asks for the commit message before going through all the mechanics? [19:14] hg asks afterwards. [19:14] I'm not saying it _good_ to lock out diff while you're sitting in the editor, nor do I think it's likely to be the eternal state. But it's not just as simple as "change X" to fix. There are likely a lot of implications and assumptions and side effects to unwind. [19:14] as far as i know, it's only inconsistant during the upload/write procedure after editing the message [19:15] fullermd: oh of course, but i figured i would bring it up [19:16] Peng_: No, the mechanics are run through. You can prove this to yourself by starting a commit, then editing the file while sitting in the log editor. [19:16] Kobaz: its the dirstate file that is the thing [19:16] not the repo [19:16] fullermd: Oh, good point. I've done that, in fact. [19:17] the repo is multimaster safe, branches are single writer N readers, trees are [currently] single-writer-no-readers | N-readers [19:17] I just tested it by committing a bunch of large files. When it was a teensy test file, the upload file was empty because of buffering. [19:18] anyways... next topic [19:18] lemme finish my paste [19:18] lifeless: So what's the fix, then? [19:18] Yum. Is it mint-flavored? [19:19] Peng_: write to a newly named dirstate each time, with a atomic-update pointer to the active dirstate, and a RCU style late-delete of old dirstates [19:19] http://pastebin.ca/1286109 [19:19] i'm trying to use authentication.conf [19:20] lifeless: Ah. [19:21] so umm, is there any config options i need to turn on in bazaar.conf, in order to use authentications.conf ? [19:21] this is 1.10 [19:22] Kobaz: its on by default, but I've never used it [19:23] as you can see from the pastebin [19:23] bzr isn't even touching authentication.conf [19:23] Kobaz: what url are you pulling from though; you've helpfully edited that out :) [19:24] i'm pulling from bzr+https [19:26] try just https: [19:27] also whats the error that occurs [19:29] the error is that the login failed [19:29] since it's not specifying the password that's stored in authentication.conf (since authentication.conf is not read) [19:30] bzr: ERROR: Generic bzr smart protocol error: Invalid http response for https://bzr.local/bzr/myProject/usrLocalLibrary/trunk/.bzr/smart: Unable to handle http code 401: Authorization Required [19:31] vila: ^ is this a smart oversight? [19:31] using bzr+https:// and https:// have the same problem... authentication.conf is never read [19:31] lemme try the example in the docs [19:32] lifeless: shouldn't be [19:32] Kobaz: What about nosmart+https? [19:32] Kobaz: try -Dhttp -Dauth [19:32] stat64("/home/root/.bazaar/authentication.conf", {st_mode=S_IFREG|0644, st_size=82, ...}) = 0 [19:32] okay... if i use ftp:// it will read authentication.conf [19:33] Kobaz: Oh, try adding user in the url [19:33] strace bzr pull ftp://localhost [19:34] ftp and http are different we provide a default user for ftp not for http [19:34] i dont get any debugging for -Dhttp -Dauth [19:34] in the .bzr.log file [19:34] ah [19:38] vila: it would be nice to prompt for credentials, what needs to happen for that? [19:39] http://pastebin.ca/1286123 [19:39] vila.cucles.free() :) [19:39] vila.cycles.free() :) [19:39] I hate typos in jokes [19:39] vila: your spellchecker needs more timeslices [19:40] Kobaz: Ok, add your user in the url [19:40] k [19:40] I don't know why I keep thinking this bug is fixed.... [19:41] jelmer would kill me for saying that :-) [19:41] vila: this sounds like the stuff I was working on a few months ago [19:41] I haven't had the time to sit down and figure out a good way to handle this. [19:41] jfroy|work-sl: Hey ! [19:41] http://pastebin.ca/1286128 [19:42] But vanilla authentication.conf certain works for me, even though it's gross to leave a password in cleartext. [19:42] authentication.conf doesn't get loaded when you use https or bzr+https [19:43] if i manually edit branch/branch.conf [19:43] and put in the url with my username in it [19:43] good morning [19:43] Kobaz: it used : 0.958 Using authentication section: 'myProject' [19:43] it will promot for a password [19:43] 2.716 Using authentication section: 'myProject' [19:43] yes, but [19:44] look at this strace [19:44] Kobaz: That's a bug, authentication.conf should be usable to provides the user [19:44] oh [19:44] wait [19:44] the password is wrong [19:44] if i provide the username, it loads authentication.conf [19:45] if i don't provide the username, it wont [19:45] i see [19:45] or at least that's what the server said (AFAICS), by the way, change it as soon as we finish discussing, basic really is not secure, [19:46] ? [19:46] what's wrong with basic auth [19:46] over https [19:46] nothing [19:47] posting pastebin with the http headers on the other hand... [19:47] it's all local [19:47] and i have a little scrubber script [19:48] oh [19:48] yeah [19:48] the source password is def123 === elmo_ is now known as elmo [19:56] Kobaz: what's wrong with basic is that if you have the header, you have the password. [19:58] so run it over https :p [19:59] evarlast: and then paste the headers on pastebin? :P [19:59] Digest isn't that hard to set up. [20:02] yeah [20:02] doing that now [20:02] heh [20:03] i dont have any real passwords in there anyway === Mario__ is now known as pygi === asac_ is now known as asac [20:43] beuno, ping [20:45] jelmer, pong [20:46] beuno, bug 305995 is blocking adoption by alioth and it seems like an easy bug [20:46] Launchpad bug 305995 in loggerhead "includes internal port numbers in links" [Undecided,New] https://launchpad.net/bugs/305995 [20:46] beuno, can you perhaps give me a hint as to how to do so? [20:47] * beuno looks [20:47] oh that [20:47] it sounds like a configuration problem tbh [20:48] jelmer, that's using start-loggerhead? [20:48] mwhudson, hi! [20:48] jelmer: please stop using start-loggerhead [20:48] Hi mwhudson :-) [20:48] beuno, yes [20:48] we should talk about trying to get a day or two a month to work on LH [20:48] jelmer: in the interests of actually solving your problem though [20:48] jelmer: can you pastebin your loggerhead.conf ? [20:49] jelmer, and you're using that because it lets you tweak stuff that serve-branches doesn't? [20:50] mwhudson, we should make sure we can provide a config for serve-branches, and kill off start/stop-lh [20:50] oh, and, of course, fix that memory problem... [20:50] mwhudson, please remove start-loggerhead then.. [20:50] * beuno pokes thumper [20:50] beuno: I thought you had a day a week :) [20:50] mwhudson, start-loggerhead is the only thing that has an init-script in Debian (but I think we've had this discussion before :-) [20:50] yes [20:51] beuno: yes? [20:51] lifeless, *sigh* [20:51] :> [20:52] jelmer: do you want to run from the loggerhead package on alioth? [20:52] jelmer: or would you be ok running trunk? [20:53] jelmer: at any rate, i really don't think you want auto_publish_folders, and would be much happier with the serve-branches approach [20:53] beuno, config is at http://pastebin.ubuntu.com/85753/ (not created by me but by Lolando) [20:53] (i mean, how many links saying "unstable" are there on http://bzr.debian.org/loggerhead/ ?) [20:53] mwhudson, Well, it should be some package, but since I'm the Debian packager I can upload a new upstream snapshot if necessary [20:54] jelmer, I'm going to try and release a new version in this week or the next [20:54] jelmer: so remind me, why is serve-branches unsuitable? lack of a config file? [20:54] jelmer, and that's not passing through apache? [20:54] mwhudson, Lack of config file and init file [20:54] or it is, and LH is creating the :8080 links? [20:55] jelmer: so there's an init file in trunk [20:55] (for serve-branches) [20:56] mwhudson, yes, but it's not using the standard functions for Debian/Ubuntu and it requires users to pick either serve-branches or start-loggerhead [20:56] lack of a config file is fixable, presumably, let's fricking fix it [20:56] mwhudson, we can hack our way around the current situation [20:56] mwhudson, I'm just lobbying for a single binary that does loggerhead and uses a config file [20:57] rather than having two binaries, both of which can do some things but can neither do both [20:57] s/do both/do everything/ [20:57] jelmer: it seems unlikely then that loggerhead can by itself supply an init file that would be acceptable by debian? [20:58] mwhudson: Not sure I follow.. [20:59] " mwhudson, yes, but it's not using the standard functions for Debian/Ubunt" [20:59] jelmer: perhaps i didn't understand this bit? ^^ [20:59] Loggerhead can include an init script that is appropriate, it just doesn't atm :-) [21:00] The infrastructure provided by start-loggerhead matches a bit better what we need there [21:00] since start-loggerhead can write pid files, etc [21:00] oh right daemonization [21:03] hm, links like http://bzr.debian.org/loggerhead//bzr.debian.org/current/changes don't look quite right :) [21:06] oh man, i always forget how much i hate config file formats :) [21:09] i'm creating a website using python/django, hosting content similar to a wiki site [21:09] and i need version control for the content [21:09] would it be possible to integrate bazaar into the website for version control? [21:10] similar to how google code uses svn for the wiki pages [21:10] rkistner: Yes, bzr has a good Python API. [21:10] how much work would it require? [21:11] or is that a bad question? [21:11] i'm completely new to bazaar [21:11] rkistner: Well, it's hard to express work. :p [21:11] It wouldn't be that hard. [21:11] jam, hi [21:12] ok, thanks [21:12] rkistner: A handful of API calls. [21:12] and i won't need to run any additional processes, apart from the main python process? [21:13] rkistner: Nope. [21:13] ok, cool [21:13]