[04:33] heya, ppa:bzr/daily are these experimental packages ? How often do they break ? [04:34] Daily ;) [04:34] by nature daily packages are ...breakable [04:34] hehehe :) [04:34] Well, *usually* they are just fine, of course [04:34] usually sounds good :) [04:34] im sure its not garuenteed [04:35] thats fine :) , as long as the fix comes in a week [04:35] The test suite of bzr's trunk always passes, that's enforced by an automatic process, so there's a limit to how horribly bad it can be :) [04:35] until then bz reports :) [04:35] sweet, thanks :) [04:36] You probably do want to be ready to rollback to the latest proper release in case of emergency, though [04:36] o/ spiv [04:36] I was unable to find bzr-colo in any ther ppa, and I like when things break infrequently [04:36] spiv, naa, I have couple of VMs setup with stable branches [04:36] And very occasionally if you have slightly different dailies on a smart server vs. smart client you might be get odd problems you would never see when using releases [04:36] isn't colocated built in now? [04:37] Hey poolie. [04:39] mgrandi, it's a different format to bzr-colo [04:39] (not drastically and they will be convertible but they are different) [04:39] ah [04:39] and i would say bzr-colo is a little more polished [05:12] hmm, another question [05:12] $ bzr branch lp:ubuntu/gtk+3.0 [05:12] Most recent Ubuntu version: 3.3.20-0ubuntu1 [05:12] Packaging branch version: 3.1.8-0ubuntu5 [05:12] Packaging branch status: OUT-OF-DATE [05:12] How does one switch branch ? [05:22] bzr switch? [06:04] mgrandi, seems to be http://package-import.ubuntu.com/status/gtk+3.0.html#2011-07-25%2009:43:52.029711 [06:05] from a short read of http://developer.ubuntu.com/packaging/html/udd-getting-the-source.html [06:06] i do not know what that means :< [06:06] neither do I, filing a bz [06:06] yeah [06:06] maybe one of the developers can figure out what that means [06:07] but for now i must be heading off, bedtime, night [06:37] https://www.youtube.com/watch?v=o9pEzgHorH0 - thanks lifeless, that's pretty awesome [06:44] hi all [06:46] hi vila [06:47] poolie: de nada [06:56] vila, did you get the link? you should watch it too, some time [06:56] I'm watching right now :) [07:00] morning! [07:01] hi there mgz [07:02] mgz: _o/ [07:04] where are we with timezones? [07:05] spread ? [07:05] i'm still utc+11 til next weekend [07:05] did you all go to summer time? [07:05] i wonder if jelmer will be around? [07:05] I did this week-end [07:13] hm, need to find a way of disabling video if we're going to use hangouts starting at 9 [07:13] or I'll murder my bandwidth allowance. [07:13] mgz, rip out the webcam ? [07:14] rmmod ? [07:14] To say nothing of having to wear pants. [07:14] the problem is downloading video from other people, not uploading :) [07:15] wearing pants is still relevant [07:16] mgz, it varies over the day? [07:17] yeah, it uses more units from 9-6 which has generally been a nice feature because I just schedual downloads for the middle of the night, [07:17] and don't have to live with the silly hard caps other providers use [07:18] * mgz wonders if fullermd has been in the US for too long, or if he often goes commando [07:18] I think he just uses a floating TZ [07:19] . o O (There is probably a joke related to drowning...) [07:19] :) [07:19] hm [07:20] so are you two expecting our call to start now? or in 40m? [07:20] now [07:20] I haven't checked jelmer's TZ though [07:21] I was expecting not to know, so set alarm for the earlier time [07:21] :) [07:21] ok, someone double booked me for the next hour [07:21] seems to be the same as me [07:21] hm [07:21] ...which didn't actually go off till just now, because phone still had the wrong time, but I woke up anyway [07:22] so, shall we go now, can catch up jelmer when he surfaces? [07:22] gggggggg/win 48 [07:23] i'll take that as a yes :) [07:23] ok let's do it [07:26] poolie: http://primeradiant.com/ may interest you [07:30] lifeless, http://pitchfork.com/reviews/albums/13009-wavering-radiant/ :) [07:31] poolie: heh, so actually it was the narrower link I posted in #launchpad-dev [07:31] thats really interesting [07:43] hi mgz, poolie, vila [07:43] hi there [07:43] Google calendar has our meeting listed as being in 17 minutes [07:44] yeah, tz changes are annoying [07:44] i think i had it in my tz [08:01] I think it must've been in ours - unless .au had a TZ change this weekend [08:03] we went from UTC+1 to UTC+2 this weekend [08:15] we're changing next weekend, for bonus confusion [08:15] jelmer, how about now? [08:15] poolie: works for me === zyga is now known as zyga-afk === zyga-afk is now known as zyga [11:52] hm, how much of a massive rewrite of setup.py should go into 2.5 [11:53] I guess I'll do the minimum there and move things around on dev only [11:54] what are you fixing? [11:55] well, directly, installation of .mo files, [11:56] but the collected cruft of distutils hacks too [11:59] mgz: minimum in 2.5 seems most sensible, indeed [12:05] it's still going to break things, I bet... [12:41] then dev first to stabilize I'd say [12:43] you want installers or not vila? :) [12:44] this is blocking 2.5.0-2 and 2.6b2 [12:44] *b1 [12:44] 2.6b1 I hop... right :) [12:44] yeah, I want installers :) [12:44] I could do another translation-less release [12:44] but that's is bit lame. [12:45] but nothing forbids you to use local branches (tagged appropriately if you think it's worth it) [12:45] ha, no, remote setup makes that awkward right ? [12:46] I've been doing manual merges [12:46] but you just gave me an idea that could save that pain [12:46] in any case, if you're cleaning up setup.py you've already got +0.5 from me ;) [12:46] no reason I can't commit a change to bzr-windows-installers that points the build at some other branch [12:46] good, I'll take credit for that then ;) [12:46] indeed [12:54] mgz: 'translation-less' ? [12:57] no .mo files. [13:06] okay, 2.5 branches up, will propose inasec when I have some food [13:07] mgz: did 2.5.0 had .mo files ? [13:07] mgz: if not, I won't object to dropping them from the whole 2.5 series and debug the remaining issues in the 2.6 one (as far as windows is concerned) [13:20] jelmer: see my pms ? [13:42] my laptop screen appears to have died... [13:47] ouch :( === zyga is now known as zyga-afk [14:55] and it's working again [14:55] clearly giving it a bit of a rest while I had lunch was enough === zyga-afk is now known as zyga [15:41] Is it possible to define per-branch hooks? Documentation only explains about ~/.bazaar/plugins, which are executed for every branch. [15:53] DktrKranz: plugings can you use configuration to decide wether to act [15:54] DktrKranz: so for example bzr-email will not do anything unless the right option is set for the branch === deryck is now known as deryck[lunch] [16:40] mgz, afternoon, do you have anything you could throw at bzr pqm ? [16:41] I shall look sir. [16:42] thanks, I hoping its less broken [16:42] I have sent https://code.launchpad.net/~jelmer/bzr/2.5-config-help-topics/+merge/99372 [16:43] http://pqm.bazaar-vcs.org/ shows it building at least, we'll see how well it does. [16:44] that's a lot further than it got earlier [16:44] I think its fixed now [16:45] is the test output slightly different or am I misremembering? [16:45] looks like it's working at any rate. [16:45] thanks gnuoy` [16:45] gnuoy`: what was it, in the end? [16:45] ok, it was fun... [16:46] jelmer, when dchroot-run was moved to cupuasso [16:46] it was modified to use schroot not dchroot [16:46] and the command that lists locations was converted to an schroot command [16:46] only it had a small typo in it [16:47] which only becomes apparent when there is more than one chroot [16:47] so the addition of the second chroot with the existing bug broke it [16:47] aha [16:47] gnuoy`: thanks again, much appreciated :) [16:48] np, sorry it was bust === deryck[lunch] is now known as deryck === yofel_ is now known as yofel [17:51] hiya. [17:51] jelmer: what versions of bzr-git and bzr-svn and deps do you want in 2.6b1? [17:54] ...I'll go with the tags as for 2.5.0 for now, don't want to risk trunks [17:55] and hi mgz [17:56] and hi to you too mgrandi [17:57] any more work on the dump i sent you? [17:57] we have like a bazillion problems with fastimport now i forget what we are working on atm [17:57] yeah... [17:58] the dump was more just to see where the memory is going [17:58] aka the original problem [17:58] so, working out what accounts for the other chunk of memory was one thing [17:58] and i think ive found a problem with bzr-git [17:58] I had an idea we had the whole revision graph [17:58] but don't remember the details [17:59] what do you mean? [18:01] 'had an idea' [18:04] it seemed from poking things that lots of objects came from a graph cache with no apparent cleanup mechansim [18:04] ah [18:04] i dont know much about the bzr internals so you would be the expert there =P [18:05] but, when i was trying ot test other git repos, i keep running into problems, mostly because git can tag files and other things [18:06] and depending on the arguments given to git fast-exported, those can be exported (the tag) but the 'revision' (mark) that it refers to is not there, so that is making bzr fast-import die [18:08] and i dont think that the arguments that bzr fast-import-from-git are enough to make sure that those don't get exported [18:08] so i dont know if the solution is to just make it so you 'have to run git fast-export with these arguments' or to make the bzr fast-import code more resiliant to these kind of things [18:11] well, presumably the latter, but can you do a minimal reproduction? [18:11] make a trivial git repo with the problem, and get fast-import failing with it? [18:11] that would then be a way in to fixing the issue. [18:12] there are various other issues with new-fangled git things that are starting to get used [18:12] yeah i can try that [18:12] cause apparently 'any' git object can be tagged [18:13] but then git fast-export filters out some of these, but leaves the tags, and its all very confusing [18:13] * jelmer waves [18:14] mgz: what problem did you find with bzr-git? [18:15] jelmer, it seems to be a problem when git tags.. a file [18:16] and the arguments that are used in git fast-export, you can end up with a tag that has a mark/revision that isn't present cause git fast-export doesn't export it [18:16] or something [18:16] jelmer: I'm just thinking of the bug reports on signatures and things, which are mostly code-import rather than fast-import related [18:16] mgrandi: I'm not sure I follow - how is that related to bzr-git? [18:17] jelmer: what I need from you is whether you have guidance on what versions of bzr-git and bzr-svn and deps need to be in 2.6b1 [18:17] is it bzr-git that handles the git fast import stuff? or is just fastimport [18:17] mgz: that's a good question [18:17] if its just fastimport then ignore me [18:17] =P [18:17] mgrandi: yes, that's bzr-fastimport [18:18] mgrandi: you can't tag files in bzr so it seems reasonable that that results in an error [18:18] mgz: trunk should be most appropriate in both cases [18:18] let me run the tests to see if there is anything missing [18:18] yeah, but the question remains whether fastimport should handle that or should just assume that git fast-export should be run with the correct arguments [18:19] mgrandi: I think it would be reasonable for it to warn and skip [18:19] rather than falling over entirely [18:20] yeah, thats easy enough for me to add since i have the line where its failing at home. [18:20] and we still have that timezone thingy [18:21] right [18:21] mgrandi: well, patches welcome :) [18:22] yay! [18:22] what should happen with the invalid timezone [18:22] just make it use +0000? [18:23] either that or what github does, which is just add the additional hours to the date [18:25] * jelmer is mostly focussed on bzr-git these days, rather than bzr-fastimport [18:26] ah [18:27] jelmer: okay, and dulwich, subvertpy? leave on current revs? [18:36] mgz: subvertpy yes [18:36] mgz: for dulwich I think trunk would probably make more sense [18:37] okay [18:44] okay, buuuuilding [18:56] hello [18:56] when i uncommit i see messages like [18:56] maar hi DonDiego [18:56] bzr pull . -r revid:diego@biurrun.de-20120327184815-t9xoi7ln0uuuwplh [18:56] s/maar// [18:56] where are those commits stored? [18:57] DonDiego: they're in the repository [18:57] i need to restore a commit :) [18:57] jelmer: yes, that much is obvious, but how do i access and find them? [18:58] DonDiego: "bzr heads" will look for revisions that don't have any children [18:58] * DonDiego tries [18:59] nah, it's not there, that commit is lost i guess [19:05] DonDiego: You're looking for revid:diego@biurrun.de-20120327184815-t9xoi7ln0uuuwplh ? [19:06] DonDiego: bzr dead --dead-only [19:06] what version of bazaar do i need for the "dead" command? [19:06] i have 2.4.1 here [19:07] sorry, 'bzr heads --dead-only' [19:10] oh, that could be it [19:10] jelmer: i owe you $beverage [19:11] or a flattr if you prefer and are into this newfangled stuff [19:13] jelmer: thanks a million [19:14] heh, that's okay; glad it works for you