[12:03] <Pygi> welcome matt
[12:03] <mdke_> thanks
[12:25] <BenC> anyone know of a util that will show the events on /dev/input devices? (not anything that goes through X)
[12:25] <BenC> something that is in breezy, preferably
[12:26] <Pygi> cat /proc/bus/input/devices  maybe this? ;)
[12:26] <BenC> no, I need to see the events
[12:27] <BenC> like when the mouse button is clicked, I want to see that event
[12:27] <Pygi> maybe this can help....
[12:27] <Pygi> http://www.ggi-project.org/documentation/libgii/current/input-linux-evdev.7.html
[12:28] <Pygi> well, all mouse's send event's throught /dev/input/mice
[12:28] <BenC> yeah, but I don't want to see raw data, I want it parsed into something meaningful
[12:29] <Pygi> k, read this
[12:29] <Pygi> http://opensource.idealcorp.com/evdev/README
[12:29] <Pygi> hope it helps
[12:30] <BenC> was hoping for something a user could install, but that may be my only option
[12:30] <BenC> thanks
[12:30] <Pygi> k
[12:31] <Pygi> BenC, hm, maybe you could make some kind of python/shell script which will ease the process?
[12:32] <Pygi> welcome clones of crimsun ;)
[12:32] <BenC> Pygi: was also trying to avoid writing software to debug a user's problem :)
[12:33] <Pygi> BenC: heh, maybe you could *force* someone to write it for you ;)
[12:36] <Pygi> BenC: still here?
[12:36] <Pygi> http://www.cpan.org/modules/by-module/Linux/Linux-Input-1.01.readme
[12:48] <BenC> think I'll just use evtest.c
[12:49] <Pygi> k
[01:15] <sistpoty> elmo: please sync paintlib from unstable, ubuntu override ok. thx.
[02:55] <eruin> where can I read about suspend to ram for dapper?
[02:55] <eruin> all I can come up with is hoary and even warty-related wiki entries, etc
[03:33] <lamont-away> if I have a machine with ubuntu-server installed, what magic glue is needed to make it mount usb drives when they are detected, I wonder...
[03:34] <Lathiat2> hrm
[03:34] <Lathiat2> they should?
[03:34] <lamont-away> mind you, I'm only logged in over the network
[03:34] <Lathiat2> oh, to auto-mount?
[03:34] <lamont-away> yeah
[03:35] <Lathiat2> i think gnome-volume-manager does the mounting part
[03:35] <lamont-away> automount
[03:35] <Lathiat2> usually
[03:35] <lamont-away> hrmfp
[04:12] <mojo_> hi every1
[04:13] <mojo_> GNOME Login Photo in Preference is quite useless since we have About Me program, then can some1 report a suggestion for deprecation?
[05:01] <zakame> hello all
[05:10] <Cimmerian> yes, all and shit
[05:16] <zakame> hey mhz
[05:16] <mhz> hey zakame 
[05:34] <zakame> er prolly stupid q, but what does a given-back in lamont's buildLogs mean?
[05:35] <fabbione> zakame: that the package is going to be rescheduled for build later
[05:36] <fabbione> but there are several reasons why you get there
[05:36] <zakame> fabbione: oh, k :D  I got this from the i386 build for the ruby-related pkgs I asked for sync yesterday...
[05:36] <lamont-away> zakame: but they all come down to "I tried to do the build, but I couldn't even get started because the source isn't fetchable or some such"
[05:37] <lamont-away> if you see them given back regularly every 8 hours or so for several times, then you might squawk.
[05:38] <zakame> lamont-away: yes, that's what I saw inside the .gz... I'll be keeping an eye on those then ;)
[05:38] <zakame> thanks :D
[05:39] <lamont-away> it's _supposed_ to be a transient error, you see...
[05:40] <zakame> ooh
[05:41] <fabbione> lamont-away: default serial on ia64 is sitll 9600 8N1?
[05:41] <fabbione> still even
[05:42] <lamont-away> actually, I think it's default is now autosense.
[05:42] <lamont-away> but yeah, 9600 8N1 will work just fine
[05:42] <fabbione> hm ok.. i must have plugged in the wrong serial than :)
[05:43] <fabbione> yeps
[05:43] <fabbione> here is is
[05:43] <fabbione> it is
[05:43] <lamont-away> heh
[05:44] <lamont-away> hppa 90.78% 5848 of 6442
[05:44] <lamont-away> sparc 88.76% 5755 of 6484
[05:44] <lamont-away> oops.  echan
[05:44] <lamont-away> powerpc 93.94% 6220 of 6621
[05:44] <lamont-away> amd64 93.03% 6129 of 6588
[05:44] <lamont-away> ia64 92.82% 6093 of 6564
[05:44] <lamont-away> i386 92.81% 6278 of 6764
[05:44] <lamont-away> hppa 89.45% 5848 of 6538
[05:44] <lamont-away> sparc 87.49% 5755 of 6578
[05:44] <lamont-away> holy-inversions batman.
[05:44] <fabbione> cat /proc/cpuinfo 
[05:44] <fabbione> processor  : 0
[05:44] <fabbione> vendor     : GenuineIntel
[05:44] <fabbione> arch       : IA-64
[05:44] <fabbione> family     : Itanium 2
[05:44] <lamont-away> ppc is leading?  and i386 is #4???
[05:44] <lamont-away> wow
[05:44] <fabbione> amen
[05:44] <fabbione> i think it
[05:45] <zakame> rocking
[05:45] <fabbione> i think it's busy building Riddell's crack :)
[05:45] <fabbione> so is sparc :)
[05:46] <fabbione> lamont-away: what did you build to gain 70 pkgs in one day????
[05:46] <fabbione> are you cheating or something?
[05:47] <lamont-away> fabbione: I, uh, reenabled mail and ftp from the 2nd buildd. :-)
[05:48] <fabbione> lamont-away: ah ok :)
[05:48] <fabbione> This boot experienced the following problems:
[05:48] <fabbione>   WARNING[10] : BMC System Event Log is full
[05:49] <fabbione> but you were right.. ia64 is on giga
[05:50] <lamont-away> fabbione: yeah - there's a bmc log dumper in universe somewhere - ping me monday and I'll tell you the name.. :-)
[05:50] <lamont-away> otherwise, it just gives you 30 extra seconds to override the autoboot. :-)
[05:51] <lamont-away> the warning specifically means that you're not running anything to clear the log, since booting is a logged event.
[05:51] <fabbione> i am ok with the 30 secondds
[06:09] <zakame> bye
[08:40] <Amaranth> do the dapper kernels have the new broadcom driver?
[08:40] <jblack> Hello. I have a multitude of problems on my vaio. Is anybody available to assist me in triaging them to figure out whether or not they're already filed, dapper specific, what packages are appropriate to file against, etc? 
[08:44] <fabbione> jblack: can you give me about 10 minutes?
[08:45] <jblack> fabbione: Sure
[08:51] <fabbione> re
[08:51] <fabbione> jbailey: ok.. tell me :)
[08:51] <jblack> This one? 
[08:51] <fabbione> ?
[08:51] <jblack> Lots of problems. Some are post going to dapper, some go all the way back to hoary
[08:51] <jblack> The most recent thing I've noticed is that /dev/hdc has gone bye-bye
[08:52] <fabbione> is that a cdrom?
[08:52] <jblack> Yes
[08:52] <fabbione> my hdc is actually a 400GB hd :)
[08:52] <fabbione> ok
[08:52] <fabbione> i am pretty sure it's a known problem
[08:52] <jblack> Ok.
[08:53] <jblack> Then that gets fixed some day. I can live without that for now. :) 
[08:53] <jblack> The next one is that /proc/acpi/sony has gone away since moving to dapper as well.
[08:53] <fabbione> you could check if the cdrom kernel modules are loaded
[08:53] <jblack> I tried modprobing idecd, but I'll do that again now
[08:53] <fabbione> let me check the acpi think
[08:53] <fabbione> there are 2 modules to load
[08:54] <jblack> ide_cd is loaded, cdrom is loaded, ide_generic and ide_disk
[08:54] <fabbione> oh first thing.. are you sure you did a full dist upgrade?
[08:55] <fabbione> because new kernel needs new udev
[08:55] <fabbione> and hotplug goes bye bye
[08:55] <jblack> Yeah, I did a apt-get dist-upgrade
[08:55] <jblack> I've done it a few times in the last few weeks.
[08:55] <fabbione> did you do it today?
[08:55] <jblack> btw, dmesg tells me "hdc: ERROR, PORTS ALREADY IN USE"
[08:55] <fabbione> there have been quite a log of fixes...
[08:55] <fabbione> ah
[08:55] <jblack> Yes. I did it this evening, about an hour ago
[08:56] <jblack> I also see this a few lines later in /var/log/dmesg:
[08:56] <jblack> [17179573.632000]  Badness in enable_irq at kernel/irq/manage.c:126
[08:56] <fabbione> ok, it might be a driver problem.. you need to check that with BenC
[08:57] <fabbione> jblack: uname -a ?
[08:57] <jblack> Ok. Used to work fine back in breezy, btw.
[08:57] <jblack> Linux pluto 2.6.15-8-686 #1 SMP PREEMPT Tue Dec 13 03:38:39 UTC 2005 i686 GNU/Linux
[08:57] <fabbione> jbailey: cd /lib/modules/$(uname -r)/kernel/drivers/acpi
[08:57] <fabbione> jblack: 
[08:58] <fabbione> do you have the sony module there?
[08:58] <fabbione> or at least loaded?
[08:58] <jblack> No, no sony module
[08:58] <jblack> I do have sonypi loaded though
[08:58] <fabbione> ok
[08:58] <jblack> I'm not sure where its loading from, if its not in that dir
[08:58] <fabbione> not sure it's the same.. let me check
[08:59] <jblack> oh, its in char/sonypi
[08:59] <fabbione> obj-$(CONFIG_ACPI_SONY)         += sony_acpi.o
[08:59] <fabbione> no it is simply not compiled.. 
[08:59] <fabbione> the code is there tho
[08:59] <fabbione> open a bug for BenC
[08:59] <jblack> Hmmm. That's two for benc. :)
[09:00] <fabbione> yup
[09:00] <fabbione> next?
[09:01] <jblack> Next... Hmmm. how about another probably kernel one.
[09:01] <fabbione> go ahead :)
[09:01] <jblack> resuming from sleep is very slow. Usually, shutting down and restarting is quicker
[09:01] <fabbione> because for once.. IT'S NOT MY FAULT :P
[09:01] <jblack> Oh, I've got some for you too. :)
[09:01] <fabbione> i doubt
[09:01] <jblack> You do synaptics?
[09:01] <fabbione> resume speed.. dunno.. you need to ask mjg59
[09:02] <fabbione> no i don't do synaptics.. i am more for classic drugs like eroin or cocaine...
[09:02] <jblack> Ok. I'll talk to him for that one.
[09:03] <fabbione> synaptics is still Xorg = daniels..
[09:03] <jblack> Next, the mouse and touchpad are slow. I have to travel large distances for movement.
[09:03] <fabbione> is that a regresion compared to breezy?
[09:03] <jblack> The touchpad stuff doesn't honor any of the settings. So in breezy, everytime I used the touchpad, I would get movement + touch.
[09:03] <fabbione> there could be several reasons for that
[09:04] <jblack> Now, I get little movement + touch. 
[09:04] <jblack> btw, all of this worked fine back in warty. 
[09:04] <fabbione> that
[09:04] <jblack> It went downhill in hoary, then more so in breezy. Desperate, I hopped to dapper.
[09:04] <fabbione> that's tricky to debug and it will take sometime.. that i don't really have today, but i can help you tomorrow
[09:05] <fabbione> jblack: the entire input layer has been rewritten between hoary and breezy
[09:05] <fabbione> and there have been even more changes in dapper
[09:05] <jblack> Yeah. Adam Conrad took a shot at it in ubz.
[09:05] <fabbione> jblack: meh you could have told me there
[09:05] <jblack> We thought we had fixed it. :( 
[09:05] <fabbione> remote debugging of that stuff = the sucks
[09:06] <jblack> I will happily limp to the next meet.
[09:06] <fabbione> let's try to look at it tomorrow than
[09:06] <fabbione> or during the next week
[09:06] <jblack> And I'll give you all the beer that you can drink if you make this thing work as well as its counterpart did with hoary.
[09:06] <fabbione> ehhehe
[09:06] <jblack> I'm serious. :) 
[09:07] <fabbione> if people keep paying me in beer.. i will not survive the next 3 months
[09:07] <fabbione> speaking of which.. shawarma the beer is good :)
[09:07] <jblack> yeah? 
[09:07] <jblack> I think I've seen that before. Where is it? 
[09:07] <fabbione> jblack: i got 5 lt of beer from shawarma :)
[09:08] <fabbione> jblack: anyway.. this distro is all about free beer :)
[09:08] <jblack> We have an american beer here called...I can't remember the name.
[09:08] <fabbione> bud wiser?
[09:08] <jblack> Oh god no.
[09:08] <fabbione> ah ok
[09:08] <fabbione> you did scare me for a second
[09:08] <jblack> No. Thats soda water with a hop from time to time.
[09:09] <fabbione> no idea of what you are talking about ;)
[09:09] <fabbione> anyway.. next issue?
[09:09] <jblack> no cdrom, broken touchpad, broken suspend and resume, that's the big ones.
[09:10] <fabbione> ok, other than the synaptic one, that we need to debug.. the others have been addressed somehow...
[09:10] <fabbione> i also think that suspend / resume is binded to the sony_acpi
[09:10] <fabbione> missing from the kernel
[09:10] <jblack> I suppose thats possible, but back in breezy, the suspend-resume problems were there, and I had sony_acpi
[09:11] <jblack> The missing sony_acpi causes a number of problems. Poor battery life, processor speed, etc.
[09:12] <jblack> Is it possible for me to build a kernel on ubuntu?
[09:13] <fabbione> jblack: yes it is of course.. the problem is that i don't know why it's not built and building for amateur is a suicide 
[09:13] <jblack> Back in the debian world I was accustomed to building kernels without a problem.
[09:13] <fabbione> mainly it will burn your life for a few days..
[09:13] <fabbione> oh the build system is similar
[09:13] <jblack> I'm worried that I'll muck up the wireless though.
[09:13] <fabbione> that's not the issue
[09:13] <fabbione> the main problem is that i don't know why it's not built
[09:15] <jblack> perhaps it causes a problem for nonsonys.
[09:16] <infinity> Are the relevant patches even included?
[09:16] <fabbione> i don't think that's the reason
[09:16] <fabbione> infinity: yes they are
[09:16] <fabbione> the code is in .15
[09:16] <infinity> We definitely don't have CONFIG_ACPI_SONY in our .configs.
[09:16] <fabbione> that might be why :)
[09:16] <infinity> So, maybe it was just an "oops".
[09:16] <fabbione> that's why i am saying it might be difficult to get there
[09:17] <fabbione> if ACPI_SONY is not in Kconfig, it becomes a pain to do
[09:17] <fabbione> much easier to ask BenC
[09:17] <jblack> Just promise me that I won't loose any more hardware!
[09:17] <fabbione> pain for people not familair with Kbuild
[09:17] <jblack> No touchpad, no cdrom, no acpi... 
[09:17] <jblack> if you take out the nic, keyboard or screen, I'm screwed! 
[09:18] <fabbione> jblack: that's because we care about you.. working too much in front of a pc is NOT healty
[09:18] <fabbione> so we preserve you
[09:18] <infinity> jblack IS the CDROM on an SATA channel?
[09:18] <fabbione> you should be grateful to us :)
[09:18] <jblack> inifinity: Nope
[09:18] <jblack> Speaking of the screen, irssi just went bonkers. 
[09:18] <infinity> jblack : Oh, it's standard IDE?  Hrm.
[09:18] <jblack> infinity: Yeah. Its apparently a known issue.
[09:19] <jblack> PORTS ALREADY IN USE or somesuch
[09:19] <infinity> That's a red herring.
[09:19] <infinity> ide-generic always says that.
[09:19] <infinity> (If it doesn't, it was loaded too early)
[09:19] <infinity> I really should silence those printks in ide-generic.  People keep using them as debugging info, and they're just not meaningful.
[09:20] <jblack> ok, in that case, I lost hdc somewhere between late breezy and contemporary dapper.
[09:20] <jblack> I noticed tonight. The drive is there. I checked on wintendo
[09:20] <infinity> Maybe replace them with something friendlier, like "A better IDE driver is already loaded, ide-generic not binding to any ports"
[09:20] <infinity> Or just remove them completely.
[09:21] <infinity> Wait, didn't i already DO that in breezy?
[09:21] <jblack> I'm on dapper.
[09:21] <infinity> Yeah, I know.
[09:22] <floam> anyone know about libata's ATAPI support? will that be working by the time dapper comes out?
[09:22] <floam> Jeff Garzik has been saying "real soon now" for almost a year
[09:22] <infinity> floam : If it's not in tip-top shape when we get closer to release, we'll fall back to the older methods.
[09:22] <floam> older methods?
[09:23] <floam> as in ATAPI not working at all?
[09:23] <floam> (as it is now)
[09:23] <fabbione> floam: do you have patches to fix these problems?
[09:23] <infinity> fabbione : Do you have an old breezy kernel tree on your hard drive?... I can't be bothered to download it to check something.
[09:23] <fabbione> infinity: yes i do
[09:24] <infinity> fabbione : Did my "drivers-ide_quiet_probe_failures.dpatch" remove the probe printk entirely, or just lower the severity to keep it off the screen?
[09:24] <floam> fabbione: uh, no. it's major work
[09:24] <floam> I'm just curious if anyone knew more than what's on the libata page
[09:24] <fabbione> floam: than don
[09:25] <floam> don't say don't complain, I certainly am not
[09:25] <fabbione> floam: than don't complain.. it's a major work for Grek too
[09:25] <fabbione> Jeff i mean
[09:25] <floam> I know that
[09:25] <fabbione> infinity: it lowers it
[09:25] <fabbione> from ERR to INFO
[09:25] <infinity> floam : BenC's been following it some.  The theory is that if libata ATAPI turns out to suck, we fall back to using ide-generic for ATAPI and libata for disks.  (which was basically how breezy's setup worked)
[09:25] <fabbione> so it should still be in dmesg
[09:26] <infinity> fabbione : Ahh.  Kay.  Then Ben probably didn't drop the patch.  I'd forgotten I left it in as INFO.
[09:26] <floam> infinity: I don't get how that can work..
[09:26] <floam> ide-generic certainly can't handle SATA CD/DVD drives
[09:26] <floam> oh.
[09:26] <floam> you must mean PATA stuff.
[09:26] <infinity> floam : My CD drive is SATA, and it woks in breezy, where we certainly weren't using the libata/atapi mess we are right now.
[09:26] <infinity> works, too.
[09:27] <floam> infinity: interesting. can it burn?
[09:27] <infinity> But yes, I thin kthe current broken state of affairs is with trying to use libata for pata atapi devices or some such.
[09:27] <infinity> Yes, it'd a DVD burner, works fine in both breezy and dapper.
[09:27] <infinity> (2.6.12-9 and 2.6.15-8)
[09:27] <floam> weird weird weird. is it using the old "(DEPRECATED)" SATA modules for that or something?
[09:28] <floam> I was under the impression that it couldn't work with libata at all at the moment
[09:28] <infinity> It's ata_piix/libata+atapi in dapper.  No idea how it was working in breezy.
[09:28] <infinity> (Well, +sr_cd+sg, obviously)
[09:28] <floam> yeah, I know it's enabled on a few chipsets in dapper
[09:28] <floam> I'm just curious now what it was doing in breezy
[09:29] <infinity> I'd have to reboot and play to remind myself how it worked in breezy, but I know it did.  Testing release CDs would have been tough if it didn't work. :)
[09:30] <floam> ide-generic certainly can't do SATA, maybe it was using the old non-libata SATA modules that were in the IDE layer for that or something
[09:30] <infinity> fabbione : Would you object to me changing that printk to be a bit friendlier/more informative?... I'm sick of people (even clueful people) thinking it's a bug.
[09:31] <jblack> Thats probably not a bad idea. It tricked me. 
[09:31] <fabbione> infinity: i have no problems at all.. just send me the patch or point me to your git repo
[09:31] <infinity> (Okay, to be fair, it's a "bug" that we need to try to load ide-generic at all, but one we can't fix any time soon)
[09:31] <infinity> Yeah, I'll fix it later and have ben pull.
[09:33] <floam> infinity: which drive do you have? the plextor one?
[09:34] <fabbione> infinity: up to you.. makes no diff for me
[09:34] <infinity> fabbione : Yeah, it wa more just a second opinion thing.
[09:35] <fabbione> infinity: ehehe 
[09:35] <infinity> floam : No, it's a Matshita drive in my Thinkpad.
[09:35] <floam> hm. completely 100% certain it's really SATA?
[09:36] <infinity> The drive, or the controller?
[09:36] <floam> well, both
[09:36] <infinity> The drives are PATA drives on a bridge, afaik, but the controller is definitely SATA, which is what should matter.
[09:37] <floam> the only experience I have with a ATAPI SATA device is the plextor one, which my friend had on a VIA chipset
[09:37] <floam> and I'm pretty sure we couldn't get it to work on breezy
[09:37] <floam> perhaps piix works better
[09:38] <infinity> I'd be willing to bet piix gets more love, but the via drivers should be getting a fair amount of love from the am64 crowd.
[09:38] <floam> yeah.
[09:38] <infinity> I was going to get one of the Plextors for my SATA VIA machine, but the PATA Pioneer drives were too well priced to turn down.
[09:38] <exarkun> I came in halfway through, but I have a PIIX w/ and ATAPI SATA plextor, it does not work with Breezy.
[09:39] <infinity> exarkun : Does it work in dapper?
[09:39] <exarkun> haven't tried, I ended up buying an IDE drive to replace it.
[09:39] <floam> I might be getting the PX-716SA as a gift over the holidays, so I'll be able to screw with that soon
[09:40] <floam> it's finally available fairly cheaply. I saw it for $82 somewhere
[09:41] <infinity> Yeah, I was shoppig about a year ago, and the Plextor was a bit out of range for someone like me who burns a few DVDs per year, and maybe 50 CDs.
[09:41] <floam> yeah.
[09:41] <floam> it was $160 when I first put my eye on it
[09:42] <floam> certainly not much more evil than ATI for only handing out binaries
[09:43] <floam> though one is cleanliness-evil and another is moral-evil
[09:43] <Treenaks> infinity: less evil than doing it in the nvidia-driver ;)
[09:43] <infinity> Treenaks : Well, the nvidia driver WORKS, so that's a non-issue. :)
[09:44] <Treenaks> infinity: The nvidia-driver _leaks_
[09:44] <infinity> Well, okay, for some value of "works"... It works a lot better than fglrx at the moment.
[09:44] <Treenaks> hmm
[09:44] <Treenaks> I need to try flight2 + latest X
[09:44] <Treenaks> see if it fixes my ATi-troubles
[09:45] <infinity> The free ATI driver treats me very well.
[09:45] <Treenaks> infinity: well, it does on my _other_ laptop, but on the canonical-supplied one, all hell breaks loose on 1920x1200
[09:45] <infinity> But I should fix DRI in fglrx, I suppose.  And that will either take dirty symlinks I don't want to ship (stuff in /usr/X11R6, ugh), or a hex editor.
[09:45] <floam> nvidia seems to be much better at distributing binary drivers that manage to work well in a hostile environment
[09:45] <floam> every other week Greg-KH adds something to the kernel blocking off more non-GPL stuff
[09:45] <Treenaks> floam: i.e. gentoo? :)
[09:46] <floam> well, I mostly meant the A{B,P}I environment
[09:47] <floam> Greg-KH is a nice guy, but I really liked it when my nvidia driver had working udev/sysfs stuff
[09:47] <Treenaks> complain to nvidia ;)
[09:47] <infinity> Can't.  That's the whole point.
[09:48] <infinity> It's not nvidia's fault.
[09:48] <Treenaks> ('why isn't it possible to work like wiif-drivers work: upload a blob of firmware to $device')
[09:48] <infinity> (Wel, except that it's their fault the driver's not free)
[09:48] <floam> other than telling NVIDIA to release all their IP to the world, there isn't anything to complain about to nvidia
[09:48] <jblack> I cared a lot more about kernel tainting before I had a job
[09:48] <Treenaks> floam: you've never used nforce-chipset motherboards :)
[09:48] <floam> the kernel people don't like proprietary drivers, so they decided one day to set a bunch of EXPORT_SYMBOL stuff to EXPORT_SYMBOL_GPL in the sysfs code
[09:49] <infinity> OTOH, udev/sysfs integration is of limited value, since modporbing 'nvidia' when the X driver loads is good enough.  You don't need it hot/coldplugging on boot.
[09:49] <floam> and now that hasn't worked sense
[09:49] <floam> infinity: meh, it was somewhat useful
[09:49] <dooglus> where do I set up my 'workgroup'?
[09:50] <Treenaks> dooglus: System -> Administration -> Shared folders?
[09:50] <Treenaks> (or whatever it's called in English)
[09:50] <dooglus> Treenaks: I saw that, but I'm not using samba or NFS.  I'm merely mounting a windows shared drive
[09:51] <Treenaks> dooglus: you don't need a workgroup for that
[09:51] <floam> mounting? literally? You'll need to use smbfs and set the workgroup in the -o parameter of mount
[09:51] <dooglus> Treenaks: do I need to install anything to be able to "mount -t cifs" ?  Currently I see mount: wrong fs type, bad option, bad superblock on //server/dokumenty,
[09:51] <floam> I assume you didn't mean actually using mount though.
[09:51] <infinity> dooglus : "smbfs"
[09:52] <floam> you should be able to find it in nautilus
[09:52] <infinity> dooglus : The package, that is.
[09:54] <floam> oh, man. awesome. Jorn finally gave someone else commit access to muine
[09:54] <floam> it's no longer dead, woot
[09:54] <floam> or less dead, at least
[09:54] <dooglus> thanks guys.  you were both right.  I didn't need to set a workgroup, and I *did* need to install smbfs to be able to mount using 'cifs'
[09:55] <floam> hmm, both nautilus and the gnomemeeting packages seem borked on amd64 here
[09:55] <floam> neither can install
[10:00] <dooglus> floam: I really meant 'mount', and I don't use 'smbfs' because that has a 4Gb (or 2Gb, I forget) file size limit
[10:01] <dooglus> floam: and I didn't have to mention the workgroup name in the -o flags
[10:01] <floam> yeah, you probably wouldn't
[10:01] <floam> workgroup is default
[10:01] <dooglus> floam: I uninstalled nautilus
[10:01] <dooglus> floam: the workgroup used here isn't the default one.
[10:01] <floam> dooglus: and it still found it? cool
[10:02] <dooglus> floam: well, I installed this chroot a couple of months ago, when dapper was first made available, so maybe I set the workgroup then.  but I can't see where, if I did.
[10:08] <infinity> The workgroup is meaningless except for browsing machines in nice little groups.
[10:08] <infinity> When connecting to a share, you just need to know how to get to it (machine name or IP) and the share name.
[10:09] <floam> oh.
[10:09] <floam> I figured it was the same as the abstract way it's presented
[10:09] <floam> (as machines under workgroups)
[10:09] <infinity> Nope, workgroups are just to keep things tidy in GUI browsers.
[10:10] <infinity> (And to allow machines that aren't actually domain members to appear in the same-named machine lists)
[10:14] <lifeless> floam: a good way to think of it is: workgroups/domains == naming service; domains also add bidirectional verification and a user lookup service.
[10:17] <floam> infinity: do you do the kernel releases? who should I bug to try to get a .config option turned on?
[10:17] <infinity> floam : You should ask in #ubuntu-kernel.  BenC does the majority of kernel maintenance and releases.
[10:17] <floam> oh. didn't know it had a channel
[10:18] <infinity> Yes, well.  The last few hours here would seem to indicate we don't have a kernel channel, but that's cause it's a weekend, and I'm more slack about not bouncing people for being off-topic on weekends (since there's very little ON-topic conversation)
[10:19] <jdub> hmm, wonder if my craptop boots now
[10:19] <floam> 80% of what I was saying here would have been in there had I known about it :)
[10:19] <jdub> probably not, haven't seen any core updates
[10:20] <infinity> jdub : What sort of hate is it giving you?
[10:21] <jdub> seems to halt at shpchp
[10:21] <jdub> at least, that's the last thing printed during a verbose boot
[10:21] <jdub> i'll try again now
[10:24] <jdub> okay, so init=/bin/sh is fine
[10:24] <jdub> so it's during hardware detection stage
[10:25] <jdub> hmm, bit different now
[10:25] <jdub> interesting dma timeout errors on hda
[10:27] <jdub> let's see that again
[10:27] <dooglus> what's this about: bash: ./small.sh: /bin/bash: bad interpreter: Permission denied
[10:28] <dooglus> /bin/bash is executable by everyone - so why "permission denied"?
[10:28] <jdub> hmm!
[10:28] <jdub> looks like it worked this time, after killing a stupid hdparm config
[10:28] <jdub> though it got further than it did before even then
[10:30] <sivang> morning all
[10:32] <Pygi> mornin' sivang
[10:32] <sivang> hey Pygi , 'sup?
[10:33] <Pygi> writing Server 
[10:33] <Pygi> gah, wrong...
[10:34] <Pygi> porting Miranda to Linux
[10:34] <sivang> oh, miranda on linux :)
[10:34] <dooglus> for the record:  the device holding 'small.sh' was mounted with option "user" which implied "noexec".  remounting with "defaults" instead fixed it
[10:34] <Pygi> hehe ;)
[10:34] <sivang> Pygi: but there's GAIM why do need to port it to linux?
[10:35] <Pygi> sivang: I rather wouldn't talk about GAIM because it's lead developer might be hear, and I don't think he would like to hear what I think about him ;)
[10:35] <Pygi> here, not hear* (first one)
[10:36] <sivang> Pygi: I see, well, better not go that way.
[10:37] <Pygi> heh ;)
[10:37] <Pygi> so, what are you doin'?
[10:41] <sivang> Pygi: I'm at work currently :-/
[10:42] <Pygi> ah :-/
[10:46] <sivang> lately leaves me no time for Ubuntu...
[10:46] <Pygi> heh, will be better eventually....
[10:46] <sivang> yes, I hope :)
[10:53] <Pygi> Lately I've been playing around with writing some patches for the kernel
[11:07] <Treenaks> hmmm
[11:07] <Treenaks> flight2 fails to boot
[11:08] <dooglus> is there an easy way to make the text smaller in GTK apps?
[11:08] <Treenaks> dooglus: choose a different font in  SYstem -> Preferences-> Fonts
[11:09] <infinity> Treenaks : Installer, live, or both?
[11:10] <Treenaks> infinity: installer
[11:10] <Treenaks> infinity: haven't tried live
[11:10] <dooglus> as easy as that, eh?  thanks!
[11:10] <Treenaks> the moment I press a key, a 'debug window' pops up
[11:10] <Treenaks> pressing enter gives me a window saying 'Error reading CD-ROM'
[11:10] <Treenaks> just waiting -> same
[11:11] <Treenaks> I have a picture of the 'debug window'
[11:11] <Treenaks> foodfight.org/zut/BOOT-ERROR.jpg
[11:13] <infinity> Oh, that's still in gfxboot.  You're not even hitting a kernel yet.
[11:13] <infinity> I'd assume bad burn or corrupt ISO.
[11:13] <Treenaks> infinity: I burned it twice, checked the ISO in between, and md5summed the CD
[11:13] <infinity> Anything that shows the menu but can't find the kernel sounds pretty "broken CD" to me.
[11:13] <infinity> Hrm.
[11:14] <infinity> Or a nifty gfxboot bug..
[11:14] <dooglus> Treenaks: did "md5summing the CD" give the right sum?
[11:14] <Treenaks> dooglus: yes
[11:14] <dooglus> Treenaks: how did you do that?
[11:15] <dooglus> Treenaks: when I tried it, "md5sum /dev/hdc" read more bytes off the cd than I had written to it, so the sum came back wrong
[11:15] <Treenaks> dooglus: uh.. 'extra bytes'?
[11:15] <Treenaks> never had that
[11:15] <dooglus> Treenaks: just random junk by the look of it
[11:16] <dooglus> Treenaks: not all zeros
[11:16] <Treenaks> anyway, I tried with 2 discs, burned at different speeds
[11:17] <infinity> Treenaks : Then file a bug on "gfxboot", and attach (a much smaller copy of) your image.
[11:17] <Treenaks> infinity: ok
[11:17] <infinity> And mention the "I did an md5sum twice, blah blah" stuff, or someone will just ask you again. :)
[11:18] <Treenaks> ;)
[11:18] <dooglus> when I boot, if I specify "vga=773" to get nice small text in the consoles, the consoles are all black.  if I miss out the "vga=" bit, the text in the consoles is far too big.  is there some way I can have small text which isn't black-on-black?
[11:23] <dooglus> I thought it was very quiet in here - and now I know why!
[11:32] <Q-FUNK> hm.  did pitti change nick recently or is he just plain not here right now?
[11:32] <Treenaks> Q-FUNK: he's not here.
[11:33] <Q-FUNK> Treenaks: ok.  thanks :)
[11:33] <Q-FUNK> for the record, esound has just gone RC in Debian and Pitti's patches fixes it. However... this is an rmurray package...
[11:35] <Q-FUNK> see Debian Bug #343861
[12:27] <Pygi> greetings ;)
[12:33] <greenpenguin13> morning
[12:41] <Kamion> floam: on easy vesafb setup, I get to wave my blessed wand of retroactively satisfying feature requests again
[12:42] <Kamion> floam: use the menu labelled "VGA" in >= Flight 2's boot menu; whatever mode you select there will be propagated as the default for the installed system
[12:42] <Kamion> Treenaks: nifty - fortunately I know how to debug those screens, so I'll have a look, thanks
[12:42] <Treenaks> Kamion: ok, cool :)
[12:43] <Kamion> err 8 means "wrong arg types" and means I screwed up the theme somewhere
[12:43] <Treenaks> even 'boot from harddisk' gives me a 'Error reading CD-ROM'
[12:44] <Treenaks> "dialog box" thing
[12:45] <Kamion> Treenaks: which arch is this? I need to check exactly which version of gfxboot-theme-ubuntu was being used
[12:45] <Treenaks> Kamion: i386
[12:45] <Kamion> elmo: please sync jlex, ok to override Ubuntu changes
[12:45] <Treenaks> Kamion: (HP laptop, hda = harddisk; hdb = cdrom)
[12:46] <Treenaks> same CD works fine on my Acer (also pentium-m; hda = harddisk; hdc = cdrom)
[12:46] <Treenaks> (maybe 512M RAM vs 1GB RAM?)
[12:46] <Kamion> you've probably got a losing BIOS, sorry
[12:46] <Kamion> all gfxboot can do is guess and chain to BIOS 0x80
[12:46] <fabbione> hey Kamion 
[12:46] <Kamion> if that doesn't work, tough
[12:47] <Kamion> hi
[12:48] <Treenaks> Kamion: sure... chaining should work... but why does it try to read the CD for that in the first place?
[12:49] <Kamion> it doesn't, unless your BIOS claims the CD is 0x80, AFAIK
[12:49] <Kamion> I have no intention of trying to do anything cleverer at the moment
[12:49] <Treenaks> Kamion: I can imagine
[12:49] <Kamion> it's a useful feature if it happens to work; if it doesn't happen to work for you, oh well, it was just thrown in as a nice-to-have
[12:49] <Treenaks> Kamion: but then, booting from CD also doesn't work.. that would be nice
[12:50] <Kamion> seems pretty separate
[12:50] <Kamion> let me work on it rather than arguing with you :)
[12:50] <Treenaks> ok :)
[12:50] <infinity> Kamion : Oh, can you avoid the default boot setting "vga=normal" in gfxboot?
[12:51] <Kamion> infinity: that's debian-cd's defaults not gfxboot. ok - why?
[12:51] <Mithrandir> Kamion: it breaks usplash
[12:52] <infinity> Kamion : (bug in usplash that it doesn't properly deal with "vga=normal", which will be fixed in the next upload, but if you say that gfxboot's settings propagate to the installed system, IMO vga=normal is silly overkill)
[12:52] <Kamion> from the sound of scrollback that was usplash's fault anyway
[12:52] <Kamion> infinity: vga=normal doesn't propagate
[12:52] <Kamion> it's only stuff after -- in the boot line that gets propagated
[12:52] <infinity> Oh, just "anything but vga=normal"?
[12:52] <Kamion> no
[12:52] <infinity> Ah.
[12:52] <infinity> Check.
[12:52] <Kamion> vga=normal goes before --
[12:52] <infinity> Right.
[12:53] <infinity> Lag.  Your explanation came after I typed my stupid question.
[12:53] <infinity> Anyhow, I'll fix usplash, I'm not too picky on what gfxboot decides to do then.
[12:54] <infinity> (If a user types "vga=123" after the '--', I assume my /proc/cmdline will only show the latter, not both?
[12:54] <infinity> )
[12:54] <infinity> Or do I have to find the "best" one to interpret? :)
[12:55] <infinity> (Yeah, tomorrow I can reboot my laptop and find out myself, just not right now)
[12:56] <Kamion> infinity: vga=normal removed
[12:57] <Kamion> infinity: it'll show both; use the last one
[12:57] <infinity> Kay.
[12:57] <Kamion> ok, that gfxboot trace is insane, it's dying on finding an undef value in timeout.areas, which is a hardcoded array containing no undefs
[12:59] <infinity> Mithrandir : How do you feel about uploading a casper that actually works on my hardware, so I can build a livefs with it and test a daily over here?  (assuming I can get the *-{live,desktop} stuff installable again this year)
[01:01] <infinity> I may just switch my job title to "Guy who makes sure the distro is installable at all times"
[01:02] <Mithrandir> infinity: I can do that, I just need to fix asterisk a tiny bit.
[01:04] <jdub> hey dudes
[01:05] <Kamion> jdub: you pinged the other day?
[01:07] <Mithrandir> infinity: want me to add squashfs support as well, or just the scsi cdrom module?
[01:07] <infinity> Mithrandir : Go ahead and add it, it's dormant code until we play with squashfs images, but it's nice to have it in there so we can.
[01:08] <jdub> syeah
[01:09] <jdub> i should get irssi to reject any attempt to say something that matches "^.*: ping$"
[01:09] <Mithrandir> infinity/Kamion: what does uname -m say on ppc/ppc64?
[01:10] <jdub> Kamion: do we need more testing for installs on openservers?
[01:10] <jdub> openpower servers
[01:10] <Mithrandir> I feel nice, so I'll unbreak the live cd on ppc
[01:10] <Kamion> jdub: sure, always
[01:10] <jdub> Kamion: did we get those yaboot patches?
[01:10] <Kamion> Mithrandir: ppc on this older kernel but I strongly suspect it'll be powerpc in dapper
[01:11] <Kamion> jdub: last time I looked they weren't published yet; I'll have another look
[01:11] <jdub> fuqrs
[01:11] <Mithrandir> Kamion: so I need to check for ppc, powerpc and powerpc64 or something?  This is so casper will use devmapper on ppc.
[01:12] <Kamion> Mithrandir: ppc/ppc64/powerpc I think
[01:12] <Kamion> Mithrandir: I could just have debian-cd pass casper-overlay=devmapper or something
[01:13] <Mithrandir> Kamion: that would mean I'd have to parse /proc/cmdline. :-)
[01:13] <infinity> It's all the rage.
[01:16] <infinity> The thermal stuff that just blindly tries to load modules that may or may not even exist on your arch is pretty special too.
[01:17] <Kamion> infinity: yes please
[01:17] <Mithrandir> infinity: that would be better, I think.
[01:22] <jdub> infinity: SOFT!
[01:22] <infinity> :P
[01:22] <infinity> I thought it would be novel to wake up in the morning for once.
[01:22] <infinity> Noon is getting old.
[01:41] <Goshawk_> hi, toolchain-source package should be upgraded, it exits with gcc-3.4 and binutils-2.15 when breezy uses gcc-4 and binutils-2.16
[01:49] <Goshawk_> should i report a bug about it?
[02:01] <ogra> could some native english speaker check the edubuntu flight2 release announcement for typos and grammar on https://wiki.edubuntu.org/EdubuntuFlight2Announcement ?
[02:02] <ogra> thanks :)
[02:02] <ogra> dont care about wiki formatting, it will go into an email anyway ;)
[02:07] <Riddell> ogra: I can't make sense of this sentence: "Please install additional languages post install if your network device is up to download the locale and language packs."
[02:07] <ogra> hmm
[02:08] <Kamion> Germanglish grammar ;-)
[02:08] <ogra> you cant install edbuntu in other languages currently, because the NIC isnt working during install and locales are missing
[02:09] <ogra> Kamion, nope, plain german grammar ;) 
[02:09] <pef> is it acceptable to backport something to breezy in order to correct a bug in another package ?
[02:09] <Kamion> try "If your system is connected to the Internet, please use the Language Selector after installation to download language packs."
[02:09] <ogra> with english words though
[02:09] <ogra> thanks :)
[02:09] <Kamion> could you capitalise Ubuntu, Edubuntu, and so on, please?
[02:09] <ogra> yup
[02:10] <ogra> as soon as Riddell is done ...
[02:10] <Riddell> Kamion: doing
[02:10] <Kamion> "are gone into this CD images" -> "have been included in these CD images"
[02:10] <Kamion> ("are gone" is almost always wrong)
[02:10] <ogra> oh, i didnt know this ...
[02:11] <Kamion> well, "are gone into" is wrong, "are gone" in other senses might be OK
[02:11] <ogra> yup, understood ...
[02:11] <Treenaks> They were here, but they are gone now ;)
[02:11] <Riddell> ogra: ok, done
[02:11] <ogra> thanks a lot :)
[02:11] <Kamion> quote 'sudo ltsp-build-client --arch i386' somehow so that it's separated from the text
[02:11] <Kamion> Treenaks: right, that's one correct usage
[02:11] <tseng> who can do test builds on the ppc64?
[02:12] <tseng> or is there a process to get access while elmo isnt looking
[02:12] <Kamion> I'd do "sped up" => "faster"
[02:12] <Kamion> "boot splash" and "boot process" are each two words
[02:13] <ogra> fixing
[02:15] <jdub> Kamion: mind if i do a fontconfig upload to add dejavu fallbacks?
[02:15] <jdub> Kamion: then can i get ttf-dejavu in the desktop seed?
[02:15] <ogra> eeek, another font ?
[02:15] <jdub> heh
[02:15] <jdub> well, i don't really want to *replace* bitstream vera
[02:15] <ogra> (my ppc live CD already needs overburn on 700MB media)
[02:16] <jdub> Size: 804424
[02:16] <jdub> Installed-Size: 1608
[02:16] <jdub> :-)
[02:16] <ogra> ok :)
[02:18] <Kamion> jdub: sounds reasonable, I guess
[02:19] <Riddell> jdub: why not replace vera?  dejavu is just vera
[02:19] <Riddell> although the z's are a little different in their spacing
[02:19] <jdub> with a different name
[02:22] <ogra> jdub, do you pick the announcement up from u-d-a ? or do i need to send it separately to fridge-devel ? 
[02:23] <jdub> ogra: dude, you totally missed the release ;-)
[02:23] <ogra> :P
[02:23] <ogra> edubuntu is always a little later ... :)
[02:23] <jdub> oh, suuuure :-)
[02:23] <ogra> i dont want to break traditions :P
[02:28] <jdub> Kamion: http://people.ubuntu.com/~jdub/2005/fontconfig-dejavu.diff
[02:28] <jdub> oh
[02:28] <jdub> obvious problem there
[02:28] <jdub> will fix
[03:09] <pef> ogra: have you time to answer a question about a bug in Breezy ?
[03:09] <ogra> sure
[03:09] <ogra> its sunday, i'm only slacking around here :)
[03:09] <pef> ogra: thanks :) the problem is with phpmyadmin https://launchpad.net/distros/ubuntu/+source/phpmyadmin/+bug/5904
[03:10] <pef> yada is used to generate debian/*stuff, and yada version on Breezy is buggy, and generate a buggy prerm script
[03:10] <pef> Dapper's version of yada works fine
[03:11] <pef> what can I do to correct that ? backport yada or write a patch for yada in Breezy so it can generates a correct prerm script ?
[03:11] <pef> (writing the patch is very easy)
[03:11] <pef> (i wrote it and asked to debian author to check it to be sure it's harmless and doesn't broke something else)
[03:12] <pef> is it the right way ? :)
[03:13] <fabbione> pef: breezy is not going to be updated.. tought
[03:13] <ogra> askink a cluefull person is always good ;) 
[03:13] <pef> fabbione: isn't it a serious bug ?
[03:13] <ogra> fabbione, he asks about backorts
[03:13] <ogra> *backports
[03:13] <fabbione> pef: noooo?
[03:13] <fabbione> ah backports...
[03:14] <fabbione> whatever :)
[03:14] <fabbione> just don
[03:14] <pef> so an unremovable package isn't a serious bug ?
[03:14] <fabbione> just don't backport the kernel and toolchain
[03:14] <fabbione> pef it's in universe :)
[03:14] <fabbione> it's MOTU's business
[03:15] <fabbione> in main it would have been fixed before release probably
[03:15] <pef> fabbione: i'm not sure MOTU are able to upload to breezy-updates
[03:15] <ogra> pef, please check what might be affected by a backport, if you can make sure it doesnt require a transition and it doesnt break anything, talk to jdong_ about it ...
[03:16] <pef> ogra: isn't a patch agains breezy-version a better way ?
[03:16] <pef> against
[03:16] <fabbione> to fix something like that, you need to fix yada and all packages that B-D on it
[03:16] <fabbione> it's not something you can just do for one
[03:17] <ogra> if its fixed in dapper and doesnt require a transition (as fabbione points out), then it should be fine
[03:17] <pef> fabbione: but if yada is backported, all packages B-depends packages need to be rebuild too
[03:17] <ogra> exactly
[03:17] <fabbione> pef: that's exactly what i said
[03:17] <ogra> thats what we call a transition
[03:18] <fabbione> i personally don't think it's worth the trouble
[03:18] <ogra> seems yada doesnt have any rdepends beyond its own -doc packages
[03:19] <fabbione> ogra: B-D don't show in rdepends
[03:19] <ogra> oh, yes
[03:19] <ogra> silly me
[03:19] <fabbione> you need to you use melanie i think
[03:22] <pef> ok, ogra fabbione thanks for the info
[03:23] <Lathiat2> melanie?
[03:24] <ogra> the sister of britney and anastacia ... ;)
[03:24] <Lathiat2> yeh but like, how do i use it?
[03:24] <ogra> and all the other nice girls that ease your developer lifes
[03:24] <Lathiat2> like, its not an apt-get or apt-cache command
[03:24] <fabbione> Lathiat2: like all the other girls :)
[03:24] <ogra> s/your/our/
[03:25] <Mithrandir> you can grep-dctrl Sources.
[03:25] <fabbione> Lathiat2: it can run only on a full archive
[03:25] <fabbione> afaik
[03:37] <sivang> Riddell: ping, has krusader made it into main Kubuntu already ?
[03:38] <Pygi> hi hi
[03:38] <Riddell> sivang: no, and it isn't seeded to do so
[03:41] <fabbione> infinity: your attempt to make archive installable didn't succeed.. nautilus isn't happy yet
[03:41] <Pygi> hi fabbione
[03:42] <fabbione> hi Pygi 
[03:44] <sivang> Riddell: I see, it's planned to make it into main or are there any issues with that? (/me looks from Inclusion Report if any(
[03:45] <Riddell> sivang: there's a main inclusion report, the krusader guys sent me a pleading e-mail asking for it to be included
[03:45] <Riddell> sivang: but the sources didn't even build with builddir != sourcedir and it pops up about 3 really nasty error dialogues on first run so I'm not convinced it belongs in main
[03:46] <Riddell> sivang: what's your interest?
[03:53] <sivang> Riddell: krusader guys sitting next me threatning to hit me with blunt objects if it doesn't make it into main :) I'll forwrad them your comment :-D
[03:54] <sivang> Riddell: other then that, I am familiar with the tool , and liked ti when I was using KDE. I figured Kubuntu could make good use of it, if it's becomes main quality
[03:55] <jdub> Kamion: when do you think the next ubuntu-meta spin will be?
[03:55] <sivang> Riddell: (I am currently mostly using GNOME)
[03:57] <ogra> jdub, just do it :)
[03:57] <jdub> meh, no way
[03:58] <ogra> why ? 
[03:58] <ogra> if you changed the seeds ... make sure the metapackage matches it ;)
[03:58] <jdub> didn't eat my spinach this morning
[03:58] <ogra> aiee ... yes, thats a valid reason :)
[04:01] <Riddell> any ubuntu users able to supply me with their /etc/xdg/menus/ directory?
[04:02] <tseng> a dir listing, or a tarball?
[04:02] <ogra> a flight 2 one ? 
[04:02] <Riddell> tseng: tar
[04:02] <Riddell> ogra: yes
[04:04] <Kamion> jdub: dejavu> I think my main caveat would be to make sure to test it with CJK scripts
[04:04] <ogra> Riddell, http://people.ubuntu.com/~ogra/xdg.tgz
[04:05] <Riddell> muchos gracias
[04:05] <jdub> Kamion: i don't believe it includes any CJK glyphs, so shouldn't have an impact
[04:05] <Kamion> jdub: ubuntu-meta> any time you like; I can do one on Monday easily
[04:06] <Kamion> jdub: on the gfxboot timeout countdown to doomsday thing, would just ripping out the graphical clock and displaying "Computer will boot automatically in %d seconds" (or some similar text) be OK?
[04:06] <jdub> worth a try
[04:07] <Kamion> Treenaks' bug is something to do with a strange race in the clock, I think, and it would simplify my life a lot if I could just kill all the complexity there
[04:07] <Treenaks> Kamion: sounds scary
[04:08] <Kamion> it's almost as if a timeout is triggering before the clock data structures have been properly set up
[04:08] <Kamion> that should be impossible from my understanding of gfxboot, but it's difficult code
[04:08] <Treenaks> Kamion: it _is_ a 2.13GHz machine.. but I guess some people are installing on faster systems
[04:09] <Treenaks> Kamion: (lots of people, actually)
[04:09] <Kamion> I did a lot of the testing on a 1.8GHz amd64 box
[04:09] <Kamion> so it must be a pretty tight race, if that's what it is
[04:10] <Kamion> anyway, if I kill the clock, then the timeout handler will just be a bit of screen-painting, and there shouldn't be a problem no matter what it is
[04:10] <Treenaks> so I should try tomorrow's daily?
[04:11] <ogra> i tested on my 2.1Ghz lappie here ... no probs so far ...
[04:11] <Kamion> no, today is Sunday and I have my stepson's carol service this afternoon
[04:11] <Kamion> please don't expect me to work weekends, even if I do bits and pieces sometimes :P
[04:11] <Treenaks> Kamion: ok, I'll wait for it :)
[04:12] <jdub> geez
[04:12] <jdub> it's 19th of december
[04:12] <ogra> not here
[04:12] <slomo_> is someone here who can test building mono for me on ppc64?
[04:12] <jdub> i think we're being sucked into a black hole and time is appearing to speed up
[04:13] <jdub> only our metaphysical consciousnesses aren't speeding up with it
[04:13] <ogra> yeah, thats typical before christmas ...
[04:20] <fabbione> ops
[04:23] <fabbione> hey zul
[04:24] <zul> hey fabbione how goes it?
[04:25] <fabbione> zul: fine thanks and you?
[04:25] <zul> fabbione: good...just fiddling with grub as usual
[04:25] <zul> amongst other things
[04:37] <Amaranth> who do i have to poke to get http://gnome-look.org/content/show.php?content=32659 in dapper? :)
[04:39] <ogra> Amaranth, ????
[04:39] <ogra> thats in since weeks
[04:39] <Amaranth> i don't see how
[04:39] <Amaranth> he just released it
[04:39] <ogra> we have the prerelease, but it will get updated
[04:40] <Amaranth> err, this is the first time he released anything to anyone
[04:40] <Amaranth> this isn't the engine, this is the metacity theme
[04:41] <rewley> does anyone know anything about ssl certificates on the ubuntu.com webservers?
[04:42] <Amaranth> they aren't official, they expired, etc
[04:43] <rewley> yep, i'm wondering who needs to be (in your words) poked?
[04:43] <Amaranth> they've always been like that
[04:44] <rewley> it would be nice, though, not to have to tell people "ignore those warnings that your browser is spewing at you"
[04:46] <Amaranth> true
[04:48] <BenC> fabbione: still getting bug reports that claim broken 2.6.12-10, but work with 2.6.12-9...one was a amd64 bug about GPF's at random, another is hibernation randomly broken
[04:49] <fabbione> BenC: yes.. reading on #u-k
[04:50] <BenC> yeah, wrong channel :)
[05:29] <hunger> Could somebody please rebuild beagle? It searches for libedataserver-1.2.so.4 and can't find it:-(
[05:30] <tseng> beagle was last build 2 days after evolution
[05:30] <tseng> hm no
[05:30] <tseng> same day
[05:32] <hunger> tseng: I wonder why it needs evo at all... damn gnome stuff... they don't stop coding till everything depends on evo:-(
[05:32] <ogra> because it indexes your email ?
[05:33] <tseng> it works for me dude
[05:33] <tseng> besides that the evo backend is a seperate package now
[05:33] <hunger> ogra: I had expected that to be done in beagle-backend-evolution.
[05:33] <ogra> so you are probably installing the wrong package :)
[05:33] <hunger> ogra: And even if it worked with evo it would still not find my mail:-(
[05:34] <ogra> it does find mine... just use the right mail proggy ;)
[05:34] <ogra> or write a backend for yours ;)
[05:34] <hunger> ogra: You are right... once I remove beagle-backend-evolution it does index stuff for me.
[05:55] <slomo_> lamont: ping?
[05:55] <siretart> what is ryhtmbox using for playing audio?
[05:55] <tseng> siretart: gstreamer
[05:55] <siretart> und wtf does it not respect my ~/.asoundrc?
[05:56] <siretart> it insists on playing on my onboard soundchip instead of using my nice sb live
[05:56] <tseng> it could be using esd or oss
[05:56] <slomo_> siretart: do you use alsa output sink or the default esd one?
[05:56] <siretart> slomo_: where do I set the output sink?
[05:57] <tseng> system - prefs - sound and system -prefs - multimedia
[05:57] <tseng> you can set the sound card and the sink
[05:57] <siretart> I dond find a 'sound and system' item
[05:57] <slomo_> siretart: gstreamer-properties
[05:57] <siretart> only 'audio', and I cannot set it there
[05:58] <tseng> erm
[05:58] <tseng> and means AND
[05:58] <tseng> its two apps
[05:59] <siretart> doen't change anything :(
[05:59] <siretart> aah, sorry, it did
[05:59] <siretart> thanks!
[05:59] <siretart> weird
[06:00] <siretart> thanks tseng and slomo
[06:00] <slomo_> np :)
[06:42] <zul> jbailey: ping
[06:54] <aroman> anyone else having X problems sayiung "Failed to load module "GLCore"", basically bug #20582, https://bugzilla.ubuntu.com/show_bug.cgi?id=20582 ?
[06:54] <aroman> saying*
[06:54] <jbailey> zul: pong, just got home.
[06:55] <Pygi> aroman: well, have you installed OpenGL and graphic card drivers?
[06:55] <zul> jbailey: i made a couple of changes to grub ill send you the diff in an email to both you and colin
[06:55] <aroman> Pygi, well, I suppose... I use the ati driver (not fglrx)...
[06:55] <jbailey> zul: Cool.
[06:55] <jbailey> zul: Are you an Ubuntu member yet?
[06:56] <zul> yeah i am
[06:56] <Pygi> arinab; use fglrx
[06:56] <Pygi> it won't work other way
[06:56] <jbailey> zul: 'kay.  So at the meeting in January, we should put you in the queue for main upload privs after we're done reviewing grub.
[06:56] <aroman> Pygi, why not?
[06:56] <zul> jbailey: according to launchpad i havent signed the coc yet which is bull
[06:57] <jbailey> If you have a GPG key, you can just sign it again.
[06:57] <Pygi> aroman: because ati drivers are very bad, and don't work nowhere
[06:57] <zul> *sigh*
[06:57] <jbailey> Mine had said that I hadn't signed it either, and it was simplest to just do it again.
[06:59] <ogra> jbailey, zul is MOTU as long as i am ... 
[07:00] <aroman> Pygi, really? they work fine on gentoo, better than fglrx ones for that matter
[07:00] <jbailey> ogra: Cool.  I wasn't sure if he had bothered doing the whole motu thing.  I was running short of time, so stopped following the motu channels, lists and meetings.
[07:01] <aroman> Pygi, notice the bug report I pasted here mentions the fglrx drivers
[07:01] <zul> jbailey: that was more than a year ago i think
[07:01] <ogra> jbailey, since he wnt off to the kernel team i dont think zul has done much motu work :)
[07:01] <zul> i havent really..
[07:02] <zul> im just a wannabe
[07:02] <Pygi> aroman: I have ATI card too
[07:03] <aroman> Pygi, and glxinfo | grep rendering shows Yes for dri?
[07:03] <ogra> zul, ah, come on... we'd have a lot more kernel bugs without you ;)
[07:04] <zul> heh...BenC is just doing fine himself ;)
[07:05] <Pygi> aroman: if you by reffering to DRI mean to "direct rendering" then yes, it does show yes
[07:05] <aroman> hmm
[07:05] <aroman> odd
[07:05] <aroman> with the latest dapper drake updates, I assume?
[07:06] <Pygi> nop, breezy
[07:07] <Pygi> I am running dapper on another computer, but I ain't really trying to help people with dapper ;)
[07:07] <Pygi> read the topic on #ubuntu - no support for dapper ;)
[07:08] <ogra> Pygi, ??
[07:08] <aroman> Pygi, aye, no support, but -devel channel, we've gotta figure out why it's messing up right? :)
[07:08] <Pygi> aroman: yup ;)
[07:08] <aroman> Pygi, why would I ask about breezy on a -devel channel? :)
[07:09] <aroman> hmmm I wonder if a package isn't installed....
[07:11] <aroman> bah.. I need to go... gonna investigate this further tomorrow
[07:11] <Pygi> k
[07:11] <Pygi> ogra: why the question marks? ;)
 read the topic on #ubuntu - no support for dapper ;)
[07:12] <ogra> #ubuntu is the proposed supportchannel for all versions we ship ...
[07:12] <Pygi> well, I think there is no support for dapper....isn't that true?
[07:12] <Pygi> yes, but dapper isn't ready just yet...
[07:12] <ogra> still 
[07:12] <ogra> all support should happen there
[07:12] <ogra> even for dapper
[07:12] <Pygi> ah, k
[07:12] <Pygi> sorry for the mixup then
[07:13] <ogra> as well as no support should happen here :)
[07:13] <Pygi> k
[07:14] <zul> jbailey: i should have something for you tonight but i have to write documentation for work
[07:14] <jbailey> zul: Awesome, thanks!
[07:16] <zul> later
[07:42] <Pygi> *we* really have to fix the keyboard layout thingy
[07:42] <Pygi> it's getting annoying
[07:43] <Pygi> not to me, but to the others...
[08:19] <LaserJock> seb128: ping?
[08:30] <seb128> LaserJock: pong
[08:31] <LaserJock> seb128: been trying to dig around trying to figure out where that compreg.dat file came from
[08:31] <seb128> LaserJock: any luck?
[08:31] <LaserJock> not really
[08:31] <LaserJock> I did dpkg -S on it and got nothing
[08:32] <seb128> it's not shipped by a package
[08:32] <seb128> it's generated by something
[08:32] <LaserJock> I greped /var/lib/dpkg/info for it and didn't get much of anything
[08:32] <seb128> I guess I'm going to write a small monitor stuff than opens a dialog when the file is create
[08:32] <seb128> created
[08:32] <LaserJock> somebody suggested it might be in a posinst script
[08:32] <LaserJock> seb128: good idea
[08:33] <LaserJock> could it be possible that it was created by a package at one time but is no longer so it doesn't show up with dpkg -S and such
[08:33] <seb128> nop
[08:34] <seb128> dpkg is not that bugged
[08:34] <seb128> if a package stop shipping a non-conffile it removes it on upgrade
[08:35] <LaserJock> hmm, seems like an extension would be a likely culprit perhaps
[08:36] <LaserJock> well, has anybody figured out what is wrong with the  compreg.dat file that gives the problem, or is it just its presence that is the problem
[08:36] <seb128> second option
[08:37] <LaserJock> really? that seems weird
[08:37] <seb128> why?
[08:37] <seb128> the file is not required
[08:38] <seb128> you can remove it and firefox works fine
[08:38] <seb128> and firefox 1.5 doesn't ship any such file
[08:39] <LaserJock> but it just seem weird that the presence of the file causes a problem. Oh, well I'm not very knowledgeable about such things
[08:40] <LaserJock> so in /var/lib/dpkg/info it says that the firefox.prerm script removes it. Why would it do that if it didn't install it in the first place?
[08:40] <seb128> leftover of 1.0.n 
[08:41] <LaserJock> ahh, ok
[08:42] <LaserJock> well, is there any output that I can give that would be useful? I am at the end of my abilities of finding where the file came from :-)
[08:43] <seth_k|lappy> compreg.dat is a component registry file
[08:43] <seth_k|lappy> it's an Extensions thing; you only get it if you have Extensions installed
[08:45] <LaserJock> so what is that a bug in if it breaks apps (like yelp)?
[08:46] <daniels> right, which I think firefox's postinst regenerates in its install
[08:46] <daniels> LaserJock: it's a bug in mozilla for being crap
[08:46] <daniels> so, y'know, news at eleven
[08:47] <seb128> LaserJock: not easy to reply to that without knowing what creates the file/when/how
[08:48] <LaserJock> well, all I know is that I have extensions installed on the install that has the problem and no extensions installed on the one that works
[08:48] <seth_k|lappy> compreg.dat basically keeps track of compatibility between components and interfaces in Firefox code, and external programs / extensions / whatever. According to http://www.mozilla.org/projects/firefox/extensions/restart.html it's trashed and recreated on Firefox startup if compatibility.ini has changed
[08:50] <seb128> seth_k|lappy: how comes it get generated to /usr, seems to be an user file according to your description
[08:52] <LaserJock> but many extensions ask to install as root in order to work properly
[08:54] <daniels> christ that's broken
[08:54] <seb128> firefox is such crap
[08:54] <seth_k|lappy> right, and when it then tries to write to the file on the next startup, b/c it's been written somewhere that a normal user can't access, things go nuts
[08:54] <seth_k|lappy> from what I can tell
[08:54] <seb128> anyway the bug happens to some people who use epiphany and not firefox and have no extension installed it seems; so I'm not sure that's the issue
[08:55] <daniels> iz epiphany bug
[08:55] <seb128> iz GTK bug rather
[08:55] <seb128> because it crashes yelp/debhelp/python-gnome too
[08:55] <daniels> definitely :)
[08:55] <daniels> just as long as it's not an XKB bug
[08:55] <daniels> seb128: gecko bug?
[08:55] <seb128> s/debh/devh/
[08:55] <seb128> daniels: gtkembedmoz bug yep: http://bugzilla.ubuntu.com/show_bug.cgi?id=20183
[08:56] <seb128> aka firefox bog
[08:58] <seb128> anyway time for dinner
[08:58] <seb128> bbl
[09:09] <HiddenWolf> hey Yvonne 
[09:10] <Yvonne> hey HiddenWolf :)
[09:31] <HiddenWolf> I just checked the dapper package page, and it seems Mozilla-thunderbird-locale-el and -es are in universe. All others are in main.
[10:00] <ogra> grrr, i'm about to kill someone ...
[10:01] <ogra> has nobody told debian maintainers that you dont modify upstream tarballs ?
[10:02] <Pygi> heh, don't kill people ;)
[10:02] <ogra> kino_0.80-1ubuntu1_source.changes REJECTED: kino_0.80.orig.tar.gz has size 1512542 instead of expected 1498967
[10:02] <daniels> sure you modify upstream tarballs
[10:03] <daniels> you remove non-dfsg-free stuff
[10:03] <ogra> why the heck do they remove stuff directly in the upstream tarball, even the package uses dpatch and it would be an easy task to use it
[10:03] <ogra> there is no non-dfsg-free stuff being removed 
[10:04] <ogra> there is stuff like includes to lqt instead of lquicktime being changed in configure and configure.in
[10:04] <ogra> stuff that belons in a patch ...
[10:09] <micke1234> Hi, I just dist-upgraded to dapper from breezy and now my xserver won't start, I am getting the error "lib
[10:09] <micke1234> libc_wrapper invalid FILE passed to xf86printf?
[10:09] <daniels> "lib"?
[10:09] <daniels> at a guess, it can't open your logfile
[10:09] <micke1234> sorry I hit Enter to soon
[10:10] <micke1234> wait, I go check the permissions of the logfile
[10:10] <Kamion> ogra: it has been Debian policy for some time that DFSG-free material must be entirely removed, not merely patched out
[10:10] <daniels> and you are running the server as root, right?
[10:10] <Kamion> but sure, random other stuff should be patched
[10:10] <ogra> Kamion, but there are no dfsg changes ... its mainly includes etc ...
[10:10] <micke1234> I run my server from the gdm scripts... (sudo /etc/init.d/gdm restart)
[10:11] <ogra> Kamion, what really bothers me is that the package already has 8 dpatches... but they didnt use dpatch for this one ... :(
[10:11] <micke1234> the message appears in my logfile also, so it cannot be the logfile
[10:12] <Kamion> ogra: so it was almost certainly an accident
[10:12] <ogra> is there a way to wipe our orig.tar.gz from the archive to be able to upload the debian one ? else we'll have to carry a silly patch for the whole 0.80 release
[10:14] <daniels> 'silly patch'
[10:14] <daniels> micke1234: if you could file a bug with the full Xorg.0.log, that would be ininice
[10:14] <daniels> micke1234: bonus points if you're able to attach a sudo strace -e file Xorg :1 -ac vt8, showing which file it's failing to open
[10:15] <floam> hm. is not all of Xorg 6.99.99.903 up?
[10:15] <micke1234> daniels, I no going after the bonus points...
[10:15] <daniels> floam: the server isn't
[10:15] <daniels> but rc3 is old hat
[10:15] <tseng> daniels: are we using dlloader now?
[10:15] <floam> why is the server held back?
[10:15] <daniels> tseng: the modular tree is incapable of elfloader support
[10:16] <tseng> thats pretty rad
[10:16] <daniels> floam: because it was fucked
[10:16] <floam> hm
[10:16] <daniels> tseng: (by design)
[10:16] <floam> I guess that's why my mouse still acts weird, perhaps I need the RC3 server.
[10:16] <micke1234> daniels, I get "strace: invalid system call +file when I try your command
[10:16] <tseng> daniels: good riddance to that
[10:16] <daniels> micke1234: works for me?
[10:17] <daniels> floam: correct
[10:17] <micke1234> "strace -e +file Xorg :1 -ac vt8" does not work for me? strace --version gives me: 4.5.12
[10:18] <daniels> ... there's no + in file
[10:18] <Kamion> ogra: no, under no circumstances do we *ever* replace a file in the pool with a different file having the same name
[10:19] <ogra> Kamion, thats what i feared :/
[10:19] <Kamion> this is a good thing
[10:19] <ogra> not in this case though ...
[10:19] <Kamion> doing otherwise would severely break a lot of mirrors
[10:19] <daniels> dude, if it really seriously bothers you, bump the upstream version
[10:20] <floam> guess I'll suffer with mousedev for another while
[10:20] <ogra> daniels, never ... the i rather build a patch
[10:20] <micke1234> daniels, sorry for that ircII is kind of new to me (it adds + to a wrapped line)
[10:20] <ogra> even if its not necessary ...
[10:20] <daniels> ogra: i'm sure there are worse things
[10:20] <Kamion> it won't kill you
[10:20] <Kamion> snap :)
[10:20] <ogra> nah, its just annoying and eats extra time i didnt want to invest ...
[10:21] <daniels> arguably you've spent more time talking about iton IRC than you would've fixing it :P
[10:21] <ogra> and its a bit frustrating to be bitten by the merge policy, just because i took the unmodofied upstream and was faster than debian
[10:21] <janimo> anybody know what this given-back is about? http://people.ubuntu.com/~lamont/buildLogs/x/xubuntu-default-settings/0.2/
[10:22] <Kamion> it's not the merge policy, it's a requirement on the archive in order to actually work properly
[10:22] <Kamion> complaining will not get it changed because changing it would be bad
[10:22] <ogra> Kamion, the kino 0.7 series didnt work with the new gtk we use, and debian released 0.80 last week ...
[10:22] <micke1234> daniels how to I pipe the output from strace to a file it's printing on stderr
[10:22] <daniels> the lesson for this is, next time if you desperately need a new upstream for something, either donate it to debian or just deal when it's different
[10:22] <daniels> micke1234: > foo 2>&1
[10:22] <Kamion> ogra: I don't care about the details :)
[10:23] <ogra> Kamion, so i had to package 0.80 before debian to get the merge done in time
[10:23] <Kamion> ogra: I still don't care
[10:23] <micke1234> daniels thanks
[10:23] <ogra> which i call being bitten by our merge policy :P
[10:24] <Kamion> 21:21 < daniels> arguably you've spent more time talking about iton IRC than you would've fixing it :P
[10:24] <Kamion> what he said
[10:24] <Kamion> seriously, it's not worth arguing about
[10:24] <daniels> except possibly with a space between 'it' and 'on'
[10:26] <micke1234> daniels, I just tried the "nv" driver instead of "nvidia", now it is working...
[10:26] <eruin> I suffer hardlocks on ati, but fglrx works like a charm (apart from GLcore failing to load) :)
[10:27] <daniels> micke1234: cool, someone else's problem ;)
[10:27] <daniels> eruin: glcore failing to load is a 'don't do that' problem, i.e. don't load glcore from your xorg.conf explicitly
[10:27] <micke1234> daniels, still it kind of stinks, because I cannot what stuff on my projector then (using TwinView)
[10:28] <micke1234> daniels, the strace didn't give me any clue about which file is failing, everything looks fine
[10:29] <lucasvo> janimo: I have problems with xfce, it doesn't use the keyboardlayout defined in xorg.conf
[10:29] <micke1234> daniels, I brb, I'm switching into X...
[10:30] <Kamion> daniels: default installations put GLcore in xorg.conf
[10:30] <janimo> lucasvo, I am looking at the xkb plugin right now
[10:31] <janimo> did you add the keyboard switch suggestion to the wiki btw?
[10:34] <mikael_> Hi daniels, I'm back :)
[10:34] <eruin> suspend now works with fglrx
[10:34] <daniels> Kamion: shit, still does; i thought we explicitly excluded that
[10:35] <micke1234> I just upgraded to dapper, no my sound is not working and the programs menu is empty...
[10:35] <daniels> micke1234: please use #ubuntu for this sort of thing
[10:35] <seb128> the menu stuff is to bugzilla already
[10:35] <lucasvo> janimo: what, keyboardswitch?
[10:36] <micke1234> seb128, do you know the bugnumber? or a quick workaround?
[10:36] <janimo> lucasvo, ok so it wasn't you :)
[10:37] <janimo> someone just added to xubuntu proposed apps a couple of keyboard swicthers and I thought it might have been you since you have a kb issue 
[10:37] <lucasvo> daniels: how can I find out if the monitor is sending right ddc constants, when you only have an Xlog?
[10:37] <seb128> micke1234: restart gam_server
[10:37] <lucasvo> janimo: I have a kb issue with xfce and ltsp
[10:37] <janimo> lucasvo, so in what way does it not use xork keymap?
[10:37] <lucasvo> janimo: it is totally wrong, it is us instead of ch_de
[10:37] <daniels> lucasvo: most of them dump the edid in human-readable form
[10:38] <janimo> what I know about keymaps is what I read in the past 5-10 minutes with interruptions btw :)
[10:38] <lucasvo> daniels: I am talking about this bug: http://bugzilla.ubuntu.com/show_bug.cgi?id=17232
[10:38] <janimo> lucasvo, could have been korean, consider yourself lucky :)
[10:38] <lucasvo> janimo: my sister is not lucky :D
[10:39] <janimo> I'll have to test keymaps as I always use the US layout
[10:39] <daniels> lucasvo: it's all there
[10:39] <janimo> I'll look at it tomorrow
[10:39] <daniels> starting at the line which reads (II) MGA(0): VBE DDC Monitor info: 0x85eab40
[10:39] <daniels> it's deliberate policy to only use the second-highest resolution on CRTs
[10:39] <daniels> since the highest often looks like crap
[10:40] <lucasvo> daniels: so it is missing in Xorg, that it autodetects it wrong?
[10:40] <janimo> lucasvo, breezy or dapper?
[10:40] <daniels> no, it's a decision I made when I wrote xresprobe
[10:40] <lucasvo> daniels: huh?
[10:40] <daniels> lucasvo: xorg doesn't do the detection, strictly speaking, xresprobe does
[10:40] <daniels> and on crts, we don't use the highest resolution
[10:40] <lucasvo> daniels: aparently it is a tft
[10:41] <lucasvo> daniels: 15 inch :D
[10:41] <daniels> if your monitor advertises 1024x768@60 and 800x600@60, as yours does, we'll use 8000x600
[10:41] <lucasvo> daniels: hm, but even if it is tft 15" ?
[10:41] <lucasvo> daniels: because 800x600 on 15 inch is waste of space
[10:41] <daniels> (II) MGA(0): Analog Display Input
[10:42] <daniels> that's all we can go by
[10:42] <daniels> lucasvo: 8x6 on 15" isn't that bad a waste of space
[10:42] <daniels> lucasvo: your eyes are good and so are mine.  ask someone who doesn't have flawless eyesight what they think of 10x7.
[10:43] <lucasvo> daniels: so they should then be able to set it, or do you use 800x600 for your 15" monitor?
[10:44] <lucasvo> tseng: the problem is I am using it for ltsp, and there it autodetects it at startup
[10:44] <daniels> lucasvo: i don't have a 15" monitor
[10:45] <lucasvo> daniels: so how comes that every other 15" I have uses 1024x786, even with xorg autodetection?
[10:49] <daniels> lucasvo: because they advertise 1024x768 at a higher refresh rate
[10:49] <daniels> well, at more than one
[10:50] <daniels> i didn't say the lagorithm was *good*
[10:50] <lucasvo> daniels: and is there any table for "special" cases, where one doesn't calculate it from the refreshrate
[10:50] <lucasvo> ?
[10:51] <lucasvo> daniels: so it is basically a WONTFIX bug?
[10:51] <daniels> well, patches are welcome
[10:51] <daniels> but it's served us pretty well over the years
[10:51] <daniels> especially within the limitations of xorg
[10:51] <lucasvo> daniels: is there already something like a table for special cases
[10:52] <lucasvo> I can't say anything about it, I don't know X
[10:52] <daniels> there's no table for special cases, no
[10:52] <daniels> i'm not inclined to add one, to be honest
[10:52] <lucasvo> daniels: so how should I change the algorythm? or apply a patch?
[10:52] <daniels> unless dell ships some monitor that half the planet buys, and its edid is so spectacularly broken that it makes the monitor explode into tiny little glass fragments which shoot into everyone's eyes
[10:53] <lucasvo> lol
[10:53] <daniels> lucasvo: look at /usr/share/xresprobe/ddcprobe.sh
[10:53] <lucasvo> I know, such a table is crap but maybe the easiest solution
[10:53] <daniels> tbh I don't see a real problem
[10:54] <daniels> for you rfor your use, if you want 10x7 on 15", sure
[10:54] <daniels> but when 'best resolution' is totally subjective anyway, it's not really useful for the common case
[10:54] <lucasvo> 8x6 is so blurry, you can't read it
[10:55] <daniels>           score
[10:55] <daniels> (argh, worst irssi misfeature ever.)
[10:55] <lucasvo> I don't think I aman uncommon case
[10:55] <lucasvo> yes
[10:55] <lucasvo> what's with score?
[10:56] <daniels> score == 'awesome'
[10:56] <lucasvo> yes
[10:56] <daniels> and, er, hate to break it to you, but ltsp is still a pretty uncommon case
[10:56] <daniels> it's also a case which by definition includes local admins
[10:56] <daniels> as opposed to 'must must must must work out of the box on cd install'
[10:56] <lucasvo> daniels: no, but xorg auto detection is not only on ltsp
[10:57] <lucasvo> daniels: it is also on must must must must work out of the box ubuntu install
[10:57] <greenpenguin13> greenpenguin13: hi
[10:57] <daniels> correct
[10:57] <daniels> i mean, if you want to send a patch with a special case for this exact monitor, including the patched edid, feel free
[10:58] <daniels> but it's not high on my todo list, y'know
[10:58] <lucasvo> no prob
[10:58] <lucasvo> now I know the reason
[10:59] <lucasvo> daniels: you mean something like: if $monitorname == "sdm": $resolutions="1024x768"
[10:59] <lucasvo> daniels: I think it would be pretty much the only thing to do :D
[10:59] <daniels> you'd want the match to be a little more strict than that
[11:00] <lucasvo> daniels: sdm-(II) MGA(0): Monitor name: SDM-M51 so SDM-M51 should be enough?
[11:01] <daniels> also match on manufacturer and model
[11:01] <daniels> and the exact resolution list it spits out
[11:02] <lucasvo> daniels: why, is there any other screen which name is sdm-m51
[11:02] <lucasvo> sony would sue the company anyway
[11:02] <daniels> lucasvo: what on earth?
[11:02] <daniels> no-one else has the right to name a monitor sdm-m51?
[11:02] <daniels> it's entirely conceivable that there is
[11:03] <lucasvo> daniels: ok
[11:04] <lucasvo> daniels: thanks for your help
[11:04] <daniels> np
[11:05] <lucasvo> daniels: if I will give you patch which meats all the requirements, will it be added to dapper ? :p
[11:06] <daniels> probably
[11:06] <daniels> but no guarantees
[11:06] <lucasvo> daniels: np