[12:09] <unfo> lifeless: sure, sounds fine.
[12:09] <unfo> And the personal web server wizard could even be accessible from the Applications menu.
[12:10] <unfo> It could also install nvu and/or phpbb and/or mediawiki.
[12:25] <Riddell> cjwatson: yesterday you said you'd made a seed change to ubuntu regarding ppd files, but I don't see any change from you in the ubuntu.feisty seed
[12:30] <unfo_> Would it be hard for me to write a spec for the above personal web server wizard idea?  Do you think people would like my spec?
[12:31] <pygi> unfo_: we've got something like that already, but I'm too sleepy to say something usable
[12:31] <pygi> unfo_: look for Ubuntu Instant Server Manager on ubuntu wiki
[12:33] <unfo_> cool, didn't know.  But how could I edit the spec to encompass my idea of autodetecting that the user just dropped a file in ~/public_html?
[12:33] <unfo_> Would the instant server manager have to watch that directory using FAM or Gamin?
[12:33] <unfo_> And what if it's not installed?
[12:34] <unfo_> Really we need a clippy (paperclip-like Assistant) in Ubuntu.
[12:41] <lifeless> unfo_: clippy must die
[12:41] <lifeless> unfo_: I hope you are joking
[12:43] <unfo_> lifeless: the problem with clippy in Word was that it popped up far too often.
[12:43] <lifeless> unfo_: no, the problem was that it existed
[12:44] <unfo_> lifeless: a better clippy would be an unobtrusive systray icon that only pops up when you do unusual things like saving files in ~/public_html when you have no webserver installed.
[01:09] <mirak>  isn't ubuntu supposed to have a ubuntu+2 developpement release soon ?
[01:10] <Burgwork> mirak: +2?
[01:12] <sladen> mirak: dapper is LTS, edgy is stable, fiesty is development
[01:14] <mirak> well I believe there should be a intermediate between stable and developpement
[01:14] <mirak> because I use linux for 5 years, and ubuntu since 2.
[01:15] <Burgwork> right, a "sid"
[01:15] <mirak> but the developpement version are too broken to have me want to even report bugs
[01:15] <sladen> sid is unstable as you'll get
[01:15] <rodarvus> mirak, as sladen pointed, there is lts (real stable), edgy, which is stable and feisty for pure development
[01:15] <mirak> edgy is not stable
[01:15] <mirak> I couldn't even boot LVM
[01:15] <Burgwork> edgy is stable
[01:15] <rodarvus> mirak, feel free to report bugs.
[01:15] <mirak> usb to serial module support is broken
[01:15] <sladen> mirak: that's a bug;  http://launchpad.net/distro/ubuntu/+filebug
[01:16] <mirak> rodarvus: problem is that I am sure there is more bug reports from ubuntu+0 than ubuntu+1
[01:16] <rodarvus> hrm
[01:16] <rodarvus> there is no ubuntu+0 or ubuntu+1. please use proper names :)
[01:16] <mirak> by not having a testing release I am sure ubuntu is cutting itself from a big bug reporters base
[01:16] <sladen> mirak: https://launchpad.net/distro/ubuntu/+source/linux-source-2.6.17/+filebug for the usb module
[01:16] <mirak> sladen: it's done
[01:17] <mirak> actually someone else did :)
[01:17] <sladen> mirak: can you confirm that you've experienced it aswell, 
[01:17] <mirak> sladen: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/39101
[01:17] <Ubugtu> Malone bug 39101 in linux-source-2.6.17 "Doesn't recognise USB Serial device" [Medium,Unconfirmed]  
[01:17] <mirak> this one yes
[01:17] <sladen> mirak: otherwise there's no way to judge the severity or validity of a bug report
[01:17] <mirak> well it's detected and reconised but it's broken
[01:18] <sladen> mirak: regarding 'testing', Ubuntu is in 'testing' for 3months out of every six months.  That is the time to jump in find bugs and get them fixed before release
[01:20] <mirak> mmm
[01:21] <mirak> but that puts us often away of using some new apps that use new libs
[01:21] <mirak> it's still frozen for six month :p
[01:23] <mirak> sladen: well for me edgy was far from usable 2 month before
[01:34] <sladen> mirak: sounds like the team could do with more help
[01:36] <minghua> edgy only has a four-month cycle so it's special
[01:36] <rodarvus> BenC, the current xorg-driver-fglrx package for amd64 is missing the X.Org driver (basically making the package useless :) )
[01:36] <rodarvus> are you aware of the problem, or would you prefer me to file a new bug on LP? (there is none on the subject, yet)
[01:36] <BenC> rodarvus: interesting...I'll check it out
[01:36] <BenC> what file is missing?
[01:37] <BenC> fglrx_drv.so?
[01:37] <rodarvus> yup
[01:37] <rodarvus> /usr/lib/xorg/modules/drivers/fglrx_drv.so
[01:40] <rodarvus> BenC, the differences are /usr/lib/xorg/modules/drivers/fglrx_drv.so, /usr/lib/xorg/modules/linux/libfglrxdrm.so and /usr/bin/fireglcontrolpanel (which are present on the old package only)
[02:03] <BenC> rodarvus: Can you test a rebuilt package?
[02:03] <rodarvus> BenC, sure
[02:04] <rodarvus> this particular machine is currently building a package, but should be done in 10 minutes most
[02:05] <BenC> rodarvus: Uploading to people.ubuntu.com:~bcollins/
[02:06] <BenC> rodarvus: It's 15461722 bytes, so keep an eye on it for when it's done
[02:06] <BenC> should be less than 2 minutes
[02:07] <rodarvus> BenC, nice, I'll report to you when I'm done with the testing
[02:07] <rodarvus> BenC, thanks!
[02:08] <BenC> rodarvus: no, thank you :)
[02:08] <BenC> if it works, I'll do a -2 upload shortly
[02:16] <crimsun> jdong: I have to presume it is a local fluke on your system; I tested on dapper and edgy systems
[02:20] <rodarvus> BenC, I can't find the package on p.o.c/~bcollins/
[02:21] <infinity> rodarvus: In his home dir, not http.
[02:21] <rodarvus> oh
[02:21] <rodarvus> infinity, thanks :)
[02:38] <rodarvus> BenC, fglrx_drv.so is on the wrong place (inside a fglrx_drv.so/ subdirectory), *and* libfglrxdrm.so is still missing
[02:38] <rodarvus> (essentially meaning X crashes on startup, if I move fglrx_drv.so to the right place)
[02:39] <BenC> ok
[02:39] <BenC> give me a minute to try again
[02:39] <rodarvus> sure
[02:47] <BenC> rodarvus: on it's way, 15470930 bytes
[03:01] <rodarvus> BenC, driver is working now, thanks!
[03:01] <BenC> rodarvus: thanks for testing!
[03:01] <BenC> uploading now
[03:02] <rodarvus> BenC, AIGLX is not working though (since the first 2.6.19, actually)
[03:02] <BenC> rodarvus: no idea why not
[03:02] <rodarvus> this is minor, and I suspect it might be related to version of Mesa
[03:02] <rodarvus> (hmm, or not)
[03:03] <BenC> what does glxinfo say?
[03:03] <rodarvus> do you plan to update the fglrx driver to 8.31.foo?
[03:04] <rodarvus> (this is on Xorg.0.log) (EE) AIGLX error: dlsym for __driCreatenewScreen_20050727 failed (/usr/lib/dri/fglrx_dri.so: undefined symbol: __driCreatenewScreen_20050727)
[03:04] <rodarvus> (EE) AIGLX: reverting to software rendering
[03:05] <rodarvus> BenC, glxinfo (actually fglrxinfo) just crashes
[03:06] <rodarvus> the right symbol name is __driCreateNewScreen_20050727, actually (I just pasted it manually from the other machine)
[03:10] <rodarvus> I'll be back in a minute
[03:14] <BenC> rodarvus: Do you have a link to a newer ati driver?
[03:16] <rodarvus> BenC, https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/64bit/ati-driver-installer-8.31.5-x86.x86_64.run and https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-8.31.5-x86.x86_64.run (supposing you create the tarball from this file)
[03:17] <BenC> thanks
[03:18] <rodarvus> BenC, thank YOU
[03:22] <keescook> BenC: woo! 2.6.19-6-generic #2 SMP  *dance*
[03:22] <BenC> nice
[03:31] <BenC> rodarvus: Want to test 8.31.5 packages?
[03:33] <rodarvus> BenC, sure
[03:47] <rodarvus> brb
[03:54] <rodarvus> BenC, fglrx 8.31.5 is working fine (including 3D)
[03:54] <BenC> sweet
[03:54] <BenC> even AIGLX?
[03:55] <rodarvus> no
[03:55] <rodarvus> and btw, disregard that message. it is relevant (for AIGLX, of course)
[03:55] <rodarvus> but not for 3D
[03:55] <rodarvus> it is still present
[03:55] <rodarvus> (the error message)
[03:55] <BenC> ok, so what is working and what isn't?
[03:56] <rodarvus> 3D works, Composite doesn't (but this is expected)
[03:56] <rodarvus> I will *try* to fix Composite for feisty, but there is a good chance it won't happen
[03:56] <rodarvus> might need collaboration from ATI people
[03:56] <lifeless> infinity: how can I tell if I have the right gl library ?
[03:57] <lifeless> I'm wondering if its easy to write a little validator scripts
[03:57] <lifeless> s/scripts/script/
[03:57] <BenC> rodarvus: How is this compared to edgy...equal or better?
[03:59] <rodarvus> BenC, same as edgy, I would say
[03:59] <BenC> rodarvus: excellent, thanks for testing again
[04:00] <BenC> cjwatson: ping
[04:00] <cjwatson> BenC: Please tell me what you want and I'll reply when I'm around.
[04:00] <rodarvus> version 8.31.5 of this driver is supposed to fix handling of various video boards, but mine used to work just fine on edgy, so I can't tell you it *really* fixes something
[04:00] <BenC> cjwatson: Is disk space ok for an lrm upload?
[04:09] <_ion> nvidia-glx | 1.0.9629+2.6.19.2-1 | http://archive.ubuntu.com feisty/restricted Packages
[04:09] <_ion> 9629 causes all OpenGL programs to segfault on NV2x hardware.
[04:11] <HrdwrBoB> NV2x is legacy isn't it?
[04:11] <_ion> Nope.
[04:21] <_ion> Bug #72805
[04:21] <Ubugtu> Malone bug 72805 in linux-restricted-modules-2.6.19 "nvidia-glx 1.0.9629 causes OpenGL programs to segfault on NV2x hardware" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72805
[04:34] <jdong> rodarvus: ping
[04:35] <jdong> rodarvus: when you get a chance take a look at bug 58721
[04:35] <Ubugtu> Malone bug 58721 in xserver-xorg-video-mga "Edgy upgrade breaks multiple Matrox cards" [Unknown,Unconfirmed]  http://launchpad.net/bugs/58721
[04:35] <jdong> rodarvus: the problem is fixed in Debian Sid's version... dunno how you want to handle getting that to Edgy though
[04:38] <rodarvus> jdong, if I'm not completely mistaken, sid is using a new upstream version (reasonably different from what we have in edgy)
[04:39] <jdong> rodarvus: that is correct
[04:39] <jdong> I recompiled the sid version under edgy and gave it to some of those guys to test
[04:39] <jdong> and they've all reported back success...
[04:39] <jdong> so whatever they done upstream they fixed that
[04:39] <rodarvus> its a regression, but I'll likely only do it if I can cherry pick the patch in question into our package, and test it for a good while on edgy-proposed
[04:39] <jdong> sounds like a lot of work :-/
[04:40] <rodarvus> jdong, I believe you, but a new upstream release (for edgy) is basically out of question, unfortunately :/
[04:40] <jdong> what about shoving the new upstream version into edgy-backports as an interim workaround?
[04:40] <jdong> it'd require a trivial patch against debian/control to tweak a dependency
[04:40] <rodarvus> this could be an option, indeed
[04:40] <jdong> but otherwise works
[04:41] <jdong> first it'd need to be synced to feisty though
[04:42] <jdong> rodarvus: would you be willing to do it that way?
[04:43] <rodarvus> jdong, sure, that can be done. its not a *high* priority thing (I want to finish drafting of two specs and update of X.Org for 7.2 on feisty, before I do anything else)
[04:44] <rodarvus> jdong, but I appreciate if you add this information into the bug report (or create a new one), and subscribe me to it
[04:44] <jdong> rodarvus: I believe it's already on the bug report
[04:45] <jdong> rodarvus: at your leisure I need you to ACK a sync of sid's version to Feisty
[04:45] <jdong> and then we can move forward from there
[04:46] <rodarvus> jdong, X.Org 7.2 breaks ABI (again :) ), I was planning to hold syncs/merges until we have the xserver ready
[04:46] <jdong> ah, I see
[04:46] <rodarvus> but if its really urgent, as you say, we can hurry it, and rebuild later
[04:47] <jdong> rodarvus: I'd prefer to see this addressed... a lot of users are affected
[04:47] <rodarvus> but note that a sync from sid will *not* work, btw :)
[04:47] <jdong> rodarvus: huh?
[04:47] <rodarvus> it will need to be a manual new upstream release
[04:47] <jdong> ah, ok
[04:47] <jdong> pardon my unfamilarity with development policy :)
[04:48] <rodarvus> jdong, sid added new dependency tracking, after we froze X for edgy
[04:48] <rodarvus> we'll have to deal with that, before we are able to sync/merge drivers
[04:49] <jdong> rodarvus: new dependency tracking?
[04:50] <jdong> the only thing I noticed was that xserver-xorg-{core,dev} deps needed its epoch bumped down to 1
[04:52] <rodarvus> exactly, and that means we can not sync from sid.
[05:02] <jdong> ok, I get what you're saying
[06:53] <viviersf> BenC, ping
[06:53] <BenC> viviersf: pong
[06:53] <BenC> viviersf: on the way to bed, just so you know :)
[06:53] <viviersf> BenC, kay
[06:54] <viviersf> BenC, was just wondering how would i go about getting the kernel guys to add 3G drivers to the restricted modules
[06:54] <BenC> viviersf: you file a bug report against linux-restricted-modules-2.6.19 with all the info you have and we'll check it out
[06:55] <viviersf> BenC, k kewl thx
[07:18] <TheMuso> c
[07:21] <cjwatson> Riddell: my branch seems to have unbound on me; I'll sort it out
[07:22] <cjwatson> BenC: lrm should be fine
[07:39] <cjwatson> Riddell: fixed now; sorry about that
[07:50] <mnepton> cjwatson: are you awake early, or insanely late?
[07:51] <cjwatson> mnepton: early; may go back to bed for a bit
[07:53] <StevenK> cjwatson: Can I bug you to look at the wlassistant SRU, or should I wait until you get up again?
[07:54] <cjwatson> StevenK: probably when I get up again would be better. I got through about half the pending SRUs yesterday.
[07:54] <StevenK> cjwatson: Shall I remind you, or just exercise patience?
[07:58] <cjwatson> StevenK: it's on https://launchpad.net/people/ubuntu-sru/+subscribedbugs, which is open in my browser, so you probably only need to remind me if it isn't done in say 12 hours' time
[07:58] <StevenK> cjwatson: Okay, sounds fine.
[07:59] <dholbach> good morning
[07:59] <_ion> Good evening.
[08:00] <mvo> good morning dholbach
[08:00] <dholbach> hey mvo
[08:25] <_ion> I took a look at the xorg roadmap; apparently the input hotplug functionality is going to be included in 7.3 (released 2007-05). Will the functionality be patched to the feisty xorg? According to https://bugs.freedesktop.org/show_bug.cgi?id=971, it's already implemented and merged into the 7.3 development repository.
[08:25] <Ubugtu> Freedesktop bug 971 in Input/Core "Input device hotplug" [Enhancement,Resolved: fixed]  
[08:42] <Riddell> cjwatson: how do you decide if a programme should be marked as recommends instead of depends in the seeds?
[09:22] <cjwatson> Riddell: judgement call based on whether you believe it should still be called the "Kubuntu desktop" (or whatever) if people remove it
[09:24] <Riddell> that makes sense
[09:24] <dholbach> hey sivang
[09:24] <dholbach> sivang: did you do the tray transparency patch for ekiga?
[09:28] <Fujitsu> cjwatson: I've uploaded maxima (the second half of bug #43150's fix) to dapper-proposed, and it's awaiting approval. It's just a rebuild, so can you please let it through?
[09:28] <Ubugtu> Malone bug 43150 in gcl "[SRU]  maxima frontends fail to connect" [Undecided,In progress]  http://launchpad.net/bugs/43150
[09:50] <Riddell> mvo: could you look over kubuntu-feisty-language-selector for approval?
[09:51] <mvo> Riddell: sure
[09:59] <slomo> cjwatson: hm, are you already finished with the open syncs? in that case you missed some of mine, banshee, banshee-official-plugins, ipod-sharp and libipoddevice :(
[10:01] <Mithrandir> slomo: the archive team will get to the syncs as soon as possible; please don't nag people about it.  Assuming the archive team is subscribed, they won't be lost.
[10:03] <cjwatson> slomo: correct.
[10:04] <cjwatson> slomo: I know I didn't do all of them.
[10:05] <slomo> cjwatson: ok, sorry...
[10:18] <TheMuso> c
[10:18] <Keybuk> as if my body clock and general sense of what day it is wasn't screwed up enough, LWN has come out a day early!
[10:22] <minghua> I think they announced that in the previous issue (due to Thanksgiving)
[10:24] <pygi> Keybuk: anything libburn related? :P
[10:24] <elkbuntu> minghua, that is what they want you to think. It was purely to confuse Keybuk, no other purpose at all ;)
[10:28] <minghua> :-)
[10:29] <pygi> elkbuntu: hehe
[10:58] <mvo> Keybuk: ok for me to do the cdrdao merge (you touched it last)?
[10:58] <Keybuk> mvo: sure
[10:59] <mvo> thanks
[11:01] <pygi> mvo: we've got some merge? new version?
[11:01] <crimsun> Keybuk: should we be fixing initscripts in feisty to use upstart syntax? If so, are there guidelines?
[11:02] <mvo> pygi: merge from the debian version, nothing exciting (1.2.1->1.2.2)
[11:03] <pygi> mvo: ah, oki. 
[11:03] <pygi> Keybuk: do you perhaps know how cdrkit bits are starting to sync?
[11:03] <pygi> or rather, have they started to sync ? 
[11:05] <Keybuk> crimsun: packages in main will be using upstart job definitions instead of initscripts, but there are no guidelines yet
[11:05] <Keybuk> pygi: cdrkit needs the cdrecord ubuntu patch applied
[11:06] <crimsun> ok, thanks.
[11:08] <pygi> Keybuk: aha, oki ... 
[11:08] <Amaranth> So, uh, is the idea to drop cdrecord and mkisofs in feisty?
[11:09] <pygi> Amaranth: in favor of cdrkit, for whatever it's worth it 
[11:09] <cjwatson> mkisofs is needed by our CD build tools
[11:09] <pygi> cjwatson: mkisofs is still there ...
[11:09] <cjwatson> yes I know
[11:10] <Keybuk> is mkisofs even in feisty? :p
[11:10] <pygi> tho cdrkit won't receive many updates :P
[11:10] <cjwatson> but I mean that in order for it to be dropped from main in favour of genisofs or whatever from libburn, genisofs needs to be able to replace it
[11:10] <Amaranth> according to synaptic mkisofs has fallen out of feisty
[11:10] <Keybuk> Amaranth: right.  it'll appear again when cdrkit is uploaded
[11:10] <pygi> cjwatson: I know, we are not talking about replacing with anything yet ^_^
[11:10] <mjg59> Keybuk: Had a chance to test the compiz patch?
[11:10] <Amaranth> ah
[11:10] <Keybuk> cdrkit is a GPL version of cdrecord
[11:10] <Keybuk> mjg59: I don't have a patch from you
[11:10] <mjg59> Keybuk: Still?
[11:11] <cjwatson> pygi: won't receive many updates> good, as far as I'm concerned :) HFS+ support is the only thing I want; aside from that I'd rather that it weren't a moving target ...
[11:11] <Keybuk> mjg59: it could be in the spam bin, or your mail server could be refusing to talk to mine?
[11:11] <mjg59> Keybuk: I sent it to your canonical address
[11:11] <pygi> cjwatson: I know ^_^ You'll get hfs+ in libisofs ;)
[11:11] <Keybuk> ah, so could be just in the spam bin then
[11:11] <pygi> cjwatson: it's not that they wouldn't like to update cdrkit with new features and things, they just can't :)
[11:11] <mjg59> Message-ID: <20061117212419.GA5385@srcf.ucam.org>                               
[11:11] <Keybuk> pygi: why can't they?
[11:11] <pygi> cjwatson: no one is able to mess with that sort of code ^_^
[11:12] <pygi> Keybuk: look above :)
[11:12] <Keybuk> pygi: you give no reasons for why
[11:12] <pygi> Keybuk: Debian people know that they cannot actually keep the fork...
[11:12] <Keybuk> why do they know?
[11:12] <pygi> well, because it makes them look bad :)
[11:12] <Keybuk> why does it?
[11:13] <pygi> they are taking bits from Joerg commits which are under gpl, and apply it to cdrkit/wodim source
[11:13] <Keybuk> right
[11:13] <Keybuk> entirely reasonable given that Joerg is a Class-A fuckwit
[11:13] <pygi> no new features or anything, no own work ... nobody can mess with level of such class, low-level scsi, things ...
[11:13] <pygi> Keybuk: true, but Joerg has some valid concerns
[11:13] <Keybuk> why can't they mess with it?
[11:13] <Keybuk> it's easy
[11:13] <pygi> Keybuk: linux kernel does have it's limitations when it comes to burning
[11:14] <pygi> Keybuk: it's easy? wow :P
[11:14] <Keybuk> fortunately the Linux kernel is also open source, so those can be fixed
[11:14] <mjg59> I don't think this conversation is going anywhere useful
[11:14] <Keybuk> it doesn't seem to have hampered burning on Linux to date though
[11:14] <pygi> Keybuk: you really think so? Can I assign you a task of implementing dvd recording in libburn? :)
[11:14] <pygi> mjg59: as always :P
[11:14] <Keybuk> use dvd+rw-tools?  WFM
[11:14] <pygi> Keybuk: that's a fork of cdrecord ^_^
[11:15] <Keybuk> I'm still entirely missing your point
[11:15] <cjwatson> ... and thus somebody clearly managed to hack on it
[11:15] <pygi> no point :P
[11:15] <Keybuk> burning must be possible under Linux, because there are tools to do it
[11:15] <Keybuk> also it can't be that hard, given other people have managed to maintain those tools
[11:15] <pygi> Keybuk: two people have managed to maintain these tools
[11:15] <cjwatson> honestly you're just coming across as a competitor
[11:15] <pygi> Joerg and Andy ...
[11:15] <cjwatson> which is fair enough, since you *are*, but still
[11:16] <Keybuk> are you saying that you weren't able to figure it out?
[11:16] <pygi> Keybuk: mkisofs code is such a mess that I even refuse to read that for example
[11:16] <pygi> cjwatson: I havent mentioned libburn in not even a word in this discussion. And it's not about libburn at all...
[11:16] <Mithrandir> pygi: that's hardly relevant if you just look at the kernel interfaces.
[11:17] <cjwatson> 10:11 < pygi> Keybuk: you really think so? Can I assign you a task of implementing dvd recording in libburn? :)
[11:17] <pygi> cjwatson: well, 'cause he said it's easy :)
[11:17] <mjg59> Keybuk: Any sign of that mail? If not, I'll just stick the patch on the web
[11:17] <cjwatson> mkisofs is not pretty, but it's comprehensible. If I had the time I would be entirely able to mess with it for HFS+ support - I just don't have the time
[11:17] <Keybuk> mjg59: yup, found it in the spam bin
[11:17] <pygi> and still, only two people in linux history have managed to maintain that kind of tools :)
[11:17] <mjg59> Keybuk: Ah, good
[11:18] <Mithrandir> the little hacking I've done on mkisofs wasn't that hard, really.
[11:18] <mjg59> Keybuk: If you could give that a go and get back to me about whether it seems to work, that would be great
[11:18] <Keybuk> mjg59: will give it a go in a bit
[11:18] <Keybuk> mjg59: btw, does this work on nvidia-glx ?
[11:18] <cjwatson> pygi: I'd honestly prefer if you stopped bashing on the competitors and put the same effort into writing better code. :)
[11:18] <Keybuk> pygi: so you can't maintain those kinds of tools?
[11:18] <Keybuk> pygi: this doesn't bode well for libburn
[11:18] <mjg59> Keybuk: Note that, right now, gnome-keybinding-properties disables the wm shortcuts editing if you're not running metacity
[11:18] <mjg59> That's something that needs fixing in gnome-keybinding-properties
[11:19] <mjg59> Keybuk: Yes, that's what I did the packaging on. Needs a 9000-series driver, though
[11:19] <pygi> Keybuk: you don't get my point ...
[11:19] <Keybuk> mjg59: we don't have that in edgy
[11:19] <Keybuk> pygi: clearly
[11:19] <pygi> cjwatson: I don't see cdrkit as competitors, but whatever
[11:19] <mjg59> Keybuk: We're not targetting edgy
[11:20] <mvo> cjwatson: ok for me to merge brltty (you touched it last)?
[11:20] <Keybuk> pygi: the point I'm hearing from you is "I'm not intelligent enough to do this, so I don't think anyone else is either"
[11:20] <pygi> Keybuk: you hear it wrong :)
[11:20] <Keybuk> mjg59: ah, duh :p
[11:20] <Keybuk> pygi: then what is your point?
[11:20] <pygi> Keybuk: nothing, lets just forget it :)
[11:20] <siretart> that cdrecord/cdrkit is nonfree as in probably not redistributable?
[11:20] <highvoltage> pygi: perhaps you should just type it out from A-Z in an e-mail
[11:20] <Keybuk> siretart: cdrkit is entirely free
[11:21] <siretart> Keybuk: you wish
[11:21] <Keybuk> that's kinda the point
[11:22] <siretart> from what I hear from zomb/ganneff they still seem to have many problems with the additional restrictions that are on the cdrecord source
[11:22] <cjwatson> mvo: sure - I was just backporting a change from unstable
[11:22] <cjwatson> if Ganneff thinks cdrkit is non-free, he's entirely capable of removing it from main himself
[11:23] <mjg59> siretart: http://svn.debian.org/wsvn/debburn/nonameyet/?rev=405&sc=1
[11:23] <siretart> well, they are currently still negotiating
[11:23] <cjwatson> given that he's an ftpmaster
[11:23] <mjg59> So, situation resolved
[11:23] <siretart> mjg59: interesting. thanks for that link
[11:24] <Amaranth> mjg59: Was your patch to add compiz keybindings to gnome-keybinding-properties?
[11:25] <mjg59> No
[11:25] <mjg59> It was to make compiz use the metacity gconf keys
[11:26] <Amaranth> ah
[11:27] <Amaranth> what about all the others compiz has?
[11:27] <cjwatson> StevenK: if the previous one has already been dealt with, please open a new one
[11:27] <Amaranth> for zoom, scale, etc
[11:27] <StevenK> cjwatson: It hasn't, which is why I'm wondering.
[11:27] <cjwatson> StevenK: just ignore it; pre-UVF we don't care
[11:27] <cjwatson> we just sync whatever's current
[11:28] <StevenK> Sure.
[11:28] <Keybuk> StevenK: what package?
[11:28] <StevenK> Keybuk: hat
[11:28] <mjg59> I'm ignoring the keybinding-properties stuff for now
[11:28] <Amaranth> mjg59: hehe, that's actually the part i'm most interested in for beryl
[11:28] <mjg59> Well, it's not difficult to implement at all
[11:29] <mjg59> Just list the keys that you want to be modifiable
[11:29] <StevenK> hat just makes me think of the leader of the Guild of Musicians from Soul Music by Pratchett.
[11:29] <Amaranth> yeah, the code is pretty simple
[11:29] <mjg59> The sad thing is that the design is somewhat non-scalable
[11:29] <Amaranth> heh
[11:30] <Amaranth> don't add lots to it ;)
[11:31] <Amaranth> mjg59: I'm guessing you've run into the fun bug that happens when you suspend while running compiz?
[11:33] <mjg59> No
[11:33] <mjg59> What fun bug?
[11:34] <Amaranth> With the nvidia driver you resume to a black screen because the driver doesn't restore the gl context or some such thing
[11:34] <Mithrandir> Amaranth: doesn't restore textures.  Iz nvidia bug, buy a better graphics card.
[11:34] <Amaranth> actually i think only the intel driver does it right
[11:35] <mjg59> nvidia binary driver in "shit" shocker
[11:35] <Amaranth> Mithrandir: it's a laptop :P
[11:35] <cjwatson> StevenK: I was confused by your comment about the Conflicts in that bug
[11:35] <Mithrandir> Amaranth: *shrug*; not much we can do about binary-only drivers.
[11:35] <mjg59> I'm afraid I don't care about whether there are suspend/resume issues with the nvidia binary driver.
[11:35] <Amaranth> mjg59: Basically you have to kill compiz/beryl and then load it again on resume
[11:35] <cjwatson> StevenK: you said that the Conflicts change could be dropped because the version in feisty still satisfied the conflicts; but doesn't that mean we need to keep the Conflicts versioning change to avoid breakage?
[11:35] <Amaranth> mjg59: pretty sure the ati driver has this problem too
[11:36] <mjg59> No, nvidia have to fix their drivers
[11:36] <cjwatson> StevenK: (or else sync/merge the other package first)
[11:36] <mjg59> I'm happy to work on the ATI ones
[11:36] <Amaranth> it did in edgy anyway
[11:36] <mjg59> Though I don't actually have any hardware with useful ATI chipses...
[11:37] <StevenK> Gah. And Launchpad is 503 at the moment.
[11:37] <Amaranth> I wonder what SLED does to work around the problem
[11:37] <Mithrandir> Amaranth: probably kills and reloads compiz.
[11:37] <Amaranth> Mithrandir: Err, I would think XGL would have the same problem
[11:38] <Mithrandir> yes, of course.
[11:38] <Keybuk> Amaranth: probably nothing; I'm not aware of resume being in their priorities
[11:38] <Amaranth> can't really kill it
[11:38] <Amaranth> Keybuk: oh, i suppose
[11:38] <Amaranth> workstation and all that
[11:39] <StevenK> cjwatson: Oh right, because of the Conflicts in 2.05-{5,6} is (<< 2.04-1) which still basically does what the package in edgy did.
[11:40] <cjwatson> but:
[11:40] <cjwatson> libghc6-hat-dev | 2.04-0ubuntu4 | feisty/universe | amd64, i386, ia64, powerpc, sparc
[11:40] <cjwatson> StevenK: so your proposal means that it'll conflict when it previously didn't, surely?
[11:40] <cjwatson> oh, except that that package comes from the hat source package
[11:41] <cjwatson> StevenK: ok, never mind, I guess it'll work once synced
[11:41] <StevenK> Yup.
[11:41] <StevenK> cjwatson: I tested the upgrade path of the package from edgy, it worked.
[11:42] <StevenK> cjwatson: It's fine.
[11:44] <cjwatson> I suppose I ought not to try supermirror pushes while LP is down
[11:44] <StevenK> Heh
[11:44] <cjwatson> mind you, pulls seem to work just fine
[11:49] <cybervegan> hello guys. i've got a question about mono in the light of the MS/Nov deal and the fact that java is now GPL...
[11:52] <mjg59> cybervegan: We've had a functional GPLed implementation of Java for some time
[11:54] <cybervegan> mjg59, yes, i understand that (tho i've had hassles with getting it working in the past) but i'm more interested in the stance on mono now
[11:54] <mjg59> What stance? It's in main, we ship software that uses it
[11:55] <mjg59> The presence or absence of Java doesn't change that
[11:56] <Keybuk> mono is in fact in our default install
[11:56] <cybervegan> mjg59, i'm a keen ubuntu user, currently running dapper on quite a few machines
[11:58] <cybervegan> microsoft is making nasty noises about their "ip" - sort of implicating mono, not being specific enough as usual, so as to create FUD
[11:59] <Keybuk> we have no fear, we're entirely certain in our steps and move forward without any doubt :)
[11:59] <mjg59> cybervegan: If we believe that we (or our users) are likely to be sued, we won't ship an item of software.
[11:59] <cjwatson> cybervegan: we'll deal with it if and when it becomes definite
[11:59] <cjwatson> cybervegan: but we aren't going to be scared off by FUD
[11:59] <Keybuk> interestingly, in this case, MS would likely have to sue Novell as the authors of Mono
[12:00] <Keybuk> their patent licence games can't apply, because they explicitly didn't grand the licence to Novell, just Novell's users
[12:00] <Keybuk> it's all very silly really
[12:00] <cybervegan> hmm. in the uk we are of course "immune" from the broken us patent system
[12:00] <cybervegan> ok, but that's me (notwithstanding the above)
[12:01] <cybervegan> or rather, i'm not a suse customer, and ballmer has been quoted as effectively saying we should watch our backs...
[12:02] <Keybuk> I actually did wonder what would happen if Canonical bought a Novell product
[12:02] <Keybuk> would we become their customers, and thus protected by it
[12:02] <cybervegan> there's also the notion that by using and distributing mono, you might be considered customers also
[12:02] <cybervegan> being "downstream" so to  speak
[12:03] <Fujitsu> cybervegan: I'm sure it is worded such that it doesn't apply to the entirety of their downstream.
[12:03] <highvoltage> Keybuk: it would be funny if caconical could buy one copy of SUSE and gain immunity :)
[12:04] <cybervegan> hmm. not sure it would fly tho
[12:04] <cybervegan> what about the possibility of division within the community - Novl/rest of world, or US/rest?
[12:06] <cjwatson> I don't think it's useful to speculate until something concrete happens
[12:07] <cjwatson> that only means the FUDders are winning by distracting us
[12:08] <cybervegan> i'd say the opposite - it's worth trying to work out what the next move might be... maybe that's an issue for more "user" types like me to ask then?
[12:08] <Mithrandir> cybervegan: it's not like anybody is going to be dragged off to court without warning.
[12:09] <cybervegan> true, but i'm wondering about the wider implications, and wanted to get a handle on the views of my favourite distro
[12:09] <cybervegan> the MS/Novl deal stinks to high heaven in my eyes
[12:10] <cybervegan> or should that be nose? :-D
[12:12] <cjwatson> more often than not this sort of thing doesn't come to anything, and by focusing on it people get all het up and worried, often unnecessarily
[12:12] <mjg59> MS has been able to sue us for patent infringement in the past. The deal didn't change that. There were various things in place in order to discourage that, and they're still in place.
[12:12] <cjwatson> as Mithrandir says, if it comes to something, we'll have due warning
[12:13] <mnepton> cybervegan: you're getting panicked about a devil MS painted on your wall. and in doing so, handing them a victory. just move ahead doing what you do, and trust that people that understand the landscape are making correct decisions. IOW, "do not panic."
[12:13] <Mithrandir> once you _do_ need to panic, you'll have plenty of time.
[12:13] <mnepton> and plenty of company.
[12:13] <cybervegan> so you aren't worried right now, that's good... i'm not likely to stop using ubuntu, and no - i'm not panicing
[12:14] <Keybuk> interesting
[12:14] <Keybuk> gnome-screensaver activating during upgrade = bad
[12:14] <cybervegan> guys thanks for your input, i've got to go now
[12:15] <cybervegan> oh, and thanks for ubuntu too
[12:15] <cjwatson> cybervegan: I think "watching with interest" is a fair characterisation of our position
[12:15] <cjwatson> you're welcome :-)
[12:15] <mnepton> cjwatson: sorta like slowing on a motorway to see an accident's aftermath ;)
[12:16] <cybervegan> i'll be back when there have been some more developments no doubt! keep it up guys :-D
[12:19] <Keybuk> mvo: consider yourself spanked!
[12:19] <Hobbsee> mvo: you're not supposed to admit that in a public channel with Keybuk in it.
[12:20] <mnepton> not to self: to get a free Keybuk spanking ....
[12:20] <mnepton> +e
[12:20] <Hobbsee> as to why you'd *want* one though....
[12:21] <mnepton> Hobbsee: deep-seated personal issues.
[12:22] <Hobbsee> so it seems.
[12:23] <Treenaks> (and a pony)
[12:23] <Hobbsee> *definetly* some deep-seated personal issues there.
[12:39] <Mithrandir> http://www.joelonsoftware.com/items/2006/11/21.html is interesting; both from a gnome HIG p-o-v as well as an idea for simplifying the logout dialog further.
[12:40] <thom> Mithrandir: i posted that about 16 hours ago :-)
[12:40] <Mithrandir> thom: I didn't see that. :-)
[12:41] <mjg59> I disagree with it in one major respect
[12:41] <mnepton> no ponies?
[12:41] <mjg59> The distinction between "I'm going away now but I want applications to continue running" and "I'm going away now but don't care if my applications carry on running" is important
[12:41] <mjg59> From a practical level, we can't implement it because suspend/resume isn't sufficiently reliable
[12:42] <Mithrandir> so "log out" vs "slumber" (which starts with screen lock, then sleep, then hibernate)
[12:42] <Mithrandir> ?
[12:42] <mjg59> Yeah
[12:43] <Ng> perhaps rather than use terms like "suspend" and "hibernate", it should talk in terms like "light sleep"/"deep sleep". they don't tell the user what it going to happen (like now), but they do at least tell you a little more about how involved the process is
[12:43] <bhale> that would seem easier as 2 menus, or 1 menu with a seperator
[12:43] <Mithrandir> sorry, slumber vs lock screen.
[12:43] <bhale> than two dialogs as in upstream gnome
[12:43] <bhale> if i dont like the menu im in i move the mouse up a few px
[12:49] <Keybuk> or just have a "Sleep" option
[12:49] <Keybuk> or even call it "Standby"
[12:49] <Keybuk> and use "suspend" for things like the lid switch, and not expose it directly
[01:13] <Riddell> lifeless: I've made https://code.launchpad.net/people/ubuntu-core-dev/+branch/hwdb-client/trunk
[02:04] <sivang> dholbach: don't recall, could be :)
[02:05] <dholbach> sivang: because the debian maintainer asked where it was from
[02:05] <dholbach> sivang: kilian@debian.org - if you want to get in touch with him
[02:05] <sivang> dholbach: well, he could get the source and just take the patch no? ;)
[02:06] <dholbach> it'd be good if the patch would go upstream
[02:06] <sivang> dholbach: sure
[02:06] <sivang> dholbach: ttl when you're back
[02:07] <dholbach> alrighty *wave*
[02:39] <pitti> bwah, only 1024x768 with the 2.6.19 l-r-m nvidia???
[02:41] <gnomefreak> pitti: i have a full range (its a hacked xorg.conf file though because ubuntu doesnt detect my refresh rates properly
[02:53] <dudanogueira> does texas instrumments card reader 5x1 works on ubuntu or linux in general? i googled, but without sucess :(
[02:54] <Treenaks> dudanogueira: if it's usb, probably
[02:54] <Treenaks> dudanogueira: if it's built-in in a laptop, maybe, but don't count on it
[02:54] <dudanogueira> Treenaks, toshiba built in
[02:55] <Treenaks> No clue
[02:55] <dudanogueira> sniiiif :)
[03:28] <jelkner> sobby appears to be broken in dapper.  does anyone know anything about this?
[03:47] <Solarion> ello
[03:58] <bddebian> Heya
[04:30] <dade`> BenC: will mactelpatches be in -7 ?
[04:34] <rodarvus> dade`, I'm curious about what are the mactel patches, specifically?
[04:35] <dade`> patches for intel-based macs
[04:35] <Mithrandir> that was kinda obvious
[04:36] <jdong> lol
[04:36] <rodarvus> :)
[04:37] <rodarvus> dade`, thanks for the helpful answer!
[04:37] <dade`> rodarvus: do you want more details ?
[04:38] <rodarvus> that was the original question, yes. but don't worry.
[04:39] <jdong> rodarvus: 10 bucks he's gonna tell you mactels are macs with intel chips ;-)
[04:40] <rodarvus> jdong, he already did so, actually :)
[04:40] <jdong> oh hah he did!
[04:40] <jdong> wow I'm awake this morning
[04:40] <_TomB> are there many problems with Ubiquity and Edgy?
[04:41] <jdong> _TomB: it's worked pretty well for me... better than 6.06's initial ubiquity that's for sure
[04:41] <_TomB> Hmm, well I released nUbuntu, and Ubiquity is failing to install grub for people
[04:41] <jdong> interesting...
[04:42] <jdong> well, I'm no ubiquity expert... so I'll let those guys answer your question
[04:42] <jdong> the only time(s) ubiquity failed to install grub on me were with XFS
[04:45] <frenkel> does anybody know why there is no build directory in  /lib/modules/2.6.17-6-generic-xen0/?
[04:46] <Vixus> Is there a reason why I cannot enter the #ubuntu channel?
[04:47] <dade`> no, a mactel is an intel chip with a macintosh around.
[04:49] <mjg59> A Mactel is something that's almost, but not quite, PC compatible and has a bunch of extra hardware on the side
[04:50] <mjg59> Other than its grossly awkward firmware, there's not a great deal of special handling required
[04:50] <dade`> mjg59: ha, I got you!
[04:50] <mjg59> Sadly, I now have to go and torture fruitflies
[04:51] <zul> mmm...torture
[04:51] <dade`> mjg59: can you tell me if your macbook sleeps with piix module ?
[04:51] <mjg59> I don't have a macbook
[04:52] <mjg59> But I know that Macbooks have suspended and resumed fine, and we've never provided ata_piix with pata support enabled (well, until recently), so yes
[04:53] <dade`> hmm, ok.
[04:53] <Keybuk> who merged coreutils?
[04:54] <Keybuk> mvo: congrats
[04:54] <Keybuk> you're the first person to make feisty not boot <g>
[04:55] <zul> yay mvo
[04:55] <mvo> Keybuk: *urg*
[04:55] <Keybuk> mvo: we had a patch to make coreutils not error with "cp -a -f" and a special file already existing
[04:55] <Keybuk> note, "had"
[04:56] <Keybuk> Nov 22 15:50:54 rcS: cp: cannot create special file `/dev/null': File exists
[04:57] <mvo> Keybuk: I haven't dropped a patch during the merge - let me check what happend
[04:57] <Keybuk> you say you "Updated" it ?
[04:58] <Keybuk> 60_ubuntu-force-clobber-specials.patch
[04:58] <mvo> Keybuk: I updated it so that it applies again
[04:59] <mvo> Keybuk: I'm checking it now
[04:59] <Keybuk> I'm just glad it's not me first this time :)
[04:59] <Keybuk> obviously I'll be making feisty not boot a lot later
[04:59] <Keybuk> but it's nice not to be the first
[05:01] <jdong> Keybuk: isn't upstart gonna take full effect in feisty? ;-)
[05:02] <Keybuk> that's the lack-of-a-plan yes
[05:02] <jdong> sounds like fun :)
[05:03] <jdong> btw does anyone have any good advice on compiling grsec kernels?
[05:03] <jdong> i.e. like I shouldn't have just selected HIGH without looking?
[05:03] <Keybuk> jdong: bluefoxicy probably would help
[05:06] <zul> has anyone merged grub yet?
[05:11] <smallfoot-> if anyone know a hardware company that done something good or bad such as cooperate with open source or anti-competive, please add it to http://vendors.bluwiki.org/
[05:14] <cjwatson> _TomB: I need details
[05:16] <jdong> ok, maybe I did overdo it
[05:16] <jdong> ps aux shows my own bash and that's about it :D
[05:24] <iwj> seb128: AYT?  I wanted to talk to you about the g-a-i codec installation stuff.
[05:31] <fabbione> mvo: how badly broken?!?
[05:31] <mjg59> Keybuk: Had a chance to test that diff?
[05:31] <Keybuk> mjg59: my machine doesn't boot atm :)
[05:31] <Keybuk> fabbione: boot will fail
[05:32] <fabbione> Keybuk: thanks
[05:32] <mjg59> Keybuk: Ah
[05:32] <fabbione> Keybuk: i reverted the waiting raids at boot in mdadm. we need to sort out the udev stuff...
[05:32] <fabbione> Keybuk: what about tomorrowi'sh?
[05:32] <Keybuk> fabbione: dude, I only started back at work today
[05:32] <Keybuk> I'm nowhere near awake, nor through my e-mail eyt
[05:33] <fabbione> Keybuk: oh i didn't know
[05:33] <Keybuk> and then I have merges to do, including udev itself
[05:33] <Keybuk> next week sometime, eh?
[05:33] <fabbione> Keybuk: i saw you around and i thought you were working
[05:33] <fabbione> Keybuk: sure that's fine
[05:33] <Keybuk> cool :p
[05:33] <fabbione> Keybuk: i don't care if people can't boot from raid right now.. this is FEISTY...
[05:33] <Keybuk> yeah
[05:33] <fabbione> hmm....
[05:33] <fabbione> actually.. i can't reboot either... but whatever..
[05:34] <Keybuk> for mdadm, iirc, that just needs the merge from Debian and new udev
[05:34] <Keybuk> and everything will be fine
[05:34] <fabbione> i already merged all the new stuff from debian
[05:34] <fabbione> we have a very small delta now
[05:35] <fabbione> so we just need new udev crack
[05:36] <cjwatson> rodarvus: I just noticed a fix for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387043 going by
[05:36] <Ubugtu> Debian bug 387043 in gdm "gdm: Mojibake if in UTF-8 mode when running XKeepsCrashing script" [Normal,Closed]  
[05:36] <cjwatson> independent of bullet-proof-x, we should probably make sure we have that fix
[05:36] <dade`> initrds are cramfs images ?
[05:37] <cjwatson> initrds are something we don't use any more ...
[05:37] <cjwatson> we now use an initramfs (although we still call it an initrd in some places for compatibility), which is a gzipped cpio archive
[05:37] <cjwatson> when we used to use an initrd, it was a cramfs image, yes
[05:37] <rodarvus> cjwatson, agreed
[05:37] <rodarvus> I 
[05:37] <dade`> so I can't mount it
[05:38] <rodarvus> I guess seb128 and dholbach sync our packages with debian from time to time, but I'll contact them to make sure
[05:38] <cjwatson> no. you can unpack it by changing to an empty directory and doing zcat file-containing-initramfs | cpio -id
[05:40] <rodarvus> cjwatson, #387043 hit us pretty badly on the xserver issue a few months ago
[05:40] <rodarvus> I'm glad to see it fixed
[05:41] <_TomB> cjwatson, where does ubiquity log to?
[05:41] <cjwatson> _TomB: dapper or edgy?
[05:41] <_TomB> edgy
[05:42] <cjwatson> _TomB: /var/log/syslog; also /var/log/installer/debug if you set UBIQUITY_DEBUG=1 in the environment
[05:42] <_TomB> ok, thanks
[05:42] <cjwatson> _TomB: (but the latter will include passwords, etc., so it's not on by default)
[05:45] <dholbach> rodarvus: sync which packages?
[05:45] <dholbach> rodarvus: ahhh, gdm
[05:46] <rodarvus> dholbach, yup :)
[05:46] <rodarvus> I sent you some information in privmsg window
[06:01] <spike> hi, I'm looking at puppet package, currently in edgy/universe, version .18.4. Quite a lot of things changed in current version (.20.1) and I'm repackaging (tryint at least) and see if I can get it to run on dapper
[06:01] <spike> how shall I handle this? shall I email debian maintainer? ubuntu ones?
[06:06] <dholbach> spike: you could ask in #ubuntu-motu
[06:07] <spike> dholbach: oh, right. ta
[06:08] <_TomB> weird
[06:09] <_TomB> cjwatson, ubiquity didn't fail on grub for me
[06:09] <cjwatson> _TomB: yes, it's not particularly surprising that it might be hardware-specific
[06:10] <cjwatson> _TomB: it could easily be a grub problem and nothing to do with ubiquity at all; we have a number of those; I cannot help with them but am happy to take patches :)
[06:10] <bluefoxicy> jdong:  always use custom; actually read the options; and don't disable textrels (don't log them either; use scanelf to find them!  :D).  Typically the options are pretty straight-forward:  "This will break Xfree86" => don't do that
[06:10] <cjwatson> _TomB: you need to get /var/log/syslog from the people with problems
[06:10] <_TomB> I will
[06:10] <jdong> bluefoxicy: thanks
[06:10] <_TomB> I'll put a notice on the website
[06:10] <jdong> bluefoxicy: have any ideas why pax didn't enable even though I told it to?
[06:11] <bluefoxicy> um.. hm.  No, I'm about to leave though.  I'll look at your config when I Get back and give you better help though k?  :)
[06:11] <bluefoxicy> (as in, about to leave this second)
[06:11] <jdong> ok, no hurry :)
[06:13] <mvo> Keybuk: coreutils should be fixed with the 5.97-5.2ubuntu2 upload, if not, please spank me again (testing appreciated) - works-for-me now
[06:14] <dade`> ho avuto una idea
[06:15] <Chipzz> dade`: speak english please
[06:16] <Chipzz> (unless you're just addressing one person I guess)
[06:16] <dade`> Chipzz: you 're right, i typed in the wrong tab, sorry
[06:18] <Chipzz> ;)
[06:20] <iwj> Anyone fancy reviewing one of my specs ?  (I'm on reviewers but it seems incestuous, particularly now that we're not all together and getting communications clear and correct is more important.)
[06:21] <iwj> https://launchpad.net/distros/ubuntu/+spec/consistent-login-screen which I've hijacked to point at https://wiki.ubuntu.com/UnifiedLoginUnlock.
[06:22] <Riddell> mvo: remembering kubntu-feisty-language-selector spec?
[07:19] <smallfoot-> if anyone know a hardware company that done something good or bad such as cooperate with open source or anti-competive, please add it to http://vendors.bluwiki.org/
[07:26] <sivang> mvo: what's borken in coreutils btw?
[07:32] <sivang> mvo: I think some of the topic line got cut out ;)
[07:49] <mvo> sivang: really? looks good here
[07:49] <mvo> Riddell: I have not forgoten you :)
[07:54] <sivang> mvo: my bad, sorry
[09:19] <mvo> Riddell: the spec is approved now, thanks! do you have a eta for python-qt4 in feisty? I would like to test a patch to port langauge-selector to qt4 :)
[09:21] <Mithrandir> mvo: http://launchpad.net/distros/ubuntu/feisty/+source/python-qt4/4.1-0ubuntu1 you mean?
[09:23] <mvo> Mithrandir: I guess so - its currently in depwait state
[09:24] <crimsun> Is doko on vacation?
[09:24] <Mithrandir> yes
[09:25] <crimsun> ok, thanks. If a merge is listed for him, should I wait for his e-mail response or proceed?
[09:26] <crimsun> (wrt alsa-lib, since it's blocking at least two builds)
[09:26] <Mithrandir> I guess he'll be happy with you taking it, as long as you don't screw up. :-)
[09:26] <crimsun> hah
[09:43] <mvo> sfllaw: could you please have a look at https://launchpad.net/distros/ubuntu/+source/xorg/+bug/68430 ? its currently in edgy-proposed and we would like to move it to edgy-updates once it got some QA
[09:43] <Ubugtu> Malone bug 68430 in xorg "Dependencies allow driver packages to be removed too easily" [Medium,In progress]  
[09:44] <sfllaw> mvo: Yes.  It didn't get into the archive until recently.
[09:45] <sfllaw> I'll get to it before I go to bed today, as I understand it's important.
[09:45] <mvo> sfllaw: yes, unfortunately it was stuck in NEW for quite some time
[09:45] <mvo> sfllaw: thanks!
[11:23] <smallfoot-> if anyone know a hardware company that done something good or bad such as cooperate with open source or anti-competive, please add it to http://vendors.bluwiki.org/
[11:29] <robertj> you know, I think it's rather silly to have specs marked essential that are deferred
[11:31] <Burgwork> robertj: which one? the ui one?
[11:36] <Chipzz> smallfoot-: what bullshit!
[11:36] <Chipzz> smallfoot-: creative is NEGATIVE?
[11:36] <Chipzz> smallfoot-: for not supporting ONE card? nevermind the fact that 99.99% of their hardware DOES work under linux?
[11:39] <HrdwrBoB> and works 100% with open source drivers and was one of the first/best cards to support multi open on /dev/dsp
[11:39] <Chipzz> realtek POSITIVE?
[11:39] <Chipzz> wtf?
[11:39] <ajmitch> robertj: if it's the xorg-config-ui, note that it was set as essential just for scheduling purposes at UDS
[11:40] <Chipzz> realtek chipsets are among the most crappy network-cards in existance
[11:40] <Chipzz> smallfoot-: you should take a look at the freebsd drivers for realtek, and read the comments of the developers; they are not nice
[11:40] <mjg59> Chipzz: Off topic
[11:41] <mjg59> smallfoot-: Also, please stop repeatedly spamming us with your site
[11:41] <Chipzz> mjg59: yeah but this site looks like a load of crap
[11:41] <mjg59> Chipzz: I don't care. This isn't the place for it.
[11:41] <Chipzz> mjg59: apologies
[11:54] <bluefoxicy> jdong:  do you have a config for grsec you want me to check out?
[11:54] <jdong> bluefoxicy: well, I answered my own question (partially)
[11:54] <bluefoxicy> ah ok :)
[11:54] <jdong> bluefoxicy: but obviously I have the security level jacked to ohigh
[11:55] <jdong> bluefoxicy: because insmod segfaults
[11:55] <jdong> bluefoxicy: and that's kinda important towards mounting /.....
[11:55] <jdong> :)
[11:55] <bluefoxicy> jdong:  now THAT's odd.
[11:55] <bluefoxicy> PaX will kill stuff
[11:55] <bluefoxicy> but nothing in grsec should cause SEGV
[11:55] <jdong> bluefoxicy: I turned on pax softmode
[11:55] <jdong> bluefoxicy: and it wasn't triggering pax
[11:56] <jdong> bluefoxicy: so I'm not sure exactly what's causing the SEGV
[11:56] <bluefoxicy> jdong:  you might want to drop by #grsecurity on OFTC with that one
[11:56] <jdong> ok
[11:56] <jdong> first I'll cut my chances of looking stupid...
[11:56] <jdong> by making mrproper :)
[11:56] <bluefoxicy> lol
[11:56] <jdong> but make's supposed to work through that right? :D