=== kiko-afk is now known as kiko-zzz [00:02] schierbeck: yes, though I can try to change that [00:05] that would be great -- i have a one-line patch that fixes a crasher in the mainline version of the viz [00:06] i'm not sure if it needs to go through the review process -- even if it doesn't, i'm not able to push [00:07] schierbeck: ok, it's now at ~bzr-gtk/bzr-gtk/trunk [00:07] wow, that was fast [00:07] do you think i should push the revision? [00:07] it's just removing an import of a now nonexisting file [00:08] yeah, sounds good to push without review [00:08] so now the main branch is at ~bzr-gtk/bzr-gtk/trunk you could start pushing your own approved revs :-) [00:09] nice :) [00:11] What order are the sections ("BUG FIXES", "IMPROVEMENTS", etc.) in NEWS in? [00:17] Peng: I'd suggest looking at NEWS to find out. :p [00:19] Newbie question: I'm working on a project with the "Decentralized with shared mainline" workflow. I want to "fork" the project into two different development efforts. I guess this would be "making a new revision"? But what is going to happen when people start pushing their changes back to the mainline from the two different branches? Is there a best practises for this, or am I going about it the wrong way? [00:20] * sorry I meant to say "This would be 'making a new branch'?" [00:21] GuyIncognito: What you would do is 'branch' the shared mainline into a separate branch. You would then 'merge' changes from that branch back into the mainline. [00:23] Old_Bloke: OK. What happens if several people want to work on the new branch? [00:23] Odd_Bloke: Seems to be arbitrary. [00:26] GuyIncognito: You can have multiple shared branches, instead of just one. Just set up the second similar to the first. [00:27] GuyIncognito: Well, any given branch can be treated as centralised. That is to say you could branch 'mainline' to 'feature-1' and then have people use 'feature-1' using any of the listed workflows. [00:27] * Peng adds a reference to the bzr branch to the trivial bug he's been working on. :O [00:28] I feel kinda bad about polluting the big important list of branches with something trivial. [00:28] But it also has taken a few commits and continued to be modified, at least a little. [00:32] fullermd, Odd_Bloke: Thanks! [00:32] GuyIncognito: No worries. :) === Necrogami is now known as Necrogami|Sleep [01:08] Hyello [01:09] Does anyone else have problems with Launchpad & olive? [01:09] I try to grab from there or push and I get "unexpected response" [01:10] The location for bzr-gtk has just moved to ~bzr-gtk/bzr-gtk/trunk [01:10] ? [01:12] ? [01:12] Were you talking to me? [01:13] Yes. I thought that might be relevant to you. [01:14] Hmm [01:14] Still wondering why no SVN on launchpad :P [01:15] Still wondering why no SVN on list of "once-popular products that no one's using" [01:16] ...no-one's using SVN? [01:16] No one should be. [01:16] (I know of at least 30 off the top of my head) [01:16] Well, i've had nothing but problems with bazaar -_- [01:17] I'm sorry to hear that. [01:18] It probably saw svn installed on the system and got huffy. [01:18] So what protocol are you using to retrieve bzr-gtk? [01:19] I'm trying to use olive at the mo [01:19] Same source tree. [01:19] Can i get bzr-gtk via yum [01:21] No idea. The Bazaar project has debs, but I don't think any rpms. [01:21] Yeah, I have it [01:21] But there's no GUI [01:21] It's just tools [01:21] And I'm using KDE :P [01:22] bzr-gtk is a plugin for Bazaar that aims to provide GTK+ interfaces to most Bazaar operations. [01:22] Can probably do a quick grep through yum list (or is it yum search? I can't remember) to see if it's in its standard repo. [01:22] The Bazaar project has debs FOR BZR-GTK, but I don't think any rpms. [01:23] Well, no app is shown [01:23] lessee [01:23] I know what bzr-gtk is. I am one of the contributors. [01:23] If it's not in the 'official' yum db, I haven't heard of anywhere else offering RPMs (which doesn't mean much since I don't track that, but...) [01:25] Oh dude [01:25] If it's not there, it's probably easiest (for experimenting, anyway) to just grab a copy manually and stick it in your personal plugins dir. [01:25] Now I have to install nautilus [01:25] No way am I using bazaar [01:25] :X [01:25] You don't have to for bzr-gtk itself; some package may be listed with it. I sure don't have nautilus around. [01:25] Nautilus is not a hard dependency of bzr-gtk. [01:26] Man, good [01:26] Cause it's nowhere near as good as Konqi :/ [01:26] Anyhow [01:26] Is that some new-fangled version of 'ls'? ;p [01:26] What is just, the long and short of it -- how do I make it easier just to commit without having to fanny around? :P [01:27] It's getting annoying when there's GUI's that don't work and bazaar is similar to arch [01:27] I'm not sure what you mean about guis that don't work. [01:27] Olive doesn't work [01:27] That's a bit off my turf. I always just use the CLI; only thing I generally use -gtk for is an occasional viz. [01:27] Won't let me commit, won't let me pull [01:28] Can't connect to servers [01:29] Well, commit works for me. [01:29] Using olive? [01:29] Okay, well if this is the case maybe I'm not getting the connection URL's correct [01:29] You'd probably have to be a little more specific about what you're trying to commit/pull and what servers :p [01:29] What's the actual URL you need to specify [01:29] My project on launchpad is photoncrm [01:30] And the advised path is ~jordancdarwin/photoncrm/modules/ [01:30] JordanC: yes, using olive. [01:30] So 'bzr+ssh://jordancdarwin@bazaar.launchpad.net/~jordancdarwin/photoncrm/modules/' for pushing. [01:30] JordanC: ^ [01:31] For writing it, I think it would be something like bzr+... what Odd_Bloke said. [01:31] Still [01:31] When I use that, I get "Cannot read response from server" [01:31] And for pulling? [01:32] Mmm. I get a bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~jordancdarwin/photoncrm/modules/" when I try branching it. [01:32] bzr push bzr+ssh://jordancdarwin@bazaar.launchpad.net/~jordancdarwin/photoncrm/modules [01:32] That's what I get given [01:33] Haha [01:33] Yeah, it just crashed [01:33] Well, it looks like there really is no branch there. [01:34] " This branch has not been published yet." [01:34] So LP has the branch listed, but not really there. I don't know LP well enough to know how you do that, or fix it. [01:34] I've never created a LP branch except by pushing it. [01:35] Why is it that after some errors, GTK will actually not allow me to click buttons, but use the keyboard instead? Argh, frustrating [01:35] Hmm [01:35] Unsupported protocol for url "bzr push bzr+ssh://jordancdarwin@bazaar.launchpad.net/~jordancdarwin/photoncrm/modules" [01:35] Everything is fine [01:36] Hang on [01:36] Why is it pasting that [01:36] Okay, here we are [01:36] Unknown error [01:37] end of file reading from server. [01:37] :) [01:37] The bzr+ssh protocol has poor diagnostics. [01:37] Try using sftp instead. [01:37] In olive? [01:37] Sure. [01:38] Same error [01:38] Just switch sft for bzr+ssh in the URL. [01:38] Yeah, I know how to do it ;-) [01:38] Sorry "sftp". [01:39] Okay, can you log into launchpad? [01:39] Already done [01:39] e.g. using an sftp client? [01:39] Yes [01:40] Works fine [01:41] And you're using the same user-id? [01:42] yup [01:43] Sound like you need to talk to someone in #launchpad, then. === mw is now known as mw|out [03:25] jam: ping === Necrogami|Sleep is now known as Necrogami [04:11] I can't remember, bzr branch lp:/// support is in bzr proper correct? Not bzrtools? [04:13] gdoubleu: Technically, I think it's in the launchpad plugin, but that's shipped with bzr. [09:12] anyone got any clues on this error ( trying to use bzr-svn ) [09:12] http://paste.ubuntu.com/2392/ [09:12] *hopes some is awake at this hour* [09:13] imbrandon: Upgrade to >= 0.92 and try again [09:13] imbrandon: (1.0rc1 would be better) [09:14] AfC: ok , is it in hardy or do i need to compile [09:14] i'm running gutsy with all -backports/-updates [09:15] imbrandon: I haven't the faintest idea what a gutsy, hardy, or whingy are, but if you look on the Bazaar website you'll find that they have an apt repo that Debian derived distributions can use. [09:15] AfC: rockin ok, ( fwiw they are the ubuntu codenames ) [09:16] gutys being the latest stable , anyhow thanks, i'll try that [09:16] gutsy* [09:18] * AfC is heaping scorn on the idea a) of codenames, and b) that Debian and Ubuntu people seem to expect that anyone else would have the faintest fucking clue what the hell they are talking about [09:19] no i dident *expect* you to know, sorry for the assumtion, bzr being another canonical project i assumed the right hand would know about the left hand, but assuming makes an ass+u+me , wont happen again [09:24] Anyway, 0.93 ^W 1.0rc1 is just out, and you'll probably do well to give it a try as it's 3-4 months (and 3-4 releases) newer than what you were using. The Bazaar hackers continue to move at an astonishing rate and problems encountered in a version that's that old are likely long since resolved. [09:27] k [09:48] Hey dudes [09:48] :) [09:51] ello JordanC [11:25] siretart: so, as a person who's fought with Recommends... ;) what's your opinion on having bzr recommend: bzrtools, and suggest: bzr-gtk, bzr-svn [11:25] siretart: I think bzrtools is on the verge of not being appropriate for recommends, but only on the verge :) [11:27] dato: I would argue this way: [11:27] dato: would you expect a typical bzr user to also install bzrtools? [11:27] if yes -> recommends, if no ->suggest [11:28] (I'd vote in favor of it) [11:29] yeah, me too. I think it'd be useful for it to be available by default. [11:29] I'm also revamping the description. [11:29] great, thanks [11:33] jam, vila: I would also like to know whether you think python-pycurl should still be pulled by default when installing bzr (in Debian, and possibly in ubuntu), or it's better to leave it out now. [11:38] siretart: do you have any idea why on earth we Suggest: libxml2-utils? [11:38] dato: no idea. maybe lifeless knows? [11:39] maybe. the changelog is not helping. [11:40] /usr/bin/xmllint, /usr/bin/xmlcatalog [11:40] I'm not sure what either of those would be for. [11:40] hi all btw. [11:40] hi james_w [11:48] oh, no jelmer [12:13] siretart: http://dpaste.com/26427/ [12:16] dato: conclicts [12:17] "yet able to adapt to many workflows, reliable, and easily extendable." is a little uncomfortable, I would suggest dropping the "yet". [12:43] james_w, thanks, fixed (both). [12:44] dato: it's good, thanks for doing it. [12:46] "no special software the server is needed" ? "no special software is needed on the server" [12:47] the intention was "no special software *in* the server is needed" [12:47] regarding pycurl, there are two http implementations in bzr: one based on pycurl, the other on urllib [12:48] yes [12:48] if pycrul is the default if present [12:48] yeah, I know. [12:48] the major difference is that pycurl verifies ssl certificates [12:48] the question was, whether to make installing bzr in a system also pull pycurl in [12:48] iow, what do you feel that would be a better default: pycurl available or not [12:49] dato: I would think available. [12:49] dato: I'm a bit biased since I rewrote most of the urllib ;) [12:49] also looking again I think vila's "no special software is needed on the server" is better. [12:50] ok, done [12:52] frankly I don't know if pycurl should be pulled or not. When people want certificate verification pycurl is mandatory (today), if they don't want certificate verification pycurl should be avoided (by forcing the use of urllib) [12:52] of course the best solution would be to get vila enough spare time to add certificate validation to urllib. [12:52] vila: avoided? [12:53] james_w: ;-) [12:53] yeah, pycurl wont let you access a site with a self-signed certificate for instance, so you have to force urllib to access it. [12:53] dato: no hhtps connection can be issued if certificate verification fails (included self-signed certificates) [12:54] and also if your installation is screwed or the site use an unknown CA [12:54] since urllib makes no verification... it's usable. *And* I will provide the necessary hooks to allow urllib to cope with the situations above [12:55] so, maybe not pull pycurl, and leave a note in README.Debian on when it could be useful? [12:55] maybe downgrade it to suggests [12:55] ah, I meant to mention in the description what paramiko is useful for [12:55] you stop doing that ? [12:56] put it back and add an equivalent section for pycurl maybe ? [12:56] stop doing what? there was never any place in the debian packagin explaining what was paramiko needed for [12:56] s/if your installation is screwed/& regarding the certificates/ [12:57] I heard at least two reports (or three) where the ca-certificates package were not installed even when pycurl was (or liburl, or curl, whatever ;) [12:58] s/liburl/libcurl/ [13:00] err, waitaminute, james_w, *you* had a case where ca-certificates not installed no > [13:00] s/>/?/ [13:01] vila: yeah, I've tried to see why, but I'm couldn't see it. [13:01] dato: sry, misunderstood you, I thought you said you *was* doing, I think it will be a good idead to do so. [13:02] james_w: I think I sent you an email afterwards with some hints (after looking a bit myself) [13:02] Subject: ca-certificates as a bzr dependency [13:02] To: James Westby [13:02] Date: Wed, 21 Nov 2007 12:01:48 +0100 [13:02] vila: yeah, thanks. [13:02] AAARGH silly posting addresses here :-( [13:03] so sorry :( [13:03] is paramiko needed to push over bzr+ssh? [13:04] vila: no problem, there are plenty of other places to harvest it. [13:04] and the '+' is a good anti-spam device anyway. [13:05] really ? I was wondering about that cause my spam level have never been too high and I tend to always use + addresses [13:06] dato: checking... [13:07] dato: yes it is [13:07] thanks [13:07] bbiab [13:07] (maybe it'd should be a dependency then) [13:07] bbiab [13:07] vila: my MTA's logs show loads of rejects to debian@jameswestby.net, which I think is a great help. [13:09] amazing... I thought there were clever enough to include + as a valid component... or may be the clever ones think that people using + are naturally anti-spam ;-) [13:10] regarding urllib's certificate verification, I have a branch whith an https test server using the ssl module provided by python2.6 (after dirty port of bzr to python2.6) [13:12] this branch is on the back burner for now because that module is currently under work in 2.6, 3k and as a package for py2.3->2.5, so it's bit hard to find the right version ;-) [13:12] 2.6, 3k and the package being at different levels last time I checked... [13:14] vila: apparently 0% of my current spam folder (1700 messages) is to that address, > 90% of ham is to that address. [13:14] do other countries have the real SPAM, i.e. the meat product? [13:15] Not that I know of ;-) [13:16] ah, you're missing out. === Gwaihir_ is now known as Gwaihir [14:11] vila: What's it used or? The ssh connection can be through openssh, and the protocol is our own. === Gwaihir_ is now known as Gwaihir [14:33] abentley: try: [14:33] from bzrlib.transport import ssh [14:33] except errors.ParamikoNotPresent: [14:33] # no paramiko. SmartSSHClientMedium will break. [14:33] pass [14:33] in smart/medium.py [14:34] ? [14:34] Perhaps it's used for something, but I would have thought not. [14:35] me too, that's why I checked, I'm as surprised as you, may well be a bug [14:37] I guess we'll just have to harass spiv. [14:38] spiv: ^ === mw|out is now known as mw === n2diy_ is now known as n2diy [16:51] New bug: #173274 in bzr "Allow pre-export hooks" [Undecided,New] https://launchpad.net/bugs/173274 [16:58] abentley: your announcement of bzrtools 1.0 doesn't mention switch being merged into core. Did it make it into 1.0rc1? [16:59] Actually, I did mention switch. [16:59] Oh, drat. [16:59] I meant "switch", not "shelf". [17:01] Okay, I've fired off a correction. [17:03] ah, that explains it :-) [17:19] Huh. Now that I'm using bzr.dev, I don't want to bother installing 1.0rc1. [17:25] Yeah, I'm chronic that way. [17:26] I did have to revert to 1.0rc1 temporarily, to make sure bzrtools 1.0.0 works with it. [17:29] Which you can do with "bzr revert -r branch:http://bazaar-vcs.org/bzr/bzr.1.0/" [17:30] What the hell is wrong with Firefox? It refuses to download GPG signatures. /me wgets the bzrtools .sig file. [17:32] so why's bzr.dev still claiming it's 0.93 ? shouldn't that be 1.0.1 ? [17:34] NEWS was updated but I guess nobody got around to updating the version number. [17:35] And now they're off for the weekend? [17:41] Going from an installed copy of 0.92 to 1.0rc1 is a 291 KB pack. :) === [1]Necrogami is now known as Necrogami [18:04] Hm, it's not possible to branch a dirstate branch into an (empty) pack repo? [18:04] Oh, never mind. [18:05] dirstate-with-subtree. [18:05] Yes, "KnitRepository" is super-useful information. [18:09] jelmer or something: Who runs doc.bazaar-vcs.org? The docs need to be updated. 1.0rc1 links to packrepo.html but it's still a 404. [18:19] Peng: I think one of poolie, jam or lifeless should be able to update it. [18:21] Okay. [18:22] jam or lifeless or someone: http://doc.bazaar-vcs.org/latest/developers/ needs to be rebuilt. 1.0rc1's "help formats" links to packrepo.html, but it's still knitpack.html on the server. It would also be nice if there was a 301 redirect from knitpack.html to packrepo.html. [18:28] Am I still connected? [18:28] jelmer: re REJECT, possibly the XS-* field has to be installed in the archive, not only in incoming, for it to work; so try again tomorrow [18:28] Peng: no :) [18:28] That was weird. [18:29] I lost my connection to the Internet, but the DSL light on the modem was still on. Then while I'm reconnecting to all the IRC networks, the last one, Freenode, recovers. [18:29] Weird. [18:30] not really... [18:30] Yes it is. [18:30] why? [18:30] How can I get disconnected without either the modem or computer being aware of it? [18:30] did you get a new IP? [18:30] ah [18:30] Nafallo: Nope. But since my account was shuffled around, I've stopped getting new IPs anyway. [18:31] (The one time it's gone down since it was shuffled, anyway.) [18:32] well, your PPPoE can disco without line-sync go down, and your computer is only aware of connectivity to the modem. [18:32] as far as freenode go, you never reached the TCP timeout. [18:33] Not PPPoE anymore. "ENET ENCAP". [18:33] My hostname changed from saying "dyn" to "dhcp" and now I get crappier IPs. [18:34] nice :-) [18:41] I got a new modem too, because apparently mine should've burned out years ago. I'm still using the old one because I don't want the (minor) downtime. I was just about to switch it out before the connection started working again. [18:41] Anyway, back on topic. Not like anything's happening... === weigon_ is now known as weigon [19:25] jelmer: ping [19:33] hello, I checked out the ubuntu-hardy docs branch from LP... I then changed my "name" and "Display Name" in LP and I can no longer commit [19:34] I think the local version is still using the old name [19:34] is there a way to change that without re-downloading? [19:34] Peng: which branch? the one took to hg? basically I'd like to know how we compare [19:34] Peng: are we still so slow you would have moved? [19:35] lifeless: Can you rebuild the docs? Or poke someone who can? [19:35] I'll see what I can do [19:36] Thanks. [19:36] sommer: you probably want to use 'bzr bind' with your new username in the URL. [19:36] james_w: ah... I'll try that [19:36] Let's see how long it takes to extract a 1.3 GB .tar. [19:37] Peng: obviously for these tests I want you to upgrade the branch to packs [19:38] 1 minute and 3 seconds! [19:38] james_w: genius that worked. Thank you very much [19:39] Hmm. I had like 8 copies of the data, and removed all of it except for 1 copy (well, there are still 2 copies of the bzr repo), and it looks like I took the copy I was experimenting with with it. [19:39] What makes something a shared repo vs. a non-shared repo? The presence of a branch in the same dir? [19:39] .bzr/repository/shared-storage [19:40] Ah. [19:40] Bah, should've just checked. [19:41] Now, let's see how long it takes to convert to packs. [19:42] (even worse, pull into a new branch, building a new working tree) [19:42] Think I have time to brush my teeth? [19:42] Well, let's see if I can brush my teeth in time, then! [19:42] BRB. [19:46] Hmm. It might work well to use git for ~/local instead of bzr. Since it doesn't track renames, I don't have to try to. [19:47] Wait, I do like being able to do renames, though. [19:47] rofl [19:48] I like being able to do renames when I want to, but I don't want to have to think about them when I don't. [19:49] commit --automatic is what you want [19:49] as we delete automatically today [19:49] you can do: [19:49] bzr add; bzr commit; [19:49] and you'll get a new snapshot [19:49] no thought. [19:55] Oh, gosh. It only took 9 minutes. [19:56] Now, why am I swapping so badly? [19:58] Better now. I guess bzr had just used a lot of RAM. [20:08] lifeless: Wow. 17 seconds user time. Slightly higher sys than with hg, I think. :P [20:09] lifeless: Now, it's gotten larger since this old copy was made, so it would be slower (no idea how much), but if bzr was this fast in August, I never would've switched to hg. [20:09] * Peng wanders off. Star Trek. [20:35] Peng: cool [20:37] Peng: btw, histor shouldn'y slow it down noticably for commits anymore, only total count of files/size of changed files. [21:34] lifeless: Cool! [21:35] lifeless: Same with hg. [21:38] Meh. The problem with me is also that the files I'm committing keep getting larger, so even if history doesn't slow it down, the diffs will. [21:49] * Peng wanders off. [22:28] jelmer: btw, you were the second approver of my small patch to NEWS, maybe you could merge it? http://bundlebuggy.aaronbentley.com/request/<20071129185051.GA12330%40chistera.yi.org> [23:29] lifeless: ping