[12:03] <desrt> this is hilariously cool
[12:03] <desrt> acpi is rapidly ascending my list of cool things
[12:04] <jdub> okay
[12:04] <jdub> we need to send desrt away on holiday
[12:05] <infinity> ACPI would be pretty cool if there was a single hardware manufacturer that actually got it right.
[12:06] <desrt> i agree.
[12:06] <infinity> Getting it "almost right" and then having Microsoft fix it via software updates doesn't count.
[12:06] <mjg59> Most vendors get it fine nowadays
[12:06] <infinity> Though I would kill for Microsoft's big database of DSDT fixes.
[12:06] <mjg59> Linux, on the other hand, really still doesn't
[12:07] <desrt> mjg59 is here
[12:07] <infinity> mjg59: My impression seems to be that we follow the spec well enough in most cases, but we don't have nearly enough workarounds in place to compete with Windows.
[12:07] <infinity> mjg59: But I'm willing to believe we also break spec occasionally.
[12:08] <mjg59> We demonstrably break spec in a couple of ways that probably don't matter
[12:08] <mjg59> But then we come up against issues like the fact that Windows has just adopted the ACPI world while Linux tries to work without it when possible
[12:08] <mjg59> So we get weird interrupt routing conflicts
[12:09] <mjg59> VIA interrupt routing is still slightly fucked on ACPI systems
[12:09] <mjg59> Because their APIC behaves slightly different to Intel ones
[12:10] <infinity> Well, in Windows, it's an all-or-nothing thing.  You either have an "ACPI PC" or a "Legacy PC", and everything is defined from there.
[12:10] <\sh> infinity: in windows it's: "I have a windows pc"
[12:10] <infinity> Which cause no end of issues when ACPI was still shiny and new, and I was constantly holding down F7 (I think?) during windows installs to say "nu uh, don't use ACPI"
[12:10] <infinity> \sh: No, very not true.
[12:11] <mjg59> Suspend/resume is (generally) broken because our drivers are fucked
[12:11] <\sh> infinity: for the plain windows user it is] 
[12:11] <infinity> The "plain" windows user gets their machine shipped with Windows pre-installed by an OEM who should know what the sanest configuration is.
[12:12] <infinity> When doing it yourself, Windows is just as fragile as Linux, if not more (says the man who's just spent ~24 hours reinstalling Windows on a system, because it's grumpy with his hardware configuration)
[12:13] <\sh> infinity: right...but then, one day, she gets an ubuntu cd and no one is there to help her...
[12:13] <zul> get more oems then
[12:14] <infinity> Indeed, the solution to the "non-technical user" isn't to make our installer EVEN BETTER (I can tell you from the past day's experience, ours IS better), it's to get more OEMs shipping Linux pre-installed.
[12:15] <infinity> No amount of simple installation can replace an OEM pre-configuring a system "just right", so you don't have to.
[12:15] <desrt> ok
[12:16] <desrt> so i can't find anything in this DSDT about sleeping
[12:16] <desrt> the ACPI spec says i should see SLP_EN or SLP_TYP....
[12:16] <desrt> all i have is SLPB
[12:16] <mjg59> desrt: No, those are just registers
[12:16] <mjg59> They're defined in the fadt
[12:16] <desrt> but nothing in the code references them....
[12:17] <mjg59> No
[12:17] <mjg59> The kernel writes to them directly
[12:17] <\sh> Oh Lord, please send Michael Dell a message that he has to pre-install Linux on Desktops and not this 666 Redmond OS.
[12:17] <desrt> oh.
[12:17] <desrt> so ACPI specifies a register region where writes mean certain things
[12:17] <desrt> like sleep is done the same way on every laptop ever
[12:17] <mjg59> You call the _PTS and _GTS methods, and then the kernel writes to those registers
[12:17] <mjg59> Yeah
[12:18] <desrt> prepare to sleep?
[12:18] <mjg59> The registers aren't necessarily in the same place
[12:18] <mjg59> Prepare to sleep and going to sleep
[12:18] <\sh> who is in charge of the kernel these days (ubuntu-server)?
[12:18] <desrt> i have PTS but not GTS
[12:18] <mjg59> GTS is optional
[12:19] <desrt> i wonder what would happen if i booted a system with practically no drivers installed....
[12:19] <desrt> i seriously get the impression that some driver is screwing up
[12:19] <\sh> s/pc/apple IIe/ ?
[12:19] <desrt> i assume _WAK is what happens when it comes back
[12:19] <infinity> \sh: BenC, with occasional input from others. (mjg59 for all things ACPI and otherwise desktop shiny, Fabio for sparc, me for occasional server input and vga16fb breakage, crimsun for all things audio..)
[12:20] <mjg59> desrt: Yup
[12:21] <desrt> i wonder if PTS is what makes the light on the case start woobing
[12:21] <desrt> or if this is HW
[12:21] <\sh> infinity: ok...do you think it's possible to fix a problem in the scsi area, which let the areca controller not doing their work correctly? as well, the configuration management software for areca is segfaulting with the actual kernel of dapper (server)
[12:22] <\sh> infinity: to be more precise, 2.6.16 is fixing this problem and it's known by the areca patch maintainer afaik from our hardware oem support :)
[12:22] <infinity> \sh: File a bug, and explain it better that "not doing their work correctly", since I have several anecdotal reports that areca works just fine.
[12:22] <desrt> woh.
[12:22] <desrt> there's an OSYS field (operating system, i assume)
[12:22] <infinity> \sh: And put a pointet to the patch in the bug.
[12:23] <desrt> it gets initialised in _INI to different numbers depending on the OS
[12:23] <mjg59> desrt: The name OSYS is Apple specific, but yeah
[12:23] <mjg59> DSDT code can be platform specific 
[12:23] <Chipzz> hrrrm
[12:23] <mjg59> On the Macs, the only difference seems to be a small amount of HPET setup. No idea why.
[12:23] <desrt> if (darwin) 0x2710, if (linux) 0x3e8, else 0x7d1
[12:24] <\sh> infinity: ok, i'll try...
[12:24] <infinity> Chipzz: If you only found one, you're not looking very hard.
[12:24] <desrt> and an OSDW() function which gets called on wake up which checks this register
[12:24] <desrt> the check is LEqual(OSYS,0x2710), though... which assuming LEqual means what i think, darwin linux and 'else' match.
[12:25] <Chipzz> infinity: pretty nasty one in my case
[12:25] <Chipzz> but an easy fix I think
[12:25] <mjg59> 0x3e8 is a weird choice
[12:25] <desrt> oh.  logical equal.  ok.
[12:25] <desrt> so it does different things on wake up if the running OS is darwin
[12:25] <desrt> OSDW() must mean 'OS is darwin'
[12:26] <desrt> if osdw  \_sb.pci0.sbus.enab()
[12:26] <mjg59> Sounds smbus related
[12:26] <desrt> think it might be causing me to not wake up?
[12:27] <mjg59> If it is, probably only because of Linux bugs
[12:27] <desrt> you're becoming more jaded about linux :)
[12:27] <infinity> Linux is far from perfect.
[12:27] <Chipzz> infinity: the GUI allows "When laptop lid is closed" to be set to "nothing", but the gconf description of those keys doesn't have that value in it's list...
[12:27] <zul> heresy
[12:28] <Chipzz> I had those keys set to "nothing", and as a result, when opening the lid after closing it, X went in an endless crash-loop
[12:28] <sladen> Chipzz: can you file a bug please
[12:28] <Chipzz> I will
[12:29] <Chipzz> sladen: you the gnome-power-manager maintainer?
[12:32] <Chipzz> sladen: file the bug in launchpad or upstream? I noticed on one of the gnome-power-manager bugs that ubuntu has quite some changes wrt upstream, and upstream isn't very happy about that...
[12:33] <desrt> hmm
[12:33] <desrt> mjg59; what are these smbus _Qxx methods?
[12:33] <sladen> Chipzz: urm. Given how much time that g-p-m upstream (Richard Hughes) spends answering bugs on launchpad, we might have to disagree about that
[12:33] <mjg59> Not sure
[12:33] <desrt> mjg59; and what exactly happens if there's an error in the ACPI code?
[12:33] <sladen> Chipzz: please stop making up 'conflict' when there isn't one
[12:33] <mjg59> _ prefixed stuff is supposed to be standards
[12:33] <desrt> two _Qxx methods under Device (SMB0) call this PNOT() function which references undefined variables
[12:33] <mjg59> Erm, standardised
[12:34] <desrt> 5.6.2.2.2
[12:34] <mjg59> They may be defined in an SSDT
[12:34] <desrt> it has to do with getting a query number from the hardwre
[12:34] <desrt> "Embedded Controller Query and SMBus Alarm control method"
[12:34] <Chipzz> sladen: I read one of his comments where he expressed his frustration about chasing a bug that turned out to be ubuntu-specific
[12:35] <sladen> Chipzz: well yes.  But that's not "isn't very happy about" the changes
[12:35] <desrt>  // following is a method that OSPM will schedule after
[12:35] <desrt>  // it receives an SCI and queries the EC to receive value 7
[12:35] <desrt>  Method(_Q07) {
[12:35] <infinity> Chipzz: That particular grumpiness is has been long since sorted
[12:35] <infinity> s/is has/has/
[12:37] <Chipzz> then I'm probably making to much of an issue about it; it was just something that stuck in my mind
[12:38] <mirak> is there a way to run the installer from a runing ubuntu installation ?
[12:39] <infinity> mirak: Not "the installer", per se, but you can just bootstrap a chroot with "debootstrap", which may be what you're looking for.
[12:40] <mirak> infinity: I know deboostrap but don't like it
[12:40] <mirak> I fell it gives a partial installation
[12:40] <mirak> infinity: why couldn't I run the installer ?
[12:40] <infinity> Well, d-i just does debootstrap + install a bootloader + set up user/pass + install extra package selection (say, ubuntu-desktop) + reboot
[12:41] <mirak> I mean since it's runnable from a live cd, it must be runnable from a normal installation
[12:41] <desrt> infinity; if i inject my own DSDT into the initramfs is there a kernel commandline i can give to have it not load it?
[12:41] <mirak> infinity: it won't ask for timezone etcetera
[12:41] <desrt> infinity; just incase :)
[12:41] <infinity> mirak: ubiquity (the livecd installer) has some very specific requirements for what it installs from, requiring access to the read-only filesystem of the livecd, etc.
[12:41] <Chipzz> mirak: it is meant to give only a base install (or "partial installation", like you call it)
[12:42] <Chipzz> I can see nothing wrong with that?
[12:42] <infinity> desrt: Better off haking sure you have two kernels installed, and only mucking with the initramfs of one. :)
[12:42] <mirak> Chipzz: no but I did it for my actual system and I feel like it's broken
[12:43] <infinity> I debootstrap installs all the time, and they're never "broken".
[12:43] <mirak> infinity: ok about ubiquity.
[12:44] <mirak> so what's the exact procedure ?
[12:44] <mirak> as far as I remember I must install the kernels too
[12:45] <mirak> "Installing this package on a normal system is unlikely to be useful."
[12:45] <mirak> ok I will try anyway :)
[12:45] <infinity> debbostrap + install kernel and bootloader + install langpack (optional, obviously) + set up a user
[12:45] <mirak> and what about timezone plus locales etcetera ?
[12:45] <Chipzz> heh
[12:45] <infinity> tzconfig for timezones.
[12:46] <Chipzz> why doesn't https://launchpad.net/distros/ubuntu/dapper/+source/gnome-power-manager/+bugs list any bugs?
[12:46] <infinity> locales come from installing the langpack(s).
[12:46] <Chipzz> I just submitted one so there must be bugs
[12:46] <mdke> Chipzz: because launchpad bugs are targetted at the whole distro, not on dapper
[12:46] <mdke> for some crazy reason
[12:46] <Chipzz> also I see most recent bugs to the right after submitting my report
[12:46] <infinity> s,dapper/,,
[12:47] <infinity> And it's not particularly crazy to assume that a bug filed on dapper probably also applies to other releases.
[12:47] <Chipzz> this is silly :)
[12:47] <infinity> It would certainly apply to edgy, for instance. :)
[12:47] <Chipzz> just clicking on the wrong link may be causing a lot of users to submit duplicate bug-reports
[12:48] <mdke> infinity: i think there should be a better way of handling that, it's pretty crazy that the url for translations involves the "dapper/" while the url for bugs doesn't
[12:49] <infinity> mdke: I think it was a mistake to have the release in the URLs at all, TBH.
[12:50] <infinity> mdke: Bugs apply to package versions, not distro releases.
[12:50] <mdke> this is true
[12:50] <infinity> (ie: apache2 2.0.55-4 will have the same bugs in both dapper and edgy)
[12:50] <Chipzz> but package versions are unique across releases
[12:50] <Chipzz> even if the upstream version is the same
[12:50] <infinity> Chipzz: No they're not.
[12:51] <infinity> Chipzz: We don't rebuild the whole archive with new version numbers for each release.  Plenty of packages have the same version in dapper as they had in warty.
[12:51] <Chipzz> debian has -sarge1 for security updates to packages in sarge
[12:51] <Chipzz> so even if the upstream version would be the same, sarge would have -sarge1 while testing/unstable would have -1
[12:51] <infinity> Chipzz: Security updates are UPDATES.  When nothing changes, the packages aren't revved.
[12:51] <Chipzz> hrrrm you are right about that
[12:51] <infinity> Chipzz: False.  I have packages in sarge that are the same version as in potato.  (really)
[12:52] <Chipzz> probably because the maintainer doesn't care about them anymore
[12:52] <infinity> Chipzz: Or because they're reasonably bug-free and don't need to be gratuitously rebuilt.
[12:52] <infinity> Chipzz: Though in the case of potato->sarge, yes, they should have been updated for policy changes if nothing else.
[12:52] <Chipzz> there's still several transitions, like the c++ ones
[12:53] <infinity> I don't maintain anything that uses C++. :)
[12:53] <infinity> The only transition I've ever been subject to was the old /usr/doc -> /usr/share/doc transition.
[12:53] <Chipzz> what I was trying to point out is that it's probably pretty rare to have the same versions across releases
[12:53] <infinity> Not really.  And certainly not in Ubuntu.
[12:53] <infinity> Since we release frequently, we have plenty of packages that don't change.
[12:54] <infinity> Like i said, there are lots (LOTS) of packages with the same version in warty, hoary, breezy, AND dapper.
[12:54] <infinity> And far more for just, say, breezy/dapper.
[12:54] <\sh> apaapa
[12:54] <\sh> infinity: 
[12:54] <\sh> adsasd
[12:55] <\sh> grmpf
[12:55] <mgalvin> jdub: should we use the ubuntu-traffic list for the ubuntu weekly newsletter (or some other list) or should we create a proper ubuntu-newsletter list maybe?
[12:55] <\sh> what was that,,,3 minutes no keyboard input and then again?
[12:55] <mdke> mgalvin: ubuntu-news exists already
[12:56] <mdke> mgalvin: is perfect for your newsletter
[12:56] <mgalvin> mdke: oh right, duh
[12:56] <mirak> infinity: I think I will use debootstrap, because I don't really trust what will do ubiquity. I want to install on a second partition that is on LVM
[12:56] <mdke> mgalvin: it's very underused
[12:57] <mgalvin> i see, one or two posts a month :)
[01:00] <Chipzz> \sh: the cat walking across the keyboard? ;)
[01:00] <\sh> Chipzz: no..keyboard just didn't reply..and I was hammering on the keyboard like a cat walking across the keyboard ;)
[01:01] <mirak> infinity: ok, ubiquity is useless since I use LVM
[01:01] <Chipzz> oh I see :)
[01:02] <sladen> mirak: use the alternate install CD
[01:03] <mirak> I will use the netinstal.iso I think
[01:04] <mirak> sladen: I wanted to know if there is a way to run the installer script that is on the alternate install CD but from a running distro
[01:05] <sladen> mirak: debootstrap ?
[01:05] <jdub> mgalvin: ubuntu-news
[01:06] <mgalvin> jdub: yup, thanks, we will use that
[01:06] <mdke> jdub: is planet still getting a 404 from my blog? I'm wondering if there is something wrong on my end
[01:07] <sladen> mirak: out of interest, what are you actually trying to achieve?
[01:07] <mirak> sladen: it's a piece of the puzzle. I would find intersting to have all the steps
[01:08] <mirak> sladen: I just want to  install to another partition a clean dapper. in fact I already deboostraped, but I really wonder why I can't just have all the steps and a guide like with the installer on the alternate installer
[01:09] <mirak> I just wasting my time in fact ;)
[01:09] <sladen> mirak: apt-get source debian-installer 
[01:10] <mirak> sladen: ah !!! thanks
[01:10] <sladen> mirak: ultimately it calls debootstrap
[01:19] <desrt> is there any way to put my root filesystem on a ramdisk without using initrd?
[01:19] <mdke> desrt: #ubuntu might be able to help
[01:19] <desrt> good call
[01:34] <sorush20> hi ugys just wanted to know if this bug would be fixed soon or later? 
[01:34] <crimsun> "this" being...?
[01:34] <sorush20> https://launchpad.net/distros/ubuntu/+source/cupsys/+bug/43824/+index
[01:34] <Ubugtu> Malone bug 43824 in cupsys "HP Laserjet 1000 doesn't work with cups2" [Normal,Confirmed]  
[01:34] <crimsun> sorush20: "sooner or later" is a good approximation, yes
[01:34] <sorush20> crimsun: you develop too? 
[01:35] <sorush20> did I tell you about the amarok bug too? 
[01:35] <crimsun> not cups*, but I'm involved.
[01:35] <crimsun> which one?
[01:35] <sorush20> well is there anyway that I can print? 
[01:35] <crimsun> and the bug is better addressed in -bugs
[01:36] <sorush20> is martin pitt here? 
[01:36] <sorush20> Martin Pitt
[01:36] <crimsun> pitti is not present; it's the weekend
[01:36] <sorush20> okay.. 
[01:36] <sorush20> I have not idea why I upgraded to dapper knowing there would be these problems.. 
[01:37] <Daemon> GDI printers annoy me, cheap and nasty
[01:38] <sorush20> but runs fine in breezy
[01:39] <sorush20> how would I downgrade to breezy cupsys? 
[01:40] <ompaul> sorush20, you reinstall breezy - walking back is not the way forward, you could try to change the sources but would it work I have no idea
[01:40] <ompaul> sorush20, doing it like a dist upgrade
[01:43] <Chipzz> sorush20: this is not a support channel; either ask on #ubuntu, or read apt-get's man-page to find out how to downgrade a package
[01:46] <Chipzz> sorush20: (if at all possible of course; but I think it would involve something like apt-get install -t breezy ...)
[01:57] <Chipzz> sorush20: no pvt messages please
[02:05] <\sh> any way to get rid of those processes? root      6086  0.0  0.0      0     0 ?        S    01:57   0:00 [mmcqd]  
[02:08] <Chipzz> \sh: I may be mistaken, but looks like a kernel process from a driver?
[02:08] <\sh> Chipzz: it should be the mmc card reader...and I have two of them now, and I'm not able anymore to mount a sd card ;)
[02:09] <Chipzz> have you tried stopping the process accessing the card reader?
[02:10] <Chipzz> I have similar processes like that when using /dev/video from ivtv
[02:10] <Chipzz> they go away when I quit mplayer
[02:11] <\sh> Chipzz: hmm...
[02:12] <\sh> automounting is what process? udev? hal? dbus??
[02:12] <Chipzz> just try unmounting it?
[02:12] <\sh> it's not mounted
[02:12] <\sh> but it was mounted
[02:12] <\sh> and I removed it to fast it seems
[02:13] <Chipzz> hrrrm
[02:13] <\sh> let's leave it for now..
[02:13] <\sh> I'll go to bed just now.
[02:14] <Chipzz> nn :)
[02:14] <\sh> thought i can build quickly a SD gpg key container with dm-crypt support
[02:15] <\sh> but it looks like that I'm screwed with automount in the moment ;)
[02:15] <Chipzz> it's possible it's a bug in the driver too
[02:15] <Chipzz> (I guess)
[02:16] <Chipzz> like, you unmounted correctly, but that process failed to quit
[02:16] <\sh> Chipzz: if removing the card is a correct unmount, but I doubt it ;)
[02:17] <Chipzz> if it's still mounted, you can always try putting it back in and unmounting properly
[02:17] <\sh> Chipzz: but if I'll try to reproduce it, to let mount a not formatted sd card ;)
[02:17] <Chipzz> (like a floppy disk)
[02:18] <Chipzz> *g* :)
[02:18] <\sh> cryptsetup -y create gpgkeys /dev/mmcblk0pl1 \n mkfs.ext2 /dev/mapper/gpgkeys and then remove it 
[02:18] <\sh> et voila screwed up
[02:22] <Chipzz> \sh: is this you? http://www.uni-koeln.de/bin2/maillist/linux-fai/20060531.095843/171988 :)
[02:23] <\sh> Chipzz: yes
[02:23] <\sh> Chipzz: how did you find it?
[02:26] <Chipzz> \sh: fai homepage
[02:26] <Chipzz> just browsing the archive
[02:26] <\sh> Chipzz: ah :)
[02:33] <bioeng> Hi everyone
[02:33] <bioeng> I'm having some programming related problems that I could use some help with
[02:33] <infinity> bioeng: -> #ubuntu
[02:33] <infinity> bioeng: This isn't a support channel for development on Ubuntu, it's a channel for the developing *of* Ubuntu.
[02:34] <bioeng> ok
[02:34] <bioeng> I'll try that channel
[02:37] <LinuxJones> infinity, he will probably get more help in here.
[02:37] <desrt> welp.  it just sucks.
[02:38] <desrt> it still does not sleep
[02:38] <desrt> or rather, wake up from sleep
[02:38] <bioeng> My question was to ask if it would be a good idea to do a CS minor while finishing my EE degree
[02:38] <mjg59> desrt: Fun
[02:39] <mjg59> So the kernel's blowing up somewhere in generic code
[02:39] <bioeng> but I'll go to another room if necessary
[02:39] <mjg59> You're under boot camp, right?
[02:39] <desrt> i had another thought
[02:39] <desrt> ya.  bootcamp
[02:39] <mjg59> Ok
[02:39] <desrt> what if it was failing to set the proper parameters on the DRAM before going to sleep
[02:39] <desrt> and by the time it woke up again it had forgotten who it was
[02:39] <mjg59> That's possible, but unlikely
[02:39] <mjg59> (That is, I've found one machine ever that appears to do that)
[02:40] <desrt> think i'll have better luck with efi?
[02:40] <mjg59> The Intel datasheets are public - you're looking for "self refresh"
[02:40] <mjg59> No, you'll have no luck at all with efi
[02:40] <desrt> no acpi there i assume
[02:41] <desrt> in your opinion what is the next most likely problem?
[02:41] <mjg59> Oh, acpi, but completely absent testing of it ever in the slightest
[02:41] <desrt> (btw... i tried the s3_ flags and i also enabled USB and HID support in my kernel to see if i could at least see capslock working -- no love)
[02:41] <mjg59> It's utterly broken
[02:41] <mjg59> Anyway.
[02:42] <mjg59> Next thing to try is shoving reboots in arch/i386/kernel/acpi/wakeup.S
[02:42] <desrt> that's the entry for coming back from sleep?
[02:43] <desrt> is there a kernel sponsored way to reboot or should i just try and trash my cr2 and hope for a triple fault?
[02:43] <mjg59> Just cut and paste the triple fault code from include/asm-i386/mach-default/mach_reboot.h
[02:43] <mjg59> Oh, hang on, that's not where it is
[02:43] <desrt> oo. pre-programmed triple fault :)
[02:44] <mjg59> Might be under arch/i386 somewhere
[02:44] <desrt> ok
[02:44] <mjg59> The fallback reboot code is to do a triple fault
[02:44] <desrt> nod.  that never fails :p
[02:44] <mjg59> So then see if it's ever getting into the wakeup code in the first place
[02:44] <desrt> do x86 chips still come up in real mode at 0xf0000 these days?
[02:44] <mjg59> Seemingly so
[02:44] <desrt> wow
[02:44] <infinity> it's in kernel/reboot.c
[02:44] <mjg59> Well, not /quite/
[02:45] <infinity>                 case 'h': /* "hard" reboot by toggling RESET and/or crashing the CPU */
[02:45] <mjg59> Coming back from acpi sleep, it immediately jumps to the address put into the wakeup code register
[02:45] <infinity>                         reboot_thru_bios = 0;
[02:45] <infinity>                         break;
[02:45] <desrt> mjg59; i bet it does that by going to 0xf0000 first
[02:46] <mgalvin> Riddell: around?
[02:46] <mjg59> desrt: Yeah
[02:46] <desrt> mjg59; there's a special memory address you can set in the PC bios (in the 0000:0400 range) which causes the power-on BIOS code to jump to some address VERY quickly
[02:46] <mjg59> But at that side of things, the hardware is supposed to be dealing with it
[02:46] <mjg59> It's not something an ACPI OS needs to care about
[02:47] <desrt> so.....
[02:47] <desrt> because this isn't really a real PC
[02:47] <mjg59> So if it gets all the way through the wakeup code, you get to stick reboot calls in the C code
[02:47] <desrt> i assume the firmware copies some bios boot block code into the f000 segment....
[02:47] <desrt> and we have to hope that nobody tries to modify it
[02:47] <mjg59> ACPI /sortof/ works on the minis and MBPs
[02:47] <mjg59> (Reportedly)
[02:48] <mjg59> desrt: Giving 2.6.17-rcwhatever might be worth a go
[02:48] <mjg59> Just to make sure it's not something that's been fixed already
[02:48] <desrt> that's a good idea
[02:48] <desrt> i'm using 16 now
[02:49] <mjg59> Or even -mm
[02:49] <desrt> i have to admit i'm confused.  apple must have ROM blocks at 0xf0000
[02:49] <desrt> or else when the hardware came up (really came up, at first)....
[02:51] <desrt> i miss the good old days of serial and parallel ports
[02:52] <desrt> back in the day when you could toggle some external pin on the machine with a single instruction
[02:52] <desrt> debugging was more fun
[02:53] <mjg59> Oh, yeah, I've done ACPI debugging with a panel of LEDs on the parallel port
[02:53] <desrt> this laptop screams when it comes to building kernels
[02:54] <nokko> Fujitsu: still there?
[02:54] <Fujitsu> Yes.
[02:54] <Fujitsu> I'm always here :)
[02:54] <nokko> Fujitsu: could we please go private? (i am the person with the bug)
[02:54] <nokko> Fujitsu: i see that people here don't like us talking about bug reports
[02:55] <Fujitsu> OK, nokko.
[03:04] <desrt> uh
[03:04] <desrt> how is one supposed to make a call to a .c file from real mode?
[03:06] <shackan> from real mode ?
[03:06] <Fujitsu> Is this on topic?
[03:06] <shackan> are you tinkering with the boot code or what ?
[03:06] <infinity> desrt: You don't?
[03:07] <infinity>                         __asm__ __volatile__("int3");
[03:07] <desrt> that'll triple-fault me?
[03:07] <infinity> Read machine_emergency_restart() from kernel/reboot.c
[03:08] <desrt> oh.  you need an empty IDT for that to work
[03:08] <desrt> and you also need to be in protected mode
[03:08] <desrt> i don't think realmode supports the idea of triple-faulting
[03:09] <shackan> why not?
[03:09] <infinity> desrt: machine_real_restart may provide some hints..
[03:09] <shackan> desrt, may I ask what you're doing ?
[03:10] <infinity> shackan: Tripping a reboot during kernel setup, to see where his resume is failing.
[03:10] <desrt> infinity; intense....
[03:10] <shackan> kprintf'ing something more verbose and then do __asm__ __volatile__("cli; hlt;") and halt the machine ? :)
[03:14] <sorush20> hi guys any development on this bug
[03:14] <sorush20> https://launchpad.net/distros/ubuntu/+source/amarok/+bug/45487/+index
[03:14] <infinity> Dude, you were just in here an hour or two ago, asking about cups bugs, AND you brought that one up.
[03:14] <\sh> sorush20: #kubuntu-devel
[03:15] <infinity> sorush20: This is not a support channel.  Bugging people about YOUR pet bugs does not get them fixed faster.
[03:15] <\sh> sorush20: and it's not a supported package...
[03:15] <desrt> infinity for dpl!
[03:15] <infinity> upl?
[03:15] <desrt> that's an appointed position :)
[03:15] <makko> Fujitsu: i think the main problem with ubiquity is that it doesn't show intelligent errors: for instance, now i moved all the data into just one folder on the same partition (for backup purposes) and it crashed much later, with similarly strange errors. then i ran a df -h and it showed me "use% -- 100%" (which means partition is full).
[03:15] <shackan> desrt, descriptor privilege level ? :D
[03:15] <makko> Fujitsu: it should simply say: partition full. right?
[03:16] <makko> Fujitsu: i mean, it should even check for this from the beginning!
[03:16] <Fujitsu> makko, yes, it's not particularly good at the moemnt.
[03:16] <makko> Fujitsu: i think checking it from the beginning is simple to implement and i simply don't understand why it doesn't.
[03:17] <makko> Fujitsu: i mean... how can you begin to install if you can very easily make sure you don't have enough space on the partition?
[03:17] <desrt> SCORE
[03:17] <desrt> my system reboots on wakeup from sleep now
[03:17] <desrt> good thing we decided to teach that assembly class last term about oldschool DOS x86 stuff :)
[03:18] <\sh> desrt: hmmm....oldschool dos x86 stuff? teach them z80 ;)
[03:18] <bddebian> heh
[03:20] <bddebian> Hmm, we don't have xulrunner in the archive?
[03:21] <infinity> bddebian: We will somewhere shortly after Tuesday.
[03:22] <\sh> bddebian: apt-cache search xulrunner says no
[03:22] <infinity> bddebian: It hit Debian too late to be useful for dapper.
[03:22] <bddebian> infinity: OK, thx
[03:22] <\sh> good night folks
[03:22] <makko> Fujitsu: maybe you could tell ubiquit devs about implementing better error messages and checking space available. i guess ubiquity only checks partition size and assumes it's being formatted.
[03:23] <makko> ubiquity
[03:23] <Fujitsu> makko, they are going to fix it a lot, I guess.
[03:28] <bddebian> infinity: Do you happen to know much/anything about it?
[03:29] <desrt> wow.
[03:29] <desrt> step 1: be sure to make a backup copy of your MBR
[03:29] <desrt> step 2: blow the MBR away
[03:29] <desrt> step 3: realise that you saved the backup copy of the MBR on the harddrive itself
[03:30] <infinity> bddebian: It?
[03:30] <infinity> bddebian: Oh, xulrunner?  A bit.
[03:30] <infinity> desrt: But you can boot from CD, so it's all good.
[03:31] <desrt> infinity; but... my harddrive....
[03:31] <bddebian> infinity: Any idea why there is no i386 build log on p.d.o?
[03:31] <infinity> desrt: MBR != Partition table...
[03:31] <infinity> desrt: Unless you zeroed a LOT of sectors...
[03:31] <desrt> infinity; ok.  "the first 512 bytes of my disk"
[03:31] <desrt> which contain both the mbr and the partition table
[03:31] <infinity> desrt: First 512 bytes is just the MBR.  No reason you can't mount that disk from a CD boot.
[03:31] <desrt> you are wrong
[03:32] <infinity> I are not.
[03:32] <desrt> first 512 bytes also contains the partition table
[03:33] <desrt> explain to my why, then, the boot CD doesn't seem to think i have partitions :)
[03:33] <infinity> Probably because I'm wrong. ;)
[03:34] <makko> desrt: maybe it's just teasing you
[03:35] <makko> Fujitsu: wow, already 87 updates?
[03:35] <Fujitsu> makko, yes.
[03:35] <makko> Fujitsu: that's what adept notifier says
[03:36] <makko> Fujitsu: from now on i guess it's much better for canonical to release a community edition (like mandriva) and then, after one month, a final version. that way we'll get more beta testers.
[03:37] <bddebian> makko: Dapper has been available to the "community" for months
[03:37] <makko> bddebian: then i don't understand why so many bugs are being detected so late
[03:37] <makko> bddebian: really... it frustrates me
[03:38] <crimsun> makko: that's not a reflection of the development, that's a reflection of people testing it at a given time
[03:38] <makko> bddebian: maybe most of them download the live cd only when it's "official" enough
[03:38] <bddebian> makko: I don't recall seeing your nick around prior to very recently?
[03:38] <makko> bddebian: i changed it, why?
[03:38] <makko> bddebian: oh, and i am new to #ubuntu-devel
[03:43] <makko> crimsun, bddebian, Fujitsu: so i think it would be very helpful if we advertized two "official" releases, like mandriva. what do you think?
[03:43] <bddebian> makko: I don't see the difference.  And if you live Mandriva, go to Mandriva
[03:43] <Fujitsu> The Ubiquity disaster has been a bit bad.
[03:43] <tseng> "disaster"?
[03:44] <Fujitsu> I would categorise it as a disaster.
[03:44] <bddebian> Aye what disaster?
[03:44] <makko> bddebian: why do you say i like mandriva?
[03:44] <makko> bddebian: did i offend you?
[03:44] <bddebian> makko: Because you keep bringing it up.  ANd regardless, this is not the purpose of this channel
[03:44] <tseng> makko: he said if
[03:44] <makko> tseng: no, i mean why did he even bring it up like that and why he put it like that
[03:45] <makko> tseng: i just thought that would be helpful
[03:45] <bddebian> Fujitsu: I installed personally Ubuntu, xubuntu, and kubuntu on 4 different machines myself
[03:45] <bddebian> With 0 issues
[03:45] <tseng> you are the first person to mention mandriva, i think
[03:45] <bddebian> s/xubuntu/edubuntu/
[03:45] <makko> tseng: because i am a "convert" from mandriva
[03:46] <makko> tseng: and i like that idea
[03:46] <tseng> this is very silly
[03:46] <tseng> but we made 2 beta and an rc release
[03:46] <makko> tseng: what is very silly?
[03:46] <tseng> and none of you tested it
[03:46] <makko> tseng: make it more official, and much more people will test. i am sure. that's how they do on mandriva.
[03:46] <Fujitsu> makko, that'd be right.
[03:46] <tseng> i dont know how much more official you can make it
[03:47] <tseng> than posting to every ubuntu list, making slashdot, digg, osnews
[03:47] <bddebian> What makes it more "official"?
[03:47] <tseng> i mean, jeez
[03:47] <Fujitsu> I would never use Ubiquity, because my config is rather odd.
[03:47] <makko> tseng: when there are too many "flights" most people are confused and prefer to say "ok... i will wait until this flood ends"
[03:47] <tseng> you can't get any more publicity if you tried.
[03:48] <makko> bddebian: i don't know... "singular". give people the impression it's something "final"!
[03:48] <Burgundavia> makko: publicity is not something Ubuntu needs more of
[03:48] <tseng> why would yo make a final beta
[03:48] <Burgundavia> well, it does, but it is not somehting we need work on
[03:48] <bddebian> This is a pointless discussion that I will take part in no longer.
[03:48] <tseng> I am starting to agree.
[03:48] <makko> tseng: not a final beta
[03:48] <tseng> it definately doesnt belong in this channel, in any case
[03:48] <tseng> if you'd read the topic
[03:49] <makko> ok
[03:49] <Burgundavia> makko: if you really want to help testing, file and triage bugs
[03:49] <tseng> file and triage bugs before the final release
[03:49] <tseng> don't be a Eugenia
[03:49] <makko> what is an eugenia?
[03:50] <shackan> what did she do?
[03:50] <tseng> if you missed it, I am not going to go into it here
[03:50] <tseng> you can figure out where to look if you are so inclined
[03:58] <desrt> does this channel piss people off or do people piss this channel off?
[03:59] <Burgundavia> desrt: what do you mean?
[03:59] <tseng> desrt: people cant read a topic
[03:59] <tseng> desrt: and use their best judgement
[03:59] <Burgundavia> we should probably just renamed this channel #ubuntu-escalation-support and be done with it
[03:59] <desrt> yuh....
[04:11] <Chipzz> shackan: former "head" of osnews, queen of garbage-journalism
[04:11] <Chipzz> not that the word "former" matters, as thom is just as bad
[04:23] <bddebian> Burgundavia: :-)
[04:37] <desrt> seriously.  WTF
[04:38] <desrt> my laptop rebooting or not seems to be more of a random whim of the kernel i build than it is of the changes i make to it
[04:39] <mjg59> Hardware is fun!
[04:40] <desrt> i hate you
[04:40] <desrt> i wonder if ; is not a comment
[04:40] <desrt> if i comment lines with ; they appear to still be run
[04:40] <mjg59> In .config?
[04:40] <desrt> in .S files
[04:40] <mjg59> Oh
[04:40] <desrt> i think that's my problem
[04:40] <mjg59> It ought to be, I think
[04:40] <desrt> i'd make a change, see that it do what i want
[04:40] <desrt> then comment it with ;
[04:41] <desrt> and see that the change remains in effect
[04:41] <mjg59> Ha
[04:41] <desrt> insanity.
[04:41] <mjg59> # is certainly a comment
[04:41] <desrt> ; is "ignore this character and keep on parsin'"
[04:41] <mjg59> So I'd recommend #, really
[04:41] <desrt> oddly, vi syntax hilights ; as a comment and # as nothing
[04:42] <desrt> *shakes fist at vi*
[04:42] <bddebian> So use an editor from this century :-)
[04:42] <desrt> i'll make you regret those words
[04:43] <desrt> i think this is the most useful my usb key has ever been to me
[04:46] <bddebian> desrt: Are you actually doing something or are we just getting running commentary? :-)
[04:47] <desrt> bddebian; i'm debugging the code that runs very very early after the machine comes back from sleep
[04:48] <bddebian> desrt: What I meant was.  Are you actually fixing an Ubuntu bug? :-)
[04:48] <desrt> the "my macbook fails to wake up" bug?
[04:48] <infinity> "Ubuntu doesn't work for crap on MacTels" sounds like a bug to me.
[04:49] <infinity> (FSVO "doesn't work for crap" that means "it works pretty well, modulo the bits that don't")
[04:49] <desrt> FSVO?
[04:49] <infinity> For some value of.
[04:50] <desrt> right.
[04:51] <bddebian> Ah
[06:53] <izm99> When you plug in a digicam memory card, a window appears asking if you want to import photos.  How do I get my own program to do that?
[06:54] <izm99> Clicking "import photos" opens gthumb.  I'm assuming the hook is implemented with dbus or hotplug or something... but where/how I'm not sure.  anyone know?
[06:55] <mjg59> izm99: #ubuntu is a better place for this, but check out the removable drives and media preferences
[06:58] <izm99> mjg59, ok, thanks.  :)
[07:01] <izm99> mjg59, out of curiosity, how does "ubuntu" know when a digitcal camera source has been connected?
[07:01] <Lathiat> gnome-volume-manger ?
[07:02] <infinity> Good ol' gnome-nolongerhasanythingtodowithvolumes-manager
[07:02] <infinity> Always entertaining to watch it fiddling with my sound cards.
[07:02] <infinity> Cause you can almost pretend the "volume" means something else.
[07:03] <StevenK> infinity: Where volume is the space taken up by devices. :-)

[07:04] <Lathiat> hrm it seems apt isnt asking questions, e.g. the java license & the flash "do you want to download" stuff, known?
[07:04] <infinity> Lathiat: Did you install that system with ubiquity, pre-release?
[07:04] <Lathiat> yeh i think so
[07:04] <Lathiat> was a bug then?
[07:05] <infinity> Then your debconf frontend is set to noninteractive (oops, my fault)
[07:05] <Lathiat> kubuntu upgraded from ubiquity RC install
[07:05] <infinity> sudo dpkg-reconfigure debconf
[07:05] <Lathiat> ah ok
[07:05] <Lathiat> cheers
[07:06] <infinity> (For the record, the defaults are "dialog, high, don't ask again and again"
[07:06] <infinity> )
[07:13] <jadaz87> infinity what is comething i could use to build metapackages?
[07:13] <infinity> -ETOOVAGUE
[07:14] <jadaz87> infinity: i see
[07:14] <infinity> But you may want to see the "equivs" package, if your questions was what I think it was.
[07:15] <jadaz87> infinity: thank you
[09:24] <crimsun> hmm, I'm delivering a dapper talk to trilug next thursday, and I'm receiving numerous requests to cover the steps after debootstrap to configure the base system in a chroot now that base-config has gone away.
[09:25] <Hobbsee> crimsun: and write us a howto on it please? 
[09:25] <crimsun> Hobbsee: yeah, that will be done since I have to demonstrate it live. :)
[09:25] <Hobbsee> :)
[09:28] <Kliment> hi, I've found a regression
[09:29] <Kliment> the panasonic acpi driver (pcc) no longer generates key events
[09:30] <Kliment> looks like there is a newer version that fixes things for the .15 kernel, but it's not in dapper
[09:30] <Kliment> who should I notify?
[09:31] <crimsun> please file a bug in malone and attach a link to the fixed version, preferrably a diff against whatever Dapper has
[09:32] <Kliment> I am not familiar with malone, where do I start?
[09:32] <crimsun> Kliment: https://launchpad.net/distros/ubuntu/+filebug
[09:55] <Kliment> https://launchpad.net/distros/ubuntu/+bug/48325
[09:55] <Ubugtu> Malone bug 48325 in Ubuntu "Panasonic ACPI driver (pcc) does not generate key events" [Normal,Unconfirmed]  
[09:55] <Kliment> is this good enough, anything I should add?
[09:58] <crimsun> Kliment: can you verify that 0.8.4 indeed fixes the regression from breezy?
[09:58] <desrt> doot.
[09:58] <Kliment> I can try
[10:03] <Kliment> grr, forgot that this update does not pull the kernel source in with it
[10:04] <Kliment> well, this will take a while then
[10:21] <Kliment> hmm, seems like the driver developer's server is having some trouble
[10:21] <Kliment> I'm getting truncated files
[10:22] <Kliment> could someone else verify it's not just my connection messing things up
[10:22] <Kliment> http://www.da-cha.org/letsnote/hotkey-handler-1.4.tar.gz
[10:48] <Kliment> adding the hotkey handler fixes the problem, but I only have an older version of it as the downloads on that site are broken for some reason
[10:49] <crimsun> all useful info for the bug report.
[10:49] <sivang> hey crimsun , what's cracking? :)
[10:49] <crimsun> sivang: me, so sleep time :)  yourself?
[10:51] <sivang> crimsun: well, just preparing some lunch and going see where I need to do work afterwards. it's a beautiful morning here
[10:51] <crimsun> sivang: excellent :)
[10:51] <sivang> crimsun: sleep time? aren't we at the same time zone?
[10:51] <desrt> i think i just fixed a bug in the linux PCI code.
[10:51] <sivang> desrt: oh cool
[10:52] <crimsun> sivang: I'm EDT (GMT -0400)
[10:52] <sivang> crimsun: ah, so it's morning for you ?
[10:52] <sivang> crimsun: where in?
[10:52] <crimsun> sivang: yep, almost 5 AM. East coast USA (North Carolina).
[10:53] <sivang> crimsun: ah, nice did not sleep throug the night I suppose? :-)
[10:53] <kagou> hi
[10:54] <crimsun> sivang: nope, going to do that now. 'night/'morning :)
[12:22] <vlad> sladen: Hello, yesterday I posted a bug comment about acpi-support + i810 xorg driver and you seem to be much involved with it. Can I ask some questions?
[12:24] <sladen> vlad: yup
[12:24] <sladen> vlad: what's the bug number?
[12:25] <vlad> Great, the lucky number is 40621
[12:26] <sladen> bug #40621
[12:26] <Ubugtu> Malone bug 40621 in acpi-support "R50e fails to resume: Green moon constantly blinking" [Normal,Unconfirmed]  http://launchpad.net/bugs/40621
[12:28] <vlad> right, my first question... you make a reference to bug #28326 which is marked as Fix Released. Does that mean that it should work in the current Dapper?
[12:28] <Ubugtu> Malone bug 28326 in xserver-xorg-driver-i810 "i810 Xv crashes after suspend -> infinite resprawn" [Major,Confirmed]  http://launchpad.net/bugs/28326
[12:28] <HrdwrBoB> yes
[12:29] <vlad> unfortunaell
[12:29] <vlad> oops
[12:29] <HrdwrBoB> erm.. I didn't mean yes to that
[12:29] <HrdwrBoB> I mean yes, it happens to  me too
[12:31] <vlad> I experience it in Dapper too and I would like to know if anything can be done to fix it.
[12:35] <sladen> vlad: I thought I'd nailed it;  but I've had it once since.  Did you attach the Xorg.log from after one of those
[12:35] <sladen> (the machine is still up, so you can SSH in, or Sync, Unmount, reBoot it
[12:36] <vlad> sladen: yes, you can see it at the very bottom of the bug page.
[12:42] <Lure> sladen: which process in gnome handles laptop hotkeys defined by your hotkey-setup package?
[12:42] <Lure> sladen: I would like to address this also for KDE and would help to know how Ubuntu does it...
[12:43] <ogra> Lure, hal and gnome-power-amanger should be responsible for that
[12:43] <ogra> *manager
[12:44] <sladen> Lure: they listen via HAL now.  do   lshal -m  and press some hotkeys
[12:44] <sladen> Lure: and gnome-setting-daemon does some evil remapping of its own
[12:44] <Lure> ogra: ok, I see
[12:45] <ogra> wasnt klaptopdaemon adjusted to use hal nowadays ? 
[12:45] <Lure> just need to find right place in KDE to put this in (kmilo, klaptop, kpowersave...)
[12:45] <sivang> wow, nice. glom has so much potential
[12:45] <Lure> ogra: klaptop only uses pmi command line to suspend/resume, but still has plenty of ACI/APM cruft
[12:46] <Lure> ogra: just had report that it does not work on the desktop as some ACPI functions are missing (while Ubuntu works) :-(
[12:46] <ogra> well, thats how g-p-m worked in breezy, just make the same switch in the code and you are done ;)
[12:47] <Lure> ogra: probably yes, I am just doing investigation in order to prepare spec for Paris meeting
[12:47] <ogra> cool
[12:50] <vlad> sladen: well, can I do anything about the i810 bug? would be some more info helpful?
[12:53] <InfraRed> sladen: msg
[12:55] <sivang> Lure: you're coming to paris to work on laptop support ? :)
[12:56] <Lure> sivang: no, but I plan to work on Kubuntu laptop support for Edgty
[12:56] <Lure> sivang: I just hope spec get reviewed in Paris
[12:57] <sivang> Lure: I feel there's great lack of complete IBM thinkpad support currently, I would wish to see it comes with all software help and support as it is in Windows
[12:57] <sivang> some of it we already have in the form of NetworkManager,
[12:58] <sivang> but would be also nice to see the Access connections there,
[12:58] <sivang> and ofcourse, out of the box support for the motion detector and fingerprint reader
[12:58] <sivang> hopefully to be reviewed in Paris as well :-)
[12:59] <Fujitsu> sivang, you do realise that Lenovo officially dropped Linux support?
[12:59] <sivang> Fujitsu: link?
[12:59] <sivang> Fujitsu: what made them take such a non sensical decision?
[01:00] <Lure> sivang: MS probably... :-(
[01:00] <Lure> sivang: http://www.crn.com/sections/infrastructure/infrastructure.jhtml?articleId=188701277
[01:00] <Fujitsu> sivang, saw it on Slashdot and other places not long ago.
[01:01] <Lure> sivang: for your needs, you would probably need proper kernel drivers to support it (fingerprint, motion detector...)
[01:01] <sivang> oh man :-/
[01:01] <sivang> Lure: yes, I already know some of this has problems for re-distribution as well
[01:03] <HiddenWolf> Well, there go my plans to buy an X60
[01:03] <InfraRed> X60 ?
[01:04] <HrdwrBoB> I love my X40
[01:04] <sivang> was also quite expansive, and does not seem to return the investment completly
[01:04] <HrdwrBoB> oh shit
[01:04] <HrdwrBoB> lenovo :(
[01:04] <InfraRed> T43p cost silly money
[01:04] <sivang> InfraRed: so I leanred , yes
[01:05] <sladen> sivang: three buttons, nipple
[01:05] <sivang> sladen: ? :)
[01:07] <sladen> "Lenovo will still supply advice to 'customers who _insist_ on deploying Linux'"
[01:08] <vlad> sladen: I have to leave now, if I could help somehow solving the mentioned bug, please mail me at vladimir.lapacek@gmail.com. thx and have a nice day
[01:08] <sladen> Microsoft has offered them a good deal (eg. this, or else)
[01:08] <sladen> vlad: thanks
[01:08] <sivang> sladen: ah, right I saw that , I ownder how much of this stands in .il ;-)
[01:11] <sivang> sladen: up till now I had terrible IO issues with Ubuntu on my thinkpad, mostly the machien is able to do one task at the time type of problems, and well , fglrx perforamnce issues. (although the prop driver is supposed to be faster then the FOSS onw)
[01:11] <sladen> sivang: remember that they just got barred from supplying .gov.us with Lenovoware.  And the security services and miltary are probably their biggest customer of Linux thinkpads
[01:12] <sivang> sladen: I'm already using elevator="deadline" but this had minor effect if any
[01:12] <HrdwrBoB> everyone i know who uses linux on laptops swears by ibm (and lenovo)
[01:12] <HrdwrBoB> oh well, things change I guess
[01:13] <InfraRed> ya
[01:13] <sladen> sivang: there seems to be a weird DMA issue;  it occasionally goes in (what appears to be a swap storm) that can take ~30 minutes to get out of.  (Even with out swap running).  I reckon it's more likely the duff SATA<->PATA bridge in the R52 and T43
[01:13] <sivang> sladen: indeed, so without those in demand, they're looking mostly at a MS oriented market? (given those securoity agencies probalm prefer linux out of quality)
[01:14] <HrdwrBoB> well, they'll soon find out if a significant portion of their market wants linux
[01:14] <Fujitsu> HrdwrBoB, hopefully.
[01:14] <Fujitsu> Boycott Lenovo.
[01:18] <sivang> sladen: oh man, any way  to make it not act like an old PIII 4200rpm machine? :)
[01:19] <sladen> sivang: not that I've found yet.  most of the time it doesn't.   Ctrl-Alt-F1  seems to be a good way to get out of it (wait a couple of minutes...)
[01:20] <sladen> sivang: I only found this out because I tried to put in a different hard-disk for testing  (one without the HDD firmware patch designed to work around the bug)
[01:20] <sivang> sladen: funny, it's probably is that PATA-SATA brige and not specifically an os issue, I managed to somewhat reproduce that in WinXP as well, more then one dir /s in more then one console just brings it down to GUI latency and dropped responsiveness
[01:21] <sivang> sladen: ah, so what bug is the fimrware patched HDD workoaounds ?
[01:22] <sladen> sivang: http://www.thinkwiki.org/wiki/Problem_with_non-ThinkPad_hard_disks
[01:22] <sladen> sivang: you may actually be able to.
[01:25] <sivang> sladen: according to the description, and the fact I don't get the warning (I never tried to replace the drive) I shoudl not have any performance issues. 
[01:27] <sladen> sivang: quite;  however, I haven't seen the 'swap-storm' issue on other machines... and the result is fairly similar (but less exagerated) to when I did put another disk in and the IDE bus hanging caused the machine to lock solid for 3 seconds every 15-20seconds
[01:28] <sivang> sladen: wow
[01:28] <sladen> when it's in the swap-storm mode, it feels more like the machine is frozen for X milliseconds out of every Y
[01:28] <sivang> sladen: so the "approved" HDs only circumvemnt the issues, to a smaller degree.
[01:29] <sivang> sladen: this is EXACTLY what I am experiencing. why didn't I got for anything else but Lenonvo...;-)
[01:34] <sladen> sivang: yes, the "approved" HDDs are ones that have had the firmware on the drive patched in an attempt to mitigate the bugs in the PATA bridge
[01:37] <sivang> sladen: god, I have exepcted abit more from Lenovo mahcine which still carries the IBM logo :-(
[01:38] <sladen> sivang: these were the first batch of 50%/50% IBM/Lenovo's.  The *60* are the first batch of true Lenovopads
[01:39] <sivang> sladen: is there anything official press release I can come with to the srvice cetner to backup my anger and shouts? :)
[01:39] <sladen> sivang: I filed a bug something like  "machine freezes under high I/O load"  But I can't find the bug report
[01:40] <mirak> debootstrap have failures when installinf with dapper
[01:41] <sivang> sladen: do you think that ni view of this, there is a still a plce for a spec to make Ubuntu on a thinkpad closer in support to how it's on a preloaded WinXP ? (without Lenovo support we'll have to do everything ourselves)
[01:41] <mirak> it unpacks everything five times ...
[01:41] <sladen> mirak: https://launchpad.net/distros/ubuntu/+source/debootstrap/+filebug along with the error messages please
[01:41] <sivang> sladen: (I was gonna start working on aspec like this before we talked ;-) )
[01:41] <ogra> mirak, then no edubuntu install would work out there (edubuntu and ltsp rely heavily on debbootstrap)
[01:42] <mirak> ogra: I say some packages fails when unpacking
[01:42] <ogra> mirak, see above ... if packages would fail, the edubuntu installs would all fail
[01:42] <mirak> I do a deboostrap debootstrap --include=ubuntu-desktop,ubuntu-minimal,ubuntu-standard,language-pack-fr dapper linux2
[01:42] <mirak> ogra: then it fails
[01:43] <sivang> sladen: any idea if one could put a real SATA drive to overcome the bridge on that machine?
[01:43] <mirak> wasabi: Failure while installing base packages.  This will be re-attempted up to five times.
[01:43] <sladen> sivang: the solution alluded to is that if you put a PATA disk in the ultrabay everything will work
[01:43] <mirak> ogra: the base install work, but other packages seems to have problems
[01:44] <sivang> sladen: the ultrabay is only pata?
[01:46] <ogra> mirak, do what sladen said, file a bug and attach a full log of the failed debootstrap
[01:47] <mirak> ok
[01:48] <sladen> mirak: if you read the mirak man-page, you'll notice that you have to resolve the dependancies for any packages which you --include
[01:50] <ogra> yes, the easier way is  debootstrap dapper linux2 && sudo chroot linux2 apt-get install ubuntu-deskto
[01:50] <ogra> p
[01:51] <mirak> ok thanks
[01:51] <ogra> (you wont need minimal and standard, minimal is installed by debootsrap by default iirc and -desktop should depend on -standard)
[01:52] <mirak> I am not sure of that
[01:52] <mirak> iwj: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Found additional base dependencies:
[01:53] <mirak> ogra: but what I did was to put all the .deb on the iso inside var/cache/apt/archives
[01:54] <sivang> sladen: I wonder if I can find anything other then http://www-3.ibm.com/pc/support/site.wss/document.do?&lndocid=MIGR-60169 as an excuse to get a replacement machine without a bridge and with true SATA drive
[01:54] <mirak> sladen ogra I think the problem comes from the configuration dependencies
[01:55] <mirak> debootstrap configures everything alphabethically
[01:55] <mirak> I have just read the log and almost everything is broken
[01:56] <sivang> sladen: so I think I will restore the machine to it's factory settings ( created the product revoery CDs before I installed Ubuntu)
[01:56] <sivang> sladen: and then go and show them how it's brought ot it's knes with 3 cmd.exe dir /s windows
[01:56] <ogra_> grmbl
[01:57] <ogra> mirak, why didnt you mount /cdrom and use file:///cdrom as mirror ? 
[01:57] <ogra> milli, (mount it as loop device if you dont have it on CD)
[01:58] <HiddenWolf> sivang: what model of thinkpad do you have?
[01:58] <mirak> ogra: yes I should have done that
[01:59] <ogra> saves a lot of time and diskspace :)
[01:59] <mirak> ogra: or mount the iso
[01:59] <ogra> yeah ... err s/milli/mirak indeed :)
[01:59] <mirak> anyway I burnt the iso meanwhile
[01:59] <mirak> I think I would do something clean from boot
[02:00] <mirak> I am afraid to miss something in the configuration
[02:00] <mirak> my system is already a bit wrecked probably from debootstrap previous install. I want something as clean as possible
[02:02] <sivang> HiddenWolf: T43p , 1.8GHz , 7200rpm , 1GB RAM FireGL V3200 
[02:02] <HiddenWolf> sivang: problematic beast, I assume? :)
[02:03] <sivang> HiddenWolf: read the backlog , it's amazing what tricks computer verndos play these dasy :)
[02:03] <HiddenWolf> sivang: heh, yeah, I just missed the model number. :)
[02:03] <sivang> HiddenWolf: also, http://www.crn.com/sections/infrastructure/infrastructure.jhtml?articleId=188701277 for my joy of choosing IBM :-)
[02:03] <HiddenWolf> sivang: I am/was in the market for a thinkpad. 
[02:04] <highvoltage> thinkpad was a favourite for linux users for a long time, afaik. that will probably change now :/
[02:04] <sladen> sivang: worth a try
[02:05] <sivang> sladen: I also have issues with the touchpad sensitify I Was unable to resolve, and those weird "bell" sounds whenever the mahcine is under heavy IO could probably serve me at the service center.
[02:06] <sivang> (I think they can also be attribute to the bridge thingy)
[02:06] <sladen> sivang: ah okay.  I never use the touchpad.  I don't know what the bell sounds are, but there is high-pitched noise during C-state changing
[02:07] <sivang> sladen: C-state ?
[02:10] <HiddenWolf> I wonder how useful dapper will be in three years
[02:10] <HiddenWolf> Since it might only work out of the box on current hardware.
[02:10] <sladen> sivang: CPU power saving states.  See  cat /proc/acpi/processor/*/power
[02:11] <sladen> HiddenWolf: why don't we wait and find out
[02:11] <HiddenWolf> sladen: heh, we sure will. ;)
[02:11] <mdke> HiddenWolf: it'll work great on your current hardware.
[02:12] <HiddenWolf> mdke: it already does. ;)
[02:12] <mdke> HiddenWolf: exactly.
[02:13] <herzi> but only if you still have your current hardware running in three years
[02:13] <mdke> herzi: yes, obviously dapper can't actually fix hardware
[02:13] <ogra> and the next LTS release will be there by then, people can upgrade
[02:14] <mirak> it's like certifying memory for fifty years
[02:14] <herzi> ogra: is there a concrete plan for the date of the next LTS release? (12, 24, 36 months)
[02:14] <mdke> ogra: potentially even another 2 LTSs
[02:14] <mirak> that's just commercial argument
[02:15] <ogra> herzi, iirc it was planned every 2 years
[02:15] <Hobbsee> ogra: you're the one who's good with screensavers, arent you?
[02:16] <ogra> Hobbsee, well... 80 open bugs (in xss and gss together) wouldnt justify me as "good" with it, but i'm responsible for it, yes
[02:17] <Hobbsee> ogra: right.  i'd love to kill off those bugs sometime - seems to need a very specific selection of packages to make rss-glx work, and i'm not sure why it's so tempramental...
[02:18] <ogra> you need only xscreensaver-gl 
[02:18] <ogra> oh, damned and it indeed misses a dependency on xss-gl
[02:19] <ogra> Hobbsee, thanks for pointing !
[02:19] <Hobbsee> ogra: for kde, you seem to need kscreensavers-xsavers too
[02:19] <Hobbsee> ogra: hehe.  not a problem :)
[02:19] <ogra> hmm, i havent looked at the KDE side of things yet
[02:20] <ogra> i always thought KDE uses its own implementation, isnt kscreensaver that ? 
[02:20] <Hobbsee> ogra: there's one package that you *cant* have installed for it to work.  i'm not remembering this second whether that's xscreensavers, or xscreensaver-gl-extra
[02:20] <ogra> -extras are only additional screensavers
[02:20] <Hobbsee> ogra: rss-glx doesnt need kscreensaver to run at all - but it does need the kscreensavers-xsavers too...
[02:20] <ogra> and xscreensaver has only the xscreensaver binary, nothing else
[02:22] <Hobbsee> ogra: there's something weird there - i'll check that out a bit more.  but if we could get a dep on kscreensavers-xsavers somehow if the people use kde...or whatever equivalent that is, that'd be cool - and that would stop a whole lot of kde bugs.
[02:23] <Hobbsee> ogra: the kscreensaver-xsavers is just the hook so that the screensavers work under kde.  that's not the same as kscreensavers
[02:23] <ogra> a dep on: kscreensavers-xsavers | xscreensaver-gl probably ... depends if kscreensaver-xsavers provides the GL tools
[02:24] <Hobbsee> ogra: and if it doesnt, the screensavers either wont work, or will work poorly, right?
[02:24] <ogra> some of them 
[02:24] <Hobbsee> the rss-glx ones are the ones that i'm interested in :)
[02:25] <ogra> i.e. most of the ants GL savers need the xss-getimage program
[02:25] <Windkracht8> Hello all, I wrote a small program with qt for ubuntu, and now I want to package it so I can share it with other people using ubuntu.
[02:25] <Windkracht8> Is there a program/tool that can create the .deb for me? It's a very small program a single executable nothing more.
[02:25] <sivang> anyone from distro-team going to guadec ?
[02:25] <ogra> if rss-glx has anything that grabs the pics or grabs the screen, you will need these tools
[02:26] <ogra> Windkracht8, see the helpfiles installed in your ubuntu, there is a simple packaging guide
[02:26] <sivang> Windkracht8: there actually soemthing like this tool planned as a SoC project, but I don't think there is anything currently other then maybe using cdbs kde targets to ease the packaging
[02:26] <ogra> Windkracht8, and the better channel for such questions is #ubuntu-motu
[02:26] <ogra> :)
[02:26] <Hobbsee> ogra: testing that...
[02:27] <pygi> sivang, there is no something like that as SoC...we didn't accepted it ;)
[02:27] <pygi> Otherwise hey ;)
[02:27] <sivang> pygi: ah ! :-)
[02:27] <Windkracht8> thanks ogra and sivang, going over to the motu after checking your suggestions \.
[02:27] <sivang> pygi: I will work on the spec today, put in order, add teh scope part with the plans and the planned backup use cases as well
[02:28] <pygi> sivang, oki, say when you do so I can look into it ;)
[02:28] <sivang> pygi: sure, but it might not be ready until evening even, but I will ping you when it's done if you're still here
[02:29] <pygi> sivang, just poke me by mail :)
[02:30] <sivang> pygi: to name a few :)
[02:30] <pygi> sivang, no worries :)
[02:31] <\sh> sivang: previous workplace?
[02:31] <sivang> \sh: heh :)
[02:31] <pygi> \sh: strange things happen :P
[02:32] <\sh> sivang: don't tell me you quit the job at private homepage processor company?
[02:33] <sivang> me hides AND lols at \sh's recalling of this ancient acronym
[02:33] <mirak> what is supposed to mount sysfs ? I don't have it in fstab but it's mounted
[02:33] <\sh> sivang: I think only old farts still know this term 
[02:33] <sivang> \sh: hehe
[02:33] <sivang> \sh: well, I actually did. for good or worse. it had to be done.
[02:34] <Hobbsee> ogra: ping?
[02:34] <ogra> Hobbsee, :)
[02:35] <ogra> Hobbsee, so what did you find ? 
[02:36] <Hobbsee> ogra: just tested that out - KDE absolutely *has* to have kscreensaver-xsaver for the rss-glx screensavers to work. no excuses.  it works with both kscreensaver-xsavers and xscreensavers-gl though.  I cant test for what happens if you've got kde and another dm installed though - not sure if it's the same there.
[02:36] <ogra> take your time, its sunday ....
[02:36] <Hobbsee> :P
[02:37] <ogra> ok, sounds like a good bet then to add the above dependency
[02:37] <Hobbsee> it's sunday night, i must be ready for monday morning.  anyway, i work weekends :P
[02:37] <Hobbsee> ogra: but what about the users who dont run kde?  is there a way to set that that's only required if the user has kde?
[02:38] <ogra> yes thats done through the |
[02:38] <ogra> "<ogra> a dep on: kscreensavers-xsavers | xscreensaver-gl probably ... "
[02:38] <Hobbsee> ogra: | means or doesnt it?   so if the user happens to install xscreensaver-gl, runs kde - then it still doesnt work
[02:39] <ogra> hmm
[02:39] <Hobbsee> is there a way to say "if this user runs...oh i dont know...kdelibs4c2a, then they must have kscreensaver-xsavers installed?
[02:39] <ogra> not really ...
[02:39] <Hobbsee> because that would be the ideal situation
[02:39] <Hobbsee> hmmm...
[02:40] <\sh> Hobbsee: what's the problem?
[02:41] <Hobbsee> \sh: on kde, the rss-glx screensavers require kscreensaver-xsavers to run.  but if we had a dep on that...then a whole lot of non kde users would get that on their systems.
[02:42] <\sh> Hobbsee: is rss-glx screensaver so important, or could we remove it?
[02:43] <Hobbsee> \sh: well...bear in mind that i *am* a girl, and those are very pretty screensavers :P
[02:44] <Hobbsee> and i expect that other people use it as well
[02:44] <ogra> yes, if its there to install, the deps should be right 
[02:45] <\sh> Hobbsee: I'm sorry, I'm just not using any screensavers at all, in times of tfts ;)
[02:45] <jsgotangco> lol
[02:45] <Hobbsee> hehe @ \sh 
[02:45] <ogra> \sh, it saves a lot of heating costs in the winter, you really should try it
[02:46] <jsgotangco> never deny a woman her vices!
[02:46] <Hobbsee> hehehehe
[02:46] <sivang> ogra: ha ha ha
[02:46] <\sh> ogra: believe me, a nice bed and this r200 laptop on my hips is just enough to keep me warm and protect me from the winter in germany 
[02:47] <ogra> on your hips ... aha
[02:47] <Hobbsee> \sh: i thought that was a bad idea, and which was why they renamed them as notebooks :P
[02:48] <\sh> ogra: with my blanket beneath the latop ;)
[02:48] <ogra> "this laptop is right *and* left wearable!"
[02:48] <\sh> prust
[02:48] <ogra> s/laptop/hiptop/ (indeed)
[02:55] <Hobbsee> ogra: hmmm...why just not stick a dep on kscreensavers-xsavers | xscreensaver-gl for the moment, then we can go back and look at it later - that will certainly cut down on the problems (kde) people have with the rss-glx screensavers.
[02:56] <Hobbsee> a mostly working version is better than a not working one, after all :P
[02:56] <Hobbsee> i cant see any other solution from my end, at the moment.
[02:56] <\sh> Hobbsee: because this | is just for "install xscreensaver-gl when kscreensavers-xsavers is not there"
[02:57] <Hobbsee> \sh: right.  which is the aim.
[02:57] <ogra> \sh, seems like the best solution so far, i bet kscreensavers-xsavers is a kubuntu-desktop dependency, no ?
[02:57] <Riddell> no
[02:57] <ogra> hmm
[02:57] <Hobbsee> oh hi Riddell 
[02:58] <Riddell> salut Hobbsee 
[02:58] <\sh> ogra: no...kscreensavers is a dep of kubuntu-desktop
[03:38] <pygi_> sivang, sorry, dc :-/
[05:00] <thesaltydog> ?
[07:03] <ivd> Ben Collins, are you there?
[07:03] <mdke> ivd: his irc nick is BenC 
[07:04] <ivd> thanks. :)
[07:05] <BenC> ivd: I'm here
[07:07] <ivd> Hi, I am one of the rt2x00 developers. And was reading the bugzilla report https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/34902
[07:07] <Ubugtu> Malone bug 34902 in linux-source-2.6.15 "Ralink Wireless USB/PCMCIA/PCI hangs PC" [Critical,Confirmed]  
[07:07] <ivd> Exactly that one. :)
[07:07] <siretart> ivd: thats our bugbot :)
[07:07] <ivd> Oops. :)
[07:08] <ivd> I am not really used to IRC. ;)
[07:08] <ivd> The problem with that rt2500 bug is that there are at the moment no new releases for the legacy drivers planned.
[07:08] <ivd> ANd the SMP bug is only fixed in rt2500. Not in rt2400, rt2570 or rt61.
[07:09] <ivd> So with a ubuntu kernel which has SMP on by default (not sure if it is, I am just assuming this) the legacy drivers will not work in ubunto
[07:09] <ivd> ubuntu
[07:11] <siretart> ivd: thats sad. SMP is enabled by default. how invasive would be a patch to fix that?
[07:11] <ivd> which actually brings the point, that perhaps untill rt2x00 2.0.0 is released ubuntu should not ship with the legacy drivers.
[07:11] <mjg59> Do they work on any hardware?
[07:11] <ivd> Well only rt2500 is fixable by using the latest code.
[07:11] <mjg59> The default install kernels aren't SMP
[07:11] <ivd> rt2400 and rt2570 are not fixed at this time, and we are missing the developers & time to make it work.
[07:12] <BenC> mjg59: On amd64 it is
[07:12] <BenC> ivd: What about my bug report with rt2x00 and my rt2500 cards? :)
[07:13] <mjg59> Oh, right
[07:13] <BenC> ivd: problem is, we arleady released with rt2400,rt2500,rt2570,rt61 legacy in dapper
[07:13] <mjg59> Why must drivers be so mean
[07:13] <BenC> ivd: Good news is that even though the kernels are SMP, on a real UP machine, the locks and stuff are nop'd out
[07:14] <BenC> so I really don't think that SMP has a lot to do with most of it (except on real SMP machines)
[07:14] <ivd> BenC: Well looking at the problems the rt2500 are causing they are really similar to the SMP bugs.
[07:14] <BenC> what exactly is the issue on SMP?
[07:14] <ivd> There have been reports before that SMP kernels on a UP machine is still causing problems.
[07:15] <BenC> ivd: Our SMP on UP is a different situation
[07:15] <ivd> deadlocks, and a lot of races
[07:15] <BenC> it really is more like a UP kernel when run on SMP, than the stock kernel would be
[07:15] <BenC> deadlocks would be impossible considering that all the lock's are nop'd out
[07:15] <BenC> more like a UP kernel when run on a UP system
[07:16] <ivd> True again. But there is something in the SMP enabled kernels that is causing problems. Even on UP machines.
[07:16] <ivd> Multiple users have tested this and it always resulted in problems.
[07:16] <BenC> ok
[07:16] <ppd> hi. where is openobex.pc in the dev package?
[07:16] <BenC> ivd: So CVS contains a fix for rt2500?
[07:17] <BenC> because we don't get a lot of reports on many other ralink cards besides rt2500
[07:17] <ivd> Yeah, latest cvs works on SMP sustems.
[07:17] <BenC> I may end up syncing the CVS version for a dapper update...I have two cards so I can atleast test it
[07:17] <ivd> Only rt2400, rt2570 and rt61 are still problematic.
[07:20] <_ion> ppd: This is probably what you're looking for: luotain% apt-file list libopenobex-1.0-0-dev
[07:20] <_ion> libopenobex-1.0-0-dev: usr/bin/openobex-config
[07:22] <ppd> _ion: hm. how shall I use that openobex-config?!
[07:22] <ivd> BenC: If you have any problems with the rt2500 on SMP with latest CVS let me know.
[07:23] <_ion> ppd: My guess would be "openobex-config [flags] " instead of "pkg-config [flags]  openobex"
[07:23] <BenC> ivd: will do, thanks
[07:23] <ppd> _ion: but this is the libsyncml configure script
[07:23] <ivd> BenC: rt2x00 beta4 will be released within a few weeks but altough that is not yet ready for distros either, it will be a major step forwards since I expect it to be one of the last beta releases before stable
[07:24] <ppd> _ion: it just complains about missing openobex
[07:24] <BenC> ivd: I'm using current CVS and my rt2500 cards still don't work
[07:24] <BenC> ivd: Anything I can do to help track that down?
[07:24] <ivd> BenC: lockups? freezes? Or something else?
[07:25] <BenC> ivd: I sent email to the list about it a few days ago
[07:25] <BenC> sent reg output for both legacy and rt2x00
[07:25] <BenC> it just wont associate
[07:25] <BenC> rt2500 works perfectly on x86 and x86_64 for me, but rt2x00 wont work at all on either
[07:26] <BenC> ivd: We release in november, any chance rt2x00 will be stable by then?
[07:26] <ivd> BenC: (Lol, and I couldn't find your email anywhere... :) )
[07:26] <ivd> BenC: I give that chance 75%
[07:26] <BenC> ivd: that's funny because you replied to the email I sent :)
[07:27] <ivd> Or at least it should have entered the Beta release where everything is working, but no hardware encryption yet.
[07:27] <BenC> Subject: 	[Rt2400-general]  Problem rt2500pci with rt2x00 CV
[07:27] <BenC> and any chance you will be using stock kernel ieee80211 instead of dscape?
[07:27] <ivd> BenC: yeah, but I quickly forget names. Especially when I it is matching a name between forums and mailinglist. ;)
[07:28] <ivd> BenC: Nope
[07:28] <BenC> isn't dscape the cause of some of your missing functionality?
[07:28] <BenC> I mean softmac is atleast in the kernel and it seems to be working well (for bcm43xx atleast, which I use too)
[07:28] <ivd> BenC: No, that was the stock kernel ieee80211 stack. That stack was used in Beta3 and it was not usable for us.
[07:29] <mjg59> BenC: It's likely that dscape will be merged to the stock kernel at some stage
[07:29] <ivd> BenC: Ah that one. That has been added not too long ago. We had moved from the IPW stack to dscape stack by then. And it would take a lot of time to switch back.
[07:29] <BenC> aslong as rt2x00/dscape is on track for kernel inclusion I have no complaints then :)
[07:29] <ivd> BenC: And indeed softmac is already on the list for removal.
[07:30] <ivd> BenC: rt2x00 is in the wireless-dev kernel tree together with dscape. When they merge they will be together. :D
[07:30] <mjg59> BenC: Yeah, we probably ought to look at pulling from the dscape branch of wireless-dev in future
[07:30] <BenC> yeah, that sounds like a good plan
[07:31] <ivd> BenC: I am following the development of dscape closely to make rt2x00 always compatible with the latest dscape version.
[07:31] <ivd> BenC: bcm43xx has 2 trees. 1 for softmac and one of dscape. The dscape version is also located in wireless-dev
[07:32] <BenC> well bcm43xx+softmac is in 2.6.17-git
[07:32] <infinity> BenC: Given the ltmodem problems on our SMP kernels on UP machines, I'm willing to belive that something's "not quite right" there.  That's why, at the last minute, I had to disable ltmodem building on anything but -386.
[07:33] <BenC> infinity: yeah, I saw that
[07:33] <ivd> Correct, but they are also maintaining the dscape version for when dscape will be merged with mainstream
[07:33] <BenC> there may be some SMP related things that aren't getting nop'd out of modules, and I hadn't thought about that
[07:34] <BenC> I need to revisit the smp-alt nop tables for modules in edgy
[07:34] <BenC> I think I can wedge something in the relocation code to help with it
[07:36] <bluefoxicy> wtf
[07:36] <bluefoxicy> Arjan is telling me the code I'm trying to write in the kernel is fundamentally impossible
[07:36] <bluefoxicy> and I'm looking at what I just wrote and it does all these things he just got done telling me can't be done o_O
[07:37] <mjg59> bluefoxicy: Which Arjan?
[07:37] <tseng> you know what happened last time you argued with arjan, linus
[07:37] <bluefoxicy> mjg59:  van de Ven
[07:37] <tseng> mjg59: van den
[07:37] <mjg59> He generally knows what he's talking about...
[07:37] <bluefoxicy> tseng:  I'm showing code this time
[07:38] <bluefoxicy> mjg59:  He's telling me I can't have one arch_align_stack() that works on all architectures because architectures may have different alignments and may have varied alignments for different userspace (i.e. 32/64 bit multilib userspace); I already solved those problems, it works.
[07:38] <ivd> BenC: I gtg now. I'll take another look at the logs you send previously. Since apparently I either missed a register initialization thing or there is another problem happening.
[07:38] <bluefoxicy> tseng what do I do, hide my code or show it to him?
[07:39] <BenC> ivd: Ok, thanks
[07:39] <mjg59> Code speaks wonders
[07:39] <BenC> ivd: btw
[07:39] <tseng> bluefoxicy: you can show it if you'd like
[07:39] <tseng> bluefoxicy: did you do one for hppa
[07:39] <ivd> BenC: I hade made several fixes for the registers yesterday, so it should have worked now..
[07:39] <BenC> ivd: If you are willing to help with bug reports from launchpad, I'm willing to force rt2x00 on folks during edgy devel to maybe whip it into shape by our release
[07:39] <BenC> more users can possible help shake down things a bit
[07:40] <bluefoxicy> tseng:  one for hppa?  The code is not per-arch, and the main randomize_stack_top() already accounts for stacks that grow up rather than down (someone else wrote that code)
[07:40] <tseng> (oh)
[07:40] <BenC> ivd: I haven't tried in a few days, I can try again
[07:40] <tseng> bluefoxicy: might as well show him I guess
[07:41] <BenC> ivd: At worst, I just switch off to legacy in the later days of devel
[07:41] <ivd> BenC: I can take a look at the bugs in lauchpad about rt2x00. But I have little time for legacy driver maintenance.
[07:41] <bluefoxicy> tseng:  oh, though thanks, you just reminded me I need to take the same stack-grows-up check and stick it in arch_align_stack(); mine currently moves %esp down, it needs to move up if the stack grows up (I think... I honestly don't know, it just seems logical)
[07:41] <tseng> bluefoxicy: I would think
[07:41] <BenC> ivd: No, I mean help with bugs on rt2x00 if I force ppl to use it :)
[07:41] <ivd> BenC: lol. :)
[07:42] <ivd> BenC: Thats a deal then. :)
[07:43] <ivd> BenC: if you could inform me about bugzilla reports I would happy to take a investigate those problems.
[07:43] <ivd> *launchpad reports
[07:43] <BenC> excellent
[07:45] <ivd> BenC: I gtg now. Cya
[07:46] <HiddenWolf> who is the ubuntu webmaster? 
[07:46] <ogra> HiddenWolf, heno
[07:46] <ogra> (one of them)
[07:46] <HiddenWolf> ogra: There is a screenshot of oo-welcome on the "desktop" page which refers to the installer as espresso
[07:47] <ogra> ouch
[07:47] <ogra> i think there is a website component in malone since a week or so ... 
[07:47] <HiddenWolf> http://www.ubuntu.com/include/img/openoffice.png
[07:48] <HiddenWolf> it might be applicable to example-content as well
[07:48] <HiddenWolf> and there doesn't seem to be a website component
[07:51] <ogra> ah, yes, there was only a discussion about re-adding itr
[07:54] <kagou> hi
[08:03] <ProN00b> wmv3 worked in vlc in badger but it doesn't work in drake anymore
[08:04] <kagou> ProN00b: you have made a bug report ?
[08:06] <ProN00b> no, i regard this as one, but where can i post formally ? (and its not really a bug, i think the package maintainer just decided to not enable external codecs anymore)
[08:08] <kagou> ProN00b: https://launchpad.net/distros/ubuntu/+source/vlc/+bugs for existing bug and https://launchpad.net/distros/ubuntu/+bugs for report one
[08:09] <kagou> ProN00b: see #ubuntu for help.
[08:11] <ProN00b> +source ?
[08:25] <HiddenWolf> ogra: can you make sure that someone looks at that screenshot?
[08:25] <mgalvin> jdub: do you also do the actual moderation of ubuntu-news?
[08:27] <mdke> mgalvin: "ubuntu-news list run by mako at ubuntu.com"
[08:27] <mdke> mgalvin: (I think Riddell is a moderator too)
[08:27] <mgalvin> mdke: ok thanks
[08:41] <BenC> has dapper-security opened yet?
[08:47] <infinity> BenC: Not yet.
[08:48] <infinity> elmo needs to mess with some fiddly launchpad->dak import stuff, then we'll be good to go.
[08:48] <infinity> Monday, hopefully.
[08:58] <desrt> heh
[08:58] <desrt> new kernel already?
[09:01] <infinity> BenC: I assume we're holding off on dapper security updates until we can sneak in Sparc tg3 fixes anyway, no? (or is there something critically urgent that we have to release for YESTERDAY)?
[09:02] <BenC> infinity: yeah, still waiting on that one
[09:02] <desrt> BenC; did you get the email i sent?
[09:02] <BenC> desrt: what was it about?
[09:03] <desrt> pci_restore_state
[09:03] <BenC> yeah, I got that
[09:03] <desrt> gregkh and andrew morton have already signed off on the mentioned change, fwiw
[09:03] <BenC> the reverse order one?
[09:03] <desrt> ya
[09:03] <BenC> can you forward the patch to me?
[09:03] <desrt> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-03-pci/pci-reverse-pci-config-space-restore-order.patch
[09:04] <desrt> it won't work for ubuntu unless you turn the fuzz level up pretty high
[09:04] <desrt> since we already have a patch in that part of the code
[09:04] <desrt> but it's just basically for (i = 0; i < 16; i++) --> for (i = 15; i >= 0; i--)
[09:05] <BenC> Ok, I'll get it into the dapper-security upload
[09:05] <desrt> are you generally open for requests?
[09:06] <BenC> if they make sense, yeah
[09:06] <desrt> also, a fix for a device table in usbhid to enable the Fn key on my macbook
[09:06] <BenC> I'm going to be more open for dapper-updates than I was for breezy-updates since I already have an edgy kernel ready, and the workload wont be so high
[09:07] <desrt> also -- if possible, could you enable mac_hid on intel?
[09:07] <HiddenWolf> BenC: wow, what happened to taking a few days off? :)
[09:07] <desrt> it's the thingy that does the mouse button emulation
[09:07] <infinity> BenC: Speaking of your edgy kernel, can you let me give LRM a once-over before you upload the first edgy revision?
[09:07] <BenC> desrt: provide patches, and I'll review them
[09:07] <infinity> BenC: There are a few gotchas that I want to make sure didn't... getcha.
[09:07] <desrt> BenC; is .dsc format ok?
[09:07] <BenC> infinity: Sure, it's pretty smallish in changes from the dapper version
[09:08] <infinity> BenC: (And I'm really bad at letting things go)
[09:08] <desrt> bah
[09:08] <infinity> BenC: And, it should be larger in changes from the dapper version than you've made it, I suspect. :)
[09:08] <BenC> desrt: .dsc, no, I need patches in git format preferably, or just diff -u if not
[09:08] <desrt> k.  i'll get back to you with them
[09:09] <BenC> HiddenWolf: No one else is taking days off, so I can't afford to look lazy :)
[09:10] <BenC> "edgy's been open for 2 days ben, and there's no new kernel crack...we need to talk"
[09:10] <HiddenWolf> BenC: lmao
[09:15] <BenC> desrt: pci-reverse patch is in git now
[09:16] <desrt> BenC; rocking :)
[09:16] <desrt> if possible, changelog cred me for finding that it makes sleep work on the macbook :p
[09:18] <infinity> desrt: Haha.  "There are no original ideas" and all that. :)
[09:18] <desrt> infinity; i was up until 6:30am!
[09:18] <desrt> crikey.
[09:18] <desrt> for a one-liner
[09:18] <infinity> desrt: At least you got confirmation from others that your fix is sane.
[09:19] <desrt> infinity; true story.  and as a result,  it'll land in the next kernel
[09:19] <desrt> ++
[09:22] <desrt> BenC; #1: http://desrt.mcmaster.ca/random/intel-hda.patch
[09:23] <desrt> BenC; ubuntuified version of a patch from the mactel-linux page
[09:23] <desrt> (were some small conflicts)
[09:26] <desrt> BenC; what's your policy about changing kernel config?
[09:26] <zul> hey
[09:26] <desrt> BenC; specifically - i have a patch in my macbook-modules package which #define's a CONFIG_ variable to avoid having to change the kernel config...
[09:26] <HiddenWolf> desrt: after release?
[09:26] <desrt> #define CONFIG_USB_HIDINPUT_POWERBOOK
[09:28] <desrt> HiddenWolf; ya.  in dapper.
[09:33] <BenC> desrt: that one should be ok
[09:33] <BenC> desrt: pass that intel-hda patch by crimsun (better yet, send it to kernel-team@l.u.c
[09:33] <BenC> )
[09:34] <desrt> BenC; the #define thing should be OK?
[09:34] <BenC> yeah
[09:34] <desrt> ok.
[09:34] <looksaus> is there anything I can still do to help https://launchpad.net/distros/ubuntu/+source/firefox/+bug/40067 get fixed?
[09:34] <Ubugtu> Malone bug 40067 in firefox "firefox freezes after a few secs on ppc" [Normal,Confirmed]  
[09:34] <desrt> the patch is pretty trivial then.  lemme post it
[09:34] <BenC> Ubugtu: odd, I'm using firefox daily (all day) on my G4
[09:34] <BenC> hrm
[09:35] <BenC> s/Ubugtu/looksaus/
[09:35] <looksaus> it's a bit ironic that I'm leading ubuntu-be.org without a working gecko engine...
[09:35] <desrt> benc; http://desrt.mcmaster.ca/random/hid.patch
[09:35] <looksaus> someone tried to reproduce it, but failed
[09:35] <BenC> desrt: kernel-team@l.u.c please
[09:35] <desrt> ok.
[09:35] <BenC> so I can just chuck the whole mbox into git-applymbox
[09:35] <looksaus> (some ubuntu dev, I mean)
[09:35] <desrt> :)
[09:35] <looksaus> another user confirmed it
[09:35] <desrt> BenC; attach the files to the email, then?
[09:36] <BenC> inline
[09:36] <BenC> no attachment
[09:36] <desrt> i hope the tab/spaces don't get messed up.
[09:36] <looksaus> BenC, would it make sense for me to set up an ssh connection into this machine?
[09:36] <BenC> short description at top, and subject should be like: [UBUNTU:foo]  short desc
[09:36] <BenC> desrt: what are you using for a mail client?
[09:36] <desrt> evo
[09:36] <BenC> preformatted should work
[09:37] <looksaus> I mean, to provide you or someone else ssh access to this machine?
[09:37] <BenC> looksaus: I'm no firefox dev, so I can't help
[09:37] <desrt> so like [UBUNTU:snd-hda-intel]  fix routing on macbook
[09:37] <BenC> yeah, perfect
[09:37] <desrt> k
[09:37] <looksaus> BenC, I don't mean you per se
[09:37] <looksaus> who could I try to talk to? or is there anything else I could do?
[09:37] <BenC> looksaus: I don't know how the firefox dev likes to handle that
[09:38] <BenC> likely a good gdb backtrace would help
[09:38] <looksaus> see the bug report
[09:38] <looksaus> it's already there
[09:38] <BenC> then there's not much else to do other than maybe go to the mozilla folks directly
[09:38] <looksaus> ok :(
[09:39] <looksaus> BenC, would it be useful for me to drop by the Paris conference?
[09:39] <desrt> BenC; about patchlevel... should the toplevel path compoent be linux/ or drivers/ ?
[09:40] <BenC> looksaus: yeah, can't hurt
[09:40] <BenC> desrt: -p1 type level
[09:40] <desrt> k
[09:40] <looksaus> ok, so now my job is to find out who's doing firefox bugs in ubuntu...
[09:40] <BenC> looksaus: can't guarantee anyone will have time to look at it
[09:40] <looksaus> thx
[09:40] <BenC> np
[09:41] <looksaus> is there also less technical work at this meeting (think stimulating local use & press coverage stuff)?
[09:42] <infinity> looksaus: Not really, it's not that kind of meeting.
[09:42] <infinity> looksaus: it's just a bunch of developers getting together to plan edgy.
[09:45] <Chipzz> ah looksaus zit hier ook :)
[09:46] <looksaus> Chipzz, hey!
[09:46] <BenC> we will be working hard on writing a lot of overly technical documents in the hopes that someone else will have to implement them :)
[09:46] <looksaus> :)
[09:46] <zul> like infinity 
[09:46] <HiddenWolf> Keybuk: lmao. :)
[09:46] <HiddenWolf> Keybuk: how about making init faster. ;)
[09:46] <looksaus> Chipzz, seen http://map.ubuntu-be.org/nl already?
[09:47] <Keybuk> HiddenWolf: actually, that _is_ what I'm planning to do for edgy
[09:48] <HiddenWolf> Keybuk: yay, you'll save me another 20 seconds once a month. ;)
[09:48] <Keybuk> HiddenWolf: though largely I'm planning to make init more reliable and useful
[09:48] <HiddenWolf> sorry Keybuk :)
[09:49] <Keybuk> the upshot of which is that we won't need to start lvm, evms, hpiod, etc. on most machines
[09:49] <Keybuk> thus saving memory too
[09:49] <HiddenWolf> oh, now we're talkin'
[09:49] <infinity> HiddenWolf: No, your cynicism, as it relates to boot time is well-founded, IMO.  I get rather irritated by "if my machine boots 10 seconds faster, YOUR OS WILL STOP SUCKING" stuff too.
[09:50] <Keybuk> apparently Marga did a talk at debconf that Debian boots faster than Ubuntu
[09:50] <Keybuk> as if this were surprising
[09:50] <infinity> HiddenWolf: Keybuk's new init proposal has little to do with speed increases, though (though it will likely yield several), it's all about completely rethinking how we do userspace even scheduling, really.
[09:50] <sivang> re all
[09:50] <HiddenWolf> infinity: still, I'm talking to people I can't see, can't judge what mood they are in, or even culture they come from, yet who I do respect, so I should be more careful.
[09:50] <infinity> Keybuk: Err, but Debian configured HOW?... Ubuntu's default setup has a lot of stuff.
[09:51] <Keybuk> e.g. "mount the usb disk on /usr when it's ready" ... not "mount it 25s after boot whether it's ready or not...oh, wait, can't mount it :p"
[09:51] <Keybuk> infinity: allegedly "the same as Ubuntu" ... I think it was just Debian standard plus GNOME though
[09:51] <sivang> Keybuk: I also get this argument, and try to ask people what's their setup that seem sto boot so quickly.
[09:52] <sivang> they usually need to go extra milage for stuff that comes ootb in ubuntu, then their debian boots just as "slow" ;-)
[09:52] <Keybuk> sivang: remove pcmciautils, brltty, mdadm, lvm, evms, pcmcia, ppp, hplip, festival, apmd, et. al. if you don't need them
[09:53] <Keybuk> it's faster, but not useful from a distrbution PoV
[09:53] <sivang> exactly
[09:55] <Keybuk> if you want the fastest possible boot, compile your own kernel and build in all the drivers you need and leave out absolutely everything else (not even as a module)
[09:55] <Keybuk> prepare a static /dev with just those nodes, then you don't need udev
[09:55] <sivang> right
[09:55] <infinity> Amen, brutha, death to udev.
[09:55] <sivang> heh
[09:55] <infinity> Err, that might be the server guy in me talking.
[09:55] <Keybuk> if you want it _really_ fast, replace init with a small shell script that just starts what you want
[09:57] <Keybuk> infinity: udev is still useful on the server - Solaris has had similar for years, after all
[09:57] <sivang> Actually with my new laptop boot times are best then ever, I just wish I could find the guy how decided ot have a SATA-PATA bridge in t43 models... what I thought was a kernel / ubuntu specific + this exact laptop model problm,
[09:57] <Keybuk> though I realise it doesn't fit in with the BSD-derived "a server must only do exactly what it was supposed to, and no more"
[09:57] <infinity> init here just starts postfix, then kicks off a while loop involving mailx and some guy named "Scott"... Not sure that that's about.
[09:57] <sivang> appears to be lying in the bugs in this bridge
[09:57] <Keybuk> which leaves you stuck when you have to change the network card, and the evil vendor changed the chipset in a minor revision ;)
[09:57] <infinity> Keybuk: Real servers don't use Netgear cards. :)
[09:58] <Keybuk> infinity: or 3com? :p
[09:58] <Keybuk> sivang: what _is_ a SATA-PATA bridge?!
[09:58] <sivang> Keybuk: you don't really want to know
[09:58] <infinity> Keybuk: What 3Com changes chipset in a monor revision?  They always used to be so good about product separation.
[09:58] <infinity> Keybuk: Did this happen in the gigabit line, which isn't their own silicon for once?
[09:58] <Keybuk> infinity: the 'v' one, can't remember which that is
[09:59] <sivang> Keybuk: according to sladen 's research , an what thinkwiki says, this is a method to under exploit a perfectly good SATA controller, and control a PATA HD with it
[09:59] <Keybuk> sivang: all SATA controllers can control PATA hard drives
[09:59] <Keybuk> they usually all have PATA ports on them
[09:59] <Keybuk> though, admittedly, they usually expose them _as_ PATA rather than SATA
[09:59] <infinity> Keybuk: The vortex's all have different model numbers to match this chipsets. (3c590, 3c595, 3c900, 3c905, 3c950, 3c450, etc)
[09:59] <infinity> s/this chip/their chip/
[10:00] <sivang> Keybuk: so , on this machine, I get /dev/sda and the SATA stack is used, but the undelying HD is PATA
[10:00] <Keybuk> infinity: hmm, I honestly can't recall, I just remember tripping over it once :-/
[10:00] <infinity> Thoug, in Linux, they all use the 3c59x driver, since they're similar enough, except for some initial register futzing.
[10:00] <sivang> Keybuk: ah, I see. Then I Wonder why a specoial "bridge" was needed as even Lenovo themselves state that this bridge is used
[10:00] <Keybuk> sivang: are you sure that's the hardware, and not a prematurely libata'd PATA controller in Linux?
[10:00] <Keybuk> all PATA will show up as /dev/sda in time
[10:00] <sivang> Keybuk: is there a more accurate way to test this?
[10:01] <Keybuk> though it would not surprise me if new ATA controllers simply exposed the PATA ports as SATA ports -- it'd me much less silicon
[10:01] <Keybuk> indeed, I'd probably say that's a good thing
[10:01] <infinity> desrt: I'm always open to evil.  'Sup?
[10:02] <thom> desrt: keybuk is a better choice for evil usually
[10:02] <desrt> infinity; i want to enable the mac mouse button emulation hack on x86
[10:02] <sivang> Keybuk: however, it turns out that there are some bugs with this bridge, which the so called "approved" HDs by Lenovo/IBM only workaround a bit
[10:02] <desrt> infinity; preferably in a way that doesn't involve the ABI shifting, ....
[10:02] <sivang> Keybuk: sladen tried with a different HD and it has an enormous performance impact,
[10:02] <infinity> desrt: I refuse to ackowlege that there are computers with less than 2 mouse buttons (unless the number is zero, due to having no mice)
[10:02] <desrt> infinity; unfortunately, the emulation thingy exports a symbol which needs to be called from char/keyboard.c
[10:02] <sivang> Keybuk: but propotional to what I am experiecning with the "approved" drive
[10:03] <desrt> infinity; 1) fewer than
[10:03] <desrt> infinity; 2) i have 2 mouse buttons, but i want to use the emulation for middle mouse
[10:03] <sivang> infinity++
[10:03] <infinity> desrt: Why not just use X's 1++2=3 hack?
[10:03] <desrt> chording is for pussies
[10:03] <infinity> s/++/+/
[10:04] <HiddenWolf> wtf
[10:04] <Mithrandir> desrt: why do you need it in the kernel?
[10:04] <desrt> Mithrandir; because that is where it lives
[10:04] <HiddenWolf> gnome-cups-icon is taking up 30mb ram....
[10:04] <infinity> desrt: Only if you deeply care about having a 3rd mouse button in the console..
[10:04] <desrt> Mithrandir; it's a driver that for some strange reason is only enabled on PPC
[10:05] <infinity> desrt: You could just as easily remap your keyboard a bit in X.
[10:05] <desrt> (admittedly, there's a high correlation between PPC and not having enough mouse buttons, but otherwise there's no good reason for this)
[10:05] <Mithrandir> desrt: you know you can do it using XKB, right?
[10:05] <infinity> desrt: In which case, you want Mithrandir, not me.
[10:05] <desrt> Mithrandir; oh, really.
[10:05] <desrt> Mithrandir; i can make keys act as mouse buttons?
[10:05] <Mithrandir> I poked at it slightly earlier today, but not enough to find out what the syntax was, but it's certainly doable.
[10:05] <desrt> please keep poking :)
[10:05] <sivang> Keybuk: so now I Have to put up with reproducable halts of the system, especially under high IO load ( 2 find running it 2 gnome terminals brings the system to its knees)
[10:06] <desrt> is it some xmodmap thing?
[10:06] <sivang> Keybuk: or restore windows from product revoercy cds and demand they repace it with a SATA drive to be SATA fully
[10:06] <sivang> Keybuk: another workaround seems to be putting the HD In the ultra slim bay, which then puts it into a native PATA controller, which solves the issue
[10:07] <sivang> Keybuk: (this is official by IBM's KB)
[10:07] <desrt> ugh
[10:07] <Keybuk> sivang: sweet :)  don't buy Lenovo <g>
[10:07] <desrt> bbiab.
[10:08] <sivang> Keybuk: I wish someone had told me that before I did that :-/
[10:09] <infinity> sivang: I thought your issue was a vendor that sold you a Thinkpad with a non-approved drive?
[10:09] <infinity> sivang: Hardly Lenovo's fault.
[10:09] <sivang> infinity: oh, that was long long ago :-)
[10:09] <sivang> infinity: I returned that one with a full refund (that was a US dealer, so I could get a full refund)
[10:09] <infinity> Oh, I don't keep up with your laptop sagas. :)
[10:09] <sivang> heheh, yes I do have quite some of them
[10:10] <sivang> infinity: this one I Purchases legite from an .IL approved and known IBM partner
[10:10] <Keybuk> surely you want a known Lenovo partner? :p
[10:10] <Keybuk> given Lenovo != IBM
[10:10] <sivang> infinity: at least it has no dead pixels anymore, and no beeps on the HD being incompatible ;-=)
[10:11] <sivang> Keybuk: same in .IL ;-) even suppport is still run by IBM for Lenovo's boxes
[10:11] <sivang> Keybuk: but yes, a Lenovo partner probably
[10:11] <tale_> can somebody point me to documentation about building cvs gnome projects on dapper?  I need to get the environment configured correctly.
[10:11] <sivang> tale_: seach for jhbuild
[10:12] <tale_> k
[10:12] <sivang> err, search even
[10:12] <Keybuk> tale_: #ubuntu
[10:12] <sivang> tale_: also what Keybuk said :)
[10:13] <tale_> ok.  I looked there, but they seem to be mostly newbie questions not interested in compiling.  I'll give it a try.
[10:13] <HiddenWolf> tale_: there is a page on the live.gnome.org site about it too
[10:13] <sivang> tale_: http://live.gnome.org/JhbuildOnUbuntu
[10:13] <tale_> thanks
[10:13] <HiddenWolf> nice timing. ;)
[10:31] <desrt> Mithrandir; do you have any pointers for me?
[10:42] <desrt> Mithrandir; ok.  i got it.
[10:45] <desrt> Mithrandir; download a utility called xkbset
[10:45] <desrt> Mithrandir; then use xmodmap -e to set the keycodes of the keys you want to Pointer_Button1, 2, 3...
[10:45] <desrt> Mithrandir; then run 'xkbset m' to enable mousekeys
[11:06] <sivang> sladen: ping, you aware of the stick point behavior such that when pressed with the same pressure at the same direction , it will eventually stop moving the curosr, "freeze" and when pressure removed and you don't touch it afterwads will make cursor go in the opposite direciton for some milisecs ?
[11:07] <infinity> sivang: That's intentional, and it's a hardware feature.
[11:07] <sivang> infinity: ah, good, I thought I was starting to get crazy.
[11:07] <infinity> sivang: The pointer is adjusting itself to drift, so that when you wear it out, it won't drift forever.
[11:08] <sivang> infinity: ah, I see interesting life facts of the stick point
[11:08] <sivang> infinity: you also have a think pad right?
[11:08] <infinity> Yeah, and a Toshiba laptop with the same type of pointer.
[11:08] <infinity> And I've owned older Toshibas before "drift correction" was invented, which would get stuck in a corner of the screen when they gold older.
[11:09] <infinity> Very annoying.
[11:09] <infinity> Trust me, drift correction is a Good Thing. :)
[11:09] <infinity> s/gold/got/
[11:09] <infinity> Odd typo, that.
[11:09] <sivang> I see, can you spot the curosr movement in dapper is "jerky" , that is not smooth while used with the stick point ?
[11:09] <sivang> infinity: gold older :)
[11:09] <sivang> you've just made me think more positvely about aging
[11:09] <sivang> indeed, odd typ
[11:09] <sivang> typo
[11:09] <infinity> Jerkiness depends on how you have your acceleration configured, among other things.
[11:10] <infinity> It behaves for me more or less how I want it to.
[11:11] <infinity> I just set an acceleration and velocity (both rather high) that seemed "about right", and got used to it.
[11:12] <infinity> Wit hthe acceleration cranked as I have it, it does "jerk" a bit, but I know exactly where it'll land, so I don't really mind.
[11:12] <sivang> same here, I have high acceleration
[11:12] <sivang> interesting, that in the same acceleration, using hte touch pad it does not jerk
[11:12] <sivang> or, "jerk"
[11:13] <sivang> I guess the touchpad provides smooth motion naturally
[11:13] <sivang> while the stick point hardware has to emulate it
[11:13] <infinity> The touchpad has no native acceleration.  It's just linear movement.
[11:13] <infinity> The stick has native acceleration based on how far you push it from center.
[11:13] <infinity> So you mix the native acceleration with GNOME's acceleration and you get a bit of jerk.
[11:14] <zul> y
[11:14] <infinity> z
[11:14] <zul> a
[11:14] <sivang> x
[11:15] <sivang> I wonder how XP make it not "jerk"
[11:15] <infinity> Better post-processing filtering.
[11:15] <infinity> Well, "better".
[11:15] <sivang> heh
[11:15] <infinity> XP's cursor movement has little to do with what you're actually telling the stick to do, which is generally what people want, I suppose.
[11:16] <infinity> It filters input from mouse devices and smooths them out, so jerky movements become smoother.
[11:16] <infinity> X just passes it through and says "you wanted that last huge jump, you got it"
[11:16] <sivang> I see
[11:17] <sivang> thanks for the clarifications. I wonder if it's worth effort to have something like this in ubuntu / linux in general
[11:17] <infinity> I'm sure people would be happy to take patches for better mouse event filtering.
[11:18] <infinity> For all I know, evdev (the wave of the future for input devices in X, in theory) may already handle some of this stuff, but we don't use it by default.
[11:18] <sivang> do we have packages to experiment and test with?
[11:19] <infinity> xserver-xorg-input-evdev -- No idea how well it works.  Never used it.
[11:20] <sivang> I will give it a try
[11:20] <sivang> ah, already installed , then probably only settings change
[11:25] <sivang> infinity: re touchpad, if it does not have native acceleration, then it uses GNOME's acceleration right?
[11:28] <infinity> sivang: The touchpad is still subject to GNOME's acceleration settings, yes.
[11:28] <infinity> sivang: So is the stick, it just has its own ideas about acceleration too.  So it's accelerated twice.
[11:42] <crimsun> infinity: are you familiar with configuring dapper chroots via deboostrap? I know at least tzconfig and locale-gen need to be executed.
[11:42] <crimsun> debootstrap, rather
[11:42] <crimsun> (and that should probably read "post-debootstrap")
[11:45] <infinity> crimsun: Well, neither needs to be run for a chroot for compiling and other such fun.
[11:45] <infinity> crimsun: But if you're intending to turn that chroot into a desktop system, then yeah, tzconfig should be run at some point, shadow should be configured, a langpack should be installed (which will generate locales for you)...
[11:47] <crimsun> infinity: thanks. I'm receiving quite a few questions about turning a chroot into a desktop system.
[11:48] <sivang> and you proper mounts for the X socks should be available to run GNOME etc..
[11:49] <infinity> sivang: Your question's a different one. :)
[11:49] <infinity> sivang: None of the above is required to use a chroot, just to turn it into an "installed desktop".
[11:49] <HiddenWolf> who will be maintaining X for edgy?
[11:49] <infinity> sivang: To run an X application in a chroot, just bindmount /tmp to /chroot/tmp
[11:50] <infinity> HiddenWolf: Several people.
[11:50] <mdke> HiddenWolf: infinity is maintaining all of edgy
[11:50] <infinity> mdke: Die.
[11:50] <sivang> heh
[11:50] <mdke> everyone else is going to start on edgy+1
[11:50] <HiddenWolf> ;)
[11:50] <HiddenWolf> Piece of cake, he'll only have to fix like 2500 bugs per month
[11:51] <sivang> infinity: and also bindmount home for completness :-)
[11:51] <infinity> sivang: Well, that's assumed.  :)
[11:51] <infinity> sivang: I bindmount /home in all my development chroots.
[11:51] <infinity> sivang: Also a good idea to make sure to "mount -t proc proc-chroot /chroot/proc"
[11:53] <sivang> ah rig
[11:53] <sivang> right, even
[11:53] <crimsun> infinity: yeah, I've followed Colin Walters's debootstrap guide for some time but wasn't familiar with needing to reconfigure passwd, install a langpack, tzconfig, etc. for a Dapper chrooted desktop
[11:55] <sivang> infinity: only one issue still elluded me (and even pitti when we did some DB2 GUI tools testing) what do you do to make the X app inside the chroot to be able to open an X connection? (this seems to be ellusive, and works find on a non chroot system, using ssh -X )
[11:56] <LaserJock> crimsun: you seen https://wiki.ubuntu.com/DebootstrapChroot ?
[11:56] <crimsun> LaserJock: I thought I contributed to that ;)
[11:56] <infinity> sivang: Erm, do you mean specifically over SSH, or just local-to-local X?
[11:57] <infinity> sivang: Bindmounting /tmp (and not blowing away your environment when you chroot) will allow local-to-local.
[11:57] <LaserJock> crimsun: well, I just wondered since it describes post-chroot and fstab
[11:57] <sivang> over ssh it would work, I want it work to local-local
[11:57] <sivang> how do I not blow away my env? is ther ean equivalen to sudo - for dchroot ?
[11:58] <infinity> sivang: If using dchroot, use "dchroot -d" to not destroy the environment, if using plain old chroot, "chroot /chroot su" and not "chroot /chroot su -", since the former is a login shell and will kill your env.
[11:58] <infinity> s/former/latter/
[11:59] <crimsun> LaserJock: it covers many, but not Dapper-specific ones like installing a langpack (i.e., it still says to reconfigure locales)
[11:59] <LaserJock> crimsun: right, hmm I should probably fix that in the Packaging Guide
[11:59] <infinity> crimsun: The only difference between older systems and dapper should be the locales move out of glibc.
[11:59] <infinity> crimsun: Everything else should be the same.
[11:59] <crimsun> infinity: great, noted. Thanks again.
[12:00] <sivang> HiddenWolf: happy birthday
[12:00] <infinity> (And that's a non-issue if, like me, you don't mind living in C/POSIX...)
[12:00] <LaserJock> infinity: one question that I dpkg-reconfigure passwd and it asks me for a root password. Do you know if it is possible to skip that part?
[12:01] <infinity> LaserJock: Don't dpkg-reconfigure passwd.  Why are you doing that?
[12:01] <HiddenWolf> sivang: I feel kinda old, actually. ;)
[12:01] <LaserJock> HiddenWolf: happy birthday
[12:01] <infinity> LaserJock: The only thing that needs to be configured it to enable shadow, so do that explicitely.  "shadowconfig on"
[12:01] <LaserJock> infinity: when I set up a dchroot to use sudo
[12:01] <sivang> HiddenWolf: then feel glad you're not 27
[12:01] <HiddenWolf> *chuckle*
[12:01] <infinity> LaserJock: Err, my dchroots don't have passwd/shadow configured in them at all.
[12:02] <infinity> LaserJock:
[12:02] <infinity> (base)adconrad@cthulhu:~$ grep adconrad /chroot/dapper/etc/passwd
[12:02] <infinity> adconrad:*:1000:1000:Adam Conrad,,,:/home/adconrad:/bin/bash
[12:02] <LaserJock> infinity: hmm, maybe I should modify DeboostrapChroot to just do "shadowconfig on"
[12:02] <infinity> LaserJock: That lovely "*" for a password makes password stop looking for a shadow entry, and you win.
[12:02] <HiddenWolf> Good night everyone
[12:03] <infinity> LaserJock: You only want shadow passwords if the chroot is going to become a "real, installed system" at some point, like crimsun is doing.
[12:03] <infinity> LaserJock: For dchroot, it's kinda pointless, since you don't need to authenticate in the chroot, ever.