[03:28] <LucidFox> What is Ubuntu's policy on supporting software outside the repositories? I've heard complaints about the removal of GTK1 breaking third-party applications.
[03:32] <ScottK> LucidFox: It's gone.  It's not coming back.
[03:32] <ScottK> It's ancient and unsupportable.
[03:32] <ScottK> I don't know that there's a formal policy, but gtk1 definitely needed to go.
[03:32] <RAOF> See also: libstdc++5
[03:33] <ScottK> Yes, exactly.
[03:33]  * ScottK got some hate mail when he wontfixed the bug to bring it back.
[03:33] <LucidFox> I wontfixed the bug to bring GTK1 back, saying:
[03:34] <LucidFox> 'It is not the responsibility of Ubuntu developers to guarantee workable conditions for "commercial linux applications and games" outside the repository; the best solution for such software would be to bundle the required libraries.'
[03:34] <LucidFox> Now I'm asked a source for that.
[03:34] <ScottK> LucidFox: What bug?
[03:34] <LucidFox> bug #478219
[03:34] <ScottK> I'll go back you up
[03:37] <StevenK> Just like people begging for libstdc++5
[03:39] <LucidFox> Well, it's a security nightmare to keep every obsolete version of every library ever written.
[03:39] <crimsun> LucidFox: the definitive reference is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520441
[06:02]  * StevenK watches nautilus combust
[06:03]  * ScottK hands StevenK another log for the fire.
[06:03] <StevenK> Haha
[06:03] <StevenK> Like dolphin is any better :-P
[06:05] <spm> xtree-pro ftw
[06:05] <StevenK> Oh god, I even remember using that
[06:06] <spm> you just dated yourself StevenK, +10 years. that is all.
[06:06] <StevenK> Meh
[06:06] <spm> :-)
[06:55] <humphreybc> Hi everyone, who do I need to talk to about Lucid CD contents?
[06:57] <alkisg> Today teeworlds complains "error while loading shared libraries: libGLU.so.1". I see that it was moved from /usr/lib/libGLU.so.1 to /usr/lib/mesa/libGLU.so.1, should there be a symlink or something now that's moved?
[06:58] <vish> humphreybc: #ubuntu-desktop
[06:58] <humphreybc> lol cheers vish i'll pop over there
[06:58] <vish> humphreybc: probably during work hrs UTC
[07:00] <ScottK> alkisg: Known breakage.  Hopefully fixed today.
[07:00] <alkisg> Thank you :)
[07:48] <didrocks> good morning
[07:51] <StevenK> didrocks: Morning!
[07:59] <dholbach> good morning
[08:15] <dholbach> could it be that libunwind is still in binary new?
[08:16] <dholbach> erm, never mind
[08:19] <xaka> is it possible to use more than 1 CPU to build packages? to speed up process...
[08:46] <ghostcube> xaka: it is
[08:46] <ghostcube> but dont ask me wheere i read about to config it
[08:46] <ghostcube> :D
[09:22] <geser> xaka: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options and read about "parallel"
[09:31] <tseliot> cjwatson, Riddell: can you approve my nvidia packages in NEW, please? (nvidia-graphics-drivers, -173, -96)
[09:32] <slytherin> Can someone with upload rights to linux-ports-meta please bump its version for karmic-updates?
[09:39] <tseliot> seb128: ^^
[09:42] <didrocks> cjwatson: when you're there, casper ready for sponsoring (bug #505140)
[09:47] <seb128> tseliot, ok, I finish something and I will have a look to those
[09:47] <tseliot> seb128: perfect, thanks
[09:48] <StevenK> seb128: I've been looking at them, I've shifted them over, I can accept them if you like
[09:48] <seb128> StevenK, please do
[09:48] <seb128> StevenK, thanks
[09:48]  * tseliot thanks both seb128 and StevenK
[09:49] <StevenK> seb128, tseliot: Accepted
[09:49] <seb128> thanks
[09:49] <tseliot> \o/
[10:05] <ttx> cjwatson, pitti: could one of you trigger a server CD respin, kirkland worked too late (on Sunday night ?) for the daily spin to pick up the latest eucalyptus
[10:09] <alkisg> Is syslinux going to be updated for Lucid? I've seen a lot of newer PCs unable to boot with the current Ubuntu isolinux/pxelinux versions, but which were able to boot with the debian ones.
[10:22] <DktrKranz> pitti: I was considering if could be feasible switching from tsclient to remmina (formerly known as grdc) as default RDP client for Lucid. The latter is actively maintained upstream, has the same features implemented in tsclient (but it has more), and is less buggy.
[10:22] <xaka> how to build packages which has cross-build deps? for example to build package A it need installed package B, but to build package B it need A.
[10:25] <geser> try to avoid it, as it makes the initial build hard
[10:25] <xaka> real example is openjade and libosp
[10:26] <xaka> libosp want openjade and openjade want libosp but how it is possible in same time? :)
[10:27] <xaka> seems like package maintainers use some "hack" to complete build process and resolve same issues?
[10:28] <geser> once you have one of the two packages build, you can use it to build the other, and so on. the hard part is the initial build
[10:28]  * geser hates several java-packages build-depending on itself :(
[10:29] <xaka> yeap, you are right. I'm about initial build
[10:30] <geser> you have to figure where is it easier to deactivate something to get it build, build the other one, undo your first changes and rebuild the package
[10:38] <cjwatson> ttx: running
[10:38] <cjwatson> didrocks: makes sense, looking at that now
[10:38] <cjwatson> alkisg: urgh, yeah, we probably ought to :-/
[10:38] <ttx> cjwatson: thanks !
[10:41] <cjwatson> didrocks: don't you want a trailing newline on that [daemon]? so echo rather than printf
[10:41] <cjwatson> (from the dept. of pickiness)
[11:10] <chrisccoulson> cody-somerville - do you install totem by default in xubuntu?
[11:22] <mr_pouit> chrisccoulson: yes
[11:22] <chrisccoulson> mr_pouit: thanks. does screensaver inhibiting work in xubuntu when you play a video?
[11:24] <mr_pouit> well, it works with mplayer + xscreensaver ^_^. I can try with totem & gnome-screensaver when I'm back at home.
[11:25] <chrisccoulson> mr_pouit - i've just thought - gnome-screensaver doesn't work in XFCE does it? it gets idletime from gnome-session
[11:27] <mr_pouit> yeah, it didn't work, but iirc, something was patched in karmic, so maybe it works finally
[11:28] <mr_pouit> 2.28.0-0ubuntu3.2 I think
[11:28] <chrisccoulson> mr_pouit - nothing has changed in karmic that would make it work under XFCE. the last update was to fix the legacy interface for inhibiting the screensaver
[11:28] <mr_pouit> okay, so yeah, still broken
[11:29] <mr_pouit> we'll probably switch to xscreensaver for lucid
[11:31] <chrisccoulson> i'd be interested to know if screensaver inhibiting works with totem and xscreensaver
[11:38] <siretart`> mr_pouit: does xfce use mplayer 'officially'?
[11:38] <siretart`> mr_pouit: I'm strongly considering dropping the mplayer-gui variant. would that affect xfce in any way?
[11:40] <mr_pouit> siretart`: no no, we do not use it officially. I'm only using it officially for myself ;)
[11:40] <siretart`> mr_pouit: what do you think about dropping gmplayer from the package?
[11:42] <mr_pouit> siretart`: I always use the cli because I found the gui ugly when I tried it (a long time ago). ^^
[11:42] <mr_pouit> and I think there are probably other guis more friendly such as gnome-mplayer.
[11:43] <siretart`> mr_pouit: well, I have the impression that more than 2/3 of the bugs in launchpad are only found in the gui variant. moreover it is more or less officially abandoned upstream…
[11:43] <siretart`> and I think we should prevent our users using it accidentally
[12:00] <jussi01> siretart`: this raises a point that I have been thinking about for a while, is there a chance we can set up a PPA or so for items like this that we drop from the archive? I mean theres been a big uproar because we have dropped things like libstdc++5 and gcc3.3 etc, it would be great if we could just say to people, hey! PPA is there, if you need it still? (I dont have skills to create/maintain it, but know anyone interested enough?)
[12:01] <cjwatson> why not just tell them to install those packages from older releases of Ubuntu?
[12:01] <jussi01> cjwatson: is that safe?
[12:02] <cjwatson> it's not like they change much
[12:02] <jussi01> I mean I can safely go tell people grab libstdc++ from hardy for your karmic install?
[12:40] <siretart`> jussi01: yes, that should work just fine
[12:46] <jussi01> siretart`: thanks!
[12:47] <pitti> DktrKranz: tsclient> wasn't that being deprecated by vinagre as well? perhaps you could mail -desktop@ or -devel@ about it?
[12:48] <seb128> pitti, it didn't yet
[12:48] <seb128> some protocols vinagre doesn't do
[12:49] <seb128> ie rdp I think
[12:49] <pitti> seb128: question is whether we should support that (especially with the nice integration into empathy now, etc.)
[12:50] <pitti> hm, RDP is fairly standard in the Windows world, isn't it?
[12:50] <seb128> yes
[12:50] <seb128> vinagre has the infrastructure for protocoles to be added
[12:50] <seb128> somebody need to do it though
[12:50] <seb128> we decided to keep tsclient until then the previous time we discussed those
[12:51] <seb128> I don't have the context for the current discussion though
[12:51] <pitti> *nod*
[12:51] <seb128> I just read you reply not the question
[12:51] <pitti> seb128: [11:22:05] pitti: I was considering if could be feasible switching from tsclient to remmina (formerly known as grdc) as default RDP client for Lucid. The latter is actively maintained upstream, has the same features implemented in tsclient (but it has more), and is less buggy.
[12:51] <pitti> seb128: that was the entire context
[12:51] <seb128> oh, no opinion about that
[12:51] <seb128> I neither use rdp nor know about remmina
[12:52] <seb128> I just use vnc and vinagre for that one
[12:52] <seb128> but mailing the list seems a good idea to get some user opinions
[12:52] <pitti> IMHO it would just replace a specialized program with another specialized program
[12:52] <pitti> maintenance is certainly an issue, of course
[12:53] <seb128> well if it's better maintained and less buggy and people want to do the work I will not say no
[12:53] <slytherin> As some4one who has used both vnc/RDP and clients vinagre/tsclient, vinagre doesn't come close to tsclient. I don't know how good is grdc.
[12:53] <seb128> I've no interest to work on either of those though
[12:53] <pitti> slytherin: usability wise, performance wise, or in which regard?
[12:53] <seb128> slytherin, what does tsclient do better? extra option? stability? speed?
[12:54] <pitti> VNC is utterly slow, but that's a matter of protocol, not implementation (mostly)
[12:54] <slytherin> seb128: pitti: tsclient is better in all regards. I never faced any problem with both vnc as well as RDP.
[12:54] <seb128> pitti, depends if that's because compression is not on for some reason
[12:54] <seb128> slytherin, not very a constructive comment to know what vinagre needs to do better
[12:55] <slytherin> seb128: pitti: Vinagre did not support compression and low color depth until 2.29.x (which is not available in any stable release)
[12:55] <slytherin> and no support for low color depth means 'not usable on slow connections'
[12:55] <seb128> "until 2.29"
[12:55] <seb128> which means it's fixed in lucid?
[12:55] <seb128> anything else that needs to get done there?
[12:56] <slytherin> It is fixed in 2.29.x as per upstream developers. I haven't actually tested it.
[12:56] <seb128> right, news states that too
[12:57] <seb128> need to restart my session brb
[13:04] <pitti> argh, disconnected; I blame the tunnel we just passed through
[13:04]  * pitti waves until tomorrow; IRC on the train is too clumsy
[13:05] <StevenK> Haha
[13:21] <slytherin> pitti: It will be great if you can approve evolution-mapi for karmic-proposed soon. :-)
[13:25] <mr_pouit> what's the preferred option if we want to add ubiquity slideshow for Xubuntu? Create a dedicated package (ubiquity-slideshow-xubuntu?), or ask for a 'xubuntu' directory inside the current ubiquity-slideshow-ubuntu (will ubiquity know which ones it should use?)?
[13:31] <didrocks> cjwatson: sorry, I was away. I guess you was prefering printf to echo (even without -e option). You can change it to echo if you prefer (or I can do it if you wish)
[13:32] <didrocks> cjwatson: do you want me to rebuild on evand's fix?
[13:33] <DktrKranz> pitti: partly. IIRC vinagre is currently able to access to VNC only, a RDP plugin is planned but still not implemented. I'll send a mail to -desktop with additional info, thanks!
[13:36] <cjwatson> didrocks: I guess you need to
[13:37] <cjwatson> didrocks: echo '<string not beginning with - and not containing \>' is fine
[13:38] <cjwatson> it's only when you have options and/or escape sequences that it all goes nonportable very quickly
[13:46] <didrocks> cjwatson: I've just pushed the merge with 'echo' and evand's change into my linked branch
[14:28] <cody-somerville> chrisccoulson, it would be nice if we could get gnome-screensaver to work again with xfce.
[14:29] <bdrung> james_w: is bug #503169 fixed? I cannot find version 0.9.6.5-4 in the archive.
[14:35] <slytherin> bdrung: looks like there is some problem even https://edge.launchpad.net/ubuntu/+source/downloadstatusbar lists -2 as latest version.
[15:42] <barry> hello ubuntu developers!  i'm trying to package my first python library but i'm having some problems.  does anybody have time to help a n00b?
[15:50] <ev> barry: #ubuntu-motu would be a better starting point.
[15:51] <barry> ev: thanks! /me -> #ubuntu-motu
[16:11] <falktx> hi
[16:11] <falktx> I'm having problems compiling opengl stuff in Lucid PPAs
[16:12] <falktx> it always fails detecting opengl/glu libs
[16:12] <falktx> is this a known issue?
[16:19] <sistpoty|work> falktx: yes, it is
[16:21] <falktx> ok, thanks
[16:21] <falktx> at first I though I was doing something wrong
[16:21] <falktx> then 2 package failed with the same error
[16:27] <blackxored> hello
[16:28] <blackxored> why songbird isn't in the repos, anyone working on it???
[16:31] <directhex> blackxored, it bundles a heavily modified xulrunner, so i doubt it would pass NEW until it builds against "normal" xulrunner
[16:31] <blackxored> directhex, oh I now I see
[16:32] <blackxored> it's detached from the xulrunner we have in ubuntu, or it's a fork or something
[16:32] <blackxored> or just a new version
[16:32] <blackxored> ?
[16:32] <directhex> forked
[16:32] <blackxored> directhex, and the only program using that fork in songbird?
[16:32] <ScottK> directhex: Given that we're taking chromium in the archive and it essentially bundles a copy of everything, I'm not sure how much we care.
[16:33] <directhex> ScottK, oh, can i upload moonlight 2.0 then, which bundles mono 2.6?
[16:34] <ScottK> You can upload it.  I won't be the one that decides if it gets in.
[16:34] <blackxored> no, I won't encourage bad practices
[16:34] <blackxored> and that for sure won't get accepted in debian
[16:34] <blackxored> so I'll wait
[16:34] <blackxored> is anyone interested in working on this package to get in touch with?
[16:53] <directhex> ScottK, well, sure. but there remains more hard work to get it finished, and i abandoned it when i hard ftpmaster say it'd get outright refused for bundling. so is there an actual policy difference in ubuntu, or simply a "policy says foo, but... but... but... chromium!"
[16:54] <ScottK> I think it's more the latter.
[17:01] <directhex> yeah, i suspected as much
[17:07] <zul> pitti: when you get a chance can you move landscape-client from -proposed to -updates?
[17:08] <ScottK> lamont: Looks like whatever you did to artigas yesterday helped, but not enough to actually get it building packages ....
[17:34] <ccheney> did kdelibs ever get built properly?
[17:34]  * ccheney needs to know when to retry OOo
[17:35] <ccheney> hmm looks like it is done on all but arm
[17:35] <Riddell> ccheney: opengl is still broken as far as I know so it won't work currently
[17:36] <ccheney> Riddell: oh
[17:36] <ccheney> :-\
[17:36] <ccheney> set amd64 to retry but won't bother with the others then
[17:36] <ccheney> Riddell: did you mean opengl is just broken on arm or that kdelibs won't work generally?
[17:36] <ScottK> ccheney: It's kdebase-workspace you want to watch.
[17:37] <ScottK> ccheney: mesa is broken generally.
[17:37] <ccheney> ok
[17:37] <ScottK> Also it's kde4libs you want to be watching.  kdelibs is the kde3 one.
[17:38] <ccheney> oh i see
[17:38] <ScottK> ccheney: At this point you may want to consider not retrying until after the Alpha given how long the builds take ...
[17:38] <ScottK> (not sure)
[17:43] <ccheney> yea
[17:44] <ccheney> slangasek: ^ looks like due to opengl/kde4libs breakage the OOo upload I did won't be building in time for alpha
[17:48] <lamont> ScottK: sigh
[18:42] <chrisccoulson> siretart` - there?
[18:49] <hyperair> slangasek: by "something like this" do you mean the template script disabled by default, or have a script shipped in pm-utils by default?
[18:49] <hyperair> i mean have the script enabled or disabled by default?
[18:52] <kees> pitti: where did the workitems go?  404 on http://piware.de/workitems/
[18:53] <ScottK> Must mean you're done.
[18:56] <slangasek> hyperair: well, in /my/ opinion we should figure out how to get it right so that we can enable it by default
[18:56] <slangasek> hyperair: as a user who frequently swears at his NFS mounts after resuming his laptop in a new location :)
[18:56] <hyperair> heheh
[18:56] <hyperair> okay
[18:57] <hyperair> so we should enable it by default, and let whoever doesn't want it chmod -x it?
[18:57] <hyperair> slangasek: but what remote filesystems do we have to cater for?
[18:58] <hyperair> slangasek: there's nfs and cifs for the non-fuse filesystems (i'm not sure if there are any more) but there are also fuse.ssh, among other fuse filesystems. then there are gvfs mounts which a pm-utils script probably won't be able to touch.
[19:03] <slangasek> hyperair: the same list of fs types that mountall uses; if there are things mountall doesn't handle as network filesystems but needs to, that should be fixed first
[19:04] <hyperair> slangasek: i thought as much, but when i dug through the mountall code, it seems that all it does upon SIGUSR1 (network device up) is to run through the unmounted stuff from fstab and try mounting them.
[19:11] <slangasek> hyperair: hmm, I don't think it's possible for mountall to work correctly unless it has a concept of remote mounts, /somewhere/.
[19:12] <hyperair> slangasek: no, not necessary. upon sigusr1, it just has to mount -a again. everything that wasn't already mounted will be mounted. stuff that didn't get mounted the first round due to lack of network will probably be mounted this round, when there is a network.
[19:12] <hyperair> slangasek: that said, it doesn't actually call mount -a.
[19:12] <hyperair> lemme find the code..
[19:13] <hyperair> no wait
[19:13] <hyperair> there's a is_remote(mnt) there
[19:13] <hyperair> lemme go check
[19:14] <slangasek> hyperair: no, it really does need to know which ones are remote, otherwise it can't behave sensibly wrt deferring them at boot-time and breaking the dependency cycle with network-manager
[19:14] <hyperair> ah
[19:15] <hyperair> slangasek: http://pastebin.com/f3e5b6c20
[19:15] <hyperair> that's the is_remote function.
[19:15]  * slangasek nods
[19:15] <slangasek> "smbfs" - obsolete, should be pruned from that list :)
[19:16] <hyperair> mm
[19:16] <hyperair> what if the user was using some legacy kernel to boot?
[19:16] <hyperair> =
[19:16] <hyperair> =p
[19:16] <slangasek> then udev would laugh at them
[19:16] <hyperair> heheh
[19:16] <hyperair> right
[19:16] <hyperair> what about the fuse network filesystems?
[19:16] <slangasek> also, we haven't shipped the userspace tools for mounting smbfs for 3 cycles
[19:17] <slangasek> fuse> dunno, but it's not a problem specific to this proposed change, mountall also has the problem
[19:17] <hyperair> yes, agreed
[19:17] <slangasek> (and we can only sensibly unmount those shares that are listed in /etc/fstab, otherwise we can't remount them from the user afterwards...)
[19:17] <hyperair> but fuse mounts are less likely to be in the fstab
[19:17] <slangasek> s/from/for/
[19:17] <hyperair> fuse mounts are more likely mounted by the user after boot. so mountall isn't as impacted
[19:18] <hyperair> as for safely remounting for the user...
[19:18] <hyperair> it is possible to dump /proc/mounts out
[19:18] <hyperair> just the required filesystems.
[19:18] <hyperair> how do you handle spaces in fstab?
[19:19] <hyperair> like spaces in the path to mount, or the mount point
[19:41] <cjwatson> hyperair: fstab(5) describes how to escape spaces
[19:41] <hyperair> ah okay thanks
[19:42] <cjwatson> hyperair: there are actually a few more escapes than that - see getmntent(3)
[19:42] <hyperair> the output of mount looks pretty hard to parse for a shell script though
[19:43] <cjwatson> that's at least part of why Keybuk wrote mountall ...
[20:28] <lool> So my system went to 100% CPU during my last upgrade and hung, had to hard reboot, and is not coming up anymore; it fails with /sbin/init: I/O error
[20:28] <lool> Oddly, if I try /bin/bash as init I get the same kind of error
[20:28] <lool> This is with ext4 on a SSD, so I would be surprized if any hardware is involved
[20:28] <lool> Is there any known bug which could cause this?
[20:29] <lool> I think I'll boot on an USB key and fsck /
[20:33] <siretart> chrisccoulson: now, yes?
[20:53] <hwilde> seen persia
[20:53] <hwilde> !seen persia
[20:54] <hwilde> :/
[20:55] <Pici> hwilde: also... hes online now
[21:04] <tseliot> lamont, NCommander: can you rescore the builds for mesa, please? Kubuntu depends on it
[21:04] <lamont> tseliot: any particular architecture?
[21:05] <tseliot> lamont: definitely i386 and amd64
[21:05] <tseliot> nixternal, Riddell: anything else? ^^
[21:06] <lamont> 7.7-0ubuntu4?
[21:06] <lamont> (it's these little details that help ...)
[21:06] <tseliot> lamont: yes, that one
[21:07] <lamont> tseliot: so it's been building for at least a few minutes everywhere but ia64 and sparc...
[21:07] <lamont> and funny thing, launchpad.net/builders shows empty queues everywhere except those two architectures...
[21:07] <lamont> so why did you want it rescored when it's already building???
[21:07] <tseliot> lamont: oh, fantastic
[21:08] <nixternal> ScottK: ^^
[21:08] <nixternal> :)
[21:08] <tseliot> lamont: I checked that before asking you. Never mind. Thanks anyway. I might need your help later
[21:08]  * tseliot > dinner (brb)
[21:11] <NCommander> tseliot, ah, lamont beat me to it
[21:11] <NCommander> tseliot, ScottK, I'll be looking at kdelibs tonight
[21:13] <lamont> NCommander: no, build-manager beat both of us
[21:19] <NCommander> lamont, :-)
[21:20] <lool> FTR, I managed to fix my laptop with dpkg --root /mnt --force-architecture --unpack /mnt/var/cache/apt/archives/libc6*.deb after I saw that dpkg.log was interrupting in libc6 packages
[21:20] <lool> Now I'm checking why the new initramfs doesn't have /init
[21:21] <lool> Hmm it does but I get a cannot run /init error
[21:34] <lool> FTR again: finished recovering by recreating initrd forcefully after the upgrade with a partially broken libc; boots fine again
[21:34] <chrisccoulson> siretart - was it you who suggested trying XResetScreenSaver for bug 428884?
[21:39] <kirkland> pitti: did http://www.piware.de/ die?
[21:39] <kirkland> pitti: 404
[21:42] <jiboumans> kirkland: i reported the same; rickspencer's pinged him
[21:42] <siretart> chrisccoulson: I'm not sure if it was exactly that function, but i remember it was from libxscreensaver
[21:42] <kirkland> jiboumans: cool, thanks
[21:43] <chrisccoulson> siretart - XResetScreensaver is just plain xlib, rather than xscreensaver, although I haven't tried to see if it works yet
[21:43] <chrisccoulson> i was going to credit you in the changelog if it works ok, but i wasn't sure if it was you who suggested it originally
[21:47] <siretart> chrisccoulson: actually, I first considered XResetScreensaver, but then you've pointed me the various screensaver APIs IIRC
[21:47] <siretart> chrisccoulson: so does XResetScreensaver reset the idle counter after all?
[21:48] <chrisccoulson> siretart - i'm not sure yet, i'm just about to try it
[21:48] <chrisccoulson> but i found some bits in google when i was at work earlier which suggests it may do now
[21:48] <siretart> if it doesn't, perhaps it could be extended to do so in the xserver?
[21:53]  * sebner hugs tseliot as he sees his gnome-shell build again :D
[21:54] <tseliot> sebner: it took a while but it seems that it was worth it ;)
[21:54] <sebner> tseliot: hmm reminds me about our nvidia testing session :P
[21:55] <tseliot> sebner: this one was more intense and my filesystem died this time ;)
[21:55] <tseliot> (without rebooting)
[21:55] <sebner> tseliot: hahahahaha, mine with rebooting you know .. so we are even now :P
[21:55] <tseliot> ;)
[21:58] <chrisccoulson> siretart - looking in the xorg code, lastDeviceEventTime is updated when calling XResetScreenSaver, and I think that is where IDLETIME comes from
[21:58] <chrisccoulson> so it should work fine :)
[21:59] <chrisccoulson> but my xorg knowledge is not so great
[21:59] <chrisccoulson> i'll just try it and see ;)
[22:16] <tseliot> lamont, NCommander: I uploaded xorg-server and it built against mesa 7.7-0ubuntu3 instead of 7.7-0ubuntu4: http://launchpadlibrarian.net/37745022/buildlog_ubuntu-lucid-i386.xorg-server_2:1.7.3.902-1ubuntu4_FAILEDTOBUILD.txt.gz
[22:16] <lamont> prolly hasn't published yet.
[22:16] <lamont> patience is a virtue, to quote another wiki page... :-(
[22:16] <lamont> and it's not somethign I can fix
[22:17] <lamont> that requires an archive admin
[22:17] <tseliot> lamont: ok, thanks
[22:17] <slangasek> what does?
[22:17] <slangasek> is mesa stuck in new?
[22:18] <tseliot> slangasek: I don't think it should
[22:18] <lamont> that or it needs a publisher run?  I'll go with 'prolly new'
[22:20] <slangasek> no, i386 and amd64 are installed; looks like it was a timing problem
[22:22] <tseliot> slangasek: can I retrigger the build now?
[22:25] <tseliot> I'll take it as a yes
[22:29] <slangasek> yes, please :)
[22:31] <chrisccoulson> siretart - it doesn't work in lucid :(
[22:31] <chrisccoulson> but does in karmic
[22:39] <tseliot> lamont: can you rescore this, please? https://launchpad.net/ubuntu/+source/xorg-server/2:1.7.3.902-1ubuntu4/+build/1441164
[22:39] <tseliot> this time you can't say that I didn't give you enough details ;)
[22:40] <lamont> done
[22:40] <lamont> tseliot: and that was absolutely perfect
[22:40] <tseliot> lamont: thanks a lot :-)
[22:43] <ion> The smooth transition from plymouth to X is really nice. Yay to Keybuk for making plymouth work.
[22:44] <TheMuso> All well and good for those with KMS hardware. :p
[22:45] <RAOF> And don't have encrypted filesystems ;)
[22:46] <tseliot> RAOF: I haven't had time to work on that but I should fix it soon
[22:47] <RAOF> Oh, your the one in charge of that?  Cool.
[22:47] <ion> Now if i could actually use KMS. It breaks vsync with Xv. (I should really get around to reporting a bug, unless one already exists.)
[22:47] <chrisccoulson> siretart - http://bugs.freedesktop.org/show_bug.cgi?id=25855
[22:48] <tseliot> RAOF: I wrote the theme (which is a program written in its own language) and but I didn't take care of the use-case of disk encryption
[22:48] <tseliot> it looks like Keybuk took care of that nasty vt problem
[22:48] <tseliot> :-)
[22:48] <ari-tczew> tseliot, thanks for nvidia-settings, could I later merge package with Debian?
[22:49] <tseliot> ari-tczew: why do you want to do that?
[22:50] <tseliot> (just asking)
[22:51] <ari-tczew> feel clean up between systems
[22:52] <tseliot> ari-tczew: feel free to try but please contact me before you upload that
[22:54] <ari-tczew> tseliot: sure of course, now other question: is it possible to provide nvidia driver 190 by nvidia-glx-190 instead nvidia-glx-185?
[22:54] <tseliot> ari-tczew: it's called nvidia-current now
[22:55] <tseliot> ari-tczew: it might not work today but it should tomorrow
[22:55] <ari-tczew> ok
[23:08] <ScottK> NCommander, lamont, elmo, pitti: Would one of you please rescore xorg-server to build first.  It's the critical path item in getting out of the mesa mess at the moment.
[23:08] <lamont> ScottK: that'd be what tseliot had me do a bit back
[23:08]  * tseliot nods
[23:09] <lamont> and yellow is back in the hunt
[23:09] <ScottK> lamont: OK.  Just making sure.  Thanks.
[23:12]  * tseliot -> off for a bit
[23:17] <ari-tczew> any sponsor for main is working on merges?
[23:50] <chrisccoulson> slangasek - a recent gnome-screensaver SRU has caused a regression in karmic (bug 505789). i think the best thing to do is back out the patch which caused it and re-open the original bug, as there is no viable solution for fixing the original issue at the moment
[23:50] <chrisccoulson> do you think that's the right thing to do?
[23:51] <slangasek> chrisccoulson: it's a reasonable thing to do, and I trust your analysis wrt the viability of a complete solution
[23:51] <slangasek> if one shows up later, it's always an option to SRU with a better patch
[23:52] <chrisccoulson> slangasek - ok, i'll do that. do i need to go through the usual route of uploading to karmic-proposed, and could you process the SRU?
[23:52] <slangasek> chrisccoulson: you mean bypass karmic-proposed entirely?
[23:53] <slangasek> I would prefer that the upload go via karmic-proposed, but we don't have to wait 7 days before copying
[23:53] <chrisccoulson> slangasek - ok, thanks. i'll work on that now