[01:30] hi all, having some issues getting multiple X servers running on maverick. [01:32] have 2 servers running :0 on VT7 and :1 on VT9 unfortunately I can only have one of them displaying at a time, (yes I do have a working setup for 2 monitors/keyboards/mice) basically to view the other X server I have to hit CTRL-ALT-F7 or CTRL-ALT-F9 from the currently focused keyboard. [01:32] does anyone have some suggestions? === smspillaz|swap is now known as smspillaz [03:07] hello [03:08] hello [03:08] anybody here? === Bertrand is now known as bl8 === oubiwann_ is now known as oubiwann [05:13] good morning [05:51] hello, I need some help. I have a built-in blueotooth device. Few days ago it start to have trouble to connect to my handsfree but was ok with my cellphone. I tried to install/uninstall blueman and bluez and after few manipulations the daemon stopped working. I can't start it any more [05:52] !support [05:52] The official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org and http://askubuntu.com [05:52] You'll probably get more help in any of those avenues. [05:53] thank you [05:58] by the way, in case there was ever any doubt, NV-CONTROL is a really crappy protocol to work with [05:59] on the plus side, i think the daemon i'm currently writing for work that tries to automatically handle hotplug events on NVIDIA is GPL tainted, so it might get to see the light of day :) [06:04] Oh! Does NV-CONTROL actually generate hotplug events? Cool :) [06:05] no, but i'm polling for them :) [06:05] generating useful events would be entirely too, well, useful for NV-CONTROL [06:17] lol [07:35] good morning [07:57] Good morning [08:06] didrocks, pitti: Good Morning! [08:06] hey Sweetshark, moin moin! [08:07] Guten Morgen pitti und Sweetshark [08:09] morning mvo pitti [08:10] hey glatzor [08:10] glatzor: great work on aptdaemon! looks really cool [08:10] thanks pitti [08:12] mvo: speaking of which, do you want to sponsor this? or want me to? [08:13] robert_ancell: hey Robert, good evening! [08:14] * Sweetshark reboots [08:14] hey glatzor! thanks for your mail [08:15] pitti: I'm working on it currently, there is a test-failure left (but only on build anoyingly) [08:15] ah, great [08:15] * pitti hugs glatzor and mvo [08:18] robert_ancell: do you have some time to look into this webkit bug 710582? [08:18] Launchpad bug 710582 in webkit "webkit crashes on amd64 architecture with SIGSEGV in WTF::OSAllocator::reserveAndCommit() was: webkit does not implement "assert" sanely" [Critical,Confirmed] https://launchpad.net/bugs/710582 [08:23] hey glatzor, mvo [08:23] morning didrocks [08:27] hey didrocks [08:30] pitti, not tonight but can tomorrow [08:30] robert_ancell: I was just wondering in general, depending on your current workload; if you are already overloaded, I'll look for someone else [08:32] pitti, assign it to me [08:33] robert_ancell: ok, thank you [08:33] hey robert_ancell, I think we are good on that meeting for tonight...no worries...pitti set my mind at ease ;) [08:34] jasoncwarner, oh, np [08:35] hey jasoncwarner, welcome back, isn't it terrible late in your TZ ? [08:35] hey mvo, not terribly, ;) [08:35] but for what time I normally wake up, it is getting late! [08:35] heh .) [08:43] hey jasoncwarner [08:44] morning didrocks! [08:44] pitti tells me that you've been slacking ;) [08:44] says you are never doing awesome things and never completely amazing him with your work ethic and dedication ;) [08:44] yeah, a whole 4 hours during his sleep!!!! [08:45] jasoncwarner: Oh, just a short question: What are your usual work hours currently? I know nothing is usual currently with all that exciting stuff going on, but I keep calculating timezones ... ;) [08:46] Sweetshark: I normally work San Francisco hours.... [08:46] which was easier to tell people when the clocked worked with timezones ;) [08:49] jasoncwarner: yeah, totally slacking :) [08:49] I +1 pitti [08:49] sorry, time for one of my 20 naps of the day :) [08:49] ha! [08:49] *chuckle* [08:49] * pitti hugs didrocks [08:50] * didrocks hugs pitti back [08:50] didrocks: don't forget to watch Big Bang Theory in between them! [08:50] When I met didrocks at FOSDEM he wasnt even sleeping ... [08:50] pitti: hehe, I have 3/4 episod late on the last season! [08:50] you see, unity destroy my life, I even can't keep up Big Bang Theory :) [08:50] rock paper scissor lizard spock! [08:51] didrocks: ah, I already caught up all the way until 4/14 [08:51] didrocks: I informed you thusly! [08:51] pitti: excellent, I'm still at 4/11 IIRC ;) [08:51] man, I love that show [08:52] yeah, it's so nice :) [08:52] I think now that I saw that one, I even prefer it than The IT Crowd [08:52] (well, maybe not the "The Internet" episod) ;) [08:52] pitti: Dont be cruel, I got the first two seasons as DVDs from my brother for my birthday, but he insisted he would like to look them together with me. And he is currently in Ingolstadt helping making nice german cars during the week that prolongs stuff needlessly. [08:53] Sweetshark: argh, poor you [08:54] didrocks: yeah, me too; but at least I still have the 4th episode of IT crowd left to watch [08:55] pitti: oh right, I hadn't started watching the last season as well! [08:55] In my desperation I already stopped the DVD in one of the episodes we had already seen and analysed the physics on the whiteboards. [08:56] Sweetshark: and so? are things correct or is it nuts? [08:56] didrocks: correct mostly [08:56] without any stop, it seemed to be correct as well, but I didn't analyse closly [08:57] closely* [08:57] at least the quantum mechanics stuff. Dunno about the string theory. Im not into esoterics ;) [08:59] Sweetshark: at least you can live in the peace of mind that _nobody_ knows whether it's correct :) [09:00] so your guess is as good as anyone elses's [09:02] (small notice: so, the invisible window bug is still there, but very very rare though… The good news is that *now* we have a reproducible test case \o/) [09:03] at least I'm using unity again since yesterday evening, and I haven't gone nuts again yet [09:05] you can trigger it in the classic session as well ;) [09:05] you won't escape compiz bugs like that! [09:05] but agreed, the situation is way better [09:06] didrocks: not in classic+metaicy :) [09:06] (which is what I was using) [09:06] pitti: that's cheating though :) [09:06] you should try metaicy, it's yummy [09:06] metacity works as well, though [09:06] I was using metacity the past last years TBH :) [09:06] (just switched for a cycle to compiz when it was the new bling bling) [09:17] good morning all [09:17] hey dpm [09:17] hey pitti. It seems there's been some feedback of non-working FF lucid translations in the -proposed langpacks -> https://lists.ubuntu.com/archives/ubuntu-translators/2011-February/004395.html [09:18] hey dpm [09:18] heya didrocks :) [09:19] dpm: oh, thanks; I'll remove that one from -proposed right away then [09:20] ok, let's see if we get some more feedback [09:20] $ cat 10.04/whitelist.txt [09:20] fi [09:20] oc [09:20] hm :( [09:20] dpm: I'm not entirely sure what the whitelist is, but that might not be a coincidence [09:20] is -oc broken as well? [09:20] it seems po2xpi is the culprit here then? [09:20] not sure [09:21] let me see if I can install a few in my lucid pc [09:25] hey [09:28] salut seb128 [09:29] morning [09:31] hey didrocks rodrigo_ [09:32] how are you? [09:32] good morning rodrigo_ [09:32] I'm fine, thanks, you? [09:33] hi seb128, didrocks [09:34] didrocks, I'm fine as well, a bit late to start, I ran out for some errands before starting [09:34] seb128: sunny days? [09:35] or cloudy weather like in Lyon? :) [09:35] no, it's not sunny here, rather went out to get some coffee and something to eat [09:35] running out of breakfast stuff here ;-) [09:35] bonjour seb128 [09:35] hey pitti [09:36] seb128: hehe, not a nice way to start the day, right. errands were mandatory then :) [09:36] I got coffee and cake so that's fixed, I can work ;-) [09:42] didrocks, did you get comments about the compiz update? [09:42] pitti, do you run again unity? [09:42] seb128: yes, I do [09:42] since the update last night [09:42] seb128: yeah, still some invisible window issue [09:42] working fine? [09:43] seb128: no problems so far [09:43] didrocks, ok, as you thought [09:43] seb128: but the good news is that we have a reproducible test case now [09:43] didrocks, using apport? ;-) [09:43] seb128: no, synaptic :-) [09:43] I didn't try yet here but I get it almost every time I use update-manager and the polkit daemon crashes [09:44] which triggers apport and let compiz in a broken state [09:44] yeah, it's really a criptic path that has been reported as well :) [09:44] but it "works" as triggering the bugs reliably [09:44] bug* [09:44] so nice :) [09:44] or rather than waiting for polkit to crash just hit esc on the password dialog [09:44] update-manager freaks out and freeze for 5 minutes and apport display a dialog and break compiz [09:44] yeah, apparently, compiz just ask for paint rather than create create reparent… [09:45] didrocks, ok, great, it means sam can work on it now then? [09:45] as it is thinking the window is already there [09:45] yeah, he's already aware of that :) [09:45] so, basically, 3 bugs before merging back the glib branch to trunk: [09:46] .oO(apt-get build-dep libreoffice <= WooHa!) [09:46] 1. alt / tab being slow (almost finished) [09:46] 2. this invisible window [09:46] 3. test the new order with the sn_* crash [09:46] I get the sn_ crash every second login [09:47] would be nice to get it fixed ;-) [09:47] maybe removing my workaround with the new patch for it can be an help [09:47] Sweetshark, hey, what about it? hours of downloads? ;-) [09:47] but there is an ABI break and such… [09:47] so I prefer rather than running untested stuff that it lands to trunk + make dist as we need to do that rebase [09:49] seb128: nah, downloads are fast here ... [09:49] * Sweetshark has 100MBit downstream at home ... [09:49] didrocks, right [09:50] Sweetshark, that's quite a nice internet access indeed ;-) [09:50] Sweetshark: wow, but you don't have a large "Uni Hamburg" plate on your front door, do you? [09:52] pitti: nope. Than it would even be faster. Uni Hamburg also has some huge IPv4 ranges. Good that they build DESY here before the dawn of the WorldWideWeb ... [09:58] we got fibreglas connections around here and cable TV and phone are served over that connection as a sideeffect. 100MBit/s almost never get saturated for simple downloads as some server on the way will choke. bittorrrent is the only thing that lights up stuff completely ... === zyga_ is now known as zyga [09:59] No I was wondering about all the additional packages that got installed as I already build LO without them ;) [10:00] ... but that was without --with-system-libs ... [10:01] Sweetshark, right, debian and ubuntu tend to not like using lib copies [10:01] it means you have copies of the code to update every time you fix a bug or a security issue === smspillaz is now known as smspillaz|dinner === kamstrup is now known as kamstrup|hackfes [10:02] Is there a policy that packages must build single-threaded? Because LO does and well, it could be a lot faster ... [10:03] Sweetshark: no, the buildds use DEB_BUILD_OPTIONS=parallel=4 [10:03] Sweetshark: most packages actually build with "debuild -j4" [10:03] but that also runs debian/rules in parallel [10:03] which the current LibO package fails on [10:04] Sweetshark: but if you set the above, it'll be a lot faster indeed (replace 4 with your number of cores) [10:04] Sweetshark: on my core i5 2.4 GHz/4 GB RAM, the last OO.o built in about 3 hours [10:05] seb128: sure, nobody likes it. But from a dev point of view it might make sense because you dont want to recompile LO everytime some system lib got updated (as LO is linking a lot of those, that would be pretty often) [10:06] Sweetshark, which is another reason to use the system libraries? [10:06] if they are dynamically loaded you don't need to rebuild l-o when a library is updated [10:06] if you use a copy you need to patch l-o and rebuild it... [10:07] Sweetshark: yeah, it's actually considered a bug if a package includes copies of system libraries [10:07] if it's a security sensitive thing like poppler, zlib, or pcre, the security team haunts maintainers pretty severely (and rightly so) [10:09] seb128: In theory. In practice, API might change, LO might depend explicitly on an outdated lib or even might only run against a patched version ... [10:10] of course, Nothing of that should happen, but it does ;) === kamstrup|hackfes is now known as kamstrup|hackfez [10:41] Hmmm, another stupid question about the debian way of building: When I apt-get source, apt-get build-dep and then apt-get source -b so that it is build via dpkg-buildpackage, what does the unpacking of tarballs? [10:48] Sweetshark: apt-get source -b is pretty much overkill there [10:49] Sweetshark: apt-get source does the unpacking, through dpkg-source -x foo.dsc === smspillaz|dinner is now known as smspillaz [10:53] pitti: I just trying to get my head around all the stuff that happens "around" the "real" build by the build.pl up to a complete package. [10:53] Sweetshark: build.pl? [10:54] Sweetshark: the most low-level program you should be concerned about is dpkg-buildpackage [10:54] -S -> build source package, -b -> build binary pacakge [10:54] pitti: the build script in the LO build itself. Scary stuff. [10:54] I think most people use the "debuild" wrapper, which calls lintian and provides some extra configurability [10:54] Sweetshark: ah [10:55] Sweetshark: the entry point to building a source package is the debian/rules Makefile [10:55] Sweetshark: for that I suggest to do the packaging tutorial first; trying to understand that stuff on the LibO package will be ... not easy [10:56] So one working set of commands would be: apt-get build-deps && apt-get source && dpkg-source -x && dpkg-buildpackage, right? Or is there anything missing in the chain? [11:00] pitti, I've had a quick look at some of the langpacks which have already been buit: es, bn, de, pt, pt_BR (same langpack), bn. In all of them firefox translations look ok to me (i.e. no obvious breakage). I could not install any other language, as the 'language-pack-LL' packages are still on the old version (I guess they haven't been built yet), and I get a conflict when trying to install the corresponding 'language-pack-LL-base', which is already on [11:00] the latest version for most of the languages. So I'm not sure how the translator installed the Finnish langpack, and I'm not sure if he might have created the breakage himself [11:00] * Sweetshark tries (but with replacing dpg-buildpackage replaced by dpkg-source -b in the unpacked dir) [11:00] Sweetshark: apt-get source already unpacks the source, unless you add -d [11:01] Sweetshark: dpkg-source -b is not what you want; you want debuild -b or dpkg-buildpackage -b [11:01] Sweetshark: dpkg-source -b is a very low-level (i. e. not meant for users) interface for building a source pacakge, i. e. the diff.gz/dsc [11:01] dpm: hm, might be your mirror which is behind? they all built over night [11:02] dpm: this morning at 9 am the queue was empty [11:03] ah, let me see... === MacSlow is now known as MacSlow|lunch [11:09] pitti: I want to go 'very lowlevel' to see what happens in each step that dpkg-buildpackage would do as per http://www.debian.org/doc/maint-guide/ch-build.en.html ... [11:10] Sweetshark: essentially it calls "debian/rules build", then "debian/rules binary" (for binary builds) [11:10] for source packages, it cleans, calls dpkg-source -b, etc. [11:10] but it's not all that important [11:13] I just want to get a feel where the magic happens ;) [11:14] Sweetshark: which package do you use for studying this? [11:15] when I run dpkg-source -b . in the dir where I ran apt-get source, I get cannot open `./debian/changelog' for reading, which is to be expected as debian is in the subdir libreoffice-3.3.0 ... [11:15] pitti: libreoffice ;) [11:15] uh [11:15] maybe 'hello' is a better place to start ;-) [11:15] Sweetshark: yeah, you need to be in the source tree for every dpkg-buildpackage operation [11:16] when I am in libreoffice-3.3.0 (actually I tried that first), I get "no orig.tar file found" [11:16] yeah, hello is already nontrivial, and still uses plain debhelper [11:17] Sweetshark: doc says dpkg-source -b [11:17] * pitti never used that himself [11:18] which is true, there is only a libreoffice_3.3.0.orig.tar.gz in ../ [11:18] actually the hello I just got doesn't even use debhelper at all o_o [11:19] indeed [11:19] right - you want hello-debhelper :) [11:19] Sweetshark: right, so dpkg-source actually does need to run outside the source tree [11:19] so if you want low level then this might be good reading [11:21] I just want to do the low level stuff once now, to get a feeling for it so I will not freak out should the need arise someday ... [11:21] rodrigo_, hey [11:22] rodrigo_, just read your comment, we already build tomboy without the applet enabled [11:22] seb128: hm, do you know what the new geoclue stuff is actually supposed to do? empathy doesn't show me the location of people anywhere [11:22] pitti, the indicator-datetime is supposed to show "do you want to change your tz" when travelling [11:22] ah [11:22] pitti, set your tz to an u.s one and restart it [11:22] it should tell you "you are in germany, do you want to set that tz" [11:23] pitti, we don't build empathy with geoclue, it would require bringing in libchamplain to gets the maps etc [11:23] $ killall indicator-datetime-service; TZ=America/Chicago /usr/lib/indicator-datetime/indicator-datetime-service [11:23] (process:15280): Indicator-Datetime-WARNING **: Unable to create GeoClue address: Address interface already started [11:23] hm, I guess it's very racy with the auto-respawn [11:24] pitti, it's likely you need to restart geoclue as well [11:24] oh, indeed [11:24] pitti, it's rather geoclue which picks the tz [11:24] -ETOOMANYDAEMONS [11:24] the indicator just talk to geoclue [11:25] hm, restarted geoclue-master, and it talked to Ubuntu GeoIP; now restarted indicator-datetime-service, but no question here [11:25] pitti, it should be a line in the indicator [11:25] not a popup [11:25] nope [11:25] how did you change your tz? [11:26] I have them both in the foreground now [11:26] seb128: running the daemons with TZ=America/Chicago [11:26] not sure how they get the tz or if they respect that [11:26] or if they just read /etc/timezone or something [11:27] that'd be a bug [11:27] but let me try changing that [11:27] * pitti changes it in time-admin [11:28] (process:15490): Indicator-Datetime-WARNING **: Unable to create GeoClue address: Address interface already started [11:28] I keep getting that [11:28] (process:15490): Indicator-Datetime-WARNING **: Unable to get Geoclue address: Geoclue master client has no usable Address providers [11:28] anyway, I was just curious [11:29] pitti, ok, check with ken or ted when they are online, I didn't play much with it [11:29] pitti, I know it's supposed to show a "set the tz to ..." line in the indicator when it detects you are on a different tz [11:30] argh, argh! I have an invisible window again [11:31] pitti, [11:31] oh, heh [11:31] interesting workaround for the invisible window bug [11:31] hide and show the desktop [11:31] pitti, try that maybe ;-) [11:31] how? [11:31] if you have a gnome-panel running put the "show desktop" applet [11:31] I don't [11:31] otherwise dunno [11:31] smspillaz, ^ [11:31] seb128: wassup ? [11:31] pitti, thereis probably a show desktop keybinding in compîz [11:31] and apparently the nasty window is on top of the unity panel, I can't even open the launche rnow [11:31] seb128: pitti: Ctrl-Alt-D [11:32] smspillaz, how do you hide and show desktop to workaround this bug [11:32] smspillaz: doesn't work [11:32] smspillaz, thanks [11:32] I used the thing on the gnome-panel [11:32] smspillaz: might only work with gnome-panel? [11:32] pitti: might have changed [11:32] ctrl-alt-D works there [11:32] showdesktop handling is done within the wm [11:32] pitti: ccsm -> general -> keybindings -> show desktop === smspillaz is now known as smspillaz|eating [11:33] seb128, yes, found out the peditor stuff is in libgnome-cil, that's where the dep comes from [11:33] seb128, so moving those files to gconf-cil and testing [11:33] smspillaz|eating: thanks, I used gnome-keybinding-properties and that worked (it was Mod4+D before) [11:33] found a time-admin window hiding itself [11:34] ok [11:34] nice [11:34] pitti: yeah we've got a reproducible test case now so I'm going to look into it tonight [11:34] * pitti calls that "sanity key" [11:34] rodrigo_, well I assumed it was in libgnome-cil for a reason, that's why I asked you if we could move to plain gconf# [11:34] rodrigo_, but if we can move it to another binary nice [11:35] rodrigo_, check with Laney or pkgcli guys maybe though [11:35] seb128, yes, I guess it's there for some reason, not sure which though, so yes, testing [11:35] Laney, ^ [11:36] you could split the peditors assembly out into another package yeah [11:36] I don't know if that would save you anything on the dep chain, but it's worth a try [11:36] is there a way to do the equivalent of "ldd" on mono bindings? [11:36] i.e to see what peditor depends on [11:36] give us a patch in Debian and we'll take it [11:37] In case anyone is interested: mkdir foo && cd foo && apt-get source libreoffice && dpkg-source --before-build libreoffice-3.3.0 && dpkg-source -b libreoffice-3.3.0 && make -C libreoffice-3.3.0 -f libreoffice-3.3.0/debian/rules build [11:37] monodis --assemblyref I think [11:37] Laney, thanks [11:37] Laney, well, it would save "Name=gnome-vfs-sharp" [11:37] coming from /usr/lib/cli/gnome-sharp-2.24/gnome-sharp.dll [11:38] is that where your problematic dep comes from? [11:38] doh [11:38] the peditor one depends on gnome-sharp [11:38] if peditors depends on gnome-sharp thoug... [11:38] yeah, :( [11:38] right [11:38] that brings the gnome-vfs stack in [11:39] seb128, the peditor stuff is in libgnome-2.24-cil [11:39] in the upstream source code, they are with the gconf 'basic' bindings [11:39] rodrigo_, yes, but it doesn't make sense to split it out since gconf-sharp-peditors.dll depends on the gnome-sharp.dll [11:39] rodrigo_, which depends on gnome-vfs [11:39] doesn't seem to depend on gnome-sharp.dll [11:39] * rodrigo_ re-checks [11:40] rodrigo_, monodis --assemblyref /usr/lib/cli/gconf-sharp-peditors-2.24/gconf-sharp-peditors.dll [11:40] rodrigo_: try monodis --assemblyref /path/to/dll | grep Name [11:40] Name=gnome-sharp [11:40] you can see it probably with "using Gnome;" in the sources [11:40] it probably follows the c lib [11:40] $ monodis --assemblyref /usr/lib/cli/gconf-sharp-2.0/gconf-sharp.dll | grep Name [11:40] Name=mscorlib [11:40] Name=glib-sharp [11:41] that one is better ;-) [11:42] I don't know the API at all, but maybe you can replicate it on top of gconf# [11:43] pitti, https://bugs.launchpad.net/ubuntu/+source/ubuntu-geoip/+bug/715445 [11:43] Launchpad bug 715445 in ubuntu-geoip "indicator-datetime doesn’t get geoclue information from ubuntu-geoip-provider" [Undecided,New] [11:43] seb128: ah :) [11:43] pitti, you might get that bug [11:43] right, it indeed uses some Gnome. stuff, just for the filepicker button [11:43] I guess we can just change that to use Gtk.FileChooser [11:44] rodrigo_, is that exposed to the clients? i.e would that be an api, abi breakage? [11:45] not exposed, afaics [11:45] rodrigo_, did you talk to upstream tomboy about that? [11:45] just to know what they think [11:46] seb128, yes, but it's got nothing to do really with tomboy, tomboy just uses the PropertyEditor objects in gconf# [11:46] ddd [11:46] rodrigo_, well, it uses an api which use libgnome [11:46] yes, but lignome usage is internal to gnome-sharp [11:46] rodrigo_, so they need to clean that in some way, either by moving away from propertyeditor or by changing the bindings [11:47] rodrigo_, right, so either we move the issue to gnome-sharp [11:47] yes, changing the bindings is the easiest, it seems [11:47] or we port tomboy to not use propertyeditor [11:47] the usage of PEditor in tomboy is huge [11:48] bah [11:48] so it means gconfpeditor should be updated to stop using libgnome [11:48] then the libgnome2.24-cil should be splitted [11:48] it would be an api break as far as i can see [11:48] or the gconfpeditor binding moved with gconf# [11:49] void Changed (object obj, Gnome.ColorSetArgs args) [11:49] yeah, indeed [11:49] k [11:49] tomboy really need to stop using gconfpeditor [11:49] to switch to gsettings or something [11:50] rodrigo_, just forget about it for this cycle then, porting tomboy to gconf# seems work over what it's worth [11:50] ok, but I'll change the description of the bug [11:50] shame because it's the only thing keeping libgnomeui and libgnome on the default install [11:50] rodrigo_, can you check with upstream what are they gnome3 plans anyway? [11:50] they need to stop using libgnome some day [11:50] using gsettings or something else [11:50] seb128, sure [11:51] thanks [11:51] the mono gi stuff is currently being hacked on [11:51] so we should be able to get better bindings in the near future [11:52] those will be really welcome [11:52] it sucks to be stucked with old libs because mono is so behind [11:52] ups [11:53] Laney, btw is there any plan in debian to update mono from 2.6 to 2.8? [11:54] Laney, or alternatively any reason why 2.6 is better? [11:55] we are skipping to 2.10 and it's being worked in git currently [11:55] most of the work was on polishing for squeeze [11:56] ok... [11:56] is 2.10 out yet? will that land in debian before natty feature freeze or not? [11:56] just trying to figure what we should do in natty [11:56] hum, lunch time [11:56] it's on RC2 currently, and no probably not [11:56] ok [11:56] so I guess stay on 2.6 [11:56] thanks === artir is now known as Artir [12:16] hey didrocks, are you still having issues ssh'ing to people.canonical.com? I am having them now, but I want to confirm it's not just me before asking IS [12:17] dpm: just tried, it seems to be okayish… the ssh connectin hasn't dropped for a minute… [12:18] ok, thanks didrocks [12:19] ah, it just worked for me right now as well [12:20] seems that there are some underlaying network issue in any case… === MacSlow|lunch is now known as MacSlow [12:32] rodrigo_, did you confirm the vino issue or just reopened the bug to track it? === smspillaz|eating is now known as smspillaz [12:33] seb128, confirmed it, and found it seems to be an avahi issue [12:33] seb128, see my last comment [12:35] rodrigo_, ok, emails are lagging behind, I just got the one about the bug being reopen and assigned to you [12:35] seb128, my comment: "Following DaveHansen's comment, if you stop avahi daemon, no CPU high usage. Ditto if you restart avahi daemon again after having stopped it. So seems it's indeed an avahi problem" [12:35] just read the comment on launchpad [12:35] rodrigo_, yeah, got it now, thanks ;-) [12:36] I'm debugging avahi-daemon now, although it seems I'll need to restart the session [12:36] can't get it to use 100% cpu now [12:36]