[02:39] Is it possible to do a lightweight checkout of a remote git branch using bzr-git? [02:39] I heard bzr-git was unfinished, with no plans to finish it === jamesh__ is now known as jamesh [20:27] hi, I ran the trunk test suite on 14.04 and got 8 failures, is that expected? [20:28] this is a part of the failure log (gee, thanks gnome-terminal for insane default of 512 lines of backlog): http://paste.ubuntu.com/6728629/ [20:52] I'm not even sure how to read that log and identify what the 8 things are. [20:58] rozzin: I'm getting a fresh run with all of the failures [20:59] rozzin: a few were caused by missing python-lzma, now installed [21:00] rozzin: what remained now are tests related to gpg [21:00] rozzin: note, this is stock trunk on python2.7, nothing fancy yet [21:05] full failure log: http://paste.ubuntu.com/6728825/ [21:30] zyga: It looks like the ones that failed due to missing python-lzma were excluded from the `8' count, though. [21:31] zyga: Do you know which 8 tests are actually the ones referred to be "failures=8"? [21:32] zyga: I'm not really all that familiar with how any of this is implemented, but I'm willing to dig in and try to help. I used to be a Python programmer. [22:04] re [22:04] rozzin: I guess each of FAIL is one test [22:21] zyga: so i wont have time to dig into anything till this weekend, but i'm highly excited about your python3 porting effort :) [22:22] zyga: also, those failures seem (mostly) related to python-gpgme, so i'd first see if its tests pass on trusty - http://packages.ubuntu.com/search?keywords=python-gpgme [22:22] possibly related to gpg 1.4.15 being in trusty, dunno - http://packages.ubuntu.com/search?keywords=gnupg [22:23] jderose: thanks, I was suspecting the same thing [22:25] jderose: I'm looking at the code now, I think the first attempt will cut a lot of functionality, I'm quite surprised by how much stuff is inside bzr, I think that some strong decisions to drop things could make the (huge) effort doable but I'm not yet sure about what to consider dropping [22:25] if it is a python-gpgme issue, you should ping James Henstridge (dunno his IRC nick) - https://plus.google.com/u/0/+JamesHenstridge/posts [22:25] jderose: I'm currently removing lazy imports so that 2to3 can be more productive [22:25] jderose: once I get --help to run I'll post my code [22:25] sweet :) [22:26] i think there are areas that should probably be trimmed, but dropping support for any old formats kinda scares me :P [22:27] jderose: this is a fork, you can still use bzr --upgrade for old stuff [22:27] true [22:27] jderose: and the game is lost anyway, so it's not about keeping what we have, it's about making something that people want [22:27] good point [22:27] jderose: or what we can still *have* [22:28] does bzr still use pyrex? (been a while since i've looked at the bzr code) [22:28] jderose: yeah [22:28] jderose: more scary stuff for me ;) [22:28] how's that as far as python3? [22:28] hehe [22:28] jderose: not sure, I never wrote any, I'm considering dropping that if needed [22:28] jderose: as there are pure python versions too [22:28] jderose: right now I want to see bzr --help [22:29] might be something that would be better replaced with c extensions [22:29] yeah [22:29] sorry, getting ahead of myself... especially considering that fact that i haven't done anything yet :) [22:29] jderose: hey, I didn't do anything at all :) I just want to :> [22:30] i'm pretty sure you're a lot closer to `bzr --help` than i am :P [22:32] I wonder if some parts of bzr could be dropped/replaced by existing libraries, I feel that a lot of bzr is actually now available as readily-available modules that we don't have to maintain [22:32] especially a lot of the network code [22:32] I'd not worry overmuch (at least at the moment_ about the server shutdown failure. I think that's a somewhat touchy area in general, so... [22:32] fullermd: thanks! [22:32] fullermd: as long as trunk fails the same way as my neutered version I'm happy [22:33] * zyga reads the launchpad plugin code [22:33] And the builddeb stuff... well, shoot, nobody uses that "deb" thing anyway. [22:33] the single most important plugin [22:33] fullermd: yeah, speak for yourself :P [22:34] Naturally; I always speak for all right-thinking people :P [22:34] zyga: i think for the HTTP/HTTPS transport stuff, yes, the standard lib could replace a lot of things. BTW, I have a lot of experience with the Python3 `http.client` module. [22:34] OOHHH [22:34] hehe [22:34] so lp_api_lite [22:34] that's so sweet, no lauchpadlib [22:35] jderose: for all networking I was hoping to use requests, it's nice and shiny and has lots of usage, it seems to handle auth very well out-of-the-box [22:35] zyga: but there is also the custom SSH implementation (can't recall the python package name)... that might be a lot harder to replace [22:35] jderose: paramiko [22:35] jderose: yeah [22:35] right [22:35] paramiko isn't actually used most of the time. [22:35] jderose: I haven't looked at that yett [22:35] zyga: er, requests? is that part of httplib2? [22:36] Only on Windows sometimes I think, unless you forcibly call it. Usually just calls the command-line ssh. [22:36] jderose: I don't think so: http://docs.python-requests.org/en/latest/ [22:36] fullermd: so even when using the SSH transport (say, with launcphad), paramiko isn't used all the time? [22:36] Er, wait, maybe paramiko is still used for sftp. [22:36] fullermd: ah, good, something that can be dropped then [22:36] But yeah, bzr+ssh calls ssh(1). [22:36] fullermd: TBH, I only care about lp and local work, everything else is gone [22:37] gotcha, then that's easy to replace [22:37] Or even putty or something on Win, I think. [22:37] fullermd: I don't care for windows yet, lots of issues for no gain for now [22:37] But thinking about it, it probably IS used for sftp. How common that still is, I dunno; it's probably mostly OBE when the smart server came in, but I'll bet there are still niches. [22:37] fullermd: what is this "Win" you right-thinking people speak of? :P [22:38] jderose: the thing with metal bars ;) [22:38] It's a recursive toy. You get Win so you can toss it out a Win, for the Win :p [22:39] fullermd: i think if you have a launchpad account, most tend to use SSH as the transport. stuff like lp:foo automatically gets transformed into a bzr+ssh URI when you've set your launchpad username [22:39] hehe [22:39] Oh, sure. I'm not even sure LP still supports sftp (though of course it used to) [22:39] But people do once in a while use bzr on something other than LP :p [22:40] launchpad definitely supports SSH still [22:40] You mean sftp, or bzr+ssh? They're two vastly different things. [22:40] er, yeah, i mean bzr+ssh:// not sftp:// [22:40] not sure about the later [22:41] Yeah, bzr+ssh [almost] always calls out to a command-line ssh(1) if it can. Pretty sure sftp is all done via paramiko though. [22:41] interesting... i would have guessed the oposite [22:41] but dropping a dependencies is always good :) [22:41] Well, over ssh it just uses it as a tunnel to blat bytes over. It could probably be made to support bzr+rsh in about 2 minutes if somebody wanted to. [22:42] But sftp, you'd have to interactively script a program or something to call out like that, which is icky. [22:42] gotcha [22:43] I'm not sure that e.g. OpenSSH's sftp(1) even lets you do all the stuff bzr tries behind the scenes. The sftp protocol is hyuge compared to the 2 or 3 things 99% of the uses do. [22:43] mmm [22:43] I'm quite interested in what github did [22:43] with their move to abandon git:// and ssh and use https for everything [22:43] they still support that but actively discourage it [22:43] Obviously, got hold of some very good drugs. They went with git, after all. [22:44] fullermd: indeed [22:44] git has a very simple model and no content type conflicts ;) [22:44] plus their excellent security track record :D [22:44] jderose: who cares, they are being used [22:45] i'm pretty sure these days you can replace "who" with "governments, large companies, non profits, etc..." :P [22:46] jderose: the same ones that run java and winxp [22:46] No, I'm pretty sure nobody cares about security, just like the last 20 years... [22:46] jderose: I agree that security is good but secure dead software is not useful [22:46] true [22:47] they care about wiretaps but they don't really care that $vendor got owned $number of times as everyone gets owned once in a while [22:47] jderose: if security was important we'd be running solaris, not linux ;) [22:48] Nah, I'd vote for AIX. [22:48] * zyga is too young for that [22:48] When I _adminned_ an AIX box, I could never get it to do what it was supposed to. How's somebody who's not root gonna pull it off? [22:49] btw, is knit a word I should know or some fancy invention? [22:50] Well, I'd expect you to know it as a word in general. The application into version control is a bit of an analogical invention. [22:50] fullermd: I'm not familiar with it [22:50] fullermd: what does it mean? [22:50] fullermd: knit was a specific repository format, right? [22:50] * zyga is google lazy while reading python on the next monitor [22:51] The way you make socks and sweaters and scarves and such? [22:51] aaah [22:51] from tiny threads and such? [22:51] In bzr, it was a history storage format, succeeding weaves. [22:51] fullermd: is knit the current history format then? [22:51] (hence the choice of naming; knits are like weaves, but append-only instead of constantly re-weaving, and since you knit purely from a top end...) [22:52] No, [pure-]knit was replaced by pack-0.92 which used knits internally, and that was replaced by 2a. [22:52] ah, gotcha [22:52] I still come across pack-0.92 stuff occasionally, but it's gotten pretty rare. [22:53] ah, i remember when pack-0.92 was the new hotness :P [22:53] The re-weaving with weaves was crazy expensive. [22:54] I remember back when bzr.dev was still in weaves, and I had to carefully time my daily pulls, because they would nail up the CPU for about 20 minutes. [22:54] hehe [22:54] (the crazy-slow reputation bzr still carries may be almost totally historical, but it sure was earned at one time...) [22:55] yeah, i do remember those days [22:56] knits were a huge improvement. packs made a number of things better too; for one thing, I could take annoying hacks out of my Apache config to avoid interpretting the knit filenames. [22:56] well [22:56] it's not crazy slow [22:56] but noticeably slower than git on anything [22:56] and pushing is dead slow [22:56] Try it with weaves; you'll get a great appreciation for how fast it is now :p [22:56] not sure if lp or bzr are to blame there [22:56] hehe [22:57] I remember all the old versions of bzr [22:57] But it is python, so stuff like startup is always gonna be way slower. [22:57] I was using it from the start, almost [22:57] way before I joined Canonical [22:57] Those lazy imports you were talking about were a major improvement in that. [22:57] yeah, I know [22:57] now I'm just killing the magic to get 2to3 to see stuff [22:57] * fullermd pictures you with a 7 foot spear standing over a dead unicorn... [22:58] fullermd: but they are full of candy inside [22:58] ;) [23:01] I have vague memories of 2to3 experiments a couple years ago. Seems like a few bumps were hit and then it was set aside due to nobody caring enough at the time. [23:02] Probably far enough back now that whatever lessons were learned are pretty stale. [23:02] fullermd: I think that 2 and 3 codebase is hard [23:02] fullermd: especially since bzr still supports really old code syntax [23:03] I think the really old stuff is gone (or at least not necessary); think the last few major releases have been 2.6+ only. [23:03] (3 being a major reason behind that) [23:04] fullermd: the code is full of 3.0 incompatible syntax though [23:04] fullermd: one thing I learned to like about recent pythons [23:04] fullermd: is that I can drop hacks [23:04] Oh, sure. But dropping 2.4 meant we could dump a lot of _required_ 3.0 incompatible stuff. [23:04] fullermd: drop static copies of stuff I needed but wasn't around [23:04] fullermd: and that my code kept getting smaller and easier to follow [23:05] fullermd: I think that 3.2+ is good enough though 3.3 could be sweeter as it has even more goodies that can replace bzrlib home-grown code [23:05] I'd bet there's a lot of stuff hiding around in bzrlib that's still 2.4 compatible but doesn't have to be. [23:05] yeah [23:06] * zyga just read 'this is not present in python2.2 so here's a copy' in one file [23:06] 2.2 [23:06] configobj.py [23:07] Hey, it's a palindromic version. Gotta support those. [23:07] what is rio [23:07] Serialization format, I vaguely remember? [23:07] hmm [23:07] relevant? [23:08] I _think_ it was something from old formats, like pre-pack knits and before. But that's very vague memory. [23:08] one thing I always liked about bzr is that it was a promise of pythonic api for vcs'es [23:08] but it was so complex that I never really got to like it or felt it was simple [23:09] and the layers of layers of indirections were a major factor each time I tried following the code [23:10] Hey, don't tell that to me; I'm the guy who doesn't like OO wholesale :p [23:11] python2.4 support is alive and strong in some files :) [23:15] Looks like it was the 2.4 release series that officially dropped py2.4 and 2.5 support. Appropriate.