[01:18] <mjg59> keescook: Any user can access arbitrary areas of memory that X has access to given SHMConfig, IIRC
[01:19] <pygi> mjg59, are you open for a little kernel-related question at this early hours?
[01:19] <mjg59> keescook: The driver should just be fixed to handle stuff based on X auth tokens, like Wacom does
[01:24] <keescook> mjg59: agreed about the "needs fixing", however, afaict, the SHMConfig option of the synaptic driver "only" lets people muck with the synaptics settings. (I sent some email about it)
[01:26] <mjg59> keescook: I still don't consider that an acceptable risk. Careful choices would allow arbitrary X input.
[01:27] <mjg59> (Just limit the coordinate space to the thing you want clicked)
[01:27] <mjg59> pygi: Sure
[01:28] <keescook> mjg59: agreed, though I wasn't too sure how that could work, after I looked at the code.
[01:34] <pygi> mjg59, are you aware of any problems with VIA VT6240 SATA controller perhaps due to a kernel/driver bug?
[01:43] <mjg59> pygi: Not to the best of my knowledge
[01:44] <pygi> mjg59, ok,thanks
[01:44] <mjg59> keescook: Anyone with local access can effectively set arbitrary constraints on the touchpad coordinates and how they correspond to the screen. It pretty much means you can control where their next mouse button click is going to be
[01:45] <calc> i'm getting failed to upload errors for ooo and ooo-l10n
[01:45] <calc> is that due to a freeze or something else?
[01:45] <keescook> mjg59: fair enough.
[01:46] <mjg59> keescook: So you have an excessive quantity of influence over what the user can do, which is kind of bad
[01:50] <mjg59> (Though Intel have been buying me Tequila tonight, so you might not want to believe anything I say)
[02:40] <ion_> Oh, i hadnt even noticed xorg 7.3 was released last week. Input hotplug 
[02:43] <mthaddon> just got a "FATAL: Error running install command for nvidia" after latest gutsy upgrade for nvidia-glx - is it just me?
[02:44] <mthaddon> or rather, my X server crapped out and after some recovery (gtk-displayconfig not too successful for me) and manually trying to load the nvidia module I get that (trying to see what errors it was giving)
[02:45] <mthaddon> sorry, just read the topic header... will head over to #ubuntu+1
[03:01] <f0rqu3> is there a newer fglrx package available?
[03:01] <f0rqu3> 8.40 for example
[03:02] <f0rqu3> the one in the repo is 8.34 :(
[03:05] <dobey> f0rqu3: in the repo for feisty?
[03:05] <f0rqu3> yes
[03:05] <dobey> there might be a newer version available for gutsy
[03:06] <f0rqu3> gutsy is older?
[03:06] <bhale> no. newer
[03:06] <dobey> why would there be a newer version of something in an older repo? :)
[03:06] <f0rqu3> lol
[03:06] <f0rqu3> fail
[03:07] <f0rqu3> can I add its repo to feisty?
[03:07] <zul_> no
[03:07] <dobey> fglrx is probably bound to the kernel
[03:07] <dobey> so that might be a bad idea
[03:08] <dobey> if there's a compelling reason to release an update for feisty, it's probably best to file a bug detailing that reason, and requesting it be done
[03:09] <f0rqu3> probably I will compile it myself when the 8.41 releases
[04:28] <mekius> hi, when the live first boots up you get a menu, where are the settings/images for this menu?
[04:28] <mekius> i would like to modify it
[04:31] <mekius> any help is appreciated
[08:01] <kagou> Good Morning :)
[08:52] <pitti> Good morning
[09:04] <StevenK> Morning pitti
[09:05] <mdke> hi StevenK, I was reading on your interview that you're interested in working on a new about window; do you happen to have a spec or something already?
[09:06] <StevenK> mdke: Sure. There are two specs, and some code on LP.
[09:07] <mdke> StevenK: can you give me the details?
[09:08] <StevenK> mdke: Looking it up now.
[09:08] <mdke> btw you might already know this, but mpt did some similar work a few cycles back. I don't know how far he got, but it's probably worth touching base with him, unless you have already
[09:09] <StevenK> Hold on, OTP
[09:11] <pitti> hey StevenK
[09:18] <Lure> pitti: morning
[09:18] <Lure> pitti: libgphoto2 is in my ppa, but I have at least one regression report, so I am not sure anymore we want to push it
[09:19] <Lure> pitti: and the condition in postinst was wrong, so it is fixed now in merged package
[09:19] <pitti> Lure: oh, what broke? if it's too bad, it's worth filing a bug upstream, they are pretty responsive
[09:19] <pitti> so that it's sorted out with the opening of hardy
[09:20] <Lure> pitti: <allee> Lure: bad news about libgphoto2 2.4.0 (with cannon powershot A40). gphoto2 --auto-detect -L works once, next try hangs after autodetecting :( 2 x Ctrl-c to hard abort. Then it works again, 2nd hangs. etc. I see same in digikam :(
[09:20] <pitti> sjoerd: any idea why python-avahi contains SimpleGladeApp.py and depends on python-glade? it pulls in an awful lot of Glade/X11 dependencies but doesn't actually use any of it
[09:21] <Lure> pitti: it works for me for Canon G3 (UMS) and 400D (PTP)
[09:21] <pitti> hey mvo
[09:21] <Lure> pitti: will talk with allee to check with upstream
[09:21] <Lure> pitti: and try to find some more testers with other digital cameras
[09:23] <mpt> mdke, StevenK's code is a rewrite of my code
[09:23] <StevenK> Right, off the phone for a moment
[09:23] <mpt> https://code.edge.launchpad.net/about-window
[09:24] <StevenK> mdke: Sorry about that - the two specs are: https://blueprints.launchpad.net/ubuntu/+spec/about-ubuntu (which is mpt's) and https://blueprints.launchpad.net/ubuntu/+spec/about-ubuntu-revisited (which is mine)
[09:24] <mdke> mpt: excellent; that's fine, I was just checking
[09:24] <mdke> StevenK: there are two things I wanted to ask you about it. (1) was whether you have been thinking about merging the gnome and ubuntu about dialogues; I think it's confusing to have both, especially because your average user won't know what Gnome is. (2) was whether you can keep the documentation team in the loop about your project, especially in terms of how much of the existing document you're using, whether you envisage it remaining available in so
[09:24] <StevenK> pitti has also had a poke around the code.
[09:24] <mdke> Ill read the specs now
[09:25] <StevenK> mdke: I've been thinking about that - so far, the current Python code fires off hal-device-manager - perhaps it should fire up yelp.
[09:25] <dholbach> good morning
[09:25] <mdke> StevenK: on (2)?
[09:25] <StevenK> mdke: This neatly allows people to see quickly what version and so on they're running, but also lets them see more information.
[09:25] <StevenK> mdke: Yup.
[09:26] <mdke> morning dholbach
[09:26] <mdke> StevenK: could be.
[09:26] <mpt> StevenK, what's the use case for the "More Information" link?
[09:26] <StevenK> mdke: Merging the Gnome and Ubuntu about dialogs I've not thought about, and secondly, that leaves Kubuntu and so on out in the cold.
[09:26] <dholbach> hey mdke
[09:26] <mpt> Kubuntu would, presumably, want a Qt About window :-)
[09:27] <mvo> good morning pitti
[09:27] <StevenK> Of course. I've modarlised the code so they can have one.
[09:27] <mdke> StevenK: ok, let's think about it :)
[09:28] <StevenK> mpt: You removed the More Information button from your spec, if I recall.
[09:28] <mpt> StevenK, I don't remember whether it was ever there
[09:28] <mpt> it may have been
[09:29] <mdke> the Gnome/Ubuntu branding conflict is something I've come up against in documentation too; we reuse quite a lot of Gnome documentation, and I find it really confusing to have some documents continuously referring to "the Gnome desktop" when ever since the user has turned the computer on it's been branded as Ubuntu
[09:29] <mpt> but I don't think it's useful
[09:29] <mdke> but I don't know what the policy is with upstream and us about branding, I think it needs discussion
[09:29] <mpt> Much of what's in the about page would make more sense in one or two help pages.
[09:32] <MacSlow> mvo, dholbach: the workspace-mapping between compiz and metacity is a mess... that and #122549 are keeping me very busy for some days to come I'm afraid
[09:32] <mdke> StevenK: anyway, just wanted to flag those things up so that we can think about / discuss them
[09:33] <dholbach> bug 122549
[09:33] <ubotu> Launchpad bug 122549 in compiz "[gutsy]  compiz fusion breaking gnome-screensaver behaviour" [High,Confirmed]  https://launchpad.net/bugs/122549
[09:33] <mdke> dholbach: congrats on the new job, that's awesome
[09:33] <dholbach> thanks a lot mdke :)
[09:33] <StevenK> mdke: Sure. Scribble all over https://wiki.ubuntu.com/AboutUbuntuRevisited if you wish.
[09:34] <mdke> StevenK: will do
[09:36] <sjoerd> pitti: It's what upstream ships inside the avahi module... But yeah it's a bit silly indeed
[09:38] <holycow> hey guys
[09:38] <allee> Lure, pitti: about gphoto problem: http://sourceforge.net/tracker/index.php?func=detail&aid=1791834&group_id=8874&atid=108874 no responds yet.  I've to wait for gerhard the canon expert
[09:39] <ubotu> Sourceforge bug 1791834 "Powershot A40: 2.3.1 -&gt; 2.4.0 regresssion:  gphoto2 -L hang" [Pri: 5,Open] 
[09:39] <Lure> allee: thanks for link - I have just send the request to mailing list as well
[09:40] <pitti> sjoerd: so we could really remove the SimpleGladeApp.py and the dependency; I got a mail from someone wanting to use it for PXE, and those dependencies really hurt him
[09:42] <sjoerd> python for PXE ? :)
[09:42] <sjoerd> But well, yeah
[09:42] <pitti> > mDNS package sharing would be very useful for the PXE clusters
[09:42] <pitti> > we are running, but the x11 dependency kinda spoils the fun.
[09:42] <pitti> sjoerd: thin clients, I assume
[09:42] <sjoerd> I'll talk to lennart about moving SimpleGladeApp into avahi-discover
[09:42] <sjoerd> aah
[09:42] <sjoerd> That's about the only thing that uses it i guess..
[09:43] <sjoerd> Maybe the service-applet too
[09:51] <mdke> StevenK: lp does the subscribe to wiki page bit automatically on the spec
[09:51] <StevenK> mdke: Ah
[09:51] <mdke> they think of everything :)
[09:54] <stdin> is there any reason that ubuntu-desktop and kubuntu-desktop need to share ~80 depends/recommends? why not put them in ubuntu-standard?
[09:59] <\sh> guys, compiz and X are going mad somehow since the last update
[10:00] <tepsipakki> \sh: in what way?
[10:01] <Amaranth> \sh: nvidia?
[10:02] <stdin> hmm, and things like acip, acpid, cups and hal really should be in -standard
[10:03] <\sh> Amaranth, standard radeon (xorg driver)
[10:03] <\sh> mouse movements are totally fast, or when you setup the mouse movement in gnome mouse config it's too slow
[10:03] <Amaranth> and turning off compiz fixes this?
[10:04] <\sh> and since the last startup (this morning) with compiz-fusion, background is black
[10:04] <\sh> disabling compiz it's back to normal, but not the mouse movement
[10:04] <Amaranth> ok, so i only need to figure out the black background :)
[10:04] <Amaranth> \sh: is it just black or do you get ghosting too?
[10:04] <\sh> oh....mouse acceleration settings in gnome-mouse-config isn't saved
[10:05] <\sh> Amaranth, just black background
[10:05] <Amaranth> hmm
[10:05] <Amaranth> do you use the wallpaper plugin?
[10:05] <\sh> Amaranth, nope
[10:05] <Amaranth> hmm
[10:05] <\sh> Amaranth, standard ubuntu background
[10:05] <Hobbsee> good evening sabdfl
[10:05] <\sh> Amaranth, I just removed all my .gnome* dirs and .gconf* dirs
[10:06] <\sh> to be sure, it's not a wrong gconf setting or whatever
[10:06] <Amaranth> \sh: try changing...oh
[10:08] <\sh> seb128/dholbach: gnome-mouse-settings are not saved correctly, and it looks like only mouse acceleration is not saved
[10:09] <Amaranth> \sh: what is your screen resolution?
[10:09] <dholbach> \sh: I told you that I don't know much about it - best to file a bug
[10:10] <\sh> Amaranth, 1280x1024
[10:10] <cjwatson> mekius: mostly in gfxboot-theme-ubuntu, though there are some extra files in /isolinux/ on the CD
[10:13] <Amaranth> \sh: glxinfo -l | grep MAX_TEXTURE_SIZE
[10:20] <\sh> Amaranth, 2048
[10:20] <Amaranth> ok, that's not it
[10:21] <Amaranth> \sh: wait, do you have a desktop manager running?
[10:21] <Amaranth> nautilus, kdesktop, etc
[10:21] <tormod> grub is now built on all platform (instead of just i386 and amd64) and fails on sparc,powerpc,ia64. should something be changed to avoid trying those builds? (the latest upload didn't change anything in that respect)
[10:22] <\sh> Amaranth, the standard gnome stuff from scratch
[10:22] <\sh> Amaranth, no kde , no other unsual stuff...plain gutsy
[10:22] <Amaranth> so nautilus is showing a desktop
[10:23] <Amaranth> i mean, you have icons and junk, right?
[10:23] <Amaranth> just no wallpaper
[10:23] <\sh> Amaranth, I have the menu bar , no icons on the desktop, background is black
[10:23] <\sh> the panels are there, I can see windows with decorations
[10:23] <Amaranth> do the icons come back when you kill compiz?
[10:23] <Amaranth> or do you just not have them at all?
[10:23] <\sh> Amaranth, when I disable effects  in the appearance configuration it all comes back
[10:24] <Amaranth> \sh: ok, when compiz is running kill nautilus
[10:24] <Amaranth> it'll restart
[10:24] <\sh> Amaranth, oh sorry...right now I see that I don't have any window decoration buttons...just the window decoration itself, with no buttons
[10:24] <Amaranth> o_O
[10:24] <Amaranth> ok, i'm now blaming this on X :P
[10:25] <Amaranth> do windows sometimes come up blank too?
[10:26] <\sh> Amaranth, I just restarted the desktop effects (normal) and I have everything back but not the icons and background
[10:26] <Amaranth> ok then, try killing nautilus
[10:26] <\sh> Amaranth, done
[10:26] <\sh> Amaranth, no nautilus{*} in my process list anymore
[10:27] <\sh> and no restart of nautilus
[10:27] <Amaranth> weird, gnome-session should have restarted it
[10:27] <Amaranth> start it manually then
[10:27] <\sh> ah background and icons are back
[10:27] <Amaranth> now stop and start compiz again
[10:27] <Amaranth> see if it happens again
[10:28] <asac> siretart: ... managed to reproduce already? do you need any infos?
[10:28] <\sh> Amaranth, ok...system->administration->appearance-> no effects == window deco is there, no metacity fallback, no buttons in the deco
[10:29] <Amaranth> err
[10:29] <Amaranth> no effects _is_ metacity
[10:29] <\sh> Amaranth, with disabled effects, there is no key accelerators anymore (so no changing of desktops) no alt-tab is working nothing
[10:29] <Amaranth> ok, that's just weird
[10:30] <\sh> Amaranth, setting to normal effects brings back deco and buttons and key accells
[10:30] <Amaranth> metacity is freaking out?
[10:31] <\sh> metacity is running when I set to no desktop
[10:31] <Amaranth> and it's broken?
[10:31] <\sh> yepp
[10:31] <Amaranth> this is new
[10:31] <\sh> metacity --replace I can see in my process list
[10:32] <Amaranth> and also not something i know how to debug :P
[10:32] <Amaranth> so when you use metacity your window decorations are broken and no key accels works
[10:33] <\sh> Amaranth, hmm..the mouse is freaking out on all machines I have....gnome-mouse-settings is not saving the mouse accell...I'll file a bug, since it could be also the kernel, just because everything what's here is usb ...and even key repeat doesn't work anymore
[10:33] <\sh> Amaranth, right
[10:33] <Amaranth> sounds like you've got some more fundamental low level problem
[10:34] <\sh> well, on the console everything works normal
[10:34] <Amaranth> i meant with X
[10:34] <\sh> so it's not the kernel with some strange usb issue...
[10:34] <Amaranth> if metacity is broken then something is going really wrong
[10:34] <\sh> Amaranth, looks like...
[10:36] <\sh> I'll file a bug against xorg because of the mouse slow motion and keyboard probelms
[10:36] <dholbach> Keybuk: what do you think about the patch in bug 57755 and putting it into udev? it'd be nice if this would get included... somewhere
[10:36] <ubotu> Launchpad bug 57755 in gnupg "Udev Rules for SmartCard Support" [Undecided,New]  https://launchpad.net/bugs/57755
[10:37] <dholbach> lamont: shall I prod you about bug 33586 again? :)
[10:37] <ubotu> Launchpad bug 33586 in nmap ".desktop file cleanup for nmapfe" [Wishlist,Incomplete]  https://launchpad.net/bugs/33586
[10:38] <dholbach> iwj: does the patch in bug 135086 look ok?
[10:38] <ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Medium,Triaged]  https://launchpad.net/bugs/135086
[10:39] <\sh> bug 138826
[10:39] <ubotu> Launchpad bug 138826 in xorg "[gutsy]  since last update of xorg mouse is in slow motion or too fast to see" [Undecided,New]  https://launchpad.net/bugs/138826
[10:40] <\sh> dholbach, what's the right package for this gnome-mouse-settings applet?
[10:41] <\sh> ah capplets-data
[10:41] <dholbach> gnome-control-center
[10:41] <\sh> yepp
[10:44] <\sh>  bug 118593
[10:44] <ubotu> Launchpad bug 118593 in gnome-panel "mouse preferences acceleration not saving" [Undecided,Invalid]  https://launchpad.net/bugs/118593
[10:44] <\sh> already reported...
[10:48] <dholbach> calc: will you include the patch of bug 134112 in your next ooo upload?
[10:48] <ubotu> Launchpad bug 134112 in openoffice.org "added Xb-Npp-xxx tags accordingly to "firefox distro add-on suport" spec" [Undecided,New]  https://launchpad.net/bugs/134112
[10:54] <geser> can someone sponsor uploading boost? bug #134684
[10:54] <ubotu> Launchpad bug 134684 in boost "Upgrade to Version 1.34.1" [Wishlist,In progress]  https://launchpad.net/bugs/134684
[10:55] <Hobbsee> ew
[10:56] <Hobbsee> oh, pitti's approved that.
[10:58] <tormod> mjg59: are you happy with bug 127273 now?
[10:58] <ubotu> Launchpad bug 127273 in laptop-mode-tools "laptop-mode init script links not created" [Undecided,Confirmed]  https://launchpad.net/bugs/127273
[10:58] <geser> Hobbsee: yes, it's approved already, I need now someone to upload it.
[11:33] <slytherin> Can anyone tell me who maintains language-support packages? There is an unnecessary dependency in language-support-en. It depends on thunderbird-locale-en-gb but we don't ship thunderbird on CD now.
[11:38] <pitti> slytherin: *raising hand*
[11:39] <pitti> slytherin: however, the dependency is correct in terms of what language-support-XX is supposed to do
[11:39] <pitti> slytherin: the problem might rather be that we do not actually want to ship the entire l-s-en on the CDs
[11:41] <slytherin> pitti: As of now, we ship thunderbird-locale-en-gb on CD where as we don't ship thunderbird. Does it make sense?
[11:43] <pitti> slytherin: in a way, yes; l-support-XX ships extra translations which aren't part of the language packs; the language packs ship a lot of translations for software which is not on the CD
[11:43] <slytherin> pitti: Will be back in 15-20 minutes
[11:45] <StevenK> pitti: I shall look at moving requestsync later tonight.
[11:46] <pitti> StevenK: ah, good
[11:47] <StevenK> pitti: I think it's a matter of uploading devscripts ubuntu3 that drops it, and adding C/R devscripts (<< 2.10.7ubuntu2) along with requestsync to u-d-t
[11:48] <pitti> StevenK: << ubuntu3, yes
[12:09] <asac> strange ... valgrind appears to be broken for me :/ anyone else sees this? http://pastebin.mozilla.org/197295
[12:38] <calc> dholbach: its already in the one stuck in 'failed to upload'
[12:38] <pitti> mjg59: meh, you forgot to commit your hal changes to bzr, doing that now
[12:38] <dholbach> calc: ok, I didn't know just looking at the bug
[12:39] <calc> pitti: is ooo/ooo-l10n stuck in 'failed to upload' due to a freeze or something else?
[12:39] <dholbach> but good to know you're on it
[12:39] <calc> dholbach: np
[12:39] <pitti> calc: no, that's usually a bug; I guess the recent LP update overwrote my disabling of that dpkg Pre-Depends: check
[12:39] <pitti> calc: give me some minutes to finish my current task, then I'll hack it in again and reprocess your uploads
[12:40] <StevenK> pitti: And hit up the Launchpad guys to fix it? :-)
[12:40] <mjg59> pitti: Hrm, sorry - I could have sworn I did
[12:40] <dholbach> pitti: shall I move requestsync to ubuntu-dev-tools?
[12:40] <mjg59> Did I commit one set and forget the second?
[12:40] <pitti> dholbach: StevenK was about to, but sure
[12:40] <pitti> mjg59: yes, only the last one (63_my_dbus_is_full_of_uints.patch)
[12:41] <StevenK> dholbach: I've started on it....
[12:41] <dholbach> StevenK: alright
[12:41] <mjg59> pitti: Ah, right - sorry about that
[12:41] <pitti> mjg59: the rest (before Fabio's upload) is in
[12:41] <pitti> mjg59: no problem
[12:41] <mjg59> pitti: I find the process of having the debian directory in bzr but not the rest of the package kind of awkward in this sort of case
[12:41] <pitti> mjg59: did you take all those patches from upstream git? or is there anything still to be forwarded?
[12:42] <mjg59> pitti: No, upstream is consistent
[12:42] <pitti> great
[12:47] <pygi> doko, any progress?
[12:50] <Keybuk> dholbach: invalid, as it uses a group not in base-files
[12:51] <dholbach> Keybuk: hm, ok
[12:51] <Keybuk> as Tollef says, the rules are shipped with libccid
[12:52] <dholbach> geser: ^ what do you think we should do with the patch?
[12:52] <pitti> I guess people wouldn't bite me if I asked for a FF exception for bzr 0.90?
[12:53] <pitti> StevenK: hit LP guys> that bug report already exists
[12:54] <StevenK> pitti: Ah
[12:56] <pygi> pitti, why would they? we do need bzr 0.90
[12:57] <pygi> if I ain't mistaken 0.91RC will be out today?
[12:57] <pitti> pygi: well, not exactly 'need', but it would certainly be cool
[12:57] <pitti> would be quite a shame not to ship the latest stable
[12:59] <geser> dholbach, Keybuk: gnupg does support some smart card readers directly. All is needed are the right permissions that gnupg can access it. The rules from libccid (which is no dependency of gnupg) need pscsd as they tell it about the new device.
[01:03] <geser> so there are conflicting rules for some smart card readers depending on how one intends to use it
[01:04] <Keybuk> geser: so the rules should be shipped in the packages?
[01:07] <geser> Keybuk: preferable, but as gnupg and gnupg2 benefit from them I don't know where exactly it should get shipped
[01:08] <Keybuk> me neither
[01:08] <Keybuk> I think that the current policy of tending towards a unique group for every unique type of device is wrong anyway
[01:09] <Keybuk> it's an awesome maintenance burden
[01:09] <pitti> geser: until we get the full magic of CK+hal changing device permissions, using 'plugdev' seems appropriate to me
[01:10] <geser> scard was suggested on the gnupg site (or some tutorial) to not allow everybody access to the smart card reader, but plugdev should also work
[01:12] <Keybuk> "console users have permission to use all connected USB devices" \o/
[01:17] <geser> Keybuk: any better ideas?
[01:19] <pitti> Mithrandir, Hobbsee, cjwatson: can either of you take a look at bug 138858? I don't want to approve my own requests
[01:19] <ubotu> Launchpad bug 138858 in bzr "FF exception request: bzr/bzrtools 0.90 for gutsy" [Undecided,New]  https://launchpad.net/bugs/138858
[01:19] <geser> gnupg{,2} need only access to the usb-connected smart card reader, libccid and/or pcscd isn't needed
[01:21] <Mithrandir> pitti: does it conflict with anything using the removed APIs?
[01:21] <Keybuk> geser: ship rules inside gnupg?
[01:21] <Keybuk> though those would conflict with those in libccid, no?
[01:22] <Mithrandir> geser: hm, does that work with the ssh-agent in gnupg-agent?
[01:23] <pitti> Mithrandir: not in the packaging; I'll check bzr-gtk and bzr-svn
[01:23] <Mithrandir> pitti: if any of those use the removed APIs, I think we should add appropriate Breaks
[01:24] <pitti> Mithrandir: ah, ignore me; they already have versioned bzr dependencies
[01:24] <Keybuk> geser: probably better to just wait for the HAL/CK method
[01:24] <pitti> Mithrandir: so we need to sync bzr-gtk as well
[01:25] <Mithrandir> pitti: ok, sounds good to me then.
[01:26] <geser> Mithrandir: after modifing /etc/X11/Xsession.d/90gpg-agent to start gpg-agent with --enable-ssh-support I can use my OpenPGP card for ssh authentication
[01:28] <Mithrandir> geser: nice.
[01:28] <geser> Keybuk: we would have then two rules files for the same device if that's no problem
[01:28] <Keybuk> geser: that's a problem
[01:29] <geser> Keybuk: any ETA when HAL/CK will be available? for hardy or later?
[01:29] <Keybuk> hardy
[01:29] <Mithrandir> Keybuk: why is that a problem?  The ccid rules mostly just do RUN+="pcscd --hotplug"
[01:29] <pitti> geser: hardy; it already more or less works in gutsy
[01:29] <Keybuk> Mithrandir: both also change modes/groups
[01:31] <Keybuk> since I know that the behaviour may change in hardy, it seems foolish to add support now for something that we might break or alter in a few weeks time
[01:32] <Keybuk> especially since this isn't a regression
[01:37] <Hobbsee> geser: but does it do it for scp too?
[01:38] <StevenK> scp uses ssh's authentication
[01:42] <geser> Hobbsee: gpg-agent works also as a ssh-agent then, so you can use your gpg-key (if it has the auth capability) for ssh
[01:42] <pitti> Mithrandir: ok, bug updated wrt. -svn and -gtk.
[01:43] <Hobbsee> geser: yeah.  i knew that.  i'd had it working that wya once, but thought it wasnt working that way this time.  it turns out that i suck instead.
[01:43] <Hobbsee> dunce cap material.
[01:51] <geser> is a ubuntu-main-sponsor around who can upload bug #134684? it has already an approved UVFe by pitti
[01:51] <ubotu> Launchpad bug 134684 in boost "Upgrade to Version 1.34.1" [Wishlist,In progress]  https://launchpad.net/bugs/134684
[01:51] <dholbach> geser: I can do that
[01:52] <geser> thanks
[01:57] <pitti> Mithrandir: so if you are fine with this, can you please give your blessing in the bug?
[01:58] <Mithrandir> pitti: done
[01:58] <pitti> Mithrandir: cheers
[02:07] <bigon> ScottK: are you there?
[02:07] <ScottK> Yes
[02:08] <bigon> ScottK: about tp-gabble, I don't see any uvfe request for the version 0.5.13
[02:09] <ScottK> bigon: If this is about my latest reply, I was working via e-mail so it may have been on the wrong bug.
[02:12] <bigon> ScottK: no problem with the reply, but you said in a previous comment that you had already an uvfe request but I don't find it
[02:12] <ScottK> Ah.
[02:12] <ScottK> Well in that case that would be the one I got wrong.
[02:13] <Hobbsee> i thought there was one that had a second uvfe on it
[02:14] <Hobbsee> not just cheese
[02:14] <ScottK> bigon: I will confess that it's hard to keep all the telepathy packages straight in my head.
[02:16] <bigon> Hobbsee: yep tp-gabble has 2 request, but not for the .13 which cause the regression
[02:17] <Hobbsee> bigon: why does it have 2 requests?
[02:17] <Hobbsee> oh, just 2x new upstream releases
[02:19] <ScottK> We should probably take this to #ubuntu-motu as it's a Universe package.
[02:20] <cjwatson> calc: please could you add the necessary Pre-Depends to ooo so that this stops happening, notwithstanding whether Launchpad is fixed?
[02:22] <pitti> cjwatson: FWIW, I consider that needless ballast nowadays...
[02:22] <cjwatson> calc: Pre-Depends: dpkg (>= 1.10.24) for any deb using a bzip2 data member
[02:22] <cjwatson> pitti: I know, but it's better to have the ballast than to lose ooo binaries until such time as Launchpad is fixed
[02:23] <pitti> calc: anyway, I have some time now, I'm going to rescue the current ones and reapply the LP hack
[02:26] <pochu> does any archive admin has sync-day anytime soon?
[02:29] <pitti> calc: hold on, it seems they already removed it; I can't find the test any more in production
[02:30] <pitti> pochu: mine is on Friday; seb128 and Riddell are on holidays, so they won't do their's
[02:30] <pitti> pochu: do you need something urgently?
[02:30] <pitti> calc: ah, there it is, a grep revealed it; /me disables
[02:31] <pochu> pitti: no, it can wait until Friday. I was just curious.
[02:31] <sjoerd> pitti: Just talked to lennart. It's fine with him if SimpeGladeApp.py is moved to avahi-discover (IOW he's open to patches)
[02:32] <pitti> sjoerd: ah, cool
[02:33] <sjoerd> pitti: Will you do one ? Otherwise i'll probably prepare one later this week
[02:34] <pitti> sjoerd: no time right now, maybe later; I'm not particularly interested in it, so I'd just file an upstream bug, I think
[02:35] <sjoerd> ok
[02:35] <sjoerd> I'll do one later this week then (upstream doesn't care to do it himself)
[02:36] <pitti> calc: hm, I can't find the binaries anywhere
[02:36] <pitti> calc: and the Pre-Depends: check is still disabled, so that wasn't it
[02:45] <pitti> calc: did you get a rejection email?
[03:18] <pitti> doko: FYI, I just fixed one of your pet bugs (bug 113145)
[03:18] <ubotu> Launchpad bug 113145 in belocs-locales-bin "language-support-XX needs to be able to generate locales" [Medium,Fix released]  https://launchpad.net/bugs/113145
[03:39] <lamont> dholbach: I'm curious about that patch... why did it need to build-depend gksu?
[03:42] <mjg59> Does valgrind work for anyone at the moment? I'm getting vex amd64->IR: unhandled instruction bytes: 0x66 0x66 0x66 0x66
[03:43] <elkbuntu> mjg59, asac mentioned something about it earlier
[03:44] <elkbuntu> mjg59, http://pastebin.mozilla.org/197295
[03:44] <elkbuntu> different error though, it seems
[03:45] <mjg59> elkbuntu: Nope, same one
[03:45] <elkbuntu> right, i only glanced, didnt see the same string you quoted
[03:45] <mjg59> Line 10
[03:45] <mjg59> Ok, so not just me. Turns out I'm not special.
[03:45] <elkbuntu> aha. im going crossied folding leaflets for saturday
[03:45] <elkbuntu> crosseyed*
[03:46] <elkbuntu> well you and asac can go cry in a corner together at least :)
[03:47] <pitti> hi mathiaz
[03:47] <dholbach> lamont: it should depends, not build-depends
[03:49] <lamont> dholbach: ok.  sadly, that permanently(?) forks it
[03:50] <lamont> although with it being a Depend: not a build-depend I _could_ munge debian/control in the clean target... I so dislike debian/control.in files
[03:55] <asac> elkbuntu: right ... its a painful especially because i wanted to fix crashes today
[03:57] <dholbach> lamont: why?
[03:57] <dholbach> lamont: debian uses gksu too, no?
[03:58] <lamont> uh.. dunno.  does it?
[03:58] <dholbach> to run a program as root, sure they do :)
[03:58] <dholbach> gksu will make use of sudo in ubuntu and su in debian
[03:59] <dholbach> so that should be fine
[03:59] <asac> doko: maybe your binutils upload broke valgrind?
[03:59] <lamont> dholbach: ah, ok
[03:59] <lamont> where gksudo just uses sudo?
[04:00] <asac> doko: like valgrind echo hallo (http://pastebin.mozilla.org/197295)
[04:00] <pitti> calc: OO.o rescued, thanks to cprov
[04:01] <calc> pitti: ok thanks :)
[04:01] <calc> cjwatson: ok
[04:02] <pitti> calc: pre-depends check was not yet disabled again when you uploaded first, but it's done now
[04:02] <calc> pitti: oh ok, i'm guessing it will pop back up again next month?
[04:02] <pitti> calc: let's hope that they fix it for good in RF by then :)
[04:03] <calc> pitti: oh yea openoffice.org-l10n still shows failed to upload as well
[04:04] <calc> oh now its good
[04:04] <pitti> calc: known, cprov is reprocessing it as we speak
[04:04] <calc> ah ok :)
[04:04] <cprov> pitti: "fix it for good" is more like "break it hadly" because we will have to remove checks and tests, it can't be good :(
[04:05] <cprov> https://edge.launchpad.net/ubuntu/+source/openoffice.org-l10n/1:2.3.0~rc1-1ubuntu1 -> rescued too
[04:07] <bddebian> Heya
[04:10] <calc> cprov: well that particular check/test is obsolete for several years now
[04:11] <cprov> calc: it will get removed, no problem.
[04:23] <calc> cprov: ok
[04:48] <pygi> doko, around?
[04:52] <mathiaz> BenC: did you get a chance to look at the apparmor patch for l-u-m I sent you on friday ?
[04:55] <manchicken_> Are folks aware of this error in the flashplugin-nonfree installer: "update-alternatives: unable to make /usr/lib/midbrowser/plugins/flashplugin-alternative.so.dpkg-tmp a symlink to /etc/alternatives/midbrowser-flashplugin: No such file or directory"
[04:55] <manchicken_> s/installer/package/
[04:58] <bigon> manchicken_: see bug #138853
[04:59] <manchicken_> Bot die?
[05:02] <BenC> mathiaz: kylem handled all the apparmor stuff
[05:10] <soren> calc: Cool! Then mine must be on their way, too! :)
[05:21] <calc> network manager still sucks
[05:21] <calc> it kills wired network connections on upgrade still it appears
[05:21] <calc> or something does, i just upgraded my desktop in the other room and my network was dead when i tried to connect to it from my laptop
[05:26] <pitti> cu later, I have an appointment now
[05:38] <Kopfgeldjaeger> hi
[06:16] <cjwatson> bryce: my new Dell laptop suffers from that notorious xresprobe bug where it buggers up the screen during installation; I can reproduce it reliably by booting into rescue mode and running '/usr/share/xresprobe/xprobe.sh intel'. Is there anything I can do to help you fix it?
[06:17] <cjwatson> bryce: I tried adding vbetool save/restore stanzas before and after running X, but that didn't help
[06:40] <doko> asac: which binutils version?
[06:44] <asac> doko: latest? 2.18-0ubuntu2
[06:44] <asac> doko: i haven't used valgrind for a few weeks ... so cannot tell if its related at all
[06:44] <asac> doko: just a guess ;)
[06:50] <doko> asac: hmm, so it worked with a pre-2.18 version?
[06:53] <asac> doko: cannot say for sure ... i have recently upgraded my amd system to gutsy. before i only had an i386 gutsy
[06:53] <asac> doko: but mjg59 complained today about valgrind as well ... so maybe its indeed a recent regression
[06:57] <eugman> Normally I wouldn't ask in here but I honestly can't find the information. I want to turn a python game into a deb. However I can only find general packaging information. I don't know if I can do it with distutils somehow and where the data and lib files would end up were the game installed so I can change the script to be able to acess them.
[06:58] <dobey> eugman: if you look at the solarwolf package, it's probably a good starting point
[06:59] <eugman> Ok, so there isn't necessary a standard?
[07:00] <dobey> there is the general debian packaging policy for python. i don't think there is anything more specific for "game written in python"
[07:00] <dobey> i don't think ubuntu alters that policy, either
[07:01] <dobey> eugman: http://www.us.debian.org/doc/packaging-manuals/python-policy/
[07:01] <Mez> dobey, no,. ubuntu uses the debian python policy, i know cause i've been moaned at for not adhering to it
[07:02] <dobey> Mez: yeah. ubuntu uses all the debian packaging policy. i don't think it is really deviated from much, if anywhere
[07:02] <Mez> er, i think there are a couple of places (ubutnu specific maintainer fields mainly i think!)
[07:03] <dobey> right
[07:03] <eugman> ok well that and solarwolf probably covers what I need. I still don't know how to get a deb out of some python files and some data. Would I use destuitls?
[07:03] <eugman> er distutils
[08:08] <siretart> asac: hi
[08:08] <siretart> asac: I have to say that since today, I also see these funny NetworkManager: <info>  SUP: response was 'TIMEOUT[CLI] ' messages in daemon.log
[08:08] <siretart> asac: I've grepped through my logfiles, the started just today
[08:10] <siretart> asac: and looking through my dpkg.log, I don't see something too fishy there either :/
[08:11] <siretart> asac: well, I know you don't want to hear that, but when I compare dpkg.log and my daemon.log, these timeouts started after upgrading to network-manager 0.6.5-0ubuntu11
[08:11] <siretart> so I'd suspect that upgrade causing the errors.
[08:14] <siretart> hmmm.. and the changelog indicates that some code that might be relevant to the timeouts have been touched in that particular upload
[08:24] <lamont> +TryExec=gksudo nmapfe
[08:24] <lamont> +Exec=gksu nmapfe
[08:24] <lamont> should those both maybe say 'gksu'?
[08:27] <Amaranth> lamont: the TryExec should probably be _just_ 'gksu'
[08:27] <lamont> TryExec=gksu
[08:27] <lamont> Exec=gksu nmapfe
[08:27] <lamont> like so?
[08:28] <Amaranth> lamont: yeah
[08:28] <lamont> or is that evil?
[08:28] <Amaranth> wait, not gksu
[08:29] <Amaranth> i meant it should be 'nmapfe'
[08:29] <Amaranth> hehe
[08:29] <lamont> TryExec means that it tries that, and failure is an option?
[08:29] <Amaranth> TryExec means it won't show it in the menu if that binary doesn't exist
[08:30] <lamont> so it actually wants to be gksu
[08:30] <lamont> or is it a list of binaries?
[08:30] <Amaranth> in pyxdg it would probably just blow up
[08:30] <lamont> (since the exec will fail if gksu isn't there...)
[08:30] <Amaranth> let me check the spec
[08:30] <DktrKranz> lamont, synaptic (which uses gksu too) recommends gksu because of kde
[08:31] <DktrKranz> nmap
[08:31] <DktrKranz> is available for both DE
[08:31] <Amaranth> lamont: TryExec is not a list
[08:31] <lamont> Amaranth: ok
[08:32] <Amaranth> lamont: in pyxdg at least if you put in 'gksu nmapfe' it'll just fail so the .desktop would be marked as hidden
[08:32] <lamont> heh
[08:32] <lamont> ok
[08:32] <lamont> TryExec=gksu
[08:32] <lamont> Exec=gksu nmapfe
[08:32] <Amaranth> So either use nmapfe or nothing at all in there
[08:32] <lamont> and Recommends: gksu
[08:32] <Amaranth> TryExec is not required
[08:33] <lamont> just drop it entirely?
[08:33] <Amaranth> Well, it'd be better to have TryExec=nmapfe
[08:33] <lamont> why?
[08:33] <lamont> if nmapfe is installed, then you get the .desktop and the binary
[08:33] <Amaranth> because if someone using alacarte to edit that entry in their menu alacarte makes a copy of the .desktop in ~/.local/share/applications and that does not go away when they uninstall it
[08:33] <lamont> if it's not installed, then you get neither
[08:33] <lamont> ah
[08:33] <Amaranth> the TryExec would make that entry be hidden
[08:34] <lamont> TryExec=nmapfe
[08:34] <lamont> Exec=gksu nmapfe
[08:34] <Amaranth> right
[08:34] <Amaranth> then make gksu a depends
[08:34] <jdstrand> I am helping #ubuntu-server and dendrobates out with https://blueprints.launchpad.net/ubuntu/+spec/ldap-authentication-client.  I have a situation where package A no longer provides a conf file.  package B is a configuration package for A and provides a different conf file for A.  Can I use B's debconf to prompt the user to delete (via B's postinst) package A's abandoned config file if it still exists, if B has a versioned depends on A?
[08:41] <keescook> jdstrand: I can't quote a packaging rule that says it's okay, but it sounds reasonable to me.  :)
[08:42] <jdstrand> keescook: I thought it reasonable too, but wanted to be sure
[09:07] <MacSlow> Amaranth, do you happen to know why it is not possible to set 'vacuum' as the animation-tpye for 'minimize'... even after changing animation.xml and restarting compiz?
[09:08] <Amaranth> MacSlow: it's not a minimize-type effect, i guess
[09:10] <MacSlow> it's the same code as magiclamp I guess
[09:12] <mvo> MacSlow: hm, that seems to work for me, lets see if I have the latest packages
[09:12] <Amaranth> oh, i guess the latest oddities with compiz animation settings are upstream
[09:13] <Amaranth> anyone else notice it doing stupid things with gecko tooltips, gecko menus, notification-daemon windows, etc?
[09:14] <MacSlow> Amaranth, jup
[09:15] <Amaranth> will make up a patch to revert these changes :)
[09:16] <Amaranth> ah, they think the workarounds plugin makes some things they had not necessary
[09:19] <MacSlow> dodge is funny
[09:19] <Amaranth> hrm, that didn't help
[09:20] <Amaranth> oh, typo
[09:22] <\sh> Amaranth, re..you know what's the best...the upgrade worked on my home desktop without anyproblem...
[09:22] <\sh> Amaranth, everything is working...or actually I should reboot my machine to see if I'm right
[09:22] <Amaranth> \sh: hehe
[09:23] <mvo> \sh: did you use update-manager for the upgrade?
[09:23] <\sh> mvo, nope
[09:23] <\sh> mvo, i never used update-manager
[09:23] <_MMA_> Amaranth: Would you be the one to talk to about how "Show Desktop" can't be set to a corner now? Looks like i would set it in the "General" with "Hide all windows and focus desktop" but it doesn't work. I wan=snt sure if I should mention it upstream or on LP.
[09:24] <\sh> mvo, but what I saw on my laptop and work desktop is brokeness in some gconf xml files...and the laptop and work desktop machine are dist-upgraded from feisty
[09:24] <_MMA_> *wasn't
[09:25] <\sh> Amaranth, mvo: give me some seconds to reboot the machine and see if everything is ok...
[09:26] <MacSlow> Amaranth, I think I found a way to fix it
[09:27] <MacSlow> Amaranth, need to touch the source (thus rebuild the package)... I wanted to avoid that initally
[09:29] <\sh> re
[09:29] <Amaranth> _MMA_: actually i don't remember that ever working
[09:29] <\sh> Amaranth, rebooted, no black background nothing, even the mouse is ok
[09:29] <Amaranth> \sh: cool
[09:31] <_MMA_> Amaranth: Actually last time it worked for me was Edgy/Beryl. :-/
[09:31] <_MMA_> gah *Feisty
[09:31] <Amaranth> Actually it was not working for me in beryl either
[09:31] <_MMA_> Oh well. :)
[09:32] <Amaranth> mvo: should i put these settings changes in compiz-fusion-plugins-main or libcompizconfig's global.xml file?
[09:32] <Amaranth> compiz-fusion-plugins-main
[09:32] <Amaranth> that was a stupid question :)
[09:34] <\sh> Amaranth, hopefully there is something with the X server which wasn't there before the update...I wonder
[09:51] <mathiaz> pitti: could you have a look at bug 120085 ?
[09:51] <ubotu> Launchpad bug 120085 in sysklogd "Various problems running syslogd with "-u syslog" option" [Medium,Triaged]  https://launchpad.net/bugs/120085
[09:52] <mathiaz> pitti: I've attached a debdiff that should fix the problem, but I don't know if it could be accepted for gutsy.
[09:58] <mhb> universe is enabled by default in gutsy, right?
[09:59] <mathiaz> mhb: yes
[09:59] <mhb> mathiaz: thanks, just checking
[10:00] <ScottK> mhb: That's for new installs.  On upgrade it won't be enabled if it wasn't before, IIRC.
[10:25] <asac> siretart: naturally those timeout messages start with the latest upload
[10:25] <asac> siretart: i added them ... before it would just fail with wierd errors
[10:25] <asac> siretart: i replace no reply with that reply if the client socket times out
[10:27] <asac> siretart: the timeout is 2 seconds for normal operations and i bumped it to 12 seconds or so for operations that appear to take longer ... that helped alot of times, but not always ... those that still take longer are those you ses with TIMEOUT[CLI] 
[10:27] <asac> siretart: i played around and found that those timeouts are operations that appear to block infinitely
[10:28] <asac> siretart: so ... my request for help was about figuring out what wpasupplicant does when you see those timeouts
[10:28] <asac> :)
[10:30] <sbalneav> jcastro: So... How's it going, eh?
[10:41] <lousygarua> hello, i'm from the ubuntu-il team and we've come up with an interesting suggestion to extend gettext functionality, is this the channel to discuss it?
[10:49] <evand> lousygarua: the ubuntu-devel-discuss mailing list would probably be best.  Many of the developers are already gone for the day.
[10:51] <dobey> lousygarua: what do you want do?
[10:52] <YokoZar_> hmm, flashplugin-nonfree doesn't seem to be working for me in Gutsy.  Still says no flash installed.
[10:54] <lousygarua> dobey: in hebrew there we usually translate sentences to fit male users, but some guy in the team thought we can hack it so it detects female users and just uses female po file or whatever for them
[10:54] <lousygarua> dobey: it can also solve many of our translation debates
[10:55] <agoliveira> lousygarua: I'm a bit of language freak so, would mind explain me why is this kind of translation needed in hwbrew?
[10:56] <agoliveira> hebrew
[10:56] <lousygarua> agoliveira: in hebrew (and arabic, etc..) sentences like "How would you like to partition your disk?" go differnetly for male and females
[10:57] <lousygarua> agoliveira: we usually phrase them for males because that's standard, or try using a plural form
[10:57] <dobey> hrmm
[10:58] <agoliveira> lousygarua: I see. In portuguese we have such kind of differences as well.
[10:58] <luisbg> lousygarua, the same happens in spanish
[10:58] <luisbg> lousygarua, the norm is to use the male version when it can include both male and female
[10:58] <dobey> lots of languages have similar male/female/neuter forms
[10:59] <lousygarua> hmm so the ubuntu project can really do something new and innovative here
[10:59] <luisbg> some cool ubuntu feature to gnome could be to ask if the user is male or female
[10:59] <dobey> does gettext not support multiple sex forms?
[10:59] <luisbg> and make the .po translation be gender intelligent
[10:59] <dobey> i know it supports multiple plural forms
[10:59] <lousygarua> dobey: i never encountered multiple sexes in gettext stuff
[11:00] <dobey> but there really is no way to know whether a male or female is sitting in front of the screen
[11:00] <luisbg> dobey, it can be held in the user account information
[11:00] <luisbg> *could*
[11:00] <luisbg> IMHO ubuntu women would really digg the idea
[11:00] <lousygarua> luisbg: dobey: exactly. we are in a multiple user environment on unixes
[11:01] <dobey> luisbg: but if one user is logged in, and another person is sitting at the keyboard...
[11:02] <luisbg> dobey, that would be as illogical as having one person use anothers password
[11:02] <luisbg> or what is behind it
[11:02] <luisbg> it's documents, it's saved firefox passwords, and all that
[11:02] <lousygarua> dobey: i don't mind the OS to think i am a girl when i'm fixing something on my g/f's laptop or whatever
[11:02] <luisbg> each person should have 1 user
[11:03] <dobey> luisbg: logic is not what users are about.
[11:03] <dobey> they are humans, not computers.
[11:03] <lousygarua> dobey: in the future we can add special devices that recognizes if you are a male or a female on runtime. i don't think it should bother us now
[11:04] <wasabi> I'd hate to have one of those devices "malfunction"
[11:04] <cjwatson> lousygarua: I'd really like to ask that this not be done in a manner specific to Ubuntu
[11:04] <_MMA_> :)
[11:04] <lousygarua> wasabi: lol
[11:04] <cjwatson> lousygarua: it is very important that such critical infrastructure as gettext be standard across systems
[11:05] <lousygarua> cjwatson: of course. but it seemed logical to me to go here first, or at least get the ubuntu support before i contact upstream
[11:05] <cjwatson> I believe there is a mailing list dedicated to discussion of gettext
[11:05] <lousygarua> cjwatson: i'm still lookign for one :)
[11:06] <lousygarua> cjwatson: there's also a problem with systems that just wont' store sex information about the user
[11:06] <cjwatson> I'm not wild about the idea personally, but TBH upstream is going to be much better informed than folks here about the feasibility
[11:06] <luisbg> lousygarua, contact upstream and please let me know what they reply
[11:07] <luisbg> I'm curious how this can follow on
[11:07] <cjwatson> https://lists.sourceforge.net/lists/listinfo/translation-i18n
[11:08] <wasabi> nvidia-glx-new.  Why doesn't this replace nvidia-glx?
[11:08] <wasabi> (I do not refer to dpkg Replaces metadata, I mean, why doesn't nvidia-glx cease to exist)
[11:08] <wasabi> It's a bit confusing having two packages, and sort of makes coexisting graphics cards... non-intuitive?
[11:09] <luisbg> wasabi, +1
[11:09] <wasabi> I'm not asking for a vote. I'm asking for a real reason.
[11:09] <wasabi> I'm sure there is a real reason.
[11:09] <wasabi> Just can't seem to find it. =)
[11:10] <luisbg> I've heard they -new supports more cards
[11:10] <agoliveira> -new includes series 100 driver which is much newer
[11:10] <wasabi> Uh huh. Sure. And it supports old cards too, as far as I can tell.
[11:11] <_MMA_> There is some overlap but -new goes higher.
[11:11] <agoliveira> wasabi: I'm not sure. I vaguely remember reading that the new drivers dropped support for series 2 cards.
[11:11] <luisbg> shouldn't they merge?
[11:12] <_MMA_> That might be a big package. :)
[11:12] <wasabi> That's silly.
[11:12] <wasabi> Grrr. So coexsting series 2 drivers with new stuff is not possible?
[11:12] <luisbg> two small better than one big?
[11:12] <agoliveira> In my case (Asus G1 laptop) I need a series 100 driver or I can't switch to an external LCD via DVI
[11:12] <agoliveira> wasabi: As I said, not sure.
[11:13] <wasabi> op