[00:00] just to mention, it seems to say that it needs "libsvn" but that isn't going to be installed [00:00] So perhaps it doesn't install dependencies of Build-Deps ? [00:00] So you have to explicitly enumerate all of them? [00:00] ah lpia [00:01] I don't quite understand why it wouldn't complain on ~hardy, but maybe the packages already exist there? [00:01] subversion hasn't built on lpia in Intrepid [00:01] james_w: well, it also failed for amd64 [00:01] so it can't install the packages [00:01] with the same error? [00:01] but it could be the same reason [00:01] james_w: essentially [00:01] http://launchpadlibrarian.net/17103816/buildlog_ubuntu-intrepid-amd64.bzr-svn_0.4.11-1%7Ebazaar1%7Eintrepid_FAILEDTOBUILD.txt.gz [00:01] the packages are there for amd64, so it shouldn't be the same [00:03] james_w: well, it did fail, but I see what you mean from "rmadison" the packages *are* available for amd64 [00:03] strange it has built on lpia, but rmadison doesn't list them [00:03] and it built ages ago, so it shouldn't be archive skwq [00:03] skew even [00:05] I prefer skwq [00:05] I think that is the root cause [00:05] vreixo: regarding signing commits -- you can find information here: http://bazaar-vcs.org/ConfiguringBzr [00:06] heh :-) [00:06] does anybody know of any docs on how one might use looms with packaging? [00:06] LaserJock: I don't think there are any yet [00:06] jonnyde1: The main doubt I have is how to choose the key used to sign [00:06] LaserJock: the NoMoreSourcePackages page gives an idea [00:07] it is chosen by your configured bazaar identity [00:07] sure? and it takes the email into account? [00:07] it must be exactly the same as used in your key [00:07] yes, AFAIK [00:08] I've tried bzr sign-my-revisions and it uses a different key [00:08] my identity is bzr whoami, no? [00:08] yes, it is [00:08] it uses your default key I thought [00:08] I think there was a bug opened on this the other day [00:09] james_w: hmm yes, that does have some ideas on workflow. It seems a bit complicated though [00:09] maybe it's the default key... but I think I've read somewhere that you should have the right whoami [00:09] in fact, I'm doing it like this and it works.... [00:10] but try to set it as the default key in your keystore [00:11] ok [00:12] LaserJock: complicated where? perhaps we can do better? [00:12] or just overall? [00:13] vreixo: make sure you've set the whoami identity like: "Your Name " [00:13] jonnyde1: I have [00:13] I had [00:14] ok [00:14] jonnyde1: $ gpg --list-keys [00:14] pub 1024D/1635CB33 2008-02-20 [00:14] uid Vreixo Formoso [00:14] ... [00:14] pub 1024D/66A4028A 2008-08-16 [00:14] uid Vreixo Formoso [00:14] james_w: maybe complicated isn't quite the right word [00:15] $ bzr whoami [00:15] Vreixo Formoso [00:15] but it uses the other key! [00:15] james_w: maybe it's not very "packaging-like" but more "vcs-like" [00:15] so maybe it's indeed an issue with the default key.... [00:17] LaserJock: yeah, I guess. Does that apply to the "wrapped" command set outlined as well, i.e. "new-patch fix-2345" or whatever it is called? [00:18] james_w: I don't think that's on NoMoreSourcePackage, but that might help [00:19] vreixo: in your ~/.bazaar/bazaar.conf you should find your identity set by whoami, I think... [00:19] LaserJock: ah in the HCT stuff, so it's not quite the same thing [00:19] jonnyde1: it is right [00:20] LaserJock: at the moment we are trying to build a set of VCS "primitives" that will allow us to model the workflow, and then we can evolve a set of tools on top that are more task-oriented for packaging. [00:20] LaserJock: or, that's my hope anyway :-) [00:20] mhm, makes sense [00:21] so loom does this quite well I think [00:21] vreixo: sorry, but that's the only advice I can give you... for me it worked right from the start... [00:21] perhaps topgit is better, but I think it's too complicated, and the task-oriented stuff will be harder === mario_ is now known as pygi [00:22] jonnyde1: tanks anyway, I will try with the deafult key idea [00:22] james_w: do you know of any efforts for sort of an inbetween flow, between no VCS and NoMoreSourcePackages? [00:22] james_w: it seems like such a huge jump [00:22] good luck! :) [00:23] LaserJock: well, NoMoreSourcePackages is kind of two things, there's the "No more source packages" part, which I hope we will reach by getting to a point where we don't want them in our workflow as they are more hassle than they are worth [00:24] LaserJock: for the command set parts it will be an evolution to get those commands (possibly there will be several tools along the way), so it won't be an instant thing [00:24] james_w: right, at some point we just replace, debuild -S && dput *_source.changes, with bzr push [00:24] LaserJock: and in the mean-time you can avoid loom and use bzr if you like, handling .diff.gz as the diff between two branches, which is much the same as you have now. [00:25] LaserJock: I hope so [00:26] james_w: one of the parts that's kind of making me wonder is that, in Ubuntu at least, many developers only upload a package once or twice [00:27] so I wonder what advantage all this workflow/vcs work is to them [00:28] I'm not sure [00:28] in essence, many developer may not care at all about history, feature branches, tracking patches, etc. [00:28] but if it makes their work easier and more efficient they will "care" [00:28] which makes NoSourcePackages possibly turn into a burden [00:29] well, that's the part that I'm trying to get my head around [00:29] how would it make their work easier and more efficient? [00:29] so an example from an hour or so ago [00:30] I had a sponsorship request open on lvm2 for a while, and in the meantime there were uploads to Ubuntu [00:30] I had the packages in bzr from dogfooding my work, so I spent a couple of minutes importing the new uploads (which no-one else will have to do) [00:31] I ran bzr merge, and got everything merged, with a couple of merge conflicts [00:31] then committed and regenerated the request [00:32] ok, so in that the advantage was bzr's merging abilities [00:32] so, I noticed the problem and ran one command to merge the work. It was done using history, not 2-way, I got easier to deal with conflicts (in my opinion), and had the history there in e.g. annotate to work out what to do. [00:33] if I hadn't I would have had to have download the new packages, generate a diff, apply that, got .rej files, worked out what had gone on from reading changelogs [00:33] *I* think that is so much easier [00:34] I know that I'm very comfortable with bzr though [00:34] it is, although i'm not sure how often we get conflicts [00:34] most of the time it's just download new package, re-apply patch, re-debdiff [00:35] but when it's not it's much harder [00:35] for sure [00:35] we have e.g MoM to automate this for merges [00:36] hmm, MoM-as-bzr would be interesting [00:36] we could build similar tools for all of the cases where things fall down, like the above case of the archive moving underneath you, or we could build on top of a framework that allows to more easily do it for anything [00:36] if we could just grab current Debian version, branch from MoM and work on the merge all in a bzr repo that'd be pretty sweet [00:36] and gives the same benefits whether we are in the easy case or the hard case [00:36] jam: did you want a standup? [00:37] in phase 2 we will have Debian in bzr, so it would be simply "bzr merge lp:debian/unstable/gcc" or something [00:37] and MoM can do dry runs and publish results in the same way as now [00:39] james_w: sound quite interesting [00:39] can bzr make "quiltable" patch series? not sure if my terminology is quite right there, I don't use quilt [00:39] we need to do better at explaining these benefits, as I don't think many people see where we can go with this [00:40] yeah, it could, there's a couple of ways [00:40] it may be a good way to go. [00:40] I wonder how good collaboration with Debian would go [00:40] one problem at the moment that merging debian/patches/* really screws you up, we need to improve that somehow. [00:40] so converting to bzr on the way in, and then converting back when building the source package would be one way [00:41] I'm kinda getting to the point where perhaps just sharing patches rather than debdiffs or DVCSs is the way to go [00:42] so something we can easily do is provide easy ways to spit out various sorts of patches, so you would fix something in bzr, and then spit out e.g. a dpatch to forward to Debian. We can then improve on that [00:42] thought generating plain patches is good for 90% of cases or more [00:43] hmm, yeah [00:44] if I were to be able to look at what the Debian maintainer is using (say dpatch) and then run something like gen-patch --dpatch that'd be really cool [00:45] if you use looms to manage the Ubuntu branch, thats totally doable [00:45] probably 20 lines of python to add a command to do that to loom [00:45] rockin' [00:46] james_w: so the gtk one, what do you need from me? I can't upload to main.. [00:47] is -gtk main? [00:47] nope, universe [00:47] oh huh universe [00:47] can't you upload it then ? :) [00:47] nope [00:47] hmm, syncs are meant to be done by archive anyhow [00:48] lifeless: yeah, but I needed a sponsor to ACK it for the archive admins to look at it [00:48] well, confirm it and subscribe ubuntu-archive [00:48] I've commented on both [00:48] hmm, am I still in sponsors [00:49] you don't need to be in the team as far as I know [00:49] I'm in ubuntu-{universe,main}-sponsors if you need anything [00:49] thanks LaserJock [00:49] LaserJock: if you could process https://bugs.edge.launchpad.net/ubuntu/+source/bzr-svn/+bug/261653 [00:49] Launchpad bug 261653 in bzr-svn "Please sync bzr-svn 0.4.11 (universe) from Debian experimental (main)" [Wishlist,New] [00:49] https://bugs.edge.launchpad.net/ubuntu/+source/bzr-gtk/+bug/261645 [00:49] Launchpad bug 261645 in bzr-gtk "Please merge bzr-gtk 0.95.0-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed] [00:49] LaserJock: would you be willing to ack a couple of main sync requests as well then please? [00:49] I don't do enough syncs to keep it all paged in, I was just checking the current procecss [00:50] james_w: where is the bzr 1.6 sync request? [00:50] james_w: depends on how many ;-) [00:50] lifeless: bug 261636 [00:50] Launchpad bug 261636 in bzr "Please sync bzr 1.6-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/261636 [00:50] LaserJock: 3 [00:50] LaserJock: I think thats all [00:50] LaserJock: that one, and bug 261644 to go with it [00:50] Launchpad bug 261644 in bzrtools "Please sync bzrtools 1.6.0-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/261644 [00:51] 4 [00:51] :P [00:51] then bzr-svn sync for universe, and bzr-gtk merge [00:51] ok, so bzr-* ? :-) [00:52] jelmer has already done all the lesser plugins and got acks, so with these four we get most-recent everything, with everything compatible [00:52] jam: ping [00:52] lifeless, if you feel like uploading bzr-search, maybe that can make it into intrepid as well [00:52] almost made it earlier but got rejected because of incorrect debian/copyright [00:53] jelmer: garh [00:53] jelmer: url me up I guess [00:53] packaging is so 1960's though [00:54] lifeless, http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=bzr-search [00:54] lifeless, are you calling me oldfashioned? :-P [00:54] damn thats a fugly url [00:54] * jelmer gives lifeless a gentoo ebuild [00:54] shudder [00:55] jelmer: don't you want sponsor-packages? [00:55] jelmer: is the package anywhere that doesn't suck arse? [00:55] lifeless, try http://mentors.debian.net/debian/pool/main/b/bzr-search/ instead [00:55] jelmer: cause that site wants me to log in 'first'. IDIOTS [00:56] yeah, sorry, I gave the link inside the login area [00:56] hmmm, I'm not in the most forgiving-of-the-universe modd today [00:56] lifeless, http://mentors.debian.net/debian/pool/main/b/bzr-search/ should work better [00:56] oh yay [00:56] now what ? :_) [00:56] stupid robots.txt defeats wget [00:57] manually copying urls now [00:57] *this* is why I don't sponsor much [00:57] its about 4 billion times harder than it should be [00:57] well, at least you *can* sponsor [00:57] * jelmer just lost another application manager [00:58] ! [00:58] are you a MOTU yet? [00:58] no - I don't do much Ubuntu stuff, I always work in Debian and then request syncs [00:58] jelmer: because its so much easier, apparently ? :) [00:59] it is, once the initial package is in. I probably wouldn't be using or developing for Debian if that hadn't made it [00:59] if you've got packages that can be just synced it's nice to just maintain in Debian [01:01] jelmer: there will be a delay [01:02] I need to update my sid [01:02] oh [01:02] crud, other machine [01:02] ETOOHARD [01:03] the packaging looks ok, though the reference export command is stale [01:04] bzr done [01:05] lifeless: It's mainly there to make ftp-master happy, I'll add a get-orig-source target later [01:05] jelmer: also it looks like you've got a bzr 1.5 deps, but it requires 1.6 [01:05] Build-Depends-Indep: bzr (>= 1.5~) [01:05] lifeless, it only build-depends on 1.5, the actual dependency is on 1.6 [01:06] I'll fix the build-dep, it should be harmless though [01:06] That needs a comment if its deliberate, or not to be different [01:06] well, the sid chroot is updating [01:06] lifeless: Yeah, I'm fixing it here; it's cosmetic though [01:06] be quite a while [01:08] lifeless, thanks for looking into this [01:11] jelmer: I'm about given up on it; another headache and it will be ETOOHARD - too much to do [01:15] lifeless: :-( [01:16] there is _so_ much beauracracy involved its insane [01:16] you'll still have to wait for NEW [01:17] please don't get me started [01:17] we practice crunchy shell security as far as copyright honoring goes [01:17] NEW's been pretty quick in the last few weeks [01:17] it may catch a bunch of stuff; but as all debian/copyright does is duplicate whats in the package already, it doesn't help anything [01:18] ... and if a new upstream release adds weird stuff, there's no review at all from ftp-master [01:18] thats what I mean by crunchy shell [01:18] ah [01:18] once you're in, you're in. [01:18] When I think of shell, I think of "shell script" [01:19] its a standard description of certain risk management techniques [01:22] ah [01:22] well, nothing's perfect, but it can indeed be pretty frustrating at times.. [01:23] lifeless, any luck getting it to build? [01:24] chroot still updating [01:35] bzrtools done [01:38] bzr-svn done [01:40] jelmer: sorry, I'm going to have to leave bzr-search [01:41] lifeless, :-( [01:42] beuno, ping [01:42] the reason I do nearly everything I do do for ubuntu is source uploads [01:42] james_w: you need to remember to update the Maintainer field in debian/control :-) [01:43] only takes a few minutes fighting pbuilder + debbuild & deps etc and my tolerance for incoherent toolchains is exceeded [01:43] LaserJock: damn, thanks for catching it. [01:43] LaserJock: I presume you don't need a new debdiff? [01:43] james_w: no, I just run update-maintainer [01:44] cool, thanks [01:44] however, it does dep on the newer bzr [01:44] so I'm not sure if I should upload until that's sync'd [01:45] I guess I could just let it fail and then somebody can hit the retry button :-) [01:48] lifeless, I can provide you with a pre-built package... :-) [01:48] jam1: are you back ? [01:48] jelmer: I can't upload that [01:48] siretart: Could you perhaps sponsor bzr-search? [01:49] lifeless: Why not? [01:49] jelmer: thou shalt not upload binaries thou didst not build thyself [01:49] LaserJock: it should just auto-depwait shouldn't it? [01:50] james_w: well, one would hope but I'm not 100% positive [01:50] or at least manual depwait [01:50] lifeless: Why? Yes, I could've tampered with the binary but once the package is in sid, I can upload newer versions without intervention. [01:51] I'd suggest just getting it in, and then fixing if we need to, but you're the sponsor [01:51] jelmer: its part of the stuff I agreed to when I became a DD [01:51] lifeless: hmm, ok [01:52] james_w: uploaded [01:52] LaserJock: great, thanks a lot [01:52] james_w: though I sort of disagree with the "no longer uses a patch system" part. It still build-depends on dpatch even though it's not using it ;-) [01:52] true, I saw that afterwards [01:53] it's already committed upstream though, so it's not a long-term problem [01:53] but without a patches/ it's just an extra dep [01:53] yup [01:54] anywhere, there's a complete bzr set [01:54] which makes me happy, i got to do more than complain about things being out of sync :-) [01:54] perfect, that puts Intrepid in good shape [02:00] well, the packaging spree was nice while it lasted [02:01] uni starts again on friday, so I guess I'll changing the remaining ones back to RFPs for now [02:01] I think I'm suffering branch overload. One of my working trees is 4 branches away from its ultimate upstream... [02:01] markh: you might like looms [02:01] jelmer: how far did bzr-git get? [02:02] I'm not sure I need *more* bzr workflow options at this point... ;) [02:02] lifeless: I ended up working mostly on fixing bugs in bzr-svn [02:02] I only just use shelve for the first time the other day - wonderful :) [02:02] lifeless: bzr-git can now do clone/pull from git -> bzr [02:02] cool [02:03] does git keep a hot refcount for each hash? [02:03] or is gc a global operation ? [02:03] lifeless: also, tags can be set, info works and log works again [02:03] afaik its global but I'd have to check to be sure [02:04] you mean does it walk the heads to find unreferenced objects? [02:09] james_w: if it has a list of heads that is always accurate and race free, then it has a hot refcount for objects with refcount 0 [02:09] james_w: doing race free with loose objects will be quite a challenge though [02:09] ah, I see [02:10] I think [02:10] I don't know how it does that [02:39] May I make the suggestion for more user-friendly release notes? [02:39] I think users are interested in something more readable than the release notes format, which seems to appeal to developers of bzr more. [02:40] I'm thinking something in the form of Ubuntu's tours would cater better to end users (highlighting major improvements, new features, etc) [02:41] would you like to help write something like that? That would be really nice [02:42] I'd certainly be glad to contribute to such an effort [02:43] I think we'd be happy to have release notes in such a form, as long as its contributed :) [02:44] :) [03:12] jam1: ping [03:48] jelmer: Why did handle-patch stop being a command? [03:48] jelmer: And have you noticed it's full of tabs? [04:00] Howdy [04:03] Anyone around who can answer a quick question? [04:06] go for it [04:06] Cool [04:06] So, I discovered Bazaar through a friend, and was thinking about moving my development/playtesting team to it. [04:06] (Mod team) [04:07] I tried installing 1.6, and everything I can find says TortoiseBZR comes with the windows install. [04:07] However, I don't see the TortoiseBZR shell integration, even after a reboot. [04:07] Is there anything special I have to do to get it working? [04:09] Ahhh, I think I found my answer. I'm using XP 64, and an included sub-readme says that the 64 doesn't work due to packaging issues. I guess that's my problem. [04:09] Takes asking it before you figure it out I guess, heheh. [04:12] http://bazaar-vcs.org/WindowsDownloads doesn't seem to mention tortoisebzr, though [04:13] markh: what's needed for win64? [04:13] py2.6 on windows [04:13] apart from that, not much ;) [04:13] bashing the required extension modules into shape [04:13] is py 2.6 not on windows yet ? [04:13] pywin32 is already there [04:14] earlier py versions use MS compilers with sucky/no support for 64bits [04:14] py2.6 is using the latest MSVC and makes life easy [04:14] py2.5 on windows is at the same place on windows as any other os roughly... [04:15] 2.6 [04:15] stable in my experience [04:16] FWIW, a 64bit native exectable can often see 15%ish perf improvement over running a 32bit version of the exe on the 64bit os. [04:17] frikazoyd: ah, sorry, I didn't see your comments. Yes, 64bit toirtoise will need to wait a little while [04:18] there is a hacky work-around [04:18] Ok [04:18] Well I don't mind running the 32 bit [04:18] to be honest [04:18] but the 32 bit installer didn't install tortoise bzr [04:18] IIRC, executing "\windows\syswow64\explorer.exe /separate" should start a new 32bit version of explorer that works with toirtoise [04:18] for some reason [04:18] or it just isn't showing up [04:18] didn't install, or didn't register? [04:18] Ah, ok [04:18] right - it registered as a 32bit extension [04:19] Well it said it registered tortoise in the installer [04:19] AAAhhhhhh [04:19] only 32bit executables will see it [04:19] gotta love that old MS style [04:19] and my explorer is 32 bit [04:20] hrmph [04:20] thunk layers? We're tired of that, WoW blew chunks, lets not do that again [04:20] Yeah, I'm not a fan. However, my hands are tied since I'm a Source modder [04:20] frikazoyd: oh cool. [04:20] windows supports 32bit processes via a "wow" (windows on windows) layer, which is basically a thunking playground. It *does* support loading 32bit binaries into 64bit executables [04:20] which is what COM and shell extensions are all about [04:21] Hm [04:21] bugger [04:21] markh: yes, YHBTHANDHTH [04:21] s/*does*/*does not*/ [04:21] Hrm, the workaround didn't let me see the shell extension [04:21] ah well, I don't mind using command line [04:21] markh: the 16-32 bit wow did allow OLE to work across boundaries IIRC [04:21] the bottom line is I have a ton of playtesters who will complain about using a command line, but if they can use the extension in 32 bit windows I can just write a batch script for the ones that run 64 bit. [04:21] markh: which is what my mini-troll was about [04:22] lifeless: yess, out-of-process COM can be marshalled [04:22] we are inproc [04:22] markh: can't you just set an oop registration anyway? [04:22] :) [04:23] frikazoyd: I admit I've never tried that workaround on 64bits - I will before the next release though. This whole problem will go away once we move the shell extension code to c++ anyway [04:23] Okay [04:23] lifeless: shell extensions only work in-proc unfortunately [04:23] Well I've played with installers quite a bit, so if you need a hand let me know. But I'm not much of a windows programmer, so I don't know how much help I'd be in general. [04:24] Though I'm not bad with C++ itself [04:24] a .msi would be good :) [04:24] but we need to sort out other internal packaging issues before we take on a different installer [04:24] ok [04:24] man [04:25] I so love how COM is inconsistent [04:25] 'its totally generic' -> except that its not [04:25] heh - for sure. Plenty of scope for tuning etc. [04:26] but the rate of calls made to shell extensions and the blobs passed around would make an out-of-proc system struggle [04:26] markh: thats no reason not to -permit- it [04:26] markh: (also, they could fix the interface to do less work more sanely) [04:26] All the interfaces would need custom marshallers iiuc [04:26] and there are *lots* of them [04:27] all the interfaces are defined in terms of c++ structs, not nice little COM variants etc [04:27] its really just using COM as a "plugin" mechanism in some ways :) [04:27] I'm not defending things, just trying to add perspective ;) [04:30] markh: remember, I'm an ex-cygwin-core dev :P [04:30] lifeless: ahh, never knew that :) [04:30] search for robert collins cygwin :) [04:32] * markh wonders what else has can come up with by putting various words after "robert collins"... [04:32] beware my evil clones [04:32] theres a rc writes for dr dobbs journal [04:33] and another in a uk python-using research job [04:33] oh - another as a porn star I see! ;) [04:33] oh really? cool [04:33] now I can get a real hackergotchi [04:33] :P [04:35] They're everywhere these days. I think there's one stealing my name too. [04:35] good morning [04:37] cant donwload openerp's source by running 'python bzr_set.py', [04:37] wait long time and no file is downloaded [04:37] last time i can download all files [04:38] but this time after installed symlink plugin, it become calm down very much [04:39] seems that python run into a dead loop or no connection for ever [04:39] it do create a directory, but no files [04:39] what is bzr_set.py? [04:39] bob2, it is from lp:openerp [04:40] the 'openerp's default branch on launchpad doesn't contain openerp? [04:41] do you means the trunk? [04:41] yes [04:41] yes, it contains only two files [04:41] one is bzr_set.py, other is a readme [04:42] bizarre [04:42] readme file say need run bzr_set.py to fetch source [04:42]