[00:03] apparently devicekit-power is supposed to provide the equivalent functionality now, see /lib/udev/rules.d/95-devkit-power-battery-recall-* [00:03] thanks johanbr [00:03] :) === asac_ is now known as asac [00:04] * asac considers to not use his laptop on next flight [00:10] asac - probably a wise decision ;) [00:12] g-s-d media-keys plugin seems to be a mess at the moment:( [00:21] chrisccoulson, it's always for "Filesystem root", assume this is / [00:22] fta - yeah, that's right [00:22] that name comes straight from GLib. i wish it could pick a better name ;) [00:28] gnome dudes: where are these icons from and what's their licence? http://people.canonical.com/~jriddell/tmp/icons.png [00:36] hmmmm. if you do a g_hash_table_lookup on something, then remove the returned value from the table with g_hash_table_remove (and the GDestroyNotify function for that value is g_object_unref), things will go pretty wrong if you then try to access that object afterwards without first increasing the ref count won't they? === Amaranth_ is now known as Amaranth === Amaranth__ is now known as Amaranth === Amaranth__ is now known as Amaranth [07:29] morning everyone [07:33] Hey, I was wondering - are we ever going to make installing single packages from -backports less troublesome? I remember reading about new gui for package managment, was it even discussed? [07:50] ola ubuntuereos$ [07:51] morning crevette [07:51] hey didrocks === tkamppeter_ is now known as tkamppeter === Tm_T_ is now known as Tm_T [08:43] hello there [08:45] hi hi seb128 [08:45] hey crevette mvo huats [08:45] hey seb128 [08:46] hey seb128 [08:46] hello chrisccoulson [08:46] hello seb128 chrisccoulson crevette and mvo ! [08:46] hello huats [08:46] hey hey huats, chrisccoulson and mvo [08:46] hello crevette and mvo also [08:47] anyone i've missed? ;) [08:47] asac: hi... Bug #387626 , are you involved in nm? [08:47] Launchpad bug 387626 in hundredpapercuts "wireless notification icon is wrong signal strength" [Undecided,Confirmed] https://launchpad.net/bugs/387626 [08:48] hey seb128, chrisccoulson, mvo [08:48] hey huats, crevette, didrocks and chrisccoulson :) [08:48] lol [08:48] :) [08:49] hey didrocks [08:49] the chan was so quiet before seb128 arrived :) [08:49] didrocks: we follow our leader :P [08:49] seb128 - i did some debugging with gsd last night. i've got a fix for the broken notification on mute now [08:49] didrocks, right, and now is time to collect homework [08:49] * mvo hugs seb'party-cannon'128 [08:49] but i havent solved the crash yet [08:50] chrisccoulson, ok, good [08:50] didrocks,huats: what about you? ;-) [08:50] seb128: hem... you already collected it and I'm fighting against launchpad translation tool :) [08:51] the automatic export in bzr branch don't want to take my branch! [08:51] seb128: I am about to work on deskbar-applet [08:51] didrocks, ah ;-) Collected what, clutter-1? ;-) [08:51] seb128 - i ran gsd in debug mode, and if you switch audio devices a few times, something goes horribly wrong (it starts spewing out loads of g_criticals) and it never recovers, but it doesn't always crash [08:51] huats, good! [08:52] chrisccoulson, you can maybe add a comment saying that on th GNOME bug [08:53] i will do. i wanted to try and get a trace of the first critical with G_DEBUG=fatal_criticals, but the problem is it prints an unrelated critical message at startup and causes it to abort long before it gets to the interesting bit [08:53] is there any way around that other than fixing the first error? [08:54] seb128: I just tried and it seems that for me gksu re-asks if I enter my password wrong [08:54] seb128: no, yesterday's homework updates. You already sponsored them :-) Clutter will be more a week-end homework, I guess :) [08:54] mvo, in fact it doesn't there because it "*** glibc detected *** gksu: malloc(): memory corruption (fast): 0x08520467 ***" [08:54] ok, and I'm taking empathy as an extra bonus :) [08:54] mvo, which might be the same issue that you fixed yesterday [08:54] didrocks, it's already done [08:55] seb128: ok [08:55] oh? waiting for publishing? [08:55] didrocks, huats, robert_ancell: versions.html outdated by one day [08:55] the script is crashing on rookery for some reason [08:55] hum, ok :/ [08:55] and there is no gdb or valgrind there to debug [08:55] ok seb128 thanks for letting us know [08:56] hmm [08:56] I blame it on mvo, sources_record.Lookup() crashes [08:56] seb128, can it be run manually? It should dump a stacktrace [08:56] I can get the issue easily with a python line [08:56] robert_ancell, it doesn't [08:57] seb128, can you update the script to pipe the output to a log file? [08:57] robert_ancell, well the issue is simple enough [08:58] (waiting to get the prompt on the box) [08:58] ok [08:59] seb128, you want to keep the new libgnome settings for menu icons? [08:59] don't you fear user reactions ? :) [08:59] crevette, it's an upstream choices why not giving a try to what they decided? [08:59] crevette, no, I'm used to users complaining [08:59] :) [08:59] honnetly I used thi settings since 2 weeks, and I'm fine with it [08:59] robert_ancell, mvo: [09:00] $ python -c 'import apt, apt_pkg; apt_pkg.Config.Set("Dir::Etc::sourcelist","./index/debian/etc/apt/sources.list"); cache = apt.Cache(rootdir="./index/debian"); cache.update(); sources_record = apt_pkg.GetPkgSrcRecords(); sources_record.Restart(); print sources_record.Lookup("speex")' [09:00] /usr/lib/python2.4/site-packages/apt/__init__.py:17: FutureWarning: apt API not stable yet [09:00] warnings.warn("apt API not stable yet", FutureWarning) [09:00] *** glibc detected *** double free or corruption (!prev): 0x0821ce78 *** [09:00] Aborted [09:00] [09:00] that's the issue basically on rookery [09:00] code didn't change, Ng said rookery didn't change [09:00] and the same code works locally there [09:00] could be the cache? [09:00] I tried deleting the dir [09:01] it does the same after rebuilding a new one [09:01] something weird with speex? [09:01] no, same on any source [09:01] speex is just the first in the list [09:01] but I tried with a bunch of names same issue [09:01] very odd [09:02] indeed [09:02] I might ask IS to install gdb or valgrind today [09:27] mac_v: yes i am involved with NM :) [09:28] asac: ah... could that be fixed? can nm notifications send the right signal strength? BTW this only affects ubuntu , since we use notify-osd [09:28] asac, hi, did you do a wiki table or something about bluetooth devices? [09:30] seb128: you mean a table where desktop team can say what devices they hav? [09:30] asac, what did we decide during the meeting? [09:31] asac, I though we would list devices we have so we know what else we need to test or I misunderstood? [09:31] seb128: you are right. [09:31] asac, context I want to buy some device for testing not sure which one though [09:31] wonder if that would be on wiki.ubuntu.com [09:32] ok, so the reply is that we don't have the table yet [09:32] I will just pick something, I've discount in a near shop to use before this evening [09:33] seb128: i think there is so much bluetooth hardware that its unlikely that you will pick a dupe [09:33] right, thanks ;-) [09:34] seb128: python-apt> hm, myserious [09:35] mvo, they have a custom version supporting lzma or something [09:35] mvo, the box is still running dapper I think [09:35] woah [09:35] dapper :) [09:35] that brings back memories [09:35] ie weird mix but used to work until this week [09:35] and Ng says the install didn't change this week [09:36] so maybe the current debian index has something which makes this python-apt old version crash [09:36] seb128: setup a "StaffBluetoothHardware" wiki.c.c patge [09:36] I'm wondering if I could do a local install of a newer version [09:36] asac, thanks! [09:37] seb128: add your thing there .. i will ask folks to add their info [09:37] asac, will do ;-) [09:39] mac_v: doesnt upstream also notify if connection was established? [09:39] upstream doesn send the signal strength, just uses this icon > /usr/share/icons/gnome/scalable/status/nm-device-wireless , for everything [09:39] asac: ^ [09:42] * seb128 is away for some shopping be back later [09:50] seb128: hi. Would be good to sync telepathy-sofiasip package from Sid. Should I open a bug about that or can you do it directly? [09:51] mac_v: i dont get the problem. [09:52] mac_v: whats the differenve that makes this not an upstream bug? [09:52] mac_v: i mean: why are we supposed to send signal strength, but upstream isnt? just because we use something that has -full in its name? [09:52] asac: upstream doesnt have notification icons for every signal strength [09:53] asac: we have icons for all strengths why not use them , make the notification more useful? [10:02] mac_v: so checkout wireless_get_icon src/applet-device-wifi.c [10:02] mac_v: the notifications can try the same thing that is used there to decide which icon to use in tray [10:02] thats in wireless_device_state_changed [10:03] asac: could you comment this on the bug report , about how this can be done? [10:03] pls [10:03] mac_v: paste what i wrote [10:03] i have no more to say about it ;) [10:03] MacSlow: ^ [10:03] except that i dont thinkg its really useful [10:04] asac: just that MacSlow wanted to know from your side , so felt it was better if the concerned dev wrote it [10:04] paste it to the bug. i dont see him commenting there though [10:05] mac_v, asac: haeh, what? [10:05] the bug about the wireles icon in the bubble [10:05] asac: we had discussed it on #ayatana ;p [10:05] now i pasted it [10:06] you could have done the same ;) [10:06] :) [10:06] mac_v, asac: which icon to use for what notification (if it is a system-level thing, like the wireless strength) is something to discuss with the design-folks on #ayatana [10:07] MacSlow: we discussed the other day with kwwii in #ayatana, remember [10:07] mac_v, asac: btw... the initial patch for NetworkManager/applet I did not write [10:07] mac_v, only vaguely if at all [10:08] * MacSlow is in bug-fixing mode atm [10:08] i dont know about ayatana [10:08] they should be in here [10:08] asac: they have a separate room #ayatana ;p [10:08] asac, btw... trying to merge you mem-leak related patch and fix some of the other pending reasons for potential mem-leaks [10:09] MacSlow: please just push it ;) [10:09] MacSlow: there were no commits after it [10:09] MacSlow: what what are you trying to fix? [10:10] asac, I know... but nothing is going into notify-osd without me looking thoroughly over it... not being strict about such things caused problems [10:11] ok. but shouldnt take long ;) [10:11] asac, there are probably still some GObject-related issues in class Bubble causing g_object_unref(bubble) to not clean up as much as it should [10:12] asac, I want to add that to the commit/push with your patch as it fits the same topic/issue [10:12] MacSlow: nah. please keep my commit separately [10:12] MacSlow: dont try to be scarce about commits ;) [10:13] MacSlow: wait another second i try to find another gigantic patch fixing many other memleaks [10:13] asac, I hope "gigantic" is a joke there [10:14] no its the truth [10:14] wait a nother second [10:15] i made that in /tmp/ ... so the tree is gone. luckily i pastebinned it :) [10:19] MacSlow: http://pastebin.com/f181a86ec ... thats on top of my patch [10:19] MacSlow: there is a lot of fine cleanup code added.... but the big hit I hit in the end in stack.c [10:20] MacSlow: so three main issues ádddressed there on top of what i already did: [10:20] 1. lots of error conditions didnt cleanup everything [10:21] 2. not all data surfaces not properly destroyed (i introduced destroy_cloned_surface ) [10:21] 3. bubbles get never popped [10:21] -> never unreffed [10:21] -> never freed [10:21] -> big bustage [10:21] i ran som bruteforce thing against notify-osd [10:21] before it was 100M mem-leak in 2 minutes [10:22] now its 200 k [10:22] looks like a win [10:22] asac, thanks for getting some overtime off my shoulders! [10:22] MacSlow: yeah i am not sure why you never freed any bubble ... the code suggested that there were issues with crashes [10:22] but i couldnt reproduce them ... and even if there were there is no reason not to free any bubble ;) [10:23] asac, there's some fundamental design issues in stack and the list-queue it maintains [10:23] MacSlow: no problem. just get that reviewed and committed. if there are problems let me know. [10:23] asac, I can tell you a bit more about what led to this in Dublin... if you're interested [10:23] MacSlow: what are those probles. i didnt see that directly. when things get removed they should get popped of the stack [10:24] asac, e.g. stach should not keep a list of bubbles... way too heavy objects... but instead abstract notifications objects... much lighter [10:25] asac, at any time only two bubble objects at maximum should be in memory [10:26] MacSlow: thats true thats what i wondered about as well ;) [10:26] but we should free them for now when they got processed [10:26] asac, that's when you get rushed and told "you can polish that later, move on" [10:27] MacSlow: i know :) [10:27] I need a good name for the list on the left side of: https://wiki.ubuntu.com/AppCenter?action=AttachFile&do=get&target=1.0-available-home.jpg - do you have any suggestions? the one with "avaialble software", ... [10:28] "ActivityList", "SwitchBoard" - help :) [10:29] MacSlow: i will commit that as a separate commit to the leak branch or make a separate branch on top of that ... let me know [10:29] pitti - now that gnome-session suspends the machine directly via dk-power, what tells gnome-screensaver to lock the screen now, so that it resumes in the locked state? (i think that g-p-m used to do that, but i can't test it because suspend doesn't work on my machine) [10:29] i only ask because i've seen some users saying their machines resume with the screen unlocked now [10:30] asac, well for the sake of clean-ness if you could make a second branch-proposal with your pastebin stuff on top of trunk (after I merged your first stuff) [10:30] asac, one moment [10:30] MacSlow: ok thats better [10:30] MacSlow: i can make two or three commits out of it [10:30] e.g. error case fixes [10:31] mvo: a conceptual name, or a display name? [10:31] asac, even better thanks [10:31] Ng: a conceptual name [10:31] copy_surface fixes, etc. [10:31] MacSlow: let me know when you have merged the other in [10:31] Ng: not a UI name, I will nag the design guys for that [10:31] Ng: but something I can idenitfy it (and name the class after) - I feel so uncreative today :/ [10:31] mvo: viewswitcher? [10:32] that seems to express what it does [10:32] Ng: yeah, thats nice [10:32] thanks! [10:32] mvo: when you talk to the UI folks about display names, can I suggest that "Available software" say "Get new software"? I think "Available" and "Installed" could be interpreted to mean the same thing ;) [10:33] * mvo was also considering class ViewView(gtk.TreeView) [10:33] hehe [10:33] mvo: listswitcher ? ;p [10:34] Ng: thanks, that does make sense, I will mention it to mpt when he is back [10:35] :) [10:37] seb128: I know this isn't priority but I found a work around for bug 384767 however once the bbc iplayer plugin is up and running there is a new error but I think that might be just audio teething issues on my test box but I'll create a new bug for it shortly. [10:37] Launchpad bug 384767 in totem "Karmic: Totem BBCiPlayer plugin doesn't install" [Low,Incomplete] https://launchpad.net/bugs/384767 [10:37] * mvo is happy that his 10 minutes writer's block is over :) [10:37] hmm, is something a bit sideways in karmic gtk atm? context menu icons don't seem to be loading [10:44] asac, merged, tested and pushed [10:44] MacSlow: great [10:44] asac, lp is still updating [10:45] Good morning [10:45] hi pitti [10:45] *grumble* virus infection and fever :/ [10:45] oh, poor pitti [10:45] pitti: oh dear .... keep that away from me [10:45] ;) [10:45] get well! [10:45] yeah, will try [10:45] pitti: go back to bed so you are getting well for dublin ;) [10:45] pitti, well... get well soon... and don't spread it in Dublin ;) [10:45] pitti: gute Besserung :) [10:45] the doctor said it usually lasts three days, so if I'm feeling good enough I can come to the sprint [10:46] but no hugs this time [10:46] thanks guys [10:46] * asac takes a mental note [10:46] no swine flu, though :) [10:48] lool: sure, for home users that might make sense; however, in order for that to make sense we also need to sort out the keyring password and such [10:49] asac, I seen your reply on the gnome-bluetooth, the introspection build should be disabled I guess, it is true I read somewhere it was not building [10:49] this is weird the build on ppa worked. === crevette_ is now known as crevette [10:50] crevette: it didnt buld here. either missing build-dep or something else not proper [10:50] asac, no, introspection is not working [10:50] s/working/building/ [10:50] I can disable that, this is a know issue apparently [10:55] crevette: yeah could be its automatically enabled if the package is on system (i didnt not use pbuilder etc.) [10:55] crevette: so explicitly disabling might help [10:56] crevette: why doesnt introdpection not work? any idea? [10:57] pitti: take care :) === onestone_ is now known as onestone [11:07] * pitti -> back to bed, cu next week [11:09] asac, it does't build upstream neither, this is not ubuntu specific. [11:11] crevette: right. we should disable it explicitly then. whats the configure switch for that so i can check what i wanted to check in the first place? [11:11] cassidy, can do it [11:12] pitti, hey [11:12] pitti, should I start taking vitamines to not get your flu sunday? ;-) [11:14] asac, I can't see the flag in configure.ac, perhaps a ./configure --help may help [11:14] i found enable introspection in acinclude.m4 [11:15] let me try --disable-introspection [11:19] ok builds with that [11:19] gnome-bluetooth conflicts with bluez-gnome [11:19] blueman provides bluez-gnome and is present and installed. [11:19] dpkg: error processing gnome-bluetooth_2.27.8-0ubuntu1_i386.deb (--install): [11:19] conflicting packages - not installing gnome-bluetooth [11:19] crevette: ^ [11:19] that's why I don't like build in system, you pick unwanted dependencies :) [11:19] i think we need to conflit/provudes it [11:20] crevette: yes. but its a packaging bug if it does that ;) [11:20] hmm, I used to be there.... [11:20] asac, my sentence was unrelated to the error you just pasted [11:20] heh ok [11:20] still its a packaging bug ;) [11:21] yep [11:21] crevette: so i dont see the problem you describe [11:21] okay perhaps a ppa issue [11:22] the build starts and works without CPU spikes ... also i dont get any error/warning [11:22] did you launched the properties or the wizard? [11:22] it happened there [11:22] crevette: ok i will --disable-introspection and check if there is something with the conflicts/provides we can do and upload [11:22] crevette: oh let me try that [11:24] yeah that shows the same bug [11:24] asac, any estimates when you think you can work on that three-way split up of the pastebin patch for notify-osd? [11:31] MacSlow: when do you need it? [11:31] asac, the earlier the better... [11:31] heh [11:31] asac, today I only do bug-fixing, testing and merge work [11:32] i will check after lunch [11:36] hell. emacs diff-split-hunk is gone ... where was that in? [11:36] i had that for ages [11:37] emacs22-el ... maybe [12:21] MacSlow: https://code.edge.launchpad.net/~asac/notify-osd/lp405364_more_memleaks/+merge/9502 -> "please push (not merge) to keep my detailed commit logs ;)." [12:21] htx [12:23] asac, I only know how to merge using "merge" [12:24] asac, how does the other suggested process work? [12:25] MacSlow: you can just pull it and if you did review push to the lp:notify-osd branch [12:25] MacSlow: that only works if the branches have not diverged (e.g. no more commits on lp:notify-osd after i started the other branch) [12:25] but i think thats the case [12:26] if you already committed something afterwards only merge will work ;) [12:27] asac, oh... thanks for rev. 358 I was expecting to do this maintainer-burden stuff myself [12:27] MacSlow: let me know if there is something or if you have pushed it ... would like to upload a new notify-osd to karmic today based on latest upstream [12:27] asac, yeah... I'd like to do a tarball-release too today if possible [12:27] MacSlow: hehe. i just found by accident that you actually did maintain such a file in bzr log ... so i added myself (other projects ask you to add yourself if you want to be in that list) [12:27] oh, asac tracking notify-osd now, one less thing to do for me there ;-) [12:27] MacSlow: yeah then do some testing and let me know [12:28] seb128: its an opportunistic thing because i did some work on it ... in future you can have it back ;) [12:28] asac, you touch it you keep it ;-) [12:28] seb128: actually i think its a team thing anyway [12:28] it's sticky [12:28] oh good [12:28] seb128, asac helped me a good bunch with some overdue bug-fixing (mem-leaks) [12:28] MacSlow, I noticed I'm subscribed to notify-osd component on launchpad [12:28] seb128: i can do that ... everything is in bzr so its pretty great ;) [12:29] or rather the ubuntu notify-osd one [12:29] and simple [12:29] asac, make sure to nag MacSlow to look at bugs too ;-) [12:29] seb128: hmm. unlikely i can do that regularly ;) [12:29] alright, I will keep having a look then ;-) [12:30] was worth trying [12:30] ;-) [12:30] i am still confident that adding QA resources to our team would be a great win [12:30] no doubt about that [12:32] asac, argl... rev 360 conflicts with fixes I did myself in another branch [12:32] *sigh* [12:33] asac, but it's not that bad as it's mostly the same kind of fix [12:34] MacSlow: 360 is the big error handling ? [12:34] no [12:34] asac, just conflicts with some GObject disposal cleanups and fixes I did [12:35] ah even more ;) [12:35] asac, god... I hate that inconsistent coding style... in stack.c (not your fault) [12:36] MacSlow: yeah. [12:38] MacSlow: are we working towards notify-osd 1.0? [12:39] * asac saw that there is a 0.9 branch [12:39] asac, no... it#s not feature complete [12:39] and there's still too much left to fix [12:39] to call it 1.0 [12:40] only if all feature from the spec are implemented and it's cleaned of all major bugs it'll be considered 1.0 [12:40] ok [12:40] MacSlow: so 1.0 not for karmic? [12:40] asac, and I don't see that happening soon [12:40] hehe [12:40] yeah [12:40] asac, impossible [12:40] asac, and I don't want to know what additiona work will be piled upon me in Dublin [12:41] asac, except for coding-style/formatting I'd say https://code.edge.launchpad.net/~asac/notify-osd/lp405364_more_memleaks looks good testing now [12:42] MacSlow: what coding style things you dont like? [12:42] if (condition) { [12:42] .... [12:42] given that its inconsitent we could do a coding style cleanup commit afterwards i would thiink [12:42] } [12:42] MacSlow: oh yeah. thats where i had printf in i think [12:42] asac, well sure but [12:43] anything else? [12:43] asac, I'm also missing the time to write a coding-style guideline for patch submission [12:43] asac, not that I can think of atm [12:43] MacSlow: ok i can fix those if you want that [12:43] its an odd coding style though ;) [12:43] asac, no... I'll do that afterwars [12:44] ok thanks [12:50] asac, what did you do to monitor notify-osd's mem-usage to verify your patches? [12:50] MacSlow: valgrind [12:50] MacSlow: also i reduced timeout and ran a while sending notifications [12:51] MacSlow: there are still a few leaks ... but i managed to get down from 200MB in a few minutes to like 200-300k [12:51] asac, how do you test with valgrind [12:51] asac, I mean in a "monitoring" fashion [12:51] run valgrind notify-osd, use a bit and ctrl-c [12:52] and see the summary [12:52] MacSlow: build it with debugging symbols and -O0 .... then killall valgrind --leak-check=full; ./src/notify-odf [12:52] then wait until you see in top that memcheck has settled [12:52] asac, seb128: ah... I thought it had a top-like mode too [12:52] and start sending notification [12:52] then after a few minutes, you cancel it and get a summary [12:52] but those are a bit tricky to interpret [12:52] MacSlow, G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full valgrind notify-osd [12:53] MacSlow, G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full notify-osd [12:53] rather [12:53] right G_SLICE=always-malloc is also good [12:53] asac, I still have to learn the full ins and outs of valgrind [12:53] MacSlow: yeah. so testing in a build tree, do like i said and set G_SLICE=always-malloc G_DEBUG=gc-friendly [12:53] that will give you beset results [12:54] killall notify-osd; valgrind --leak-check=full ./src/notify-osd [12:54] sorry there were typos further up ;) [12:55] so: killall notify-osd; G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --leak-check=full ./src/notify-osd [12:55] MacSlow: ^ ;) [12:55] then hit ctrl-c after a while processing notification [12:56] sometimes the output directly shows you where theproblem is ... but often it just tells you: you still have a leak ... and you still have to read code thoroughly; which is why i did all the error case cleaning [13:03] asac, so I can push your branch now to trunk via lp you said? [13:03] MacSlow: yes. if it doesnt work bzr would complain [13:03] so its safe [13:04] asac, how? I don't see any button on link for it... where is that "hidden"? [13:05] MacSlow: oh . i dont know about lp interface. you can just do a bzr push lp:notify-osd if you have my branch locally [13:05] MacSlow: it should also mark the merge request merge. at least it does if i push merges that way [13:06] how do you merge without merging on your local disk? [13:06] it doesnt do that if i approve merges at least [13:07] asac, if I do "bzr push lp:notify-osd" from your branch I've locally on my hd I get "No new revisions to push" [13:08] MacSlow: heh. do you have a local checkout? [13:08] or branch? [13:08]