| Necrosan | Just an FYI, after building sunffb on jaunty, xorg is crashier than ever. | 00:02 |
|---|---|---|
| Necrosan | Will not run. | 00:02 |
| === CarlFK1 is now known as CarlFK | ||
| Necrosan | Not sure if it's sunffb or xorg itself. | 00:02 |
| slangasek | where's the best place to assign bugs in langpacks? (bug #286065) | 01:03 |
| ubottu | Launchpad bug 286065 in apt "Swedish translation typo: opeation -> operation" [Undecided,New] https://launchpad.net/bugs/286065 | 01:03 |
| slangasek | if I assign it to the actual langpack that's at fault, will it get looked at? | 01:03 |
| cjwatson | I generally subscribe the relevant translation team and hope they'll pay attention | 01:04 |
| cjwatson | I'm not convinced bugs against individual language packs get looked at remotely promptly | 01:04 |
| cjwatson | though they probably ought to | 01:04 |
| slangasek | oh - n/m, this bug was present in the intrepid source and is fixed in the jaunty source, so I guess not a langpack bug in this case | 01:05 |
| slangasek | but noted for the future, thanks | 01:05 |
| cjwatson | wow, how did partman-crypto ever work | 01:07 |
| cjwatson | it's attempting to find UUIDs by looking at the encrypted block device | 01:08 |
| * slangasek squints | 01:08 | |
| cjwatson | "<shuffle> <shuffle> I guess this looks a bit like a UUID, I'll use that" | 01:08 |
| cjwatson | this bug appears to have existed since gutsy ... | 01:09 |
| cjwatson | bug 321732 | 01:10 |
| ubottu | Launchpad bug 321732 in partman-crypto "Alternate and Server CD installer fails to create encrypted swap parition" [Undecided,Incomplete] https://launchpad.net/bugs/321732 | 01:10 |
| Necrosan | cj | 01:11 |
| Necrosan | ill pastie now, had some car problems. | 01:11 |
| Necrosan | http://pastebin.com/m7c3de64 | 01:11 |
| cjwatson | though even then I'm confused - this code seems to be supplying a UUID where the encrypted block device was desired. Surely that doesn't work? | 01:12 |
| cjwatson | Necrosan: OK, you described the problem incorrectly earlier :-) | 01:12 |
| Necrosan | cjwatson: Eh? how'd you interpret it? =P | 01:13 |
| cjwatson | Necrosan: aptitude hasn't installed linux-image-sparc64-smp, so there's no bug of the form "installs package without dependency satisfied" here | 01:13 |
| cjwatson | Necrosan: instead, what it's done is attempted to install as many of the dependencies of that package as it can | 01:13 |
| Necrosan | Oh, a miscommunication. | 01:13 |
| slangasek | I'm wondering if that wasn't an unused code path before now; I'm pretty sure I went through partman-crypto to set up my crypted LVM in earlier iterations | 01:13 |
| Necrosan | cjwatson: Alright. Good to know. | 01:13 |
| cjwatson | which is perfectly legitimate although (to me) surprising | 01:13 |
| cjwatson | i.e. the result is still a sound dependency graph | 01:13 |
| Necrosan | cjwatson: an FYI, x11 is all messed up on sparc64.. | 01:14 |
| cjwatson | I'm glad my initial diagnosis was wrong | 01:14 |
| Necrosan | Bad... | 01:14 |
| cjwatson | Necrosan: noted but I'm not the person to do anything about it :-) | 01:14 |
| Necrosan | C'mon, take one for the team ;) | 01:14 |
| cjwatson | I'm directly involved with neither X nor sparc | 01:14 |
| Necrosan | Is there anyone actively working on the 9.04 build? | 01:15 |
| Necrosan | IE, someone to fix the problems before release? | 01:15 |
| cjwatson | you've already spoken to the main X developers in Ubuntu | 01:15 |
| Necrosan | Ah.. | 01:15 |
| cjwatson | bryce and tjaalton | 01:15 |
| Necrosan | Do either of them own sparc machines? or do they cross compile? | 01:16 |
| bryce | no | 01:16 |
| Necrosan | which one, bryce? | 01:16 |
| cjwatson | neither is particularly required, since we have sparc build daemons in our datacentre for building binary packages | 01:16 |
| slangasek | compiling is done by the central buildds | 01:16 |
| cjwatson | Ubuntu developers do not themselves build the binaries you install on your system | 01:16 |
| Necrosan | I see. I'm a little unfamiliar with all ofthat. | 01:16 |
| cjwatson | we upload source packages which are built centrally | 01:16 |
| cjwatson | therefore as long as the source doesn't break, a port can in theory be kept going with very little manual attention | 01:17 |
| bryce | I always build packages against at least amd64 before uploading, sometimes i386 as well, but not really anything beyond that | 01:17 |
| Necrosan | Pretty slick | 01:17 |
| bryce | s/build/test build/ | 01:17 |
| Necrosan | bryce: The stuff builds fine.. just segfaults. | 01:17 |
| slangasek | bryce: presumably not the sunfb package, though. ;) | 01:17 |
| bryce | if I were to modify it and upload it, yeah I'd definitely try building it first ;-) | 01:18 |
| Necrosan | I had to manually go grab libdrm though, as the package is broken horribly on sparc64.. | 01:18 |
| cjwatson | slangasek: it seems to give me some kind of UUID when used in encrypted LVM mode, although I have no idea what it represents | 01:22 |
| slangasek | hmm, I got nothin' | 01:23 |
| cjwatson | maybe the LUKS header | 01:24 |
| cjwatson | ah yes | 01:24 |
| cjwatson | so it'll work as long as you're using the passphrase key type | 01:27 |
| slangasek | asac: hrm; libnss3-1d is using dpkg-symbols, but all of the symbols have been revved to version 3.12.2~rc1? | 01:42 |
| slangasek | asac: that's quite a bit of overhead for the same result as a .shlibs file :) | 01:43 |
| asac | slangasek: thats a one time thing ... because we flipped SONAME | 01:45 |
| slangasek | oh? | 01:45 |
| asac | tthe win of this move was that we get back to upstream binary compatibility in both directions | 01:45 |
| slangasek | from what I can see, libnss3-1d in hardy already provided /usr/lib/libnss3.so, so there really isn't a need to bump the minver so high in practice | 01:47 |
| asac | slangasek: yes, versions for a bunch of symbols were even below the addition of that symlink | 01:48 |
| asac | so i hit the reset button. | 01:48 |
| slangasek | I don't think I understand | 01:48 |
| asac | hmm ... right. sorry misread. i didnt research carefully enough. we probably added the symlink during hardy dev cycle then. | 01:49 |
| slangasek | appears so | 01:50 |
| asac | but is not really a big issue from what i can tell | 01:50 |
| slangasek | anyway, minor issue - I was really looking at bug #272314 and ended up down a rabbit hole :) | 01:50 |
| ubottu | Launchpad bug 272314 in update-manager "update-manager disabled multiverse on 8.04 -> 8.10 upgrade (Was: NSPlugin Viewer ERROR: libnss3.so)" [Undecided,Invalid] https://launchpad.net/bugs/272314 | 01:50 |
| * asac looks with tired eyes ;) | 01:50 | |
| slangasek | don't worry about it :) | 01:51 |
| asac | thats not related ;) ... | 01:51 |
| asac | but the min version would still be good to have i think | 01:52 |
| slangasek | heh, it's related in that I was looking for a shlibs file to parse mentally. :-) | 01:52 |
| TheMuso | asac: Re bug 318985, have you had a chance to try my suggestions? | 02:07 |
| ubottu | Launchpad bug 318985 in linux "line-in doesnt work for my HDA NVIDIA device" [Undecided,Confirmed] https://launchpad.net/bugs/318985 | 02:07 |
| === nhandler_ is now known as nhandler | ||
| RAOF | Anyone feel like applying a 3.7 MiB debdiff to f-spot for me? :/ | 03:30 |
| RAOF | Buildsystem changes suck. | 03:31 |
| * ScottK steps away. | 03:31 | |
| TheMuso | RAOF: What build system changes? | 03:33 |
| RAOF | TheMuso: Well, there's autoreconf-ing to make it support passing in CSC, for the mono 2.0 transition. Then, I need to patch it again to make it pick up Mono.Cairo (libmono-cairo2.0-cil doesn't ship mono-cairo.pc). Then, there were buildsystem changes (accidentally) rolled up in the .diff.gz for -0ubuntu5, which I rolled into 98_autoreconf. | 03:35 |
| ajmitch | minor things, only 3.7MB | 03:35 |
| RAOF | If it wasn't CDBS I'd have just switched it to running autoreconf during build. | 03:36 |
| RAOF | Actually, that still would've been a 3MB debdiff, but at least the next buildsystem change we needed to make wouldn't be so big. | 03:39 |
| TheMuso | Right. | 03:49 |
| * TheMuso is not sure he wants to take that on atm. | 03:49 | |
| RAOF | Eh. Someone will, eventually. Someone will want both f-spot and banshee to be simultaneously installable. | 03:53 |
| ScottK | That takes me off the hook for sure. | 03:58 |
| RAOF | Now that some part of it actually works, KDE4 appears to be kinda neat, yes. | 04:02 |
| ScottK | Based on some of the ranting I've seen here recently I get the impression that KDE decided on purpose to take a hit and redo a bunch of stuff in order to get to a better future and is now starting to come out of it while this is happening to Gnome bit by bit and it's always something new. | 04:04 |
| ScottK | Of course I may just be listening to channel trolls too much. | 04:04 |
| ScottK | Since I don't know much about Gnome it's hard for me to tell. | 04:05 |
| RAOF | ScottK: Yeah, that's about right. GNOME's breaking stuff just about slowly enough that not too much stuff is broken at any one time, it seems. | 04:16 |
| calc | slangasek: ping | 05:08 |
| slangasek | calc: yo | 05:08 |
| calc | slangasek: what did we decide about the help support wrt search/cd | 05:08 |
| calc | slangasek: dropping help for english off the cd? | 05:09 |
| calc | iirc there was the issue of how the user would get it installed | 05:09 |
| calc | versus help being broken without lucene | 05:09 |
| * calc checks what happens when he removes lucene to see how bad the issue is | 05:09 | |
| calc | well it appears that 'Find' in Help just does nothing at all if its not there | 05:11 |
| calc | no error, no nothing | 05:11 |
| slangasek | calc: right, it's not resolved how we would get the help package in later; I think embedding a copy of lucene might be simplest? | 05:12 |
| calc | hmm yes, i'll see what that entails, brb | 05:12 |
| slangasek | that solves the problem of not being able to recommend: lucene without pulling in the whole java stack; leaving only the "java is missing so things don't work" problem common to the rest of OOo | 05:12 |
| calc | slangasek: yea that looks doable, i'll just have to verify it still works after a build | 05:13 |
| calc | i don't think it will work for jaunty+1 but i can deal with that later, heh | 05:13 |
| * slangasek nods | 05:13 | |
| calc | ok, well off to start the build and then to bed :) | 05:15 |
| * calc wonders why his laptop goes into automatic sleep mode when he unplugs the power cord | 05:43 | |
| calc | seems like some sort of ubuntu bug to me | 05:44 |
| Necrosan | or a feature | 05:44 |
| calc | Necrosan: hah | 05:44 |
| Necrosan | =P | 05:44 |
| RAOF | calc: What does gnome-power-manager think your battery life is like? | 05:44 |
| calc | well i am running Gnome so perhaps they do consider it a feature | 05:44 |
| slangasek | presumably it's built-in troll detection. :) | 05:45 |
| calc | RAOF: 99% | 05:46 |
| calc | RAOF: i had to pull the power then bring it back from sleep again to see | 05:46 |
| RAOF | So, I guess it's not getting freaked out about low power, then. | 05:47 |
| calc | apparently its just braindead | 05:47 |
| TheMuso | calc: something to get debugged at the sprint next week. | 05:47 |
| calc | TheMuso: yea :) | 05:47 |
| calc | hopefully its not a heisenbug, i've seen it happen several times already though | 05:47 |
| slangasek | run gnome-power-manager --no-daemon --verbose, capture the output when it does it, and dump it to a bug? | 05:47 |
| calc | slangasek: would that actually work since it shoves it immediately into sleep mode? | 05:48 |
| slangasek | it'll still be running when you resume | 05:48 |
| ajmitch | maybe it thinks your battery is at 1% or so | 05:48 |
| calc | ok | 05:48 |
| calc | heh heisenbug | 05:49 |
| calc | i killed g-p-m then ran it from command line and pulled the power and it was fine | 05:49 |
| slangasek | heh | 05:49 |
| * ScottK is currently chasing a bug that goes away when you install debug packages. | 05:49 | |
| calc | i'll have to look at it again later when i reboot | 05:50 |
| calc | ScottK: those are fun | 05:50 |
| calc | ScottK: OOo has one of those with accessibility | 05:50 |
| calc | ScottK: forwarded it to upstream they saw it happened but when building it in debug mode its fixed :\ | 05:50 |
| ScottK | Right, well OOo is just chock full of insanity. | 05:51 |
| dholbach | good morning | 06:05 |
| * slangasek waves | 06:07 | |
| calc | slangasek: hey are you able to sync packages from debian? :) | 06:10 |
| slangasek | calc: yes | 06:10 |
| calc | slangasek: can you sync suitesparse and lp-solve from experimental for me? :) | 06:10 |
| slangasek | what are the chances I'll regret it if I do? :) | 06:11 |
| calc | slangasek: hopefully none :) its the new version OOo 3.0.1 depends on | 06:11 |
| calc | slangasek: i will be working on breaking up suitesparse later after it syncs (probably at the sprint) | 06:12 |
| calc | calc needs lp-solve but only libcolamd from suitesparse | 06:12 |
| slangasek | calc: ah; will you continue to leave the lp-solve dep out of OOo for alpha-4, then? | 06:12 |
| slangasek | (since alpha-4 comes out during the sprint) | 06:12 |
| calc | i can get it broken out early in the week, the issue is calc actually really links to it, so anyone trying to use the solver has a good chance of it blowing up on them currently | 06:13 |
| calc | actually i can try to get it done before i leave for the sprint (maybe tomorrow) | 06:13 |
| slangasek | wgrant: I've gone and subscribed you to bug #303587, since this bug seems to be fixed by merging from Debian unstable and you appear to have TIL :) | 06:14 |
| ubottu | Launchpad bug 303587 in maxima "Error in CONDITIONS::CLCS-UNIVERSAL-ERROR-HANDLER [or a callee]: Caught fatal error [memory may be damaged] " [Undecided,Confirmed] https://launchpad.net/bugs/303587 | 06:14 |
| calc | slangasek: does that sound ok? | 06:14 |
| slangasek | calc: that seems to imply OOo uploads next week during the sprint so probably not | 06:15 |
| slangasek | anyway, suitesparse and lp-solve synced | 06:15 |
| calc | ok | 06:15 |
| calc | hmm i'll break suitesparse up before uploading tomorrow then | 06:15 |
| calc | so it will only need one OOo upload (assuming OOo doesn't show up any other issues) ;-) | 06:15 |
| slangasek | that would do nicely | 06:16 |
| calc | i'll try to get it done tomorrow morning | 06:16 |
| pitti | Good morning | 06:25 |
| === ara_ is now known as ara | ||
| siretart | mdeslaur: okay, I've now merged the xine package, but I still need to have a look at the tons of dpatches lool added to it. I currently think that all of them have been merged upstream (at least the package builds fine in jaunty), but I need to double check it | 07:08 |
| === tkamppeter_ is now known as tkamppeter | ||
| lool | siretart: Cool, thanks | 07:42 |
| siretart | lool: what's the status about the broken translation dpatch? | 07:46 |
| siretart | lool: I've applied it inline now, but I remember you were talking with darren about it? | 07:46 |
| lool | siretart: So basically Darren didn't want to protect strings in xine-lib in this way | 07:46 |
| lool | siretart: It's basically assuming that all translations are perfect and you can trust all translators or you review each translation file in full when you merge it | 07:47 |
| lool | siretart: So feel free to remove the dpatch for these two strings after the next langpack update in jaunty | 07:47 |
| siretart | I don't find that too unreasonable, TBH. | 07:47 |
| siretart | ok, I've applied it inline for now, I'll add a note in debian/changelog about that | 07:48 |
| lool | I think it's the case of many upstreams so not worth fighting | 07:48 |
| siretart | ok | 07:48 |
| lool | Concerning the patches to port to new APIs, these should be all upstream I guess | 07:49 |
| lool | Finally there's the imagemagick build-deps mess | 07:49 |
| lool | I think I changed them in a way which will work in both jaunty and backports, but in the mean time I've readded the imagemagick compatibility packages | 07:49 |
| lool | I didn't recheck, but I don't think these should have any bad influence | 07:50 |
| siretart | I've dropped them for now, because the package builds just fine in jaunty | 07:51 |
| siretart | TBH, the hole merge was terribly painful | 07:51 |
| siretart | could you perhaps double check my merge before I upload? | 07:51 |
| lool | siretart: Hmm ok | 07:51 |
| siretart | (or upload yourself if you are OK? - need to run to work now) | 07:51 |
| siretart | hg clone http://hg.debian.org/hg/xine-lib/pkg/xine-lib-deb-ubuntu | 07:51 |
| siretart | thanks | 07:52 |
| siretart | lool: btw, I've committed your debian/rules cleanup to the debian packaging branchj | 07:52 |
| lool | siretart: Thanks | 07:57 |
| * lool shivers on mercurial | 07:58 | |
| LaserJock | lool: not a fan? | 07:58 |
| lool | I'm not yet confortable with it | 07:59 |
| lool | So it's a pain each time I need to use it | 08:00 |
| === Jon is now known as Jonbo | ||
| === mcasadevall is now known as NCommander | ||
| === thekorn_ is now known as thekorn | ||
| tkamppeter | pitti, I tried "bzr get lp:~ubuntu-core-dev/cups/intrepid/", commit, "bzr push lp:~till-kamppeter/cups/intrepid" to create a BZR repo of the newest CUPS SRU for you, but the bzr push falls into an infinite loop. | 08:54 |
| pitti | tkamppeter: oh? how does that look? | 08:54 |
| pitti | tkamppeter: maybe name the branch "intrepid-till"? | 08:55 |
| pitti | (it should work with "intrepid", too, but maybe not) | 08:55 |
| tkamppeter | pitti, when I look on Launchpad, an empty lp:~till-kamppeter/cups/intrepid is created, telling that there was never pushed anything into it yet. | 08:55 |
| pitti | tkamppeter: okay, then that should work; maybe you just didn't wait long enough or so? (should take some 3 minutes) | 08:56 |
| pitti | tkamppeter: the branch is visible as soon as it gets created, but the push needs to finish until lp can browse it | 08:56 |
| tkamppeter | I have deleted the branch now and I am retrying. | 08:57 |
| pitti | tkamppeter: recursive loop> did you get some output, or did it just get stuck? | 08:58 |
| pitti | (it usually looks like the latter) | 08:58 |
| tkamppeter | pitti, I have also another problem: I have uploaded GS 8.64RC1 yesterday and RC2 today. In both cases they build only on i386 and x86_64, on powerpc, ia64, lpia, ... they do not build. | 08:59 |
| pitti | tkamppeter: hm, and it's a non trivial build failure? | 09:00 |
| tkamppeter | The error message is the following: | 09:00 |
| tkamppeter | The following packages have unmet dependencies: | 09:00 |
| tkamppeter | freeglut3-dev: Depends: xlibmesa-gl-dev but it is not going to be installed or | 09:00 |
| tkamppeter | mesag-dev or | 09:00 |
| tkamppeter | libgl-dev | 09:00 |
| tkamppeter | Depends: xlibmesa-glu-dev or | 09:00 |
| tkamppeter | libglu-dev | 09:00 |
| pitti | oh, then that needs to be fixed, and the build can be attempted again | 09:01 |
| tkamppeter | I uploaded a development snapshot of GS 8.64 last week and it installed without problems. | 09:01 |
| pitti | tkamppeter: (don't upload a new version just for a rebuild, that can be done in the web ui) | 09:01 |
| tkamppeter | pitti, I know, todays upload was RC2, it was not an attempt to force rebuilding. | 09:01 |
| pitti | tkamppeter: right, I know; just mentioning | 09:02 |
| tkamppeter | I have posted about this problem here yesterday, too, but no one showed any reaction. | 09:02 |
| apw | TheMuso, don't suppose you are about still? | 09:04 |
| pitti | tkamppeter: right, it's because mesa failed to build on all those | 09:05 |
| pitti | tkamppeter: so don't worry about it for now (mesa should be fixed at least for lpia, though) | 09:05 |
| pitti | ^ tjaalton | 09:05 |
| pitti | bryce: ^ too | 09:05 |
| bryce | pitti: thanks | 09:06 |
| tkamppeter | pitti, now my bzr push is transferring, so the repo should arrive before Christmas. | 09:12 |
| pitti | *chuckle* | 09:12 |
| tjaalton | pitti: yes, lpia has switched to 2.6.28 so it should now build on it | 09:14 |
| pitti | tjaalton: oh, shall I give-back? | 09:14 |
| tjaalton | pitti: a retry should do | 09:14 |
| tjaalton | if that's the same :) | 09:15 |
| tkamppeter | pitti, now the bzr push finished, the progress bar was at around 49 %, disappeared, and it said "Created new branch.". | 09:15 |
| pitti | yes, sorry | 09:15 |
| pitti | tkamppeter: ok, thanks; please just commit to that one then, and prod me to pull from it once you have updates to be uploaded | 09:15 |
| tkamppeter | pitti, I have already given back lpia. | 09:15 |
| pitti | tkamppeter: won't work, mesa needs to build first | 09:15 |
| pitti | tjaalton: kicked | 09:15 |
| Mirv | ArneGoetje/mvo: noticed that desktop team would (still) not have time for language-selector. anyway, I'd hope someone could review and import my bzr branch to fix the bug #311228 | 09:16 |
| ubottu | Launchpad bug 311228 in language-selector "[jaunty] Extra Translations and Writing Aids not installed for the default language" [Undecided,New] https://launchpad.net/bugs/311228 | 09:16 |
| tkamppeter | I have already committed before pushing, so the changes should already be inside. | 09:16 |
| Mirv | it's the last bug people encounter in the flow "install non-English Ubuntu from a CD without a network connection and boot to it (and get language support installed)" | 09:16 |
| tjaalton | pitti: thanks | 09:17 |
| mvo | Mirv: I have a look | 09:17 |
| mvo | Mirv: patch looks fine, thanks a lot | 09:22 |
| Mirv | mvo: great that it looks proper, I tried a few more ugly approaches before finding that one | 09:24 |
| mvo | Mirv: just to confirm, the old way was that it would have prompted the user about missing translation packs and after the next re-open of the language-selector it would have noticed the missing support packages? this now makes it one go (which is much better) | 09:25 |
| tjaalton | pitti: still failed.. I need to relax the dependency on linux-libc-dev for lpia, and maybe other archs too | 09:29 |
| Mirv | mvo: (just tested it again). no, it never suggested support packages. ie. after suggesting the basic support to be installed, no matter how many times l-s is opened, it will not offer support packages to be installed for the default languages (ie. there is no cross mark for the default language, only the "half mark" (color, no check) | 09:34 |
| pitti | superm1: great work wrt. moving hotkeys out of hotkey-setup! I'm committing everything upstream now | 09:43 |
| siretart | lool: regarding hg, if you are happy with my merge, just upload it to the ubuntu archive, I'll import the upload to the hg branch | 09:59 |
| siretart | lool: if you have changes and want them committed to the branch, just tell me the url, I'll fetch & push them. otherwise just upload, I'll import them | 10:01 |
| lool | siretart: I'm uploading as we speak | 10:01 |
| lool | siretart: I resisted doing a trivial change: moving from XS-Vcs-* to Vcs-* | 10:02 |
| lool | siretart: I built the source with debuild -i'\.hg|\.hgtags' -S -sa; hope that's fine | 10:02 |
| siretart | lool: yes, that's fine. I'm building it with hg-buildpackage -S, but haven't noticed a difference yet | 10:03 |
| siretart | just make sure that you grab the orig.tar.gz from debian | 10:03 |
| siretart | ah, I'll commit that change in debian, so we'll get that on the next merge | 10:04 |
| siretart | pushed | 10:05 |
| tkamppeter | pitti, the CUPS SRU is successfully committed. I have checked on Launchpad. I have also proposed to merge it into your branch. So you have probably some click button to merge it in now. | 10:05 |
| pitti | bryce, tjaalton: hm, (for bug 311895), it seems that Xorg.0.log doesn't report pipe underruns any more? I still get them, though | 10:05 |
| ubottu | Launchpad bug 311895 in xserver-xorg-video-intel "[i945] spontaneous black screen (major pipe-A underrun)" [High,Triaged] https://launchpad.net/bugs/311895 | 10:05 |
| bryce | heya pitti | 10:07 |
| tjaalton | pitti: that's with the current driver? | 10:07 |
| pitti | tjaalton: jaunty du jour, yes | 10:07 |
| bryce | I think eric may have suppressed some error/warning messages | 10:07 |
| pitti | okay; it was useful for counting, but I still see the flickering, so I can still test it | 10:08 |
| pitti | I'm currently trying the "FramebufferCompression" "off" suggestion | 10:08 |
| ogra | cjwatson, http://www.nslu2-linux.org/wiki/Debian/TroubleShooting ... acording to martin michlmayr the -r and -k options dont work for slugimage or do i read that wrong ? (you use them both in latest d-i) | 10:33 |
| === asac_ is now known as asac | ||
| cjwatson | ogra: *I* don't use anything | 10:48 |
| cjwatson | ogra: that code is straight from Debian, just with numbers tweaked | 10:48 |
| ogra | well, the d-i buid does | 10:48 |
| ogra | *build | 10:48 |
| cjwatson | ogra: I am not going to get involved in debugging this; somebody needs to work out what's wrong and send a patch | 10:48 |
| cjwatson | I have already spent far too much time trying to get d-i going on armel | 10:49 |
| ogra | i'm not sure i'm reading it right though ... "Don't be fooled by the documentation -- the -r and -k options don't work for Debian-on-slug, because of the APEX bootloader " | 10:49 |
| ogra | ok, thats fine (you said yesterday to leave you alone with it ... ) | 10:50 |
| === davmor2 is now known as davmor2-away | ||
| pitti | Riddell: any idea what to do with the KDE 4.1.4 in intrepid-proposed? only two packges have a bug mentioned in the changelog, so we have no written feedback for them whatsoever | 11:19 |
| Riddell | pitti: ScottK was keeping track of them, I believe there is a bug open | 11:23 |
| Riddell | although can't seem to find it | 11:25 |
| Riddell | mm, no, can't find it, we'll need to wait for ScottK-desktop to wake up | 11:27 |
| dholbach | seb128: you were quicker than I was on pochu's vinagre upload :) | 12:11 |
| dholbach | mid-air collision :) | 12:11 |
| Kaloz | hey. libasound2_1.0.18-1ubuntu3_i386.deb breaks audio on intel hda for me | 12:25 |
| Kaloz | reverting to libasound2_1.0.18-1ubuntu2_i386.deb and restarting pulseaudio fixes it | 12:25 |
| seb128 | dholbach: sorry about the race upload ;-) | 12:26 |
| dholbach | no worries | 12:26 |
| dholbach | I'll go and do something else now :) | 12:26 |
| seb128 | dholbach: I'm trying to be responsive on desktop requests when I'm not too busy ;-) | 12:26 |
| pochu | dholbach: that explains the reject mail - diff.gz already in the archive ;-) | 12:31 |
| dholbach | pochu: yeah | 12:40 |
| === LucidFox_ is now known as LucidFox | ||
| fabbione | Uploading to ubuntu (via ftp to upload.ubuntu.com): | 13:24 |
| fabbione | Connection failed, aborting. Check your network (111, 'Connection refused') | 13:24 |
| fabbione | known issue? | 13:24 |
| pitti | fabbione: yes, cocoplum is down ATM | 13:24 |
| fabbione | pitti: ok thanks.. | 13:24 |
| fabbione | pitti: do you have an ETA? | 13:24 |
| pitti | fabbione: might take a while, thanks to my stupidity we need to recover some files | 13:25 |
| fabbione | it's nothing urgent anyway.. just wanna flush the queue :) | 13:25 |
| pitti | fabbione: an hour or two perhaps | 13:25 |
| fabbione | pitti: no worries man.. i doubt it was your stupidity.. rather your fingers didn't obbey the master :P | 13:25 |
| pitti | either way :) | 13:26 |
| lool | infinity: Hmm I think we need manual intervention to fix the lpia and probably other chroots to install a newer linux-libc-dev | 13:26 |
| lool | infinity: This affects e.g. mesa which has a libdrm-dev bdep which has a versionned dep on linux-libc-dev; mesa failing to build affects a bunch of packages | 13:27 |
| DexterF | hi | 13:32 |
| DexterF | 8.10 in vmware workstation 6.5.0, linux host: no X driver from vmware tools, won't compile. options? | 13:32 |
| === DktrKranz is now known as DktrKranz_nobrow | ||
| === DktrKranz_nobrow is now known as NoBrowser | ||
| === evand_ is now known as evand | ||
| === davmor2-away is now known as davmor2 | ||
| superm1 | pitti, great thanks | 14:12 |
| === NoBrowser is now known as DktrKranz | ||
| * ogra pokes pitti in the ribs | 14:21 | |
| pitti | ogra: eek | 14:25 |
| ogra | heh | 14:25 |
| ogra | pitti, i have some touchscreen issues with the latest hal | 14:25 |
| ogra | apparently the "touchkit touch" on the Q1 forcefully gets capabilities input.touch*pad* set so hal uses synaptics (which doesnt work) | 14:26 |
| ogra | it should either be evdev or evtouch, where does the synaptics suddently come from ? | 14:27 |
| ogra | *suddenly | 14:27 |
| DexterF | 8.10 in vmware workstation 6.5.0, linux host: no X driver from vmware tools, won't compile. options? | 14:28 |
| ScottK | pitti: On 4.1.4 we have two issues we're investigating. It's working quite well for me and others, but I don't want to say verification is done until we get the issues sorted. | 14:33 |
| ScottK | So I think we'll get them verified, but it may take several days. | 14:33 |
| ScottK | Riddell: ^^ | 14:33 |
| ogra | pitti, aha, removing /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi fixes it | 14:33 |
| tjaalton | ogra: lshal should show the capability of input.tablet | 14:39 |
| ogra | tablet | 14:39 |
| ogra | that would be wrong as well | 14:39 |
| tjaalton | why? | 14:39 |
| ogra | since touchscreen != tablet | 14:39 |
| tjaalton | well that's what it's called in hal anyway | 14:40 |
| ogra | touchscreen us definately closer to touchpad | 14:41 |
| ogra | but it needs to use the right driver | 14:41 |
| tjaalton | now it matches 10-x11-input.fdi | 14:41 |
| tjaalton | if you remove the synaptics one | 14:41 |
| ogra | no, it matches evdev | 14:41 |
| ogra | err | 14:41 |
| ogra | evtouch | 14:41 |
| ogra | let me remove that as well and see if evdev recognizes the taps | 14:42 |
| ogra | grrr, if only ctrl alt BS would work now to kill the calibration X server | 14:42 |
| tjaalton | well, I don't know what evtouch does to it, but it shouldn't list input.touchpad as a capability | 14:42 |
| ogra | well, touchpad isnt to wrong here | 14:43 |
| ogra | just synaptics is | 14:43 |
| cody-somerville | slangasek, Ugh... the new kernel update prevents Xubuntu users from logging in??! | 14:43 |
| cody-somerville | :S | 14:43 |
| ScottK | bryce: I was wondering what your thoughts on a SRU for Bug #254468 are? I can guarantee you lots of testers, starting with me. | 14:43 |
| ubottu | Launchpad bug 254468 in xorg-server "MASTER: momentary video garbage upon drawing new objects (particularly in KDE)" [High,Confirmed] https://launchpad.net/bugs/254468 | 14:43 |
| ScottK | cody-somerville: Should cut down on bug reports then. | 14:43 |
| cody-somerville | : P | 14:44 |
| tjaalton | ogra: but because it lists input.touchpad (because of some evtouch trickery?) it'll use synaptics | 14:44 |
| cody-somerville | charlie-tca, Can you fill me in on what you know? | 14:44 |
| charlie-tca | I ran the updates to 7.10 yesterday, about 83 of them installed. When I restarted, I got the GDM login screen. | 14:45 |
| charlie-tca | It went into a continuous loop using automatic login, just trying to login | 14:45 |
| tjaalton | ScottK: probably not going to happen | 14:45 |
| ogra | tjaalton, evtouch doesnt touch any capability settings, it matches only vendor and device names | 14:45 |
| ScottK | tjaalton: Why not? It's a pretty major bug. | 14:46 |
| tjaalton | ogra: then the kernel gets it wrong | 14:46 |
| ogra | tjaalton, removing it *and* the synaptics fdi doesnt make it use evdev though | 14:46 |
| tjaalton | ScottK: I think the performance regression would be greater | 14:46 |
| ogra | there is no x11 driver in lshal at all now | 14:46 |
| charlie-tca | I logged in through tty, changed to not auto login, and every time I tried to login it just keeps asking for a name and password, never leaving the gdm screen | 14:46 |
| ScottK | tjaalton: Apparently we already decided to take that hit for Jaunty. | 14:46 |
| charlie-tca | When I start the -15 kernel, it works | 14:46 |
| tjaalton | ScottK: yes | 14:46 |
| tjaalton | well, for now anyway | 14:46 |
| ScottK | tjaalton: So it's been decided the performance hit is acceptable. | 14:47 |
| tjaalton | ScottK: I can't see it with current intel stack. maybe radeon is safe too since we are using EXA now | 14:47 |
| charlie-tca | Something in the 2-6.22-15-generic kernel is blocking me from logging in through the GUI | 14:47 |
| ScottK | tjaalton: Can't see the performance hit or can't see the screen corruption? | 14:48 |
| tjaalton | ScottK: neither | 14:48 |
| charlie-tca | No, 2.6.22-16-generic kernel is blocking me | 14:48 |
| tjaalton | ScottK: it was dropped during feisty, but got added back almost immediately | 14:48 |
| tjaalton | I think the legacy nvidia* would be hit the most | 14:49 |
| tjaalton | maybe the problem is more evident in KDE.. it never bothered me much | 14:51 |
| ScottK | tjaalton: It really has an attrocious affect on KDE. In addition to looking horrible, it causes hangs. | 14:51 |
| Amaranth | Wait, you dropped the "make X go fast but break KDE" patch? | 14:51 |
| Amaranth | Put it back, put it back | 14:51 |
| ScottK | yep | 14:51 |
| tjaalton | Amaranth: why? | 14:51 |
| Amaranth | I wondered why I could watch windows redraw again | 14:51 |
| tjaalton | Amaranth: on intel? it's not that | 14:52 |
| Amaranth | KDE is only broken because they're not doing something correctly I thought anyway | 14:52 |
| ogra | tjaalton, creating an fdi file to make it use evdev doesnt make evdev recognize any input events | 14:52 |
| ScottK | tjaalton: And if we got to upstream and say "We've patched X to make it suck on KDE, please help us work around it" I don't think we'll get a lot of support. | 14:52 |
| ScottK | Amaranth: Tell us what so we can get it fixed. | 14:52 |
| Amaranth | ScottK: Did fedora drop the patch as well then? | 14:53 |
| ScottK | Currently KDE is fine with an unmangled X. | 14:53 |
| tjaalton | ScottK: fedora still has it | 14:53 |
| ScottK | Amaranth: I have no idea. | 14:53 |
| Amaranth | scottK: the upstream bug report says what to do | 14:53 |
| ScottK | Get upstream to accept the patch and then I'll accept it's a KDE problem. | 14:53 |
| Amaranth | scottK: Upstream wrote the patch | 14:54 |
| Amaranth | Well, ajax did anyway | 14:54 |
| ScottK | What's the upstream bug report? | 14:54 |
| Amaranth | There is something wrong with the spec I think that causes the problem | 14:55 |
| Amaranth | scottK: I dunno, I'd have to find the launchpad one first | 14:55 |
| * Amaranth woke up about 30 minutes ago, brain not firing right yet | 14:55 | |
| tjaalton | Amaranth: so, are you on intel or what?-) | 14:55 |
| Amaranth | tjaalton: Yep | 14:55 |
| tjaalton | Amaranth: ok, bug 320813 | 14:56 |
| ubottu | Launchpad bug 320813 in mesa "[GM45] with EXA compiz animations cause temporary freezes" [High,Confirmed] https://launchpad.net/bugs/320813 | 14:56 |
| tjaalton | caused by vblank | 14:56 |
| Amaranth | tjaalton: X3100, vsync disabled in compiz, using UXA | 14:56 |
| tjaalton | Amaranth: ah :) | 14:57 |
| tjaalton | I don't have problems with UXA, other than X crashes on resume | 14:57 |
| tjaalton | oh and the alpha corruption | 14:57 |
| Amaranth | tjaalton: Well for me gutsy was the last one to work right | 14:57 |
| Amaranth | Most people wish we'd go back to hardy graphics, that was the worst one for me | 14:58 |
| tjaalton | intel is in flux.. | 14:58 |
| Amaranth | Until recently performance in jaunty was pretty good, now it's pretty slow on the desktop yet 3D is nice and speedy | 14:58 |
| Amaranth | So it's either UXA is really slow or put it back, put it back (the patch) :P | 14:58 |
| tjaalton | Amaranth: please verify that it would help ;) | 14:59 |
| ogra | tjaalton, so any suggestions ? | 14:59 |
| Amaranth | bleh, the bug report in KDE is on my OtherOS partition | 14:59 |
| Amaranth | What is the launchpad bug report for KDE being broken? | 14:59 |
| ScottK | Amaranth and tjaalton: We currently have a KDE SRU pending for Intrepid, so if there's a bug that says what needs to change in KDE to work around this patch, please point me at it and I'll see if I can get someone to look into it. | 15:00 |
| Amaranth | The one where people are screaming for blood to get the patch dropped :P | 15:00 |
| ogra | tjaalton, i see it being configured properly in Xorg.0.log as mouse device now ... but apparently no events are getting through at all | 15:00 |
| ogra | (by forcing evdev | 15:00 |
| ogra | ) | 15:00 |
| tjaalton | ogra: sorry, not really.. file a bug with the log and output from evtest | 15:00 |
| tjaalton | ogra: might be a kernel bug then | 15:00 |
| Amaranth | scottK: There is a KDE bug report where ajax tells them what the patch does, why, and what to do to KDE to work with it | 15:00 |
| tjaalton | http://bugs.kde.org/show_bug.cgi?id=170462 | 15:00 |
| ogra | tjaalton, well, they get through with using the evtouch driver | 15:00 |
| Amaranth | scottK: But I have no idea how to find it | 15:01 |
| ubottu | KDE bug 170462 in compositing "Video garbage when drawing new object (Comment #54)" [Normal,Resolved: downstream] | 15:01 |
| ScottK | OK | 15:01 |
| ogra | tjaalton, so i'm pretty sure its in the X layer | 15:01 |
| Amaranth | ScottK: You up for adding a major chunk of plumbing to Qt? I hear they accept community contributions now :/ | 15:03 |
| tjaalton | ogra: then try evtest to be sure | 15:03 |
| ScottK | Nope. | 15:03 |
| ogra | tjaalton, hrm, why is that in the joystick ackage | 15:03 |
| tjaalton | ogra: no idea.. | 15:03 |
| Amaranth | Qt needs to support _NET_WM_SYNC_REQUEST on initial drawing, not just resizing | 15:03 |
| ogra | weird | 15:03 |
| Amaranth | Until they KDE is broken on lots of X servers when you use a compositor | 15:04 |
| Amaranth | s/they/then/ | 15:04 |
| ScottK | As the bug says, this patch violates the current design, which is why it isn't accepted upstream. | 15:05 |
| ogra | tjaalton, hmm, funny, i see events in evtest | 15:05 |
| ogra | and even with the proper coordinates | 15:06 |
| ScottK | Now that I've read that, I'm more convinced than ever dropping the patch as a bad hack is the right answer. | 15:06 |
| Amaranth | ScottK: It breaks what applications _expect_ the server to do, I don't think it violates the spec | 15:07 |
| Amaranth | ScottK: I dunno if SuSE carries this patch but Fedora still does, what do they do to Qt/KDE to not have this problem? | 15:08 |
| ScottK | Last I heard they had the problem. | 15:08 |
| ogra | tjaalton, so am i right to assume the kernel side is fine if it passes evtest ? | 15:08 |
| tjaalton | ogra: probably. file a bug against evdev with all the findings | 15:09 |
| ogra | will do ... | 15:09 |
| * ogra wonders if the joystick driver would work ... *g* | 15:09 | |
| ScottK | Amaranth: In the bug report, I find, "<ajax> trying to do what the protocol says is intensely painfully slow since it's a readback from the card and those aren't fast". That sounds to me like "we don't like the spec so we'll just ignore it." | 15:10 |
| ScottK | So the right way is to change the spec. | 15:10 |
| ScottK | Not just hack around it and not care what users get screwed in the meantime. | 15:11 |
| ScottK | But I guess I'm done. | 15:11 |
| bbs | hi -- i'm a programmer -- this is the first time i've used ubuntu on my own system coming from gentoo type system | 15:11 |
| bbs | where can i find the vim / emacs/ gedit syntax files | 15:11 |
| bbs | so i can program with highlighting | 15:11 |
| Amaranth | ScottK: I'd still rather not destroy the performance of everything else | 15:12 |
| ScottK | I understand KDE isn't a priority. | 15:12 |
| Amaranth | ScottK: There is a clear thing Qt can do here that will fix the problem _and_ make Qt look better on unpatched servers too | 15:12 |
| hyperair | where can i get access to ia64 debs? | 15:12 |
| Amaranth | ScottK: That is pretty much what I am saying, yes. | 15:12 |
| jpds | hyperair: ports.ubuntu.com | 15:13 |
| hyperair | jpds: ah thanks. i'll take a look | 15:13 |
| Tm_T | Amaranth: without knowing better, doing something that break Qt-related stuff and just point them is not helpful IMO | 15:13 |
| jpds | bbs: /etc/vim/vimrc | 15:13 |
| Tm_T | Amaranth: point/point at | 15:14 |
| Amaranth | Tm_T: Ok then, let's just permanently disable compositing for everyone that way they don't run into the problem the patch is trying to fix. | 15:14 |
| bbs | jpds: everything is installed by default? | 15:14 |
| bbs | the syntax files | 15:14 |
| Tm_T | Amaranth: that's not the solution either (: | 15:15 |
| jpds | bbs: You might want to intall vim-full for that. | 15:15 |
| ScottK | Amaranth: Fix the design first. | 15:15 |
| Amaranth | Tm_T: Or just disable compositing for kwin since that seems to be where the problems are | 15:15 |
| Amaranth | ScottK: We can rewrite the core X protocol now? | 15:15 |
| * Amaranth goes to do something else | 15:15 | |
| ScottK | Amaranth: That or carry an out of tree hack forever | 15:15 |
| Amaranth | Which one sounds more likely? | 15:16 |
| Tm_T | Amaranth: anyway, for this particular case, I don't comment on details until I know what is this all about | 15:16 |
| ScottK | Which upstream will never support and we're continually screwed. | 15:16 |
| Tm_T | Amaranth: but, just breaking and waiting others to fix is not nice, it can be done more collaborative way too | 15:16 |
| Amaranth | ScottK: One of the main upstream developers wrote the patch and maintains it in Fedora | 15:16 |
| ScottK | And KDE is still borked there too. | 15:16 |
| ScottK | Just because he's an upstream dev doesn't make it less of a hack on the protocol. He even says as much in that bug. | 15:17 |
| Tm_T | ScottK: this is the buffer thing? | 15:17 |
| ScottK | Yeah. | 15:17 |
| Tm_T | ...no point breaking stuff because of that, until it's properly fixed IMO | 15:18 |
| Amaranth | ScottK: It does mean as long as he cares about the performance in Fedora the patch will be maintained by someone else | 15:18 |
| ScottK | It's not the maintenance of that patch that worries me. | 15:18 |
| tjaalton | Tm_T: we've had the patch for 2,5 years.. now who's breaking what again?-) | 15:19 |
| ScottK | It's the knock on effects and getting upstreams to accept change to work around it. | 15:19 |
| ScottK | We didn't have KDE4 for that long. | 15:19 |
| Tm_T | tjaalton: exactly, its broken at begin with (: | 15:19 |
| ScottK | Obviously we aren't going to solve this. | 15:20 |
| tjaalton | true | 15:20 |
| Amaranth | I consider Qt broken | 15:20 |
| Tm_T | Amaranth: I consider too | 15:20 |
| Amaranth | So then fix Qt or wait for someone to fix Qt | 15:20 |
| Tm_T | tjaalton: anyway, IMO this is the kind of issue that must be taken cautiously, it's not helping anyone to just break things for some people to help performance elsewhere, unless it really is greater benegit | 15:20 |
| Tm_T | tjaalton: this in short term, in long term it must be fixed everywhere properly | 15:21 |
| Mirv | (tjaalton: nice to know X is crashing for you, too, on resume) | 15:21 |
| Amaranth | Tm_T: At this point dropping the patch would be a large regression in performance | 15:21 |
| JontheEchidna | then compiz should be fixed! | 15:21 |
| Tm_T | Amaranth: how large? | 15:21 |
| tjaalton | Tm_T: no-one has been breaking anything, it's been there for a long time | 15:21 |
| Tm_T | tjaalton: I know | 15:21 |
| JontheEchidna | kwin works just fine without the patch, compiz must be broken | 15:22 |
| Tm_T | JontheEchidna: heh | 15:22 |
| Amaranth | JontheEchidna: The bug was reported against kwin's compositor? | 15:22 |
| JontheEchidna | I'm saying, kwin has no slowdown after removing the patch. If compiz does it must be broken | 15:22 |
| tjaalton | JontheEchidna: maybe not with your driver | 15:23 |
| Tm_T | tjaalton: Amaranth: JontheEchidna: but anyway, really, thinking compiz or kwin is more important than other is not a solution, we don't like to divide community, do we? | 15:24 |
| Amaranth | Tm_T: I'm absolutely only thinking about GNOME/Compiz users | 15:24 |
| Tm_T | Amaranth: I know that | 15:24 |
| Amaranth | Tm_T: The rest of them either don't have the problem or have always had the problem | 15:24 |
| Tm_T | Amaranth: I'm not, because I have to answer to every user, not only those | 15:25 |
| Amaranth | Tm_T: If you change the patch we have a regression | 15:25 |
| Tm_T | Amaranth: and Qt breaking isn't regression then? | 15:25 |
| Amaranth | I think we've had the patch longer then we've had Qt4 | 15:25 |
| Tm_T | perhaps | 15:25 |
| Tm_T | perhaps not | 15:25 |
| * Tm_T remembers doing Qt4 stuff for over 3 years now | 15:26 | |
| Amaranth | I know we've had it longer than KDE 4 | 15:26 |
| Tm_T | Amaranth: I dealt with KDE4 3 years ago first time | 15:26 |
| Amaranth | tjaalton would be able to tell you for sure but I thought we added that patch for dapper | 15:26 |
| Tm_T | well -2 month but anyway | 15:26 |
| Amaranth | Tm_T: When was it in the archive? | 15:26 |
| Tm_T | Amaranth: I have no idea, I do a lot with upstream | 15:27 |
| tjaalton | Amaranth: nope, for edgy (Mon, 7 Aug 2006) | 15:27 |
| Amaranth | Tm_T: My point is the patch is older then our having KDE4 or possibly even Qt4 in the archive so from an ubuntu point of view KDE4 has always been broken and changing the patch is a regression for others | 15:27 |
| Tm_T | Amaranth: could be | 15:28 |
| Tm_T | Amaranth: that doesn't mean we as a whole, not you alone, should ignore qt | 15:28 |
| JontheEchidna | Qt4 has been in the archives since 2005 | 15:29 |
| Amaranth | So fix Qt, doubt it'd take more then a week | 15:29 |
| Tm_T | Amaranth: anyway, are you willing to wait until qt4 side is fixed? | 15:29 |
| JontheEchidna | https://launchpad.net/ubuntu/+source/qt4-x11 | 15:29 |
| Tm_T | JontheEchidna: thanks | 15:29 |
| Amaranth | It'd be a nice test for community involvement in Qt Software | 15:29 |
| Riddell | I've filed a task with Qt upstream | 15:29 |
| tjaalton | Tm_T: the patch is disabled in jaunty (for now anyway) | 15:29 |
| Tm_T | Riddell: thanks sir, bug number? | 15:29 |
| Amaranth | Fixing this would make KDE look better on unpatched X as well so it's a win-win | 15:30 |
| Riddell | Tm_T: no number until it's public | 15:30 |
| Tm_T | Riddell: roger | 15:30 |
| Tm_T | Amaranth: true | 15:30 |
| Tm_T | Amaranth: that's what I meant by collaborating | 15:30 |
| Tm_T | Amaranth: one side soloing isn't helpful (: | 15:31 |
| Tm_T | tjaalton: I see, thanks for info, so, are we now evaluating situation or what? | 15:31 |
| * Amaranth tries to free up HD space to build X with the patch again | 15:31 | |
| Tm_T | Riddell: have any our friend trolls been poken about it? | 15:31 |
| tjaalton | Tm_T: yes.. nvidia updated their legacy drivers to support the new xserver video ABI, so once tseliot has updated the packages we should know how they are affected | 15:32 |
| Tm_T | tjaalton: appreciate all info in the future too, son (: | 15:33 |
| tseliot | I'll do it soon | 15:33 |
| Riddell | Tm_T: 15:29 < Riddell> I've filed a task with Qt upstream | 15:33 |
| tjaalton | tseliot: now! :) | 15:33 |
| Tm_T | Riddell: ah, with! thanks | 15:33 |
| Tm_T | tjaalton: these issues are messy, I notice | 15:34 |
| tseliot | tjaalton: I'll go back in time and since "now" has just passed | 15:34 |
| tseliot | s/and// | 15:35 |
| tkamppeter | pitti, I have added also the fix for bug 309314 to the CUPS SRU. Can you merge it into the Intrepid CUPS repo? Thanks. | 15:38 |
| ubottu | Launchpad bug 309314 in cups "Documents silently fail to print" [Undecided,Fix committed] https://launchpad.net/bugs/309314 | 15:38 |
| === ssweeny_ is now known as ssweeny | ||
| pitti | tkamppeter: did you see my merge request reply? did you pull before? | 16:02 |
| ScottK | pitti and tkamppeter: Can we arrange it so all core-dev don't have to get emailed about those? | 16:03 |
| pitti | ScottK: I don't know how... I get annoyed by those, too (getting merge requests for firefox etc.), but ATM there's nothing in LP to change that :( | 16:04 |
| ScottK | I think there have been some recent changes. | 16:04 |
| * ScottK looks.... | 16:04 | |
| pitti | tkamppeter: ah, apparently you did; looks fine, pulled | 16:05 |
| ScottK | pitti: https://code.launchpad.net/~ubuntu-core-dev/cups/intrepid/+subscription/ubuntu-core-dev - Unsubscribing the team will, I think, do it. | 16:06 |
| pitti | ScottK: I set it to "no email" | 16:07 |
| ScottK | pitti: Excellent. | 16:07 |
| tkamppeter | pitti, thanks for taking that one in. | 16:08 |
| pitti | ScottK: thanks, didn't know about that | 16:08 |
| ScottK | pitti: It's a recent development. A few weeks ago and went and bitched about it in #launchpad and they pointed me at the feature. | 16:09 |
| === dholbach_ is now known as dholbach | ||
| slangasek | charlie-tca: was '7.10' a typo? | 16:37 |
| dholbach | slangasek: so... sponsoring :) | 16:43 |
| slangasek | dholbach: it was actually less a comment on the sponsoring queue per se, than a repeat of my kvetch from UDS about there being packages in main with authoritative repos that core-dev don't have commit rights to | 16:44 |
| dholbach | slangasek: ah, I see - sounds like something we should discuss on the mailing list | 16:45 |
| dholbach | slangasek: I don't think that "make ubuntu-core-dev join a bunch of other teams" will help | 16:46 |
| cjwatson | the main reason I haven't just added ubuntu-core-dev to the ubuntu-installer team is that I think it would generate a lot of mail | 16:46 |
| dholbach | *nod* | 16:46 |
| cjwatson | in principle, I think it would be correct enough, actually | 16:46 |
| Keybuk | the way this was always envisioned as working was that you had a lp bzr branch that ubuntu-core-dev can commit to, that matches what's in the archive | 16:46 |
| cjwatson | perhaps somebody could write up a primer on LP mail handling as it affects team memberships | 16:46 |
| Keybuk | and you have a second team branch | 16:46 |
| cjwatson | I actually do that for ubiquity | 16:46 |
| Keybuk | which the entire mozilla team can commit to | 16:46 |
| slangasek | dholbach: I don't think there are "a bunch" of other teams; I know of 4 | 16:46 |
| dholbach | in an archivereorg + bzr-for-everything world it will be different, I don't know what the best way to do it now | 16:46 |
| Keybuk | and when you do releases, you merge from the team branch into the core-dev branch | 16:47 |
| slangasek | mozilla, OOo, network-manager, and (apparently) installer | 16:47 |
| cjwatson | but I often forget to push to the core-dev branch (I certainly don't want to merge if I don't have to) | 16:47 |
| dholbach | slangasek: artwork stuff too | 16:47 |
| cjwatson | (I'd rather revision numbers stayed the same) | 16:47 |
| dholbach | docs too | 16:47 |
| slangasek | dholbach: oh, those don't count because I don't ever commit to them. ;) | 16:47 |
| slangasek | though, I think g-p-m is also in this state, now that I think of it | 16:47 |
| cjwatson | desktop | 16:48 |
| Keybuk | what broke when we set the core-dev mailing address, can anyone remember? | 16:48 |
| cjwatson | ~ubuntu-desktop/vte/ubuntu was one I ran into recently | 16:48 |
| slangasek | dholbach: anyway - I agree it should go via mailing list; I'm not volunteering to drive this discussion just at the moment. Was just kvetching. :) | 16:48 |
| cjwatson | Keybuk: I think the "matches what's in the archive" constraint is weird, because it doesn't hold if a core-dev not in the team commits something but doesn't think it needs to be uploaded right away | 16:49 |
| dholbach | slangasek: kvetching... is that something like czechnology? | 16:49 |
| slangasek | if czechnology is Yiddish, then yes | 16:49 |
| Keybuk | cjwatson: right | 16:49 |
| dholbach | slangasek: no, not really :) | 16:49 |
| cjwatson | Keybuk: so the effect of that policy is that the branch is up-to-date for anything core-devs commit, but not for anything that the team most qualified to work on the package is concerned, which seems precisely backwards | 16:49 |
| Keybuk | cjwatson: I agree with you there | 16:49 |
| cjwatson | Keybuk: which is why I just push ubiquity to the ubuntu-core-dev branch when I feel like it ;-) | 16:50 |
| cjwatson | really, though, I'd rather that the branch be "ubuntu-core-dev + ubuntu-installer" | 16:50 |
| seb128 | slangasek: hello, so the g-s-d changes fix your issue, good ;-) | 16:50 |
| Keybuk | branch permissions? | 16:50 |
| cjwatson | once they exist ... | 16:50 |
| Keybuk | I don't think they are even planned | 16:50 |
| cjwatson | if ubuntu-core-dev can have a mailing address set, I can just make it a member of ubuntu-installer and not care | 16:50 |
| cjwatson | Keybuk: they are, as part of the distro branch namespace work | 16:51 |
| Keybuk | cjwatson: we tried setting a mailing address for it | 16:51 |
| Keybuk | it broke some things | 16:51 |
| james_w | cjwatson: you would like the branch permissions to be different to the upload permissions? | 16:51 |
| cjwatson | Keybuk: i.e. eventually it'll just be ubuntu/+trunk/ubiquity or whatever, and anyone who can upload ubiquity can commit to it | 16:51 |
| slangasek | seb128: yep - like magic! | 16:51 |
| Keybuk | oh, interesting | 16:51 |
| Keybuk | that would certainly fix the problem | 16:51 |
| cjwatson | james_w: perhaps, but that isn't required for this; we could just say that some extra people can upload ubiquity | 16:52 |
| geser | mvo: about bug 243550: I've just tested your patch, but it doesn't work (for me). gdebi still lists all recommends if I enable recommends again in my host system (I've checked, it's still disabled in the pbuilder) | 16:52 |
| ubottu | Launchpad bug 243550 in python-apt "gdebi --root doesn't use the apt config from the chroot but the one from the "host"" [Medium,Triaged] https://launchpad.net/bugs/243550 | 16:52 |
| cjwatson | we originally moved it to ubuntu-installer because evand wasn't in core-dev but needed to work on ubiquity, and I was fed up merging his stuff on autopilot | 16:52 |
| james_w | cjwatson: I think that makes more sense at this point. | 16:52 |
| mvo | geser: yeah, thanks for testing it | 16:52 |
| mvo | geser: sorry that its not quite there yet, I'm investigating | 16:52 |
| cjwatson | I *would* like extended branch permissions at some point, but we could get by without | 16:53 |
| geser | mvo: does it matter that I'm still on intrepid? | 16:53 |
| james_w | (p.s. lp namespace and branch permissions based on upload permissions are well on the way) | 16:53 |
| dholbach | slangasek: here's where I first stumbled over the word: http://jimmac.musichall.cz/log/?cat=31 | 16:53 |
| mvo | geser: the patch I did initially had some bad side effects, I need to redo it I think | 16:54 |
| geser | should I add my test results to the bug? | 16:54 |
| mvo | geser: feel free, but I hope to get a new version up soonish :) | 16:55 |
| === azeem_ is now known as azeem | ||
| charlie-tca | slangasek: Sorry, No, 7.10 was not a typo. | 16:59 |
| slangasek | charlie-tca: ah. so cody-somerville was hitting the panic button about a bug in gutsy then? | 17:00 |
| charlie-tca | I'm running a fresh install now, to see if it happens again | 17:00 |
| charlie-tca | Gutsy is 7.10. We do still support it, right? | 17:00 |
| slangasek | there's security support for it. You're not going to get much support for other bugfixes. | 17:01 |
| charlie-tca | So if the kernel won't boot, what? | 17:01 |
| charlie-tca | We just tell the user "too bad, it is not a security issue"? | 17:02 |
| slangasek | charlie-tca: direct them to the forums for a workaround that will let them upgrade to a version of Ubuntu whose kernel *is* actively maintained? | 17:02 |
| charlie-tca | But the update to the new kernel was just this month! | 17:03 |
| slangasek | oh? | 17:03 |
| charlie-tca | The kernel was upgraded from 2.6.22-15 to -16 and that is what broke | 17:03 |
| slangasek | sorry, I thought you were saying that you had just recently upgraded your system to 7.10 from an older release | 17:03 |
| slangasek | if it's a regression *in* a security update, yes, that should be tracked down and fixed | 17:04 |
| charlie-tca | The -15 kernel will start, the -16 kernel will loop the GUI login screen | 17:04 |
| charlie-tca | Once it upgrades the kernel, you can not log in at the GUI | 17:04 |
| slangasek | charlie-tca: is there a bug report open for this issue? | 17:10 |
| charlie-tca | No, not that I can find. I can file it, though | 17:11 |
| slangasek | charlie-tca: please do, and give me the bug number so I can escalate | 17:12 |
| charlie-tca | Okay, I will. | 17:12 |
| slangasek | also, can you capture an strace of what gdm is doing when it's supposed to instead be logging you in? | 17:13 |
| charlie-tca | I can try, but so far none of the logs are showing anything. | 17:13 |
| slangasek | I wouldn't expect them to; hence, 'strace' | 17:14 |
| charlie-tca | I'll do that | 17:14 |
| === warp10_ is now known as warp10 | ||
| pitti | Riddell: FYI, bug 297152 is the boost transition thing, and immediate uploads just for this aren't really required (but thanks for your kdepim upload) | 17:31 |
| ubottu | Launchpad bug 297152 in linux-ports "boost -> boost1.35 transition / demote gcc-4.1 and gcc-4.2 to universe" [High,In progress] https://launchpad.net/bugs/297152 | 17:31 |
| Riddell | pitti: yep, found that out | 17:32 |
| kees | charlie-tca: that sounds like video driver version mismatch. did all the other kernel-related packages get updated too? | 17:38 |
| charlie-tca | yes, to the best of my knowledge | 17:39 |
| Kano | hi, could syslinux upgraded to 3.72 to use hybrid iso mode of isolinux? | 17:42 |
| Kano | or newer... like in experimental | 17:43 |
| Kano | 3.73 | 17:43 |
| kees | charlie-tca: when you've got a bug #, let me know, and I can poke around at it. | 17:45 |
| Kano | then you could call isohybrid on the created iso image | 17:53 |
| soren | Kano: What would that do? | 17:53 |
| Kano | well you can cp the iso image 1:1 onto hd or usb stick | 17:53 |
| Kano | and it is bootable | 17:53 |
| Kano | like that moblin iso, which is created that way | 17:54 |
| soren | I'm almost certain we can already do that. | 17:54 |
| Kano | you have got a pretty bad installer for usb stick | 17:54 |
| soren | I've done some testing of extboot in kvm that suggests that that is the case, anyway. | 17:54 |
| soren | Kano: Perhaps I'm not fully understanding what you're saying. | 17:55 |
| cjwatson | simply changing the way the image is written to the USB stick would not change the other problems with running from a USB stick in any way, and those are more urgent. | 17:55 |
| cjwatson | generally speaking upgrading syslinux is a complete pain to do because we have to upgrade the gfxboot patch as well | 17:55 |
| Kano | soren: cp image.iso /dev/stick | 17:55 |
| Kano | is what you do, then you can boot it | 17:55 |
| cjwatson | so I try to avoid it whenever possible. If you want it faster, send a fully-tested patch that preserves all of the things we use | 17:56 |
| soren | Kano: I'm 99% sure that works now. | 17:56 |
| Kano | cjwatson: why dont you use the standard routines? | 17:56 |
| cjwatson | Kano: because people screamed at us until we did gfxboot | 17:56 |
| cjwatson | and it's a pain to change now | 17:56 |
| Kano | syslinux has nice gfx support | 17:56 |
| cjwatson | soren: no, you have to use usb-creator | 17:56 |
| soren | Kano: But I appear to be wrong. | 17:56 |
| cjwatson | Kano: it's different, and would require substantial porting. I will not be harangued by you about it, I'm afraid | 17:57 |
| cjwatson | and it didn't have any of that support when we first added gfxboot | 17:57 |
| Kano | vesamenu | 17:57 |
| cjwatson | would require substantial porting work | 17:57 |
| cjwatson | read my lips | 17:57 |
| cjwatson | it's not just as simple as saying that the facilities exist | 17:58 |
| cjwatson | I would get shouted at if I made it look less pretty | 17:58 |
| soren | cjwatson: Hm... That is interesting, actually. I had a libvirt bug once where Fedora CD's failed to boot. The conclusion was that due to some misunderstandings between libvirt and kvm, we were booting the CD's as though they were hard drives, and for some reason, Ubuntu and Debian CD's worked fine, but Fedora ones didn't. | 17:58 |
| cjwatson | which I think is pretty shallow, but that's not my problem | 17:58 |
| cjwatson | soren: they might use some different bootloader on their CDs, e.g. grub | 17:58 |
| calc | i have a question i am modifying suitesparse to break a library out and it uses cdbs, how do i make it link automatically to the other package (being produced at the same time) or should it know how to do that already and something possibly broken? | 17:59 |
| cjwatson | right now, we depend very extensively on the customisations that have been applied to gfxboot | 17:59 |
| Kano | which are not working with pxelinux btw. | 17:59 |
| calc | iirc dh_shlibdeps (or something like that) is supposed to do it, but i thought cdbs does this automatically? | 18:00 |
| soren | cjwatson: I think they also used syslinux, but ICBW. Anyhow, this sheds new light on the issue. | 18:00 |
| cjwatson | Kano: yes, I am aware that gfxboot doesn't currently work with pxelinux; there is a bug about it | 18:01 |
| cjwatson | nobody has sent a patch yet AFAIK and I haven't had time to dust off my assembler and figure it out | 18:01 |
| Kano | could you put that into a module? | 18:02 |
| cjwatson | put what into a module? | 18:02 |
| Kano | your gfxboot hack | 18:02 |
| cjwatson | it's not my gfxboot hack, it's SuSE's | 18:02 |
| cjwatson | ask them, I'm not interested in that level of work on it | 18:02 |
| Kano | i know that gfxboot is from suse | 18:03 |
| cjwatson | nor do I think I would do a good job on it | 18:03 |
| TheMuso | 8/c | 18:03 |
| * ogra really wonders how "cp image.iso /dev/stick" would work though ... | 18:03 | |
| * calc thinks he found the issue | 18:03 | |
| ogra | are you sure you didnt mean dd ? | 18:04 |
| Kano | ogra: you can use dd, cat or write your own app, all would work | 18:04 |
| cjwatson | our gfxboot customisations are in gfxboot-theme-ubuntu, which is written in gfxboot's own interpreted language. They would not make a lot of sense as a standalone syslinux module | 18:04 |
| ogra | but not cp ... thats what confused me | 18:04 |
| Kano | cp too | 18:04 |
| Kano | no diff | 18:04 |
| cjwatson | cp image.iso /dev/stick => replace the /dev/stick device node with a regular file | 18:05 |
| Kano | just dont forget sysnc | 18:05 |
| Kano | sync | 18:05 |
| cjwatson | hmm, that's interesting, cp foo devicenode does actually appear to write to devicenode | 18:06 |
| ogra | hmm, i always thought you had to pipe a binary stream to it ... | 18:06 |
| calc | yep got it working | 18:06 |
| ogra | which is what cat and dd would do | 18:06 |
| cjwatson | I take it back | 18:06 |
| ion_ | cjwatson: echo foo >foo >bar; strace cp foo bar: cp just open()s bar for writing and write()s to it. | 18:09 |
| cjwatson | yes I already did | 18:09 |
| slangasek | calc: should already do it automatically; is it not working? | 18:09 |
| slangasek | calc: oh, scrolling down, n/m | 18:10 |
| slangasek | :) | 18:10 |
| Kano | btw. when you use: default vesamenu.c32 | 18:11 |
| Kano | then you see at least the logo and have got a menu | 18:12 |
| Kano | of course you have to put that module on the iso | 18:13 |
| calc | slangasek: i found the problem it uses a .symbols file i forgot to update | 18:14 |
| calc | slangasek: so it was claiming the symbols were in the wrong file | 18:14 |
| slangasek | aha | 18:14 |
| slangasek | :) | 18:14 |
| * calc notes he isn't sure how good a feature that is ;-) | 18:14 | |
| slangasek | dpkg-gensymbols has an option to make it complain if there's a mismatch | 18:15 |
| slangasek | hmm, except the levels are wrong, warning if libraries have disappeared should be a lower level than warning if symbols have been added | 18:16 |
| slangasek | doh | 18:16 |
| slangasek | charlie-tca: have a bug number yet for us? :) | 18:35 |
| === ivoks_ is now known as ivoks | ||
| DexterF | does ubuntu 8.04 support the GeForce 8x00 chipsets out of the box or is there a backported kernel that does? | 18:44 |
| directhex | DexterF, are you talking plug-in gpus, or motherboard chipsets? | 18:48 |
| DexterF | directhex: chipsets | 18:48 |
| directhex | DexterF, you be wantin' Envy. | 18:51 |
| directhex | envyng-gtk package | 18:51 |
| DexterF | uh... no, *not* gpus - chipsets. sATA ports, usb and such. | 18:51 |
| calc | the nvidia geforce 8300 chipset came out after 8.04 so probably not supported i would imagine | 18:52 |
| DexterF | there goes that plan | 18:52 |
| DexterF | any backported kernels available? | 18:52 |
| calc | afaict it wasn't even reviewed by sites until ~ July 2008 | 18:53 |
| calc | DexterF: 8.10 might support it | 18:53 |
| DexterF | not an option | 18:53 |
| directhex | sata ports should be AHCI these days shouldn't they? | 18:55 |
| directhex | USB hasn't changed for about a decade | 18:55 |
| calc | the newest kernel in hardy is 2.6.24-23.46 | 18:55 |
| DexterF | all irrelevant if the chipset is unsupported | 18:55 |
| calc | DexterF: you could try booting a live cd and see if it works | 18:55 |
| directhex | i don't think you know exactly what "the chipset is supported" means though | 18:55 |
| DexterF | system is in planning stage right now | 18:56 |
| DexterF | directhex: in order to talk to the board components the chipset has to be supported by the kernel. it's quite obvious I'd say | 18:56 |
| calc | but yea in general its not a good idea to buy a chipset newer than the version of linux you want to run on it ;-) | 18:56 |
| DexterF | dang I need a board with nvidia based onboard video... | 18:57 |
| directhex | you'd be wrong, though. the chipset's individual components, as reportsed to given busses, is what matters | 18:57 |
| DexterF | the old 7050 work fine I know but I need a *tad* more punch | 18:57 |
| calc | directhex: i don't know if its as problematic as it used to be but generally linux has had to add quirks, etc for new chipsets | 18:57 |
| directhex | so whilst sata_nv might be too old, as an example, EHCI is EHCI and usb2 will just work regardless of vintage | 18:57 |
| calc | DexterF: so why is it you have to run 8.04? :) | 18:57 |
| directhex | version matching for mythtv at a guess | 18:58 |
| calc | DexterF: even if there was a backported kernel you would have to somehow get the machine bootstrapped probably on another machine before upgrading the kernel | 18:58 |
| DexterF | friend's machine, 8.10 means kde4 which I can't support because I don't use it. kde4 quite frankly and imo sucks wet farts from dead pidgeons | 18:58 |
| calc | DexterF: you could try installing just the kernel from intrepid or jaunty i suppose | 18:58 |
| directhex | calc, nah, too much changed | 18:59 |
| DexterF | hmm, manually backport, eh? | 18:59 |
| calc | directhex: oh? need new userland for them? | 18:59 |
| directhex | and building ubuntu kernels manually sucks | 18:59 |
| * calc is running jaunty kernel on intrepid, but hasn't run hardy in a long time | 18:59 | |
| directhex | calc, lots of things changed around, so you'd lose the entire support structure for, say, nvidia graphics drivers | 18:59 |
| calc | directhex: ah ok | 18:59 |
| DexterF | i see where this is going | 18:59 |
| * calc avoids nvidia due to their stance on floss ;-) | 19:00 | |
| DexterF | if that fglrx drivers wasnt that crappy I'd go for a 780G board... | 19:00 |
| directhex | in the end, ubuntu has a particularly bad mechanism for supporting new hardware in old LTS releases | 19:00 |
| calc | well thats not completely true i run nvidia card with the nv driver because ati at the time had no fanless dual dvi cards i could find | 19:01 |
| calc | DexterF: intel ftw :) | 19:01 |
| DexterF | calc: $$$-issue. not applicable. that is.. wait. hm. the X3100 series packs a punch in terms of integrated video, right? | 19:02 |
| directhex | depends. what do you want it to be able to do? | 19:03 |
| directhex | games are right out | 19:03 |
| calc | intel cpu can be really cheap eg the c2q 8300 | 19:03 |
| calc | and are much faster than amd | 19:03 |
| calc | but yea no gaming on them, probably not too good gaming on any integrated chipset really | 19:03 |
| calc | some can run games only 5 years old instead of 10 ;-) | 19:04 |
| calc | DexterF: the one good point about amd is that there are open drivers in active development with specs so you are less likely to get bitten by ugly nvidia bugs | 19:04 |
| charlie-tca | slangasek: no, not yet. I'm trying to verify it on another system first. | 19:05 |
| calc | like not being able to see text on menus in applications | 19:05 |
| slangasek | charlie-tca: well, even if it's only reproducible on a single system, regressions in security updates are a critical issue | 19:05 |
| ogra | pfft, menus are overrated anyway | 19:05 |
| directhex | i wonder whether intrepid will install on my new pc, once i get the broken motherboard issue solved | 19:05 |
| directhex | i was surprised enough that it worked on this laptop | 19:05 |
| calc | DexterF: but no fglrx is not the open driver :) | 19:06 |
| calc | i'm waiting to buy a new computer until ~ dec/jan at the end of the year | 19:06 |
| DexterF | calc: I fell for ATi PR chatter for five f?!*ing years, I hardly have adequate words for how through I am with their video cards | 19:06 |
| slangasek | so is libxcb upgrading ok for folks now on jaunty, as opposed to being held back in update-manager? | 19:06 |
| slangasek | (I already forced the upgrade on my system, so don't have a convenient test case anymore) | 19:06 |
| calc | DexterF: phoronix has articles about the work, it has taken a few years to get them running (aiui) | 19:06 |
| calc | DexterF: and nvidia still has no real open source drivers at all after claiming they would help floss over 10 years ago now, so ymmv ;-) | 19:07 |
| directhex | DexterF, i benchmarked it about 5 years ago. ut2004 performance, £100 geforce ti4200 versus £300 ati 9800 xt... guess which was 3x faster than t'other :) | 19:07 |
| superm1 | calc, was it ever discerned if that was a driver bug, or did it only happen with compiz running (and is possibly a compiz implementation bug?) | 19:07 |
| superm1 | i remember hearing about it a long time ago, but never followed it | 19:07 |
| calc | i was in a discussion with nvidia (iirc on irc) back around 1998 | 19:07 |
| calc | superm1: aiui it only happens on nvidia so it is almost certainly their bug | 19:08 |
| DexterF | I've been monitoring the open drivers dervelopment lately and from what I saw/heard full featured stable drivers are *way* in the future, 2010 perhaps when everything current is more outdated than socket A boards and don't get me started on moronix' fanboi drivel | 19:08 |
| calc | superm1: but i don't know the current status | 19:08 |
| directhex | DexterF, phoronix mean well, they just don't really understand how to benchmark things properly | 19:08 |
| DexterF | they are fanbois | 19:08 |
| superm1 | calc, well it only happens with them doesn't mean it's "their" bug, it still could just be that their driver emphasizes a bug with a lower layer. i know that was happening with gnome screensaver a release or two ago | 19:09 |
| DexterF | each time I glimpsed in it was "NEW!! ATi free drivers now *even better!!" | 19:09 |
| superm1 | in this case turned out to be a compiz bug | 19:09 |
| DexterF | yeah, like: it doesn't crash now when changing resolution or such | 19:09 |
| directhex | DexterF, you don't think that counts as "even better"? :) | 19:09 |
| calc | DexterF: well if you do go with nvidia do realize your hardware is going to become unsupported in the not too distant future, just look at the list of drivers for nvidia in ubuntu, we have to maintain 5 sets of drivers because nvidia dropped support for older cards at various times | 19:09 |
| DexterF | I switched to nv finally and while I'm aware of the perf issues I can't describe how happy I am with that evil closed src driver | 19:10 |
| calc | DexterF: we have 71, 96, 173, 177, 180 | 19:10 |
| DexterF | speaking of which: I _don't_ habe 180 in 8.04. any way to get it? I'd like the perf extra plus... | 19:10 |
| calc | back when i used nvidia it would always crash when i tried to switch to console | 19:11 |
| directhex | DexterF, sure. don't be 8.04 | 19:11 |
| DexterF | kde4 still = teh suck | 19:11 |
| directhex | calc, anyway, i have similarly bad glitching on intel | 19:11 |
| Riddell | DexterF: can you stop flaming please | 19:11 |
| calc | DexterF: xubuntu? :-) | 19:11 |
| DexterF | Riddell: k | 19:11 |
| directhex | calc, if i allow usplash to use its default resolution, i can't switch to a console after x starts | 19:11 |
| calc | directhex: ah ok | 19:11 |
| directhex | calc, and sadly usplash doesn't correctly work with widescreen | 19:12 |
| calc | directhex: luckily we'll be rid of usplash with 9.10 | 19:12 |
| ogra | directhex, until them patches are hapily accepted ;) | 19:12 |
| ogra | *then | 19:12 |
| directhex | ogra, i had a look at the code, and ran screaming | 19:12 |
| directhex | ogra, both at the code and at the idea of telling mjg59 that something sucks | 19:13 |
| ogra | directhex, just call it a challenge ;) | 19:13 |
| DexterF | calc: I'd like nv to port over the old stuff, too, yes, just pointing out everything works with those. 3D, Xv... with ATi couldn't get even decent Xv. | 19:13 |
| directhex | DexterF, ati sorta kinda got xv support in driver 8.5 or so | 19:14 |
| calc | DexterF: nv can't since nvidia refuses to give out any documentation at all | 19:14 |
| calc | DexterF: the ati drivers are better because amd released nearly full docs | 19:15 |
| DexterF | directhex: fglrx had Xv ever since, only problem was serious artifact issues over month they didn't solve. last time I checked was... mmh... 8.3 or 8.4. | 19:15 |
| calc | DexterF: they won't even release documents for the nv01 | 19:15 |
| DexterF | calc: yeah, sad story. thing is they dont really need to. | 19:15 |
| directhex | calc, zomg trade secrets!!! | 19:15 |
| calc | DexterF: yea what with intel having more market share than them ;-) | 19:16 |
| DexterF | ? | 19:16 |
| calc | DexterF: nvidia isn't in a market dominant position so probably should be releasing documents | 19:17 |
| calc | their stock price is less than 1/4 what it was a year ago | 19:17 |
| calc | they had product recalls that nearly killed them as well | 19:17 |
| DexterF | didn't know about the stock thing. well, I guess their main interst is windows gamers. I came to think ATi made the open src move because they were desperate before the 48x0 series rolled in real cash | 19:18 |
| calc | iirc intel has the vast majority in the market for video chipsets with ati and nvidia trailing fairly far behind | 19:19 |
| directhex | the real cash is in OEM sales | 19:19 |
| calc | DexterF: not really before the amd buyout even finished they had already announced they were going to release the documents | 19:19 |
| DexterF | calc: intel? Oo | 19:20 |
| calc | directhex: yea and that is where nvidia has been having trouble, esp with all the bad parts | 19:20 |
| calc | DexterF: in the past there have been graphs published showing the breakdown of the market between the vendors | 19:20 |
| calc | slangasek: i think the new suitesparse i uploaded might be stuck in new | 19:34 |
| calc | slangasek: i haven't received an email about it yet though, it has a new binary package | 19:34 |
| slangasek | did you get confirmation of the source upload? | 19:34 |
| slangasek | yeah, I see the binaries in new; processing | 19:35 |
| calc | slangasek: not yet | 19:35 |
| TheMuso | Keybuk: Afaik you are working on initramfs-tools. Are you likely going to upload soon, or is it safe for me to do an upload today? | 19:35 |
| calc | slangasek: thanks :) | 19:35 |
| slangasek | calc: oh, the binaries I see are from 3.2.0-1, which is the one we synced - if there's another upload, I don't see it | 19:35 |
| calc | yea a 3.2.0-1ubuntu1 upload | 19:35 |
| Keybuk | TheMuso: I'm not doing any work on initramfs-tools right now | 19:35 |
| calc | slangasek: hmm maybe i should try uploading again | 19:36 |
| TheMuso | Keybuk: Ok thanks. | 19:36 |
| slangasek | calc: doesn't show up on https://launchpad.net/ubuntu/+source/suitesparse, so if it's been more than 15 minutes, yeah probably | 19:36 |
| calc | slangasek: ok | 19:36 |
| calc | slangasek: should it show up there even if it is new? btw i just uploaded again | 19:37 |
| slangasek | calc: yes, the source should show up there. | 19:38 |
| calc | ok | 19:38 |
| calc | once i see it finished building i'll let you know for the new processing bit | 19:39 |
| superm1 | tseliot, tedg should we be pulling in http://svn.gnome.org/viewvc/gnome-power-manager?view=revision&revision=3167 to fix the high CPU usage bug on gnome power manager? does jaunty have RR1.3 yet so we could do that? | 19:40 |
| superm1 | (bug 307306 for reference) | 19:42 |
| ubottu | Launchpad bug 307306 in gnome-power-manager "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [High,In progress] https://launchpad.net/bugs/307306 | 19:42 |
| === hyperair_ is now known as hyperair | ||
| maxb | superm1: I'm running with that patch locally - it works, and helps, but doesn't completely fix things (as per my later comments in the bug) | 19:47 |
| superm1 | maxb, considering it's upstream, perhaps we should pull it in then to at least get the behavior improved until a final resolution is found. | 19:47 |
| maxb | It would undoubtably be appreciated by people testing Jaunty on problem setups who haven't done local builds. | 19:48 |
| superm1 | maxb, have you explored at all, do you have any idea why there are so many randr calls happening in the first place? | 19:49 |
| Amaranth | You mean X will stop chewing 50% CPU for 3 minutes after gnome-power-manager starts soon? :) | 19:49 |
| maxb | Unfortunately my X-fu is insufficient | 19:50 |
| Amaranth | superm1: The call they are making used to return a cached result, now it probes | 19:50 |
| maxb | I'm hoping the log I posted will mean something to someone | 19:50 |
| Amaranth | And apparently GDK sends the "monitors-changed" signal when you change the brightness which is broken | 19:51 |
| superm1 | Amaranth, so who is really to blame then and should be fixed? GPM to cache the result and/or make it less frequently? | 19:52 |
| Amaranth | superm1: There is another function they can use to get the cached result in randr 1.3 | 19:52 |
| superm1 | Amaranth, is that the call that was added in the patch i posted above, or you are meaning a different one yet? | 19:52 |
| Amaranth | superm1: probably that one | 19:53 |
| superm1 | Amaranth, "XRRGetScreenResourcesCurrent" ? | 19:53 |
| Amaranth | yep, that one | 19:53 |
| Amaranth | gnome-settings-daemon needed patched as well, iirc | 19:53 |
| superm1 | okay well i'll get this into an upload to GPM then, it's upstream already, and way annoying. | 19:54 |
| Amaranth | oh, the gsd one was actually in gnome-desktop which we have already | 19:55 |
| calc | slangasek: i uploaded suitesparse again 30m ago and i still haven't received an email and its not showing up on LP, any ideas? | 20:07 |
| slangasek | calc: see other channel where you've been highlighted. :) | 20:08 |
| slangasek | there are some delays right now with package accepts | 20:09 |
| tseliot | superm1: my patch for g-p-m is ok but we still need other two patches for gnome-control-center. And yes we have randr 1.3 | 20:09 |
| calc | slangasek: thanks :) | 20:10 |
| tseliot | superm1: we're discussing with upstream on the patches for gnome-control-center here: http://bugzilla.gnome.org/show_bug.cgi?id=568160 | 20:16 |
| ubottu | Gnome bug 568160 in libgnome-desktop "Gnome Settings daemon causes high CPU usage with an expensive call" [Major,Resolved: fixed] | 20:16 |
| mohbana | am i the only one who is experiencing a really slow file browser (the gnome one) | 20:26 |
| mohbana | yet the kde file explorer - dolphin - is very fast | 20:26 |
| mohbana | it's very noticeable | 20:26 |
| === mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down from 22:00 UTC until 23:00 UTC for a code update | Archive: open, MoM running, alpha-3: released | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/Helpi | ||
| thinkgnu | which one is better for my system (dual core2 , 1GB ram) ? kubuntu32 but or kubuntu64 bit ? | 20:41 |
| Riddell | thinkgnu: user questions in #kubuntu | 20:41 |
| thinkgnu | :D | 20:41 |
| === sabdfl1 is now known as sabdfl | ||
| * directhex smiles sweetly at tseliot and superm1, asks gently about nvidia 180.22 in intrepid | 21:00 | |
| tseliot | directhex: I'll work on it tomorrow | 21:01 |
| * directhex offers tseliot a muffin | 21:01 | |
| tseliot | directhex: keep an eye on https://bugs.launchpad.net/bugs/322416 | 21:01 |
| ubottu | Launchpad bug 322416 in nvidia-graphics-drivers-180 "update request: nVidia ver 180.25, stable" [Medium,In progress] | 21:01 |
| directhex | can't find 180.25 on nvidia.com :/ | 21:02 |
| directhex | at any rate, wanna be sure my new pc works, when i eventually get a fixed motherboard ;) | 21:03 |
| superm1 | tseliot, okay i pushed the GPM patch in, so that should be some improvement at least. thanks for writing it :) | 21:05 |
| tseliot | superm1: great, thanks | 21:05 |
| calc | slangasek: can you process suitesparse now, or does it have to be built on all archs (for the new processing bit) | 21:17 |
| calc | its still working on armel/hppa | 21:18 |
| charlie-tca | slangasek: bug 322497 | 21:44 |
| ubottu | Launchpad bug 322497 in linux-source-2.6.22 "gutsy 7.10 will not login after updating to kernel linux-source-2.6.22.16 *regression*" [Undecided,New] https://launchpad.net/bugs/322497 | 21:44 |
| charlie-tca | could not reproduce on two different systems with fresh installs | 21:44 |
| ScottK | charlie-tca: I'm having similar symptoms on 8.10 right now. | 21:48 |
| ScottK | charlie-tca: If you do a console login does df -k say there's no space left? | 21:48 |
| charlie-tca | I'll go look | 21:48 |
| charlie-tca | This just started on 7.10 after the latest kernel update | 21:49 |
| charlie-tca | ScottK: no, mine shows lots of space left; over 40% unused | 21:52 |
| ScottK | charlie-tca: And it shows block in the available column? | 21:52 |
| charlie-tca | yes | 21:52 |
| ScottK | OK. Then I've got a different problem. | 21:53 |
| charlie-tca | yeah, quick glance shows it about right, too | 21:54 |
| ScottK | Mine is basically no user level ability to write to disk because it thinks it's full. | 21:54 |
| ScottK | I can write as root and delete as user, but writes as user fail. | 21:55 |
| charlie-tca | I see. This is different. | 21:55 |
| ScottK | If anyone has thoughts on that, I'm all ears. | 21:56 |
| slangasek | calc: if I make it before the LP maintenance it can be, sure | 21:58 |
| calc | slangasek: ok | 21:58 |
| slangasek | kees: ^^ seen bug #322497? | 21:59 |
| ubottu | Launchpad bug 322497 in linux-source-2.6.22 "gutsy 7.10 will not login after updating to kernel linux-source-2.6.22.16 *regression*" [Undecided,New] https://launchpad.net/bugs/322497 | 21:59 |
| slangasek | charlie-tca: thanks, fixed up the bug state | 21:59 |
| calc | "Launchpad will be going offline for maintenance very very soon." lol | 21:59 |
| kees | slangasek: I'll check in a moment... doing kernel updates. ;) | 21:59 |
| slangasek | sure | 21:59 |
| charlie-tca | You're welcome. I hope there is enough there to count | 22:00 |
| kees | slangasek: will you be around after LP is back to do some pocket-copies for me? (kernel updates from -security to -updates) | 22:02 |
| slangasek | calc: should libsuitesparse-dev have a dep on libcolamd-3.2.0, given that it ships the .so for it? | 22:03 |
| slangasek | (it currently depends indirectly) | 22:03 |
| slangasek | calc: anyway, LP maintenance window hit before I got a chance to accept it; will try again in an hour | 22:04 |
| calc | slangasek: ok np | 22:28 |
| calc | slangasek: not sure wrt your question, i saw it was getting pulled in by libsuitesparse-3.2.0 already so just left it at that | 22:29 |
| calc | slangasek: apparently this will probably be fixed in debian soon as well, so we hopefully will be able to go back to syncing in the near future | 22:29 |
| * slangasek nods | 22:30 | |
| cody-somerville | slangasek, Hows that Xubuntu killing bug going? | 22:37 |
| slangasek | cody-somerville: it's been filed and the security team is in the loop | 22:38 |
| kees | slangasek: you've meaning 322497? | 22:40 |
| slangasek | yes | 22:41 |
| slangasek | charlie-tca: why are all of these vboxsf mounts happening at login time? | 22:49 |
| slangasek | charlie-tca: and I bet you don't have a virtualbox-ose modules package to match your kernel, because vbox isn't in main so didn't get updated with the kernel security release | 22:50 |
| slangasek | charlie-tca: also, please check for gdm output in /var/log/auth.log; the strace shows some of it being written, but it's truncated because I didn't ask you to use -s :) | 22:51 |
| charlie-tca | The virtualbox came direct, I ran /etc/init.d/vboxdrv setup to update it. | 22:51 |
| slangasek | ok | 22:52 |
| slangasek | [pid 4995] 07:36:56.235593 writev(2, [{"gdm[4995]: PAM adding faulty mod"..., 71}, {"\n", 1}], 2) = 72 | 22:52 |
| charlie-tca | I don't know why all the mounts happen at login | 22:52 |
| slangasek | that looks promising; pam_gnome_keyring.so is referenced but absent | 22:52 |
| charlie-tca | you're right about /var/log/auth.log | 22:54 |
| charlie-tca | let me get a copy out | 22:55 |
| charlie-tca | slangasek: added the auth.log to the bug report | 23:00 |
| slangasek | thanks | 23:00 |
| charlie-tca | Thank YOU. I know you are very busy | 23:01 |
| calc | how often do packages get put in the archive (eg ACCEPTED -> DONE)? | 23:01 |
| slangasek | charlie-tca: could you please confirm that 'grep pam_gnome_keyring /etc/pam.d/*' returns only 'optional' lines? | 23:01 |
| charlie-tca | how? | 23:02 |
| slangasek | charlie-tca: well, regressions in security updates are kind of a priority | 23:02 |
| slangasek | charlie-tca: run the command 'grep pam_gnome_keyring /etc/pam.d*', and tell me if there are any lines that don't say "optional" | 23:02 |
| === mthaddon changed the topic of #ubuntu-devel to: Archive: open, MoM running, alpha-3: released | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | this week: https://wiki.ubuntu.com/UbuntuDeveloperWeek | ||
| charlie-tca | slangasek: no lines at all | 23:03 |
| charlie-tca | nothing comes up | 23:03 |
| slangasek | er, oops, wrong command | 23:03 |
| slangasek | charlie-tca: grep pam_gnome_keyring /etc/pam.d/* | 23:03 |
| charlie-tca | slangasek: two lines, both with 'optional' | 23:04 |
| slangasek | ok | 23:04 |
| slangasek | so it doesn't appear to be an authentication failure | 23:04 |
| slangasek | charlie-tca: I notice that the PIDs from the logfile and from the strace don't match; I guess they're from two different tests? (it probably doesn't matter, just want to be sure) | 23:05 |
| charlie-tca | yes | 23:06 |
| cjwatson | calc: hourly | 23:06 |
| charlie-tca | I been in there so many times I got confused | 23:06 |
| slangasek | charlie-tca: the problem is in /etc/gdm/PostLogin/\:0 - could you send a copy of that file to the bug? | 23:11 |
| charlie-tca | slangasek: sure, let me get it. | 23:12 |
| slangasek | this is the script that's trying to do all of the vboxsf mounts; it's the only thing run between the 'session opened' and 'session closed' lines, and there are a lot of failures, with the script eventually exiting non-zero | 23:13 |
| slangasek | so this still points back to a vbox problem, ultimately | 23:13 |
| charlie-tca | slangasek: Oh, no. Do I just pull that and try to login, then? | 23:14 |
| charlie-tca | Oh, sent the :0 file to the bug report | 23:15 |
| slangasek | charlie-tca: you could try that, yes | 23:15 |
| slangasek | charlie-tca: alternately, you could change the 'exit' at the end of the script to an 'exit 0'... | 23:16 |
| calc | cjwatson: ok | 23:18 |
| charlie-tca | slangasek: I renamed the file, it did not allow the primary user to log in, but did allow another one. | 23:18 |
| charlie-tca | Is this all my fault, then? | 23:19 |
| cjwatson | calc: (this is aside from all the problems there've been specifically today of course) | 23:20 |
| slangasek | charlie-tca: well, as far as I can tell the login failures were the result of your local PostLogin script; but the reason for that script to start failing may still point to a regression that should be addressed | 23:20 |
| charlie-tca | I lied. wrong system | 23:20 |
| calc | cjwatson: ok, i see it got marked as done, i guess it takes a while after that for it to show up on archive.u.c? | 23:20 |
| slangasek | yes, it's marked as 'done' at the very beginning of the publisher run | 23:21 |
| cjwatson | calc: yes - the bug is closed at the ACCEPTED->DONE transition, but that's actually at the ... what slangasek said | 23:21 |
| calc | slangasek: ah i see :) | 23:21 |
| slangasek | and the publisher run lasts ~1h | 23:21 |
| charlie-tca | slangasek: I haven't changed that script in a very long time. | 23:21 |
| calc | well sometime tonight i should have new OOo in after its deps get finished anyway ;-) | 23:21 |
| slangasek | charlie-tca: sure. I think your virtualbox-ose setup is broken following the kernel ABI change, which may be an Ubuntu issue | 23:22 |
| slangasek | charlie-tca: did I understand you to say that you weren't using the virtualbox-ose packages from the archive...? | 23:22 |
| charlie-tca | slangasek: Okay, it does allow login with out the script. | 23:23 |
| * slangasek nods | 23:23 | |
| TheMuso | superm1: Re bug 32250, do you think that could have anything to do with the missing kernel hid quirk modules from the initramfs? I uploaded an initramfs-tools earlier to add the hid quirk modules. | 23:23 |
| ubottu | Launchpad bug 32250 in gnome-power-manager "g-p-m critical power warning states "will power-off" which is misleading" [Medium,Fix released] https://launchpad.net/bugs/32250 | 23:23 |
| TheMuso | sorry sorry bug 322506 | 23:23 |
| ubottu | Launchpad bug 322506 in busybox "Caps lock doesn't work in initramfs environment" [Undecided,New] https://launchpad.net/bugs/322506 | 23:23 |
| TheMuso | superm1: ^^ | 23:24 |
| cjwatson | caps lock has occasionally been a source of console-setup-related glitches | 23:24 |
| slangasek | charlie-tca: it should also allow login if you put the script back, but edit the last line to say 'exit 0' instead of 'exit'; that can be a permanent change to make the script more robust, then we can focus on debugging your vbox problem | 23:24 |
| cjwatson | is this consistent across keyboard layouts? | 23:24 |
| cjwatson | superm1: attaching /etc/default/console-setup would probably be a good thing, as well as confirming that that file is also present in the initramfs | 23:25 |
| charlie-tca | slangasek: I am running virtual peul. It is not virtualbox-ose | 23:25 |
| charlie-tca | virtualbox peul | 23:25 |
| charlie-tca | I installed it before virtualbox-ose was in the repositories, and the system has been upgraded to 8.04 | 23:25 |
| TheMuso | cjwatson: ah ok. | 23:27 |
| Hobbsee | hrm. Preseeding packages won't get their recommends, will it? | 23:27 |
| slangasek | charlie-tca: ok. what does 'lsmod | grep vbox' give you? | 23:30 |
| cjwatson | bug 281940 | 23:30 |
| ubottu | Launchpad bug 281940 in tasksel "Debian-installer can't be (and isn't) told not to install recommends by default." [Wishlist,Confirmed] https://launchpad.net/bugs/281940 | 23:30 |
| cjwatson | err, no, maybe not that one | 23:30 |
| charlie-tca | slangasek: nothing | 23:30 |
| slangasek | charlie-tca: output of find /lib/modules -name 'vbox*.ko', please | 23:31 |
| cjwatson | I'm sure there was a bug about allowing pkgsel/include to install recommends | 23:31 |
| cjwatson | oh, I can't find it because Timo fixed it :) bug 315363 | 23:32 |
| ubottu | Launchpad bug 315363 in pkgsel "add an option to install "Recommended" packages too" [Wishlist,Fix released] https://launchpad.net/bugs/315363 | 23:32 |
| cjwatson | Hobbsee: on jaunty, pkgsel/install-recommends=true tweaks it; on earlier releases, no | 23:32 |
| charlie-tca | slangasek: 2 lines, '/lib/modules/2.6.22-15-generic/misc/vboxvfs.ko' | 23:32 |
| slangasek | charlie-tca: the other line? | 23:33 |
| charlie-tca | '/lib/modules/2.6.22.14-generic/misc/vboxvfs.ko' | 23:33 |
| Hobbsee | cjwatson: ah, excellent, thanks. | 23:33 |
| charlie-tca | '/lib/modules/2.6.22-15-generic/misc/vboxvfs.ko' | 23:33 |
| slangasek | charlie-tca: yep. So, you need to rebuild your peul kernel module for the new kernel | 23:33 |
| charlie-tca | same line with -14 | 23:33 |
| slangasek | charlie-tca: presumably you had to do this before for the -14 -> -15 update | 23:34 |
| charlie-tca | I sure don't remember it, but you are most likely correct. | 23:34 |
| slangasek | charlie-tca: so it's not actually a regression in the linux security update, but the vbox folks should provide an updated virtualbox-ose-modules package for gutsy as well; I've fixed up the bug to reflect that | 23:35 |
| charlie-tca | Thank You. I'll go rebuild it then. | 23:35 |
| * Hobbsee invalidates a bug, claims it for 5-a-day | 23:36 | |
| * directhex opens 5 bugs for Hobbsee to close | 23:37 | |
| Hobbsee | directhex: darn you ;) | 23:37 |
| RAOF | Hobbsee: Like to add making f-spot installable with monodevelop, banshee, et al your next bug? | 23:46 |
| Hobbsee | RAOF: not overly, but nice try ;) | 23:46 |
| pwnguin | how 'bout eclipse 3.4? ;) | 23:47 |
| Hobbsee | not that crazy... | 23:47 |
| RAOF | All it needs is for you to apply a debdiff. Nice and simple :) | 23:49 |
| pwnguin | RAOF: speaking of closing bugs, what should we do about bugs against nv? | 23:50 |
| pwnguin | ask them to retest on nouveau? | 23:50 |
| RAOF | nv is still maintained by a guy at nVidia. | 23:50 |
| RAOF | Feel free to ask them to check on nouveau; that'd probably be useful/nice. | 23:51 |
| RAOF | But we're not replacing nv with nouveau for Jaunty. | 23:51 |
| pwnguin | does nv support anything nouveau doesn't? obviously it might be buggy, but that "guy at nVidia" seems to dislike features | 23:51 |
| pwnguin | so long term i'd imagine a replacement is going to happen. (certainly not for jaunty) | 23:52 |
| RAOF | "That guy at nvidia" really doesn't like features, no. | 23:52 |
| RAOF | nv probably supports some newer cards than nouveau does; nouveau apparently doesn't support nv9x chips at the moment. | 23:52 |
| slangasek | who can blame him, no good has ever come of features | 23:52 |
| slangasek | ;) | 23:52 |
| pwnguin | RAOF: if you have a nv9x chip, it's probably connected to a display that nv wont drive properly | 23:53 |
| * RAOF rather likes the fact that nouveau actually dithers for his laptop's 18bit LCD properly. | 23:53 | |
| pwnguin | but there's not really a point to debating this | 23:54 |
| pwnguin | im not arguing for the removal of nv | 23:54 |
| RAOF | Debating? Feel free to suggest people test nouveau. | 23:54 |
| RAOF | If it drives their card, it'll almost certainly be better than nv. | 23:54 |
| pwnguin | RAOF: what if a bug comes in against nv, is confirmed broken, the tester tries nouveau and drops nv entirely? | 23:55 |
| pwnguin | do we leave the bug open? | 23:55 |
| RAOF | I'd say yes. It's still a bug in nv, and nv is still our default nvidia driver. | 23:55 |
| pwnguin | i kinda wonder how often nv is used in practice | 23:56 |
| RAOF | Everytime someone with nvidia hardware loads a livecd, certainly. | 23:56 |
| pwnguin | good point | 23:56 |
| pwnguin | RAOF: perhaps an invitation to test should be published, so people know it's available? | 23:57 |
| RAOF | That sounds like a job for ReleaseNotes™ | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!