[00:12] hello everybody. [00:13] anyone had experience installing bzr on a shared host? [00:13] yes, sure [00:14] poolie: dreamhost, bluehost or site5? [00:14] oh, huh [00:14] none of those [00:14] why not use launchpad.net? [00:15] poolie: is for a private project [00:15] poolie: been pushing via ftp and pulling via http, but these dumb protocols are a bit slow. [00:15] are you using a pack repository? [00:16] yep, pack-0.92 [00:16] with 1.1 [00:16] sorry, bzr 1.1 [00:16] freshly created repos :) [00:16] luislavena, I'm not sure you can install python apps on shared hosts [00:17] (I'm fairly sure you can't unless it's a virtual server or the likes) [00:19] beuno: thank you [00:20] beuno: maybe something like this [00:20] beuno: http://joshstaiger.org/archives/2007/01/bzr_on_dreamhos.html [00:21] luislavena, ah, seems pretty straight forward [00:22] beuno: I'll need to check if the dependencies can be installed in the same way, since I've 2.4.3 available and only tested bzr with 2.5.1 [00:22] if you're allowed to install stuff in your home, for the most part, those same steps should work [00:22] luislavena, bzr works fine with python 2.4X [00:23] beuno: thank you for the info [00:23] beuno: is there a way I can see if everything works as expected ? (selftest?) [00:24] luislavena, yeap, bzr selftest [00:26] Uff. Not a particularly kind thing to do... [00:27] fullermd: What in particular? [00:27] fullermd: yes, I know... will make the shared host a nightmare to other users. [00:29] Odd_Bloke: running 'selftest' on a shared webhost? [00:29] because of cpu usage? [00:29] run it niced... [00:29] or run, say 'selftest command' [00:29] sorry, i mean 'blackbox' [00:30] cpu, disk... last time I ran it, it made my workstation crawl for about 40 minutes. [00:30] Still negotiating the restraining order my hard drive filed at the time... [00:31] fullermd: hehehe, no problem, the InstallationFaq contains pointers on how to check for the missing dependencies. [00:31] so far, the shared host lack all of them :P [00:31] I'll see if I can install them like bzr... [00:31] (on $HOME) [00:32] fullermd: Ah, OK, I was thinking more generally. [00:40] ffworked fine on dh for me [00:44] bob2: how did you handle the dependencies? ElementTree, pyramiko, etc? [00:45] Well, you don't need paramiko unless you're sftp'ing _out_ from there. [00:46] aelementree is python, as is paramiko, and what fullermd said [00:46] you could probably even get bzr+http working, I think they do fastcgi [00:50] revie requested: http://bundlebuggy.aaronbentley.com/request/%3C1201262061.16337.52.camel@lifeless-64%3E [00:54] bob2: how bzr+http will handle authentication? [00:54] poorly! [00:56] bob2: uhm [00:56] luislavena: it should handle it fine [00:56] lifeless: thank you :) [00:57] but anyway, it fails to compile the c part of bzrlib [00:57] so I think this shared host is not as good as other ;-) [00:57] hm, I was reading the bzr+http docs yesterday, and it looked like you couldn't control what people could write to [00:58] bob2: thats access control not authentication [00:59] bob2: bzr+http delegates authorisation and authentication to apache and makes no direct effort at access control [01:00] touche [01:00] Well. Access control is a subset of authorization... [01:00] fullermd: bup [01:00] fullermd: bah, nup, its not [01:01] fullermd: its a subset of AAA, but other than that you can have any one without the other two [01:01] The third A in AAA is 'accounting', though. [01:01] but it's not possible to have differing read and write authorization with bzr+http yet, right? [01:01] bleh, my brain has clearly faded [01:02] Dirstate does that to ya ;) [01:02] bob2: depending on what granularity you want, yes or no [01:02] bob2: in a single repository, we still depend on VFS access for some methods, so any access to the data base implies full data visibility [01:03] I would phrase it as "bzr+http delegates authentication to Apache, and abdicates authorization to merely be contingent on authentication". [01:03] bob2: but you can certainly split read and write access in a couple of ways - you can run the server with different parameters via the apache config to block writers [01:04] The usual suggestion for that is "read/only bzr+http, read/write bzr+https with HTTP auth" [01:05] not sure why you'd split the protocol [01:05] but whatever [01:09] Well, that makes the URL's almost the same on both sides. Gives you SSL where you're sending auth info over the wire. [01:10] digest auth ftw; or has that not landed yet ? [01:10] Well, it would also prevent a MitM when you were pushing data. If anybody still bothers trying to carry those out. [01:11] digest supports body signing [01:11] plus sign your commits kthxbye [01:16] igc: I wonder if I can borrow you for http://bundlebuggy.aaronbentley.com/request/%3C1201262061.16337.52.camel@lifeless-64%3E [01:17] lifeless: sure. Meant to get to it yesterday. [01:17] I'll move it to the top of my review list [01:18] (ahead of thumper's one) [01:18] :( [01:21] guys, there is no feed generator that can hook push and commit? [01:22] branchfeed seems old and don't work. [01:23] luislavena: my plugin should still work [01:23] lifeless: can you point me to the branch? [01:23] one sec [01:24] lifeless: thank you [01:25] branchfeed is what I called mine lol, I had to re-read it [01:26] lifeless: the one here doesn't work: [01:26] https://code.launchpad.net/~bzr/bzr-branchfeed/trunk [01:27] it's supposed to generate a feed in .bzr/branch/branch.atom, but no file get generated. [01:28] https://bugs.edge.launchpad.net/bzr-branchfeed/ [01:28] could you file a bug please [01:29] lifeless: will help you if I run the plugin selftests? [01:30] is the plugin installed on your client or server? [01:30] client, doing everthing locally and sometimes using smart server. [01:31] yah, I can't look at this right now [01:31] please file a bug with as much info as you can gather [01:31] lifeless: yeah, sure. thank you again :) [01:39] lifeless: done :) [01:45] New bug: #187479 in bzr-branchfeed "BranchFeed don't generate atom feed after commit or push" [Undecided,New] https://launchpad.net/bugs/187479 === mw is now known as mw|out [02:07] guys, another silly question, but i cannot find a way to verify the signed commits [02:08] there is sign-my-commits and re-sign, but no verify-signed-commits or something similar. [02:11] poolie: perhaps https://code.edge.launchpad.net/~mbp/bzr/dev should be registered, its a dupe with https://code.edge.launchpad.net/~bzr/bzr/trunk [02:11] luislavena: yah, someone was working on it [02:13] lifeless: good to know, the check_signature and create_signatures configuration options works? [02:14] (branch based and globals) [02:15] ok, it seems so, just wanted to be sure :) [02:15] lifeless: is get_data_stream_for_search meant to have ordering restrictions? === variaas_ is now known as variaas === variaas is now known as variaas_ [02:59] abentley: no more so than the get_data_stream api it replaced [03:00] They both have prefixes with lists of versions after them. [03:00] I'm not sure whether a prefix is allowed to be repeated. [03:00] The use of prefixes suggests that the designer wasn't expecting the prefix to change frequently. [03:00] I don't think the current code or tests prevent that [03:01] the goal was a single namespace for all data atoms [03:01] Since ('a')['b'], ('c')['d'] isn't all that helpful. [03:02] But in packs, I would expect the prefix to change at least twice per revision. [03:02] why? [03:02] If you read from the beginning. [03:02] oh right [03:02] currently on sftp I do four readv's per pack [03:03] each readv linear sorted [03:03] (for fetching this is) [03:04] Cool. [03:04] that seems a reasonable tradeoff in simplicity/speed - it lets us keep the read revision, read inventory, read texts etc sequence [03:04] Oh, I see. [03:04] which means we don't copy unreferenced data, can sanity check etc [03:05] But revisions and sigs are fulltexts, so it wouldn't hurt to read them at the same time as inventories. [03:05] No additional memory cost, at least. [03:05] and transactional inserts into the repository means we can just flush to disk [03:05] abentley: right, it can certainly be tweaked; howver the sigs and revisions are in different indices to the inventories [03:06] so if we were trying to optimise memory more we would actually be dropping index content from memory after grabbing the data for that index [03:06] Yes, I suppose it makes sense to do each index in turn. [03:07] I haven't had any breakthough thoughts about storage/repository; I will reply to the thread though and see if we can get a good compromise; I _do not_ want to prevent improvements [03:08] Even though we haven't agreed on the structure for Storage, I think that we can agree that an implementation of iter_files_bytes that reads each pack only once would be a win. [03:09] abentley: oh for sure [03:09] So I'm going to look at restructuring the knit-building code to support that. [03:09] abentley: great; I hope you'll find its already half way tere [03:09] *there* [03:09] I split out the 'get data' stuff to a KnitAccess helper a ways back [03:10] Oh, I've been wondering what that thing was. [03:10] so PackAccess knows how to get stuff from an arbitrary key [03:10] by mapping the key which is (index, key) [03:10] through the index to get an actual pack file [03:11] KnitAccess maps likewise but to a single file the .knit file [03:11] this gives KnitData as simply providing the logic for combining hunks etc [03:11] Hmm. Somewhat different approach than I was thinking, but it could work. [03:12] and KnitIndex maps into a combined index for packs, which filters out the fileid prefix [03:12] so what I have been thinking about doing is [03:12] adding a file id prefix to the standard knit code [03:13] which the existing KnitIndex stuff would enforce as always being the file id the index is for [03:13] and the pack index mapper would just stop filtering out the file id prefix [03:14] thus giving the existing iter_versions etc stuff the ability to deal with many file ids at once [03:14] anyhow, I'm rambling - this is what I had in my head, not the only way to do it :) [03:14] Well, it's interesting. [03:15] I basically already have the code to map a bunch of requested knit entries to their pack transport/name/offset/size. [03:16] So I was thinking about doing that part up front. [03:17] the map code should a single index iter_entries query really :) [03:17] Basically via the iter_raw_items variation on get_data_stream. [03:18] Yeah, I like that. [03:19] the thing I like about extending knit is that the combining logic does not get duplicated, or have to move [03:20] so improvements there will still help anything thats roughly delta combining related [03:24] The downside is you can't retrieve everything in a single read. [03:27] hmm? sure you can [03:27] get_raw_records [03:29] used by read_records_iter_raw [03:30] so read_records_iter_raw is already multiple-file-id ready, as long as the _Access object it has been given is [03:33] By everything, I meant fetching files, revisions, inventories and signatures all at once [03:33] oh right [03:34] You can achieve that by adding a prefix, I think. [03:34] hmm, if we guarantee that the indices contain enough data [03:37] You then wind up with something very close it Storage.iter_raw_items. [03:37] I like the idea of getting get_data_stream and insert_data_stream [03:38] s/it/to [03:50] lifeless: I think you were cut off: "I like the idea of getting get_data_stream and insert_data_stream" [03:58] But I'll mention that if we get the inventory first, we can do fetch and build_tree at the same time. [03:59] yup [03:59] fetch currently puts the inventory before all texts [03:59] for locality of reference its grouped too [03:59] not really cut off; just not finished === lamont` is now known as lamont [08:51] whats the difference between a branch and a trunk? [08:53] Aloha: one starts with a b, the other with a t. That's pretty much it. [08:53] weigon, whats the point of differentiating? [08:53] Aloha: "trunk" is svn-speak for the main-development-branch [08:54] weigon, so why have more than one branch? [08:54] Trunk is a branch that you call trunk. [08:54] Aloha: release-branches, feature-branches, merge-branches, ... [08:54] in bzr-world everything is a branch, everyone has it's own repository. [08:55] weigon, so whats the difference between feature branch and release branch? [08:55] Aloha: I think the best example is taking a look how the linux kernel-development works [08:56] Pretty much the difference between a water glass and a milk glass... [08:56] why would my project have more than one branch? different parts of it go in different branches? [08:57] Aloha: no, put sometimes you have to release something to users|customers [08:57] and they call you 6 month later about a bug and you are already working the next big release [08:58] weigon, so you can pull up the source code from that release and work on the bug? [08:58] ... and fix it for that release to build a new release (1.0.1), while you are still doing your main-dev in "trunk" for the 2.0 release [08:59] if you want to implement a new feature and want to write a Proof-of-Concept you will commit it not to trunk, but to a feature branch. [08:59] if it works well and matures, you merge the new feature back into trunk [08:59] weigon, so your source code that you edited would be in 1.0-dev branch and your release would be in 1.0.1-release? [09:00] if it doesn't work out, you only have to trash your work, not the work of others that are in the main-dev branch [09:00] weigon, gotcha [09:00] if you do it right, the main-dev branch is always in release quality [09:01] everything unstable is in feature branches until it is well tested and can be merged over [09:02] weigon, gotcha [09:03] Aloha: that means proper test-cases, unit-testing, ... [09:04] weigon, do you have a seperate branch for debian packages? or do you make those from release tarball? [09:16] Aloha: debian packages are built aside anyway. [09:16] weigon, aside? [09:17] Aloha: scroll down on http://packages.ubuntu.com/feisty/net/hostapd [09:17] Source Package: hostapd, Download: [dsc] [hostapd_0.5.5.orig.tar.gz] [hostapd_0.5.5-3.1.diff.gz] [09:18] it is always a the original tar + a diff that includes the build-files for debian [09:18] weigon, i know but the files uses to build the original tarball, does anyone keep a debian branch knowing that that branch will only be used to build packages? [09:19] s/uses/used/ === doko_ is now known as doko [10:40] New bug: #187593 in bzr-webserve "list index out of range" [Undecided,New] https://launchpad.net/bugs/187593 === mrevell is now known as mrevell-lunch === SteveA_ is now known as SteveA [13:14] hi. I just installed the bzr-svn plugin (I am running fedora core 7). However, when I try to check out an svn branch, I get an error telling me that the url is not a branch. The cmd 'bzr selftest svn' failed, but I cannot make out what the problem is. Can anyone help me out here, please? [13:15] the error I get is '_get_location_config() takes exactly 1 argument (4 given)' === mrevell-lunch is now known as mrevell [13:40] ok, I found out the error. I relates to bzr-svn not being able (yet) to check out from webdab [13:40] webdav [15:01] ricardokirkner: bzr-svn supports webdav yet [15:03] ? [15:18] Can anyone tell me the significance of .~1~ files in my BZR trees? [15:21] They're files left behind by 'bzr revert' [15:21] When you 'bzr revert' it moves your locally-changed file to .~1~ in case you wanted to keep it, before overwwriting it with a clean copy [15:21] Aha, thanks [15:21] * awilkins executes ls -r -inc *.~1~ | rm === mw|out is now known as mw [15:28] awilkins: there is bzr clean-tree --detritus, from the bzrtools plugin. try it with --dry-run first. [15:56] info je [15:56] info jelmer [15:57] whoops [15:57] sorry === bigdo2 is now known as bigdog [17:01] after i upgrade my launchpad branch using sftp://@bazaar.launchpad.net/~username/project/branchname, what should i do to my local working copy? [17:01] alefteris, upgrade it too [17:01] and, reconcile both [17:01] bzr reconcile sftp://@bazaar.launchpad.net/~username/project/branchname [17:03] i was reading this http://beuno.com.ar/archives/48, it mentions that I should recogline only if there is a problem.. is reconcile a dangerous operation? [17:03] alefteris, oh, then I have to correct it [17:03] you *must* do reconcile [17:03] :) [17:03] alefteris, no, it isn't [17:03] upgrade might be [17:03] ok thanks [17:04] alefteris, I changed it a few hours ago, can you see if it's clearer now: http://beuno.com.ar/archives/48 [17:04] (upgrade, on the other hand, already does it's own backup before doing anything, so all operations are fairly safe) [17:04] hey folks. does this mean anything to any of you? [17:04] [projects]$ bzr branch bzr+ssh://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main/ exaile [17:04] bzr: ERROR: Could not install revisions: [17:04] sasongko@gmail.com-20080129204555-7h0j46m8wwlpcff2 [17:06] synic, what version of bzr are you using? [17:06] 1.0.0 [17:06] synic, you might want to use http to branch [17:07] (and, is that your user in LP?) [17:07] well, I'm trying to branch because a pull failed with the same error [17:07] yes, that's my LP user [17:07] beuno, you used to have a "check" step before the upgrade, its not actualy needed? [17:07] alefteris, not really, if you have knits, it isn't required [17:08] I also moved reconcile to _after_ upgrading [17:08] it's million times faster [17:09] synic, let me try and branch it [17:09] yeah, I just installed bzr 1.1 and same error [17:09] I get 0 revisions [17:10] uh, there are a lot more than 0 revisions [17:10] hmmmm [17:11] LP is reporting problems with the branch... [17:11] great. [17:11] synic, can you do: bzr reconcile bzr+ssh://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main [17:11] has the branch been upgraded lately? [17:12] well, I didn't do it (I wouldn't even know how), but one of the other devs may have done something [17:12] synic, try and run reconcile, and I'll ask in #launchpad if anyone can help [17:12] running it now [17:13] ah, you already did... [17:13] let's give reconcile a try first [17:23] whew, reconciling isn't the speediest operation, heh ;-) [17:24] beuno: ok, yeah, it's still broken. [17:25] synic, argh... I suspect it's a LP problem [17:25] bummer [17:26] lifeless, jam, abentley, any ideas on why https://code.launchpad.net/~exaile-devel/exaile/main might be broken? [17:27] Broken how? [17:28] abentley, it doesn't branch [17:28] 0 revisions [17:28] and LP reports it has a problem [17:28] synic already ran reconcile on it [17:28] and still nothing [17:28] (nobody seems to be available in #launchpad) [17:30] I see there is a broken character in the last commit message [17:31] but I'm not sure if that can cause LP to go crazy [17:31] (codebrowse also breaks: http://codebrowse.launchpad.net/~exaile-devel/exaile/main/files) [17:32] yeah, but on all the revisions, not just the last one (I don't know if that means anything) [17:32] synic, I think it basically mean LP can't ready from the branch either [17:33] hrmm [17:33] Yeah, you can see the "branch has errors" thing on the page [17:34] abentley, so... how can this be solved? push --overwrite from a healthy copy? [17:34] It's also in format 5, which is a bit odd. [17:34] Did you upgrade it? [17:34] or did you push from an upgraded branch? [17:34] synic, can you find out what the last dev did? [17:35] I'll have to wait until he gets online [17:35] But I can confirm that revision-history is empty, so Bazaar is correctly interpreting that. [17:36] I'm not real excited to hear that :) [17:37] synic, maybe the branch was upgraded and not reconciled [17:37] do you have a healthy copy locally? [17:38] (even if a bit out of date) [17:38] I have one at home. I've been trying to log in and get it, but I can't get in for some reason [17:38] * synic thinks of where there might be another [17:39] ah, I have one on exaile.org, but I'm not sure how old it is. [17:39] synic, just so we can check what storage format you have and narrow it down to "someone upgraded recently and broke stuff" [17:41] ok, yeah, I found it. How do I check? [17:41] synic, bzr info -v | grep 'repository' [17:42] bzr: ERROR: Unknown branch format: 'Bazaar pack repository format 1 (needs bzr 0.92)\n' [17:42] synic, ah, so it's packs. And you're using some old bzr version [17:43] on exaile.org, yeah. It's 0.90 [17:43] I'll upgrade, if it won't hurt anything [17:43] synic, I would recommend upgrading it to 1.0 (or 1.1 even) [17:44] k, doing that now [17:44] you should try and get a hold on the last dev that uploaded [17:44] see if he can fix his locla copy [17:44] if not [17:44] find the latest healthy one you can find [17:45] to 'bzr reconcile; [17:45] s/;/' [17:45] and then add the changed files [17:45] ok [17:45] commit [17:45] and move on :D [17:46] make sure everyone is using bzr 1.0+, and have upgraded their local branches [17:46] I just blogged on how to upgrade a few days ago: http://beuno.com.ar/archives/48 [17:46] beuno: I'm trying to get more info on this, but no luck so far [17:48] abentley, great, thanks! synic can you stick around for a while and see if we can dig a bit deeper? [17:48] yeah [17:48] how do i get bzr 1.0 on ubuntu? [17:48] might be a bit before the other dev signs on [17:48] if he does at all [17:48] he's in australia, I'm in utah [17:48] thanks [17:48] dacresni, you can get the latest from: https://launchpad.net/~bzr/+archive [17:49] bzr info -v | grep repository repository: Packs containing knits without subtree support [17:49] that's after the upgrade. [17:50] i c [17:50] synic, good. I would run 'bzr reconcile' on it now [17:50] thanks beuno [17:50] dacresni, no problem! :D [17:51] beuno: it says "no repository present". Ack, it's a checkout, not a branch. Rats. [17:52] synic, you can use 'bzr unbind' to make it into a branch, although I'm not sure who it's parent is [17:52] it's parent is the broken branch [17:53] synic, I believe unbind won't call the parent at all if it's a regular checkour [17:53] s/checkour/checkout [17:53] heh, it's a --lightweight [17:53] aaargh [17:53] not your lucky day... [17:54] no, no it isn't. [17:54] well, I'd find out what kind of beer abentley likes then :p [17:54] You could try doing bzr reconfigure --branch, though. [17:55] in the checkout? [17:55] synic: yes. [17:55] k [17:55] I like irc so much more than forums, its so much harder to search for what you wnt [17:55] That assumes that upstream actually has the necessary revisions. [17:55] c ya [17:56] bzr reconfigure replaces bind, unbind and remove-tree. [17:57] Though I suppose you probably want reconfigure --tree. [18:01] hey, back [18:02] had a bit of a "problem with the package [18:03] well, i just wan'ted to fix my commit signing process [18:05] it responded gpg: problem with the agent - disabling agent use [18:05] bzr: ERROR: Failed to gpg sign data with command "['gpg', '--clearsign']" [18:06] is this a bzr issue or a gpg issue [18:07] ? [18:07] beuno are you still there? [18:08] dacresni, yes, although I haven't used gpg signing in bzr [18:08] have you signed any commits yet? [18:08] i tried [18:08] no i haven't [18:08] do you have your key setup with gpg? [18:09] i think so [18:09] i followed the instructions on the pgp site [18:09] i mean gpg [18:09] and those of the bzr site linked from bzrVSgit [18:10] the one http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/ [18:12] dacresni, and you've setup the email to use to sign commits? [18:12] im using this localy [18:12] so no [18:15] dacresni, does: gpg --list-keys print out your key? [18:15] hmm [18:15] yes [18:16] and that's the same email address you have configure in "bzr whoami"? [18:16] pub something [18:16] uid, my info [18:16] accept for the comment [18:16] o wait [18:16] beuno, the upgrade prosedure at a launchpad branch sure takes a while :) [18:16] ok, so i put my whole name [18:17] thanks i guess ill be fixing that [18:17] alefteris, ah, yes, large branches + remote access are always fun to watch :D The upgrade is worth it though! [18:17] dacresni, np [18:18] shouldn't it not use the comment? [18:18] thats kind of silly [18:19] i have 2 keys, one at home and one at work [18:19] dacresni, that's why you can specify your email on ~/bazaar/, so it can find the key you want [18:20] i c [18:21]