[08:49] <BUGabundo> hi guys
[08:49] <BUGabundo> I'm getting: E: /var/cache/apt/archives/xserver-xorg_1%3a7.4~0ubuntu1_amd64.deb: subprocess new pre-removal script returned error exit status 1
[08:51] <tjaalton> BUGabundo: you need to give the full log, that doesn't say much
[08:57] <BUGabundo> well its what I got from todays update-manager, tjaalton
[08:57] <BUGabundo> where can I get the full log?
[08:58] <BUGabundo> found it 
[08:58] <BUGabundo> on the details arrow
[08:58] <BUGabundo> where should I make this available?
[08:59] <tjaalton> BUGabundo: somewhere like paste.ubuntu.com
[09:00] <BUGabundo> opening
[09:00] <BUGabundo> lol
[09:00] <BUGabundo> FF 3.1 just exploded
[09:00] <BUGabundo> just a sec
[09:01] <tjaalton> better use the stable version ;)
[09:01] <BUGabundo> lol
[09:02] <BUGabundo> it would be great if update-manager log window would allow copy-paste
[09:02] <BUGabundo> I guess I'll have to do a dpkg --conf to get the log
[09:04] <tjaalton> no need
[09:04] <BUGabundo> http://paste.ubuntu.com/26159/
[09:04] <tjaalton> they are somewhere
[09:04] <BUGabundo> maybe in some /var/log
[09:04] <tjaalton> well there you go
[09:04] <BUGabundo> I'll search for it
[09:05] <tjaalton> something broke your debconf
[09:05] <BUGabundo> got it on /var/log/apt/term.log
[09:05] <BUGabundo> debconf: DbDriver "config": could not open /var/cache/debconf/config.dat
[09:05] <BUGabundo> is this it?
[09:06] <tjaalton> yes
[09:07] <BUGabundo> I cleared the folder I tried again
[09:07] <BUGabundo> here is what I got
[09:07] <BUGabundo> http://paste.ubuntu.com/26160/
[09:08] <BUGabundo> I'm going to unistall ntop
[09:08] <BUGabundo> seems to be too much trouble
[09:09] <BUGabundo> seems to be fine now
[09:09] <BUGabundo> thanks tjaalton
[09:09] <tjaalton> so you deleted config.dat?
[09:10] <BUGabundo> or I got a corrupt file
[09:10] <BUGabundo> I deleted the folder and made a new one
[09:10] <tjaalton> check the size of var: 'df -h /var'
[09:11] <BUGabundo> /dev/sda1             9.3G  6.6G  2.2G  76% /
[09:11] <tjaalton> ok so that's not it
[09:12] <tjaalton> but that file.. now you've lost all the debconf data
[09:12] <BUGabundo> ohh
[09:12] <BUGabundo> can I reinstal it?
[09:13] <tjaalton> it holds configuration data from many packages, so it's not that easy to recover I think
[09:14] <tjaalton> what files do you have in that directory?
[09:14] <BUGabundo> currently?
[09:14] <tjaalton> yes
[09:14] <BUGabundo> !ls /var/cache/debconf
[09:14] <ubottu> BUGabundo: Error: I am only a bot, please don't think I'm intelligent :)
[09:14] <BUGabundo> grrr
[09:14] <BUGabundo> bad pidgin
[09:15] <BUGabundo> config.dat and .dat.old; passwords.dat ; templates.dat and .dat.old
[09:15] <BUGabundo> oh and I love this one
[09:15] <BUGabundo> linux-backports-modules-intrepid-generic:
[09:15] <BUGabundo>  Depends: linux-backports-modules-2.6.26-3-generic  but it is not installable
[09:16] <tjaalton> what size does the config.dat* have?
[09:16] <BUGabundo> 1.9k
[09:16] <tjaalton> and .old?
[09:17] <BUGabundo> same
[09:17] <tjaalton> ok, so it's broken
[09:17] <BUGabundo> W: Failed to fetch ftp://darkstar.ist.utl.pt/pub/ubuntu/archive/pool/universe/n/nvidia-settings/nvidia-settings_1.0+20080304-0ubuntu3_amd64.deb   Size mismatch
[09:17] <BUGabundo> great way to start the day
[09:17] <BUGabundo> lol
[09:17] <tjaalton> the archive is broken
[09:17] <tjaalton> use a better mirror
[09:17] <BUGabundo> bahh.. I'll just reinstall the laptop when alpha 2 comes out
[09:17] <BUGabundo> this is the best portugues mirror
[09:17] <BUGabundo> and I have main too.
[09:18] <BUGabundo> let me just comment that line
[09:18] <tjaalton> in that case wait for it to update
[09:19] <BUGabundo> this machine was dist-update from hardy to ibex
[09:19] <BUGabundo> on the 12th of june.... around the inicial date for alpha1
[09:19] <BUGabundo> there weren't even seeds for update-manager -d
[12:02] <tjaalton> tseliot: a question about the nvidia driver. what happens when the new driver version is changed? does nvidia-glx-177 (and only that) update nicely to -1xx?
[12:04] <tjaalton> the other versions don't have that problem, since the major version does not change
[12:09] <tjaalton> tseliot: I'll send an email
[12:23] <tjaalton> umm, maybe no problem after all.. 
[12:24] <tjaalton> I'll ask pitti to be sure
[12:51] <tseliot> tjaalton: we're still discussing the solution. I have written a script which should make the whole process smooth
[12:54] <tseliot> this might be included in a different package, say, nvidia-kernel-common, and talk to debconf.
[12:55] <tseliot> oh, pitti has already replied
[13:03] <tjaalton> tseliot: the thing is, do we want to let those running the latest version upgrade directly or not
[13:03] <tjaalton> or should we introduce a new version every time nvidia bumps their ABI (and remove the previous one from the archive)
[13:04] <tjaalton> note that I'm not talking about -71, -96, -173
[13:05] <tjaalton> keeping a same name for the latest driver would upgrade the driver when a new version is available, without any magic
[13:07] <tseliot> tjaalton: keeping the same name for the latest driver would be ok if NVIDIA stopped dropping the support for certain card series
[13:07] <tjaalton> then introduce new hardcoded versions
[13:07] <tjaalton> like -173
[13:08] <tjaalton> which would replace the last same-name version that supported the device
[13:08] <tseliot> if we had a reliable way to distinguish between graphics cards series
[13:08] <tjaalton> or maybe I'm missing something
[13:09] <tseliot> that would be doable
[13:09] <tseliot> currently, all we can do
[13:09] <tseliot> keep the names as -173. etc. and rely on hardware detection
[13:09] <tseliot> performed by Jockey, EnvyNG, or that new package
[13:10] <tjaalton> I mean if they do that, make every nvidia-glx upgrade to nvidia-glx-VER, and those that want the latest, install by hand (and notify) or let update-manager/jockey do the thinking
[13:11] <tseliot> tjaalton: this would screw a lot of users too
[13:11] <tjaalton> how?
[13:11] <tseliot> since nvidia-glx doesn't support all the models of -new
[13:11] <tseliot> etc.
[13:11] <tjaalton> I'm not talking about -new
[13:11] <tseliot> in the future
[13:11] <tseliot> we'll have a database
[13:12] <tseliot> and we'll be able to introduce metapackages
[13:12] <tseliot> which would do exactly what you suggest
[13:12] <tjaalton> I'm just thinking this is getting a bit overengineered..
[13:13] <tseliot> tjaalton: if you have a look at the emails that we forwarded to you, you will see that it took us some time to come to an agreement
[13:13] <tseliot> on this
[13:13] <tjaalton> it's a long thread :)
[13:14] <unggnu> hi all
[13:14] <tseliot> hi
[13:14] <unggnu> bryce: could you please check Bug 246835
[13:14] <ubottu> unggnu: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/246835/+text)
[13:14] <tseliot> tjaalton: yes, I know ;)
[13:15] <unggnu> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/246835
[13:15] <tjaalton> unggnu: what about it?
[13:15] <ubottu> unggnu: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/246835/+text)
[13:15] <unggnu> tjaalton: Something has fixed upstream but the ubuntu patch is still applied
[13:16] <unggnu> in the intel driver
[13:16] <tjaalton> unggnu: it still works fine :)
[13:16] <unggnu> Seems so :)
[13:16] <unggnu> just shouldn't get lost
[13:17] <tjaalton> none of the 1900+ bugs are lost
[13:17] <tjaalton> we just ignore them :P
[13:17] <tjaalton> "la la la can't see you.."
[13:18] <unggnu> :-D
[13:18] <tjaalton> maybe I could drop that
[13:18] <tjaalton> for alpha2
[13:18] <unggnu> There are too much bugs for two? men so I just wanted to point on this one since it even should be easy to fix
[13:19] <unggnu> maybe three, don't know :)
[13:19] <unggnu> Btw. does the new Xorg input hotplugging recognizes the correct keyboard layout?
[13:19] <tjaalton> no
[13:20] <unggnu> Then there is a problem if xorg.conf will be removed from intrepid.
[13:20] <tjaalton> there's no magic, HAL needs to know about the layout somehow
[13:20] <tjaalton> of course
[13:20] <tjaalton> it won't happen before it works
[13:21] <unggnu> There was a discussion with the timezone and everything else could be handled through the GUI I guess but I don't know
[13:21] <unggnu> In the past changing keyboard layout in Gnome doesn't work so well.
[13:21] <tjaalton> that should work, but also gdm should have the correct layout..
[13:22] <tjaalton> otherwise it could happen that your password doesn't work, with us layout anyway
[13:22] <tjaalton> been there
[13:23] <unggnu> So the touchpad scrolling detection problem is fixed in new Xorg?
[13:23] <tjaalton> no idea
[13:23] <Ng> how can the input hotplug know the layout btw, do USB keyboards expose that?
[13:23] <jcristau> Ng: no
[13:23] <unggnu> timezone maybe, don't know
[13:23] <jcristau> you still need to configure it
[13:23] <tjaalton> Ng: that was discussed at UDS, but very few devices support that
[13:23] <jcristau> timezone has nothing to do with keyboard layout
[13:23] <Ng> afaics there would be no way to infer it
[13:24] <tjaalton> if only the hal-script approach would work..
[13:25] <tjaalton> so you can feed HAL with the data from, say, console-setup
[13:25] <unggnu> What is with the environment language variable? Maybe gdm could have an flag where you can change the keyboard layout on the fly.
[13:25] <Ng> unggnu: language isn't a good indicator of keyboard layout, and may actually be a really bad one
[13:25] <unggnu> Console keyboard layout even works without xorg.conf of course so there have to be a way :)
[13:25] <tjaalton> locale and layout don't always match..
[13:26] <unggnu> yeah, your are right. Just the country code like us or something like that.
[13:26] <tjaalton> I mean you might want to use another locale with some other layout
[13:27] <unggnu> How does the console get the layout?
[13:28] <tjaalton> console-setup
[13:28] <tjaalton> and xserver-xorg.postinst uses that (on ubuntu)
[13:28] <unggnu> maybe that could be used for an xorg.conf free setup
[13:29] <tjaalton> exactly my point
[13:29] <unggnu> :)
[13:29] <tjaalton> but it's pointless to generate yet-another file (the hal .fdi)
[13:29] <tjaalton> hence the proposal of a HAL-script that would read the values and inject them to HAL
[13:32] <unggnu> Do you have a link for enabling input hotplugging in Intrepid?
[13:32] <tjaalton> nope
[13:32] <tjaalton> just copy the example fdi file from.. gimmeasec
[13:32] <tjaalton> /usr/share/doc/hal/examples/
[13:32] <tjaalton> 10-x11-input.fdi
[13:33] <unggnu> thx
[13:33] <tjaalton> that doesn't have the magic about the keymap though
[13:33] <unggnu> sure
[13:33] <unggnu> If this works only a good graphical modeline generator for faulty hardware is needed imho.
[13:34] <unggnu> displayconfig-gtk changes to much imho and has to be manually installed
[13:34] <tjaalton> and input properties is implemented upstream.. goodbye ugly sharedmem-hacks of synaptics :)
[13:34] <tjaalton> it's about to be deprecated
[13:34] <tjaalton> so don't rely on it too much :)
[13:35] <unggnu> I know
[13:35] <unggnu> that's why a modeline generator is needed
[13:38] <Ng> imho having to generate a modeline is a bug ;)
[13:39] <Ng> I do wonder if the xinput stuff could key the layout of the first keyboard off the console layout and then have a nice easy way to let users change the layouts for additional keyboards, but I bet simple USB keyboards don't have any uniquely identifying information in them :/
[13:44] <unggnu> Ng: Maybe we could move the hardware upstream ;)
[13:45] <Ng> heh
[14:03] <jcristau> tjaalton: the keymap stuff is in /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi
[14:04] <tjaalton> jcristau: oh right
[14:04] <jcristau> so copying that to /etc/hal/fdi/policy/ and customizing the layout would work
[14:04] <tjaalton> yes
=== crevette_ is now known as crevette
[16:12] <bryce> morningh
[17:21] <crevette> hello
[17:22] <crevette> I just bought a thinkpad with a intel card, and it seems to me the performance are not terrific
[17:22] <crevette> for example scrolling inside firefox the page reader.google.com is not really smooth
[17:23] <crevette> I've look the xorg.conf file and is it really small, no driver directive or such
[17:25] <jcristau> crevette: the x server detects your video card so it doesn't need to be in xorg.conf
[17:27] <crevette> yeah, this is what I understand, I used to have a complete Xorg back in my early days of linux
[17:27] <crevette> I didn 't follow closely the Xorg development
[17:27] <crevette> so I though the intel X3100 was a rather well supported chip
[17:29] <crevette> I saw there is choice between EXA and XAA acceleration; and I saw related bug about that and intel. could it be related?
[17:30] <jcristau> yes, it could
[17:34] <crevette> I could test this repo http://people.ubuntu.com/~bryce/Testing/intel/hardy-i386/ ?
[20:12] <crevette> hello
[20:12] <crevette> I'm back
[21:01] <tormod> hi, you guys with Intel chips, does glplanet (from xscreensaver-gl-extra) run dog slow?
[21:02]  * tormod tries to understand bug 198272
[21:02] <ubottu> Launchpad bug 198272 in xscreensaver "glplanet is very slow for no apparent reason" [Undecided,Incomplete] https://launchpad.net/bugs/198272
[21:16] <tjaalton> don't have my intel laptop around to test that
[21:17] <crevette> tormod: I have my thinkpad
[21:19] <crevette> tormod: it works rather fine here
[21:19] <tormod> crevette: thanks, what card do you have?
[21:20] <crevette> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)
[21:24] <tormod> crevette, I guess you're using the i965 mesa driver (xdriinfo will tell) but the reporter use i915.
[21:25] <crevette> ah, I admit I don't know a lot
[21:25] <crevette> I just bought this laptop
[21:26] <crevette> baptiste@oak:~$ xdriinfo 
[21:26] <crevette> Screen 0: i965
[21:27] <tormod> crevette: I know pretty much nothing about intel as well :) thanks for trying out.
[21:42] <tormod> I would like to provide test packages for a potential ati SRU (bug #204483). Since I already have a newer version in my PPA I can not use it. Can someone else house it?
[21:42] <ubottu> Launchpad bug 204483 in xserver-xorg-video-ati "[Hardy] Closing Laptop lid corrupts screen and beeps" [Undecided,Fix released] https://launchpad.net/bugs/204483
[21:59] <tormod> or maybe it can go straight to hardy-proposed ?
[22:53] <tormod> night