[12:13] <jdub> http://osdir.com/Article2346.phtml
[12:13] <jdub> ha ha ha
[12:14] <jdub> "Well, my goodness! It seems as if we're in for an upset. Despite previous polls, it appears that the Ubuntu Nude Man has sneaked ahead of Voting Machines in the final count. It seems that, in the evilness stakes this month, moral values beat the invasion of a self-electing junta of semi-sentient tabulating machines. Ubuttnaked Guy wears the Evil crown, and not much else, and invites us all back to his pad for some Twister and a toast... to evil!"
[12:17] <mjg59> I'm close to wanting more extensive testing of PM stuff
[12:17] <mjg59> Looks like we should be able to manage support for a decent range of Thinkpads, Dells, Toshibas and Sonys
[12:18] <jdub> is there a "file stored *in* the initrd" solution for loading DSDT foo?
[12:19] <mjg59> No
[12:19] <mjg59> It's too late by the time the filesystem code is running
[12:19] <jdub> boh, seriously? yeesh
[12:19] <mjg59> You need a sane ACPI table before you do any PCI setup
[12:19] <jdub> bong
[12:20] <jdub> so tacking it onto the end of the initrd is the only "sane" solution
[12:20] <jdub> what about another file pointed to by grub?
[12:20] <jdub> kernel=blah, initrd=blah, dsdt=blah ;)
[12:21] <mjg59> Yeah, extending grub so it loaded the dsdt and passed the address to the kernel would work
[12:21] <mjg59> But you'd need to extend the linux boot protocol
[12:21] <mjg59> That's the way FreeBSD does it, BTW
[12:22] <jdub> ahar
[12:23] <jdub> that'd be handy
[12:23] <jdub> i'm going to cry rebuilding my kernel all the time
[12:23] <mjg59> The dsdt-in-initrd thing is easy enough
[12:23] <mjg59> Just add a hook to mkinitrd
[12:24] <mjg59> The infrastructure is there already. When you install a deb, it builds a new initrd on the fly.
[12:24] <jdub> yeah
[12:24] <jdub> but didn't you just say you couldn't do that? :)
[12:24] <mjg59> Uh
[12:24] <mjg59> On the end of the initrd, rather
[12:25] <jdub> oh right, yeah
[12:25] <jdub> but we didn't accept that patch
[12:27] <lamont_r> moo
[12:28] <Kamion> hi lamont
[12:28] <lamont_r> evening Kamion
[12:28] <jdub> morning
[12:28] <mjg59> jdub: It's the least invasive way of doing it. Upstream won't take it because the acpi guys want people to fix their BIOSes instead.
[12:28] <mjg59> But, unsurprisingly, that's unlikely to happen much...
[12:29] <lamont_r> mjg59: first step in getting them to fix their bios is to obtain > 10% market share
[12:29] <Kamion> we're working on that one ..
[12:29] <mjg59> lamont_r: Yeah
[12:29] <lupus_> has gnome decent dualview and tv-out support (I mean you can turn them on and put a window on them)
[12:29] <jdub> lupus_: X does :)
[12:29] <mjg59> lupus_: Uh, ish
[12:29] <mjg59> It's X that's responsible for that, and Gnome can then display stuff on it
[12:30] <mjg59> But it's not easy to switch it on or off on the fly at the moment
[12:30] <jdub> mjg59: do you think it's a relatively sane solution?
[12:30] <mjg59> Oh, argh
[12:30] <mjg59> Does Hoary have the fontconfig version that fucks up if you switch on sub-pixel anti-aliasing?
[12:31] <mjg59> jdub: Of the solutions, I think it's the sanest
[12:31] <mjg59> It doesn't break anything unrelated
[12:32] <jdub> there have been quite a few comments about font bongery
[12:32] <mjg59> The fontconfig maintainer forced the autohinter on if you're using subpixel anti-aliasing
[12:32] <mjg59> Which is crack
[12:35] <lifeless> daniels: looking for me ?
[12:43] <Kamion> can some Xish person look at http://people.ubuntulinux.org/~lamont/buildLogs/c/control-center/1:2.8.1-0ubuntu3/control-center_1:2.8.1-0ubuntu3_20041109-2312-i386-failed please?
[12:44] <Kamion> ah, I appear to be missing a build-dep on libxkbfile-dev
[12:45] <lupus_> why is network-manager not yet in hoary?
[12:45] <lupus_> ic that it is in a seperate repository
[12:46] <mjg59> lupus_: Because it doesn't work
[12:47] <lupus_> hehe I wonder how long it will take for me to break my system :)
[12:49] <mjg59> netapplet works better at the moment, but is less cool in the long run
[12:49] <mjg59> Right. I need to add a couple more patches to the kernel, make it depend on initrd-tools, update acpi-support and then we're set
[12:55] <lupus_> btw when I switched to gamin
[12:55] <lupus_> fam package is still installed and running famd
[12:55] <lupus_> shouldn't the gamin package say it can't be installed together with fam 
[12:56] <lupus_> or does running both give no problems
[12:57] <tseng> they dont exactly conflict
[12:57] <tseng> what should happen is something needs to depend on gamin to pull it in on dist-upgrade
[12:57] <tseng> because gnome gets all wacky when you switch from libfam to libgamin and gamin isnt around
[12:58] <tseng> nautilus + g-panel try to connect
[12:58] <tseng> fam will just be dropped from the meta packages and go away on new installs i presume
[12:59] <lupus_> k
[12:59] <jdub> mmm, ubuntu-desktop will depend on gamin
[12:59] <tseng> sounds like a plan
[12:59] <jdub> though fam will still be there
[12:59] <tseng> mm?
[12:59] <jdub> unless i make the libgamin libs conflict with fam
[01:00] <jdub> or something like that
[01:00] <lupus_> uhu
[01:00] <jdub> which is roughly scary
[01:00] <jdub> Kamion: ping
[01:00] <tseng> libgamin conflicts with libfam
[01:00] <Keybuk> "Conflicts" is not to be used for "I think this package smells" :)
[01:00] <jdub> Keybuk: thought so :)
[01:00] <tseng> the packages do, at least. i assume its for good reason
[01:00] <lupus_> libfam is uninstalled
[01:00] <lupus_> but fam isn't
[01:00] <jdub> lupus_: yes
[01:00] <lupus_> when you install gamin
[01:01] <jdub> tseng: yes, those ones do because they conflict at the file level with each other
[01:01] <jdub> Keybuk: *however*
[01:01] <Keybuk> assuming people used aptitude or synaptic, fam will be automatically removed when ubuntu-desktop no longer depends on it
[01:01] <lupus_> but when people upgrade to hoary from debian or warty how do you make it uninstall fam then?
[01:01] <jdub> Keybuk: if libgamin replaces libfam, and fam doesn't work with libgamin, then surely a conflicts would be relatively sane? :)
[01:01] <jdub> lupus_: thus far, we don't
[01:02] <Keybuk> lupus_: it'll happen automatically because it was installed as a dependency of ubuntu-desktop, and nothing depends on it anymore
[01:02] <tseng> libgamin + fam doesnt seem to work here
[01:02] <jdub> if you're using aptitude
[01:02] <Keybuk> jdub: synaptic does it too, fwir
[01:02] <tseng> nautilus hangs waiting to connect, then fails and proceeds to act flakey
[01:02] <tseng> i imagine thats readily reproducable
[01:03] <jdub> Keybuk: so it's not a file conflict, it's a compatibility conflict
[01:03] <Keybuk> jdub: no, Conflicts actually require the complete and utter removal (including postrm) of the package before the conflicting is installed
[01:03] <Keybuk> when combined with meta-packages, it creates a small dependency hell
[01:04] <jdub> so can we make libgamin 'not like' fam in some way?
[01:04] <Keybuk> that'd probably result in some intelligent behaviour such as the removal of ubuntu-desktop and anything else depending on fam before the new packages could even be unpacked
[01:05] <mdz> Keybuk: the aptitude magic won't happen, because it was installed as a task
[01:05] <mdz> not as a dependency
[01:05] <Keybuk> mdz: I thought we installed the meta-package now, and not the task?
[01:05] <mdz> Keybuk: nope
[01:05] <Keybuk> oh, boo, hiss, etc.
[01:05] <mdz> the metapackage happened way too late in the release cycle for that
[01:06] <Kamion> jdub: yes?
[01:06] <jdub> Kamion: n/m
[01:07] <Kamion> ok
[01:07] <Kamion> bleh, that libxklavier change wasn't as simple as I thought
[01:07] <jdub> Kamion: just attempting to tackle the libgamin vs. fam issue :)
[01:07] <Kamion> turns out (a) X.Org build-dep changes and (b) source-level changes for libxklavier are required
[01:07] <amu> FYI, the xorg packages works fine on a sid ( ppc ) 
[01:07] <Keybuk> jdub: this is what "upgrade notes" are for :)
[01:08] <Kamion> Keybuk: we so need Breaks
[01:08] <jdub> it won't actually cause any problems
[01:08] <Keybuk> we do ineed
[01:08] <jdub> but fam and portmap are there needlessly
[01:08] <Keybuk> doogie's reading -dpkg ... maybe he'll contribute some code :p
[01:08] <Kamion> you wish
[01:08] <Keybuk> :o)
[01:09] <Kamion> just a shame that implementing Breaks would lightly touch nearly all of dpkg
[01:11] <jdub> Breaks?
[01:11] <Keybuk> jdub: a gentler version of conflicts
[01:12] <jdub> ah, which is what i'd want
[01:12] <Keybuk> The basic idea is that, roughly, Breaks is to Conflicts as Depends is to
[01:12] <Keybuk> Pre-Depends. Conflicts requires that the conflicted-against package
[01:12] <Keybuk> isn't even unpacked when the conflictor is unpacked, while Breaks allows
[01:12] <Keybuk> the two packages to coexist on the system but (with --auto-deconfigure)
[01:12] <Keybuk> deconfigures one of them. Breaks would be appropriate in cases where
[01:12] <Keybuk> Conflicts: foo (<< some-version) is currently used to indicate that foo
[01:12] <Keybuk> needs to be upgraded to some-version or newer in order to work with the
[01:12] <Keybuk> conflictor.
[01:12] <Keybuk> (me quotes an old Colin mail :p)
[01:13] <jdub> so many thingies
[01:13] <jdub> what do you call those?
[01:13] <jdub> depends/pre-depends/conflicts/etc?
[01:13] <Keybuk> "relationships" :)
[01:13] <jdub> mmm
[01:13] <elmo> "shiny"
[01:13] <jdub> heh
[01:14] <Keybuk> though I'm all for naming the field "Anally-Violates"
[01:17] <Keybuk> kick thom, more fun
[01:17] <lamont2> so, how do I unblank an X server?
[01:18] <lamont2> vt7 is boring - totally black,
[01:18] <pitti> Night everybody!
[01:18] <lamont2> the other vt's are more interesting...
[01:18] <lamont2> and I'd rather not restart X to fix this obvious lidbutton.sh/X interaction bug...
[01:18] <srbaker> guh
[01:19] <tseng> xset dpms force on do anything?
[01:20] <lamont2> tseng: that produces a usage message.. :-)
[01:20] <tseng> works here..
[01:20] <lamont2> xset dpms force on does nothing
[01:21] <lamont2> per xset q: dpms is enabled, monitor is on.
[01:21] <lamont2> however, nothing shows on the Xserver vt...
[01:22] <lamont2> fabbione/daniels still awake?
[01:23] <lamont2> how very amusing... X died/restarted finally...
[01:29] <mdz> how come the hoary-changes messages for my uploads come From: "Ubuntu Installer", while most others come from the uploader?
[01:30] <elmo> the email you used wasn't whitelisted
[01:30] <Keybuk> Changed-By: Matt Zimmerman <mdz@debian.org>
[01:31] <elmo> katie@jackass:~/scratch $ grep mdz /srv/ftp.no-name-yet.com/katie/katie.conf 
[01:31] <elmo>      "mdz@alcor.net";
[01:31] <Keybuk> instead of Changed-By: Matt Zimmerman <mdz@canonical.com>
[01:31] <elmo> (and of course *@canonical.com is whitelisted too)
[01:31] <mdz> hmm, I wonder how that happened
[01:32] <mdz> I could have sworn I changed my $DEBEMAIL a long time ago
[01:32] <mdz> the one thing dch *doesn't* have an option for is the maintainer name/address
[01:33] <elmo> aren't you an emacs user?
[01:33] <mdz> oh, I know what it is
[01:33] <mdz> that was ubuntu-meta
[01:33] <mdz> whose changelog is automagically generated by a script
[01:33] <mdz> which invokes dch
[01:33] <elmo> why would any card carrying emacs user use dch vs. debian-changelog-mode?
[01:33] <mdz> my ubuntu-changelog-widget script sets DEBEMAIL for me
[01:34] <mdz> elmo: seems a lot easier to use from python
[01:34] <mdz> I use debian-changelog-mode for interactive editing
[01:36] <Keybuk> elmo: emacs takes too long to start? :)
[01:37] <elmo> card carrying emacs users always have a copy open :P
[01:37] <Keybuk> yeah, but it might be in the wrong window, or directory
[01:37] <mdz> yeah, that's like complaining that firefox takes too long to start
[01:37] <Keybuk> but usually uses vi to edit things
[01:37] <thom> they're usually wearing white coats backwards, too
[01:38] <Keybuk> otherwise I'd have to find the terminal with emacs open, then remember the path to the debian/changelog I wanted to open, edit it, save it, then find the terminal I was working in before again, then build the package
[01:38] <Keybuk> far easier to just "dch" :p
[01:39] <Keybuk> elmo: if someone can make the X version of emacs not suck, I'll be happy
[01:39] <Keybuk> but all the time it sucks, it's emacs-nox for me
[01:39] <jdub> elmo: he wants pretty fonts, basically.
[01:39] <Keybuk> mdz: can't open a new window
[01:40] <mdz> Keybuk: dude, it can execute arbitrary elisp forms
[01:40] <Keybuk> because emacs is in a terminal
[01:40] <mdz> wtf is emacs doing in a terminal? :-P
 elmo: if someone can make the X version of emacs not suck, I'll be happy
[01:40] <mdz> I thought you were saying it sucked because you had to play the cwd game
[01:42] <Keybuk> http://descent.netsplit.com/~scott/ugl-emacs.png
[01:43] <Keybuk> the X version on the left is far too wide and ugly for me to use
[01:43] <lamont_r> mdz about?
[01:44] <mdz> lamont_r: yes
[01:44] <jdub> Keybuk: can't just fix the fonts?
[01:44] <Keybuk> jdub: edd once compiled the Xft version of emacs, but never got it to run -- it has had little love
[01:44] <Keybuk> the patch won't even apply now, let alone compile or run
[01:45] <lamont_r> mdz: about 820 packages from main are built for ia64 - does it make sense to drop them into w-b and the archive?  worst case elmo winds up moving the Packages files to grumpy and dropping them from hoary
[01:45] <thom> why didn't they use pango/gtk for the main window when they have done so for the menus?
[01:45] <Keybuk> thom: allegedly it's so custom that it's impossible
[01:46] <thom> meh.
[01:46] <Keybuk> so I have an emacs open to work in and use as an IDE, and when I want another editor for anything, I use vi :p
[01:47] <jdub> thom: new ff industrial theme does look nice
[01:47] <Keybuk> 1.0.5?
[01:47] <jdub> 1.0.6
[01:47] <thom> 1.0.6
[01:47] <thom> jdub: yeah
[01:48] <thom> if i get bored of packing tomorrow i'll do a 1.0 ;-)
[01:48] <jdub> is packaging the theme still a pita?
[01:48] <Keybuk> oh, what did that fix?
[01:48] <jdub> heh
[01:48] <thom> Keybuk: it's fixed that the search box was utterly broken on debian/ubuntu installs
[01:48] <jdub> and there were file selector problems
[01:49] <Keybuk> oh right, not noticed anything with 1.0.5 but then I haven't really stressed it :p
[01:49] <thom> yeah, those too appear fixed
[01:49] <jdub> hrm, that was fixed in 1.0.5, as it happens
[01:49] <jdub> he hasn't said anything about 1.0.6 on his blog
[01:50] <jdub> (changes, that is)
[01:50] <Kamion> remind me what I have to do when GNOME hangs at the splash screen?
[01:50] <Kamion> no icons at the bottom
[01:51] <Kamion> gnome-settings-daemon is spinning
[01:51] <jdub> Kamion: got libgamin and no gamin?
[01:51] <Kamion> jdub: got both
[01:52] <jdub> hrm
[01:52] <jdub> http://www.google.com.au/firefox
[01:53] <Keybuk> jdub: pretty
[01:55] <jdub> takes a long time to connect to ftp stuff in nautilus
[01:56] <Kamion> ok, how might I have broken gnome-settings-daemon?
[01:58] <mdz> Kamion: you don't need InstallerSeed stuff in the wiki anymore, right?
[01:58] <jdub> the only thing i can think of that's tweaked it recently would be libgamin/gamin
[01:58] <mdz> I turned the other Seed pages into lists of proposals
[01:58] <mdz> but since InstallerSeed won't get proposals, I think it's obsoleted by the arch archive
[01:59] <Kamion> mdz: nope
[01:59] <Kamion> jdub: trying now after installing libxxf86misc-dev
[02:00] <Kamion> the xorg stuff is conspicuously missing transitional dependencies for things that used xlibs-static-dev
[02:00] <lamont_r> mdz: at any rate, I think ia64 is ready to be in the archive, and would certainly benefit from being there.  your call.
[02:00] <jdub> Kamion: hrm, was this from a futzy control-center build post-xorg?
[02:01] <jdub> oh, pre-xorg...
[02:01] <Kamion> jdub: it's from the one I'm doing now to try to get it working with an xklavier that's actually in the archive
[02:01] <jdub> yuck
[02:01] <Kamion> jdub: I made a no-brainer upload fiddling the build-dep, and now that it's broken I feel obliged to do a proper job rather than leaving it broken
[02:01] <mdz> lamont_r: I don't have a problem with it in principle
[02:02] <mdz> any other considerations?  mirrors?
[02:02] <elmo> as long as there's not going to be an ABI change, mirrors shouldn't be a factor
[02:02] <elmo> (and there's not going to be an ABI change :)
[02:03] <mdz> elmo: was talking about ia64
[02:04] <elmo> so was I ?
[02:04] <jdub> hrm
[02:07] <mdz> elmo: adding a new architecture doesn't impact mirrors?
[02:07] <mdz> I assumed it meant dumping a few extra gigs on them
[02:07] <elmo> oh, well, yes, there is that
[02:07] <mdz> and additional churn
[02:08] <elmo> sorry, I was talking in terms of, if it didn't - for whatever reason - make hoary
[02:08] <elmo> it'll be ~7Gb impact for mirrors - plus the initial churn
[02:11] <jdub> u,
[02:16] <mojo> good morning every1
[02:17] <mojo> check out this new theme for d4x
[02:17] <mojo> http://xlife.zuavra.net/temp/gnomeria-ubuntu.png
[02:25] <Kamion> what is it that spawns gnome-settings-daemon?
[02:26] <Kamion> I want to strace it
[02:27] <mdz> gnome-session, I'd imagine
[02:27] <Kamion> ENOSUCHPROCESS
[02:27] <mdz> it's invoked as x-session-manager via alternatives
[02:27] <Kamion> aha
[02:27] <Kamion> I tried stracing that, though
[02:28] <mjg59> thom: Still awake?
[02:28] <mdz> I think when I was chasing this stuff, I ended up replacing gnome-settings-daemon with a wrapper script
[02:28] <Kamion> hm, probably a good plan
[02:28] <thom> mjg59: barely
[02:29] <thom> mjg59: what can i do you for?
[02:29] <mjg59> thom: Oh, ok - I'm working on exciting! Hot! New! acpi scripts
[02:30] <mjg59> If you'll be around in a couple of minutes you can take a look
[02:30] <thom> rock and roll
[02:30] <m_tthew> anyone else using amd64+xorg heavily?
[02:30] <thom> i'm so staying awake then
[02:30] <thom> m_tthew: i've been running it since monday...
[02:31] <thom> m_tthew: as my primary system
[02:31] <m_tthew> thom: do you seem to be losing mouse events occasionally?
[02:31] <thom> m_tthew: not that i've noticed
[02:31] <m_tthew> I'm having some transient oddness since going to xorg and I'm trying to confirm ym sanity
[02:31] <m_tthew> thom: ok, thanks
[02:32] <m_tthew> my*
[02:34] <robertj> where is the trendy place to put /etc/X11/XF86Config-4 in xorg?
[02:35] <mdz> robertj: trendy?
[02:36] <robertj> hehe, ;)
[02:37] <lupus_> are there plans to integrate lm-sensor and smartd in ubuntu?
[02:37] <lupus_> so you check your systems health :)
[02:38] <mjg59> thom: http://www.kern.srcf.ucam.org/~mjg59/laptops/
[02:38] <mjg59> I've managed to fuck my machine royally while looking at this, so I'm going to reboot now in order to test it :)
[02:38] <mjg59> It adds scripts, but doesn't add events for all of them
[02:38] <mdz> lupus_: there was a proposed goal for Hoary to integrate SMART; see /topic
[02:39] <lupus_> and lm-sensor ? 
[02:39] <lupus_> or is their something familiar
[02:39] <mjg59> thom: Oh, and I forgot to add the rmmod button; modprobe button thing (but that ought to be obvious enough)
[02:39] <mjg59> Hang on, I'll reboot and then test it myself...
[02:40] <thom> k k
[02:45] <lupus_> if I apt-get grepmap
[02:45] <lupus_> it will just work?
[02:54] <mjg59> thom: Heh. Couple of minor issues - give me one more moment...
[02:54] <thom> heh
[02:55] <Kamion> lupus_: depends what you want it to do
[02:57] <Kamion> lupus_: it's not really for end-user use
[03:01] <thom> mjg59: sorry dude, i have to hit the hay now
[03:01] <thom> i'll look in the morning
[03:04] <mjg59> thom: No problem - the ones on the site now should work
[03:10] <lupus_> k I think I found a bug
[03:10] <lupus_> can someone verify
[03:10] <lupus_> with latest xorg
[03:10] <lupus_> ctrl+alt+backspace will stop X
[03:10] <lupus_> but not restart it
[03:11] <lupus_> I just get the terminal then
[03:11] <Kamion> that's up to your display manager
[03:11] <lupus_> can someone test this
[03:11] <Kamion> if you kill X forcibly too many times, it may get bored and give up restarting it
[03:11] <Kamion> I've been using ctrl-alt-backspace lots just now with Xorg, it works as normal with gdm
[03:11] <lupus_> I only did once after reboor
[03:11] <lupus_> hmm
[03:11] <lupus_> weird then
[03:12] <sivang> is there anything I shouldn't bee douing while dist-upgrading ? Just got
[03:12] <lupus_> going to bed now 
[03:15] <sivang> it broken.
[03:15] <sivang> kdelibs-bin and kcontrol conflicts on /usr/bin/filesharesets
[03:15] <Kamion> universe is unsupported, as you well know :)
[03:16] <sivang> ah right :)
[03:16] <sivang> kde will stay out :), in universe..
[03:17] <mjg59> So much rock
[03:45] <mjg59> Ok. The contents of http://www.srcf.ucam.org/~mjg59/laptops should work on a wide range of machines
[03:45] <mjg59> I heartily encourage anyone with an x86 laptop to try them out
[03:46] <mjg59> There's a decent chance of working ACPI suspend to RAM, and if that doesn't work then there's a good chance of working suspend to disk
[03:47] <Kamion> I hate hangs in mallopt()
[03:47] <Kamion> I especially hate them on architectures without valgrind
[03:47] <mjg59> Ha
[03:48] <jdub> mjg59: got dsdt/initrd patches? :)
[03:48] <mjg59> jdub: Dude, it's in there
[03:48] <jdub> yay
[03:49] <mjg59> Oh, shit
[03:49] <mjg59> Missed one (moderately important) ACPI patch
[03:49] <mjg59> jdub: But go ahead and try that stuff, anyway
[03:49] <mjg59> Or give me 10 minutes (or less) and I'll have a slightly better package :)
[03:51] <mjg59> ARSE.
[03:53] <mjg59> SHIT
[03:53] <mjg59> Where has my debian directory gone?
[03:53] <Kamion> a kernel package?
[03:53] <mjg59> OH YOU FUCKING BASTARD
[03:54] <mjg59> For reasons I do not understand, debian/rules just blew away my debian directory
[03:54] <mjg59> Including all the patches
[03:54] <Kamion> mjg59: what package?
[03:54] <mjg59> ACPI test kernels
[03:54] <Kamion> do you have a fully up-to-date kernel-package?
[03:54] <mjg59> Mm?
[03:54] <Kamion> if not, upgrade and read the rant in the changelog on this very subject
[03:55] <mjg59> That is going to make life... awkward.
[03:55] <mjg59> Arse. I have headers but no source file.
[03:55] <mjg59> ARGH.
[03:55] <Kamion> I believe the current version contains a workaround as well as a rant
[03:56] <mjg59> On the bright side, there's relatively little work involved in recreating it
[03:56] <mojo> ^o^, X.org up, thx fabbione, nice exp here
[03:57] <mjg59> Sigh.
[03:57] <jdub> mjg59: :-(
[03:57] <mjg59> jdub: Heh
[03:57] <mjg59> jdub: Just try the ones up there, anyway
[03:57] <jdub> ok
[03:57] <mjg59> I'll worry about it later
[03:58] <jdub> need all those debs?
[03:58] <mjg59> Yeah
[03:58] <mjg59> Need the initrd one installed first
[03:59] <Kamion> segfault inside *ORBit*? how the hell did gnome-settings-daemon get there ...
[03:59] <jdub> ok
[03:59] <Kamion> Oh. gconf. Fuck.
[03:59] <jdub> Kamion: ouch.
[04:00] <mjg59> ACPI is so my bitch
[04:00] <jdub> eugenia makes baby jesus cry
[04:00] <mjg59> Except on the craptop
[04:00] <mjg59> Or some HPs
[04:00] <Kamion> this is only electric fence's idea of a segfault, mind you
[04:00] <mjg59> And my other Thinkpad
[04:00] <mjg59> But the last of these is a driver bug
[04:02] <Kamion> the new Firefox find widget rocks my world
[04:02] <jdub> it's way sexy
[04:04] <mjg59> jdub: You'd better be grabbing packages, boy
[04:04] <jdub> am! am!
[04:15] <jdub> mjg59: rebooting...
[04:15] <Kamion> oho!
[04:15] <Kamion> XklConfigInit() helped
[04:22] <jdub> hrm
[04:22] <jdub> mjg59: so, i put it in S3 sleep
[04:22] <jdub> and woke it up by hitting the power button
[04:23] <jdub> (this is in very single user mode, init=/bin/sh)
[04:23] <mjg59> Ok
[04:23] <jdub> how do i turn the screen on? :)
[04:23] <mjg59> Heh
[04:23] <mjg59> Try running video_post
[04:23] <mjg59> The scripts do that automatically
[04:23] <jdub> aha
[04:23] <jdub> uh oh
[04:23] <mjg59> echo -n 3 >/proc/acpi/sleep; sleep 1; /usr/sbin/video_post
[04:24] <mjg59> Mm?
[04:24] <jdub> ok
[04:24] <jdub> that did the crazy "my lcd screen is about to blow up" effect
[04:24] <mjg59> Ah
[04:24] <mjg59> Ok
[04:24] <mjg59> You need to do this:
[04:24] <mjg59> Add
[04:24] <mjg59> option VBERestore true
[04:24] <mjg59> (but with normal quotes)
[04:24] <mjg59> to /etc/X11/xorg.conf (or whatever)
[04:24] <mjg59> In the device section
[04:25] <mjg59> And then boot fully and press the sleep button
[04:25] <jdub> note that i wasn't running X at all by then
[04:25] <mjg59> Yeah
[04:25] <mjg59> We need X to fully reinitialise the screen
[04:25] <jdub> aha
[04:25] <mjg59> Though this depends on the hardware
[04:25] <jdub> also, i now have a buttload of ide controller modules loaded
[04:26] <jdub> ooh, and now i'm getting buffer i/o errors on uba
[04:26] <jdub> exciting
[04:26] <jdub> mjg59: given that i wasn't in X before, should i try without the vberestore change?
[04:26] <mjg59> They're all loaded in 2.6.8, but in 2.6.8 you could unload them again
[04:27] <jdub> ahar
[04:27] <mjg59> jdub: Add the vberestore change - it seems to be needed on various i855 machines
[04:27] <jdub> ok
[04:27] <mjg59> And remember to restart X :)
[04:28] <jdub> doing so :)
[04:30] <jdub> wha-hey
[04:30] <jdub> suspended correctly from X
[04:30] <jdub> aaaand...
[04:31] <jdub> haha
[04:31] <jdub> the power button woke it up and halted the machine :)
[04:31] <mjg59> Haha
[04:31] <jdub> the screen came on correctly in console mode though :)
[04:31] <mjg59> Oh, rock
[04:31] <pasc> jdub: I get that when I resume my laptop
[04:31] <pasc> so I need to unload the buttom module before I suspend
[04:31] <mjg59> jdub: Does the /etc/acpi/prepare.sh script have rmmod button at the top of it?
[04:32] <jdub> heh
[04:32] <jdub> saw that on the list
[04:32] <jdub> hold on
[04:32] <mjg59> I have a sudden feeling I may have forgotten that
[04:32] <jdub> booting again :)
[04:32] <mjg59> Ha, no
[04:32] <mjg59> It doesn't
[04:32] <jdub> woo :)
[04:33] <mjg59> Add that, and see whether it works
[04:33] <jdub> after the chvt?
[04:34] <jdub> oh top
[04:34] <mjg59> Yeah, right at the top
[04:34] <mjg59> Has the added advantage of reducing bouncing
[04:35] <jdub> we have glowing power light indicating suspend
[04:35] <mjg59> So far so good
[04:35] <jdub> we have console
[04:35] <jdub> haha
[04:35] <jdub> we have shutdown
[04:36] <mjg59> Ha
[04:36] <jdub> i don't actually have a sleep button
[04:36] <jdub> i have a power button
[04:36] <mjg59> Uh
[04:36] <mjg59> How are you triggering the sleep?
[04:36] <jdub> echo -n 3 ...
[04:36] <mjg59> Oh, right
[04:36] <mjg59> That's not going to work
[04:36] <jdub> oh
[04:36] <mjg59> How do you not have a sleep button?
[04:37] <jdub> hrm
[04:37] <mjg59> It's normally Fn+one of the F keys
[04:37] <jdub> i have a suspend function button
[04:37] <jdub> yeah
[04:37] <jdub> i'll see if that works
[04:37] <jdub> those keys are affected by the dsdt foo
[04:37] <jdub> some don't work
[04:38] <mjg59> Yeah, but the spec requires (well, strongly encourages) at least one of them
[04:39] <jdub> yeah, i don't think it's doing bong all
[04:39] <jdub> can i fake it?
[04:39] <mjg59> Just to test, can you do /etc/init.d/acpi stop
[04:39] <mjg59> And then cat /proc/acpi/event
[04:39] <mjg59> And press Fn+all of the keys
[04:40] <jdub> mjg59: acpid?
[04:40] <mjg59> jdub: Sorry, yes
[04:40] <mjg59> Oh, it ought to be Fn+Escape
[04:41] <jdub> button/sleep SLPB 00000080 00000003
[04:41] <jdub> it is
[04:41] <mjg59> Rock
[04:41] <mjg59> Restart acpid, switch to X, hit Fn+Escape
[04:42] <jdub> hrm, i am in X :)
[04:42] <mjg59> Heh
[04:42] <mjg59> Skip that step, then
[04:42] <jdub> nah, not happy
[04:43] <mjg59> Hrm.
[04:43] <mjg59> In what way?
[04:43] <jdub> same as before - no effect at al
[04:43] <jdub> all
[04:43] <mjg59> ?
[04:44] <mjg59> Oh, I see
[04:44] <mjg59> Fuck, I'm useless
[04:45] <pasc> *sigh*
[04:45] <mjg59> jdub: Can you grab http://www.srcf.ucam.org/~mjg59/laptops/acpi-support_0.10_i386.deb ?
[04:45] <pasc> sounds like I'm going to have to switch my laptop to ubuntu too if it has such mad laptop support =-\
[04:45] <mjg59> jdub: Install that and do Fn+Escape
[04:45] <mjg59> I managed to copy files in the wrong direction at one point...
[04:46] <mjg59> pasc: All of this will end up in Debian (eventually)
[04:46] <jdub> pasc: why the sad face? :)
[04:46] <mjg59> Probably post-Sarge, though
[04:46] <mjg59> There's too much that needs to go into the kernel to make it practical right now
[04:46] <jdub> mjg59: AHA!
[04:47] <jdub> we have sleepy power light
[04:47] <jdub> we have flashing screen
[04:47] <mjg59> Tension...
[04:47] <mjg59> It ought to (with luck) result in xscreensaver
[04:47] <pasc> jdub: well i'm already doing most of my debian stuff from within a chroot on an ubuntu desktop
[04:47] <jdub> it does indeed!
[04:48] <mjg59> WHO IS YOUR FUCKING DADDY?
[04:48] <jdub> mjg59: so we totally need to send a key/mouse signal to xscreensaver when it wakes up ;)
[04:48] <jdub> mjg59 IS MY DADDY!
[04:48] <mjg59> jdub: Dude, that rocks
[04:48] <pasc> does anyone know where bob2 is btw?
[04:48] <mjg59> We are going to have totally mad-phat laptop support
[04:49] <jdub> mjg59: i have this really bizarre usb spew though
[04:49] <jdub> pasc: sydney
[04:49] <jdub> mjg59: *everything* comes back up properly
[04:50] <mjg59> jdub: Yeah, there will be weird USB spew
[04:50] <mjg59> The drivers are excessively chatty
[04:50] <jdub> new to 2.6.9?
[04:50] <jdub> i'm getting all kinds of buffer i/o errors and stuff
[04:50] <jdub> unable to read partition table
[04:50] <jdub> there's no disk in there :)
[04:50] <pasc> mjg59: do you have stuff for debian already?
[04:51] <pasc> mjg59: or is this a "in the future" kind of thing?
[04:51] <mjg59> pasc: Not for Debian, yet
[04:51] <mjg59> It needs kernel patches
[04:51] <mjg59> jdub: Heh
[04:51] <mjg59> Yeah, 2.6.9 wants to tell you all about itself
[04:52] <mjg59> pasc: Post-Sarge, I'll be looking at getting all this infrastructure into Debain
[04:52] <mjg59> The problem is that it requires coordinating the kernel, initrdtools and the acpi userland tools
[04:52] <mjg59> And that's going to be pain
[04:52] <pasc> yeah
[04:52] <jdub> ubc...
[04:52] <mjg59> ubc?
[04:53] <jdub> usb block device, it seems
[04:53] <mjg59> Ah, right
[04:53] <jdub> no longer sdX
[04:53] <mjg59> Heh
[04:53] <mjg59> But if you ignore the errors, it all comes back?
[04:53] <mjg59> I've tried to be smart about unloading network drivers, which are the normal reason for breakage nowadays
[04:53] <mjg59> It's possible it needs to do the same for sound drivers, but that's going to be far, far messier
[04:54] <jdub> oh, usb stuff seems to be unrelated
[04:54] <pasc> my main problems on my toshiba was the usb stuff
[04:54] <mjg59> Probably easier to fix all the sound drivers...
[04:54] <jdub> it's just reiniting the usb foo on wakeup
[04:54] <jdub> hrm
[04:54] <jdub> sound
[04:54] <mjg59> pasc: 2.6.9 is much better for usb
[04:54] <pasc> cool
[04:54] <jdub> no problems with sound
[04:54] <pasc> sounds like I need to upgrade then
[04:54] <mjg59> Once we have video sorted, sound is the next big problem
[04:54] <mjg59> jdub: Heh. Except there almost certainly would be if you were playing any when you suspended.
[04:54] <jdub> ooh, that sounds like fun
[04:55] <pasc> mjg59: you can start working on my next problem with suspend too
[04:55] <mjg59> pasc: At this rate I'm going to have to start charging people
[04:55] <pasc> when you knock the bottom of my laptop, sometimes the battery moves 
[04:55] <mjg59> Ha
[04:55] <mjg59> Blue-tac
[04:55] <jdub> okay
[04:55] <pasc> and then it doesn't resume properly ;-)
[04:55] <mjg59> Fixes everything
[04:55] <jdub> that was not appreciated
[04:56] <mjg59> jdub: Yeah. Don't Do That (at the moment, anyway)
[04:56] <mjg59> We need to get in touch with the ALSA people
[04:56] <jdub> mpg123 is now in D state :)
[04:56] <mjg59> jdub: Other thing that you can do is hack the /etc/acpi/events/lidswitch script to suspend on lid closure
[04:57] <jdub> very tempting
[04:57] <jdub> did you hear my surprise at unexpected functionality once i got acpi going?
[04:57] <mjg59> In the long run, we'll have support for checking whether there's an external monitor plugged in
[04:57] <mjg59> And if so, not lock the screen when you close it
[04:57] <jdub> aha
[04:57] <jdub> :)
[04:57] <tseng> mjg59: thatd be killer
[04:57] <jdub> the top line of my console has funny flashing bits
[04:57] <tseng> ive been fighting that here
[04:57] <jdub> after wakeup
[04:58] <tseng> jdub: same here, but it goes away.
[04:58] <tseng> oh suspend, not lidclose lock
[04:59] <jdub> i wonder if xorg will have support for i855 external vga crap
[04:59] <mjg59> jdub: Under what circumstances?
[04:59] <mjg59> jdub: xorg has support for non-mirrored output
[04:59] <mjg59> So you can have separate content on both
[05:00] <jdub> mjg59: when hitting the suspend button, the top line on the console flickers (rows of pixels on and off), and stays that way after wakeup
[05:00] <jdub> ahar
[05:00] <jdub> mjg59: so does this kernel have wacky swsusp stuff in it?
[05:01] <tseng> i wonder if doing the non-mirrored output i could get a higher res on the CRT
[05:01] <mjg59> jdub: Just the console, or in X as well?
[05:01] <mjg59> jdub: It has swsusp stuff in it, yes
[05:01] <jdub> not fussed
[05:02] <mjg59> jdub: Sorry, are there any flickering lines in X?
[05:02] <mjg59> jdub: Add a resume=/dev/hdawhatever to /boot/grub/menu.lst and do update-grub
[05:03] <jdub> no flickering lines in X
[05:03] <jdub> X is in glorious resumed technicolour
[05:03] <mjg59> Cool
[05:04] <bob2> pasc: yo
[05:04] <mjg59> As long as you installed the initrd-tools package before the kernel, just adding the resume line should result in echo -n disk >/sys/power/state doing hot suspend to disk action
[05:06] <jdub> grr.
[05:06] <jdub> even with 2.6.9, my digital sound output still has this zinging noise
[05:07] <mjg59> Now, if only I knew why the craptop and keybuk's HP didn't work...
[05:09] <bob2> beats a short, sharp bong.
[05:10] <mjg59> jdub: You're going to be the envy of your friends now, you know
[05:10] <mjg59> Working ACPI is still a thing of wonder
[05:13] <jdub> i will have to find a crowd of people to impress
[05:17] <jdub> debsig
[05:17] <mjg59> Haha
[05:17] <mjg59> IN THE FUTURE THERE WILL BE ACPI
[05:17] <jdub> AND YOU WILL BOW DOWN BEFORE IT
[05:17] <hornbeck> when do we get inotify
[05:17] <hornbeck> ??
[05:18] <mjg59> Man, I'd better get a wedding invitation after this
[05:18] <jdub> dunno
[05:18] <jdub> haha
[05:18] <bob2> I for one welcome our new ACPI overlords
[05:18] <mjg59> jdub: We need more testers
[05:18] <mjg59> Find more testers
[05:19] <jdub> make your repo suckable
[05:19] <jdub> and ping ubuntu-devel :)
[05:19] <mjg59> Oh man
[05:19] <mjg59> I'll do that in the morning
[05:19] <mjg59> It's 04:20 here
[05:19] <jdub> heh
[05:19] <mjg59> jdub: I keep subscribing to ubuntu-devel but I never here anything after I go to the confirmation link
[05:20] <jdub> oh?
[05:21] <mjg59> No idea why
[05:22] <jdub> want me to sub you?
[05:22] <mjg59> Yeah, thanks
[05:22] <jdub> preferred address?
[05:23] <mjg59> mjg59@srcf.ucam.org is good
[05:24] <jdub> done
[05:24] <mjg59> Thanks!
[06:27] <fabbione> morning guys
[06:27] <lamont_r> evening fabbione
[06:27] <lamont_r> I have a question for you fabbione
[06:28] <lamont_r> sometime after X is blanked (lidbutton.sh), it won't come back... how do I whack it enough to wake it up?
[06:29] <fabbione> lamont_r: is that on a laoptop?
[06:29] <lamont_r> yes
[06:29] <fabbione> i am not sure what lidbutton.sh does...
[06:29] <fabbione> is that x.org or xfree86?
[06:29] <lamont_r> xf86 - stock warty
[06:30] <lamont_r> it does this:
[06:30] <lamont_r> su $user -c "(xscreensaver-command -throttle && xscreensaver-command -lock)"
[06:30] <lamont_r> xset dpms force off
[06:31] <lamont_r> and if I wake it up soon enough, then all is happy.  if not, then it's not so happy.
[06:31] <fabbione> does the laptop die completely? or only X=
[06:31] <fabbione> ?
[06:31] <lamont_r> only X.
[06:31] <lamont_r> black screen.
[06:31] <lamont_r> other vt's are happy
[06:31] <fabbione> hmmmm
[06:31] <fabbione> it would be nice to 
[06:31] <fabbione> strace it
[06:31] <fabbione> and see what is going on...
[06:32] <lamont_r> I tried 'xset dpms force on' and a few other things...  eventually X died.
[06:32] <fabbione> or gdb the -dbg version
[06:32] <lamont_r> and restarted --> all well.
[06:32] <lamont_r> likewise, ctl-alt-backspace is a known "fix" :-(
[06:32] <fabbione> hell no
[06:32] <fabbione> but there is a lot of code that i don't know in X
[06:32] <fabbione> it's simply too big
[06:32] <lamont_r> yeah, way big.
[06:33] <lamont_r> I figure I'll worry more after I switch over to xorg.
[06:38] <fabbione> ehe
[06:53] <fabbione> hmm
[06:54] <fabbione> i really really don't like this phase one on sparc
[06:54] <fabbione> lamont_r: i keep getting tons of failure on the gcc test suite
[06:54] <fabbione> but i don't understand why
[06:54] <fabbione> the chroot is a fresh sid
[06:54] <fabbione> (phase one)
[06:54] <fabbione> so there is really no difference on what is building
[06:55] <fabbione> and gcc has been imported from sid
[06:57] <lamont_r> fabbione: yeah - saw interesting failures on other architectures as well.
[06:57] <lamont_r> are you trying to build warty or hoary?
[06:57] <fabbione> hoary
[06:57] <fabbione> so it's basically recompiling gcc from sid in a sid chroot right now
[06:57] <lamont_r> which should work.
[06:57] <fabbione> exactly
[06:57] <lamont_r> or bug doko, would be my activity.. :-)
[06:59] <fabbione> i think i know what it is
[06:59] <fabbione> i am afraid it is still trying to build 64bit binaries
[06:59] <fabbione> and i need to change the call to dpkg-buildpackage
[06:59] <fabbione> i had to do the same ith pbuilder
[07:28] <fabbione> mdz: ping
[07:28] <fabbione> pool/universe/x/xorg/xfree86-common_6.8.1-1ubuntu1_all.deb
[07:28] <fabbione> THIS IS REALLY REALLY REALLY REALLY BAD!
[07:28] <fabbione> it has to be into main!
[07:41] <lamont_r> fabbione: that's an elmo overrides thing, I expect.
[07:41] <lamont_r> trivial fix, just requires a whack.
[07:41] <fabbione> i know
[07:41] <fabbione> but all xfree86 -> xorg upgrades are broken without that piece
[07:41] <fabbione> it is required to migrate some config files
[07:41] <fabbione> and to force the switch over to xorg-common
[08:04] <daniels> lifeless: I was, yeah
[08:04] <daniels> KeyserSoze: oh, neat
[08:05] <daniels> lamont_r: sup
[08:10] <doko> morning
[08:11] <doko> lamont_r, fabbione: I'll start a gcc build in a current sid env to reproduce the failures ...
[08:12] <lamont_r> doko: thanks
[08:13] <fabbione> doko: i am trying to build again using sparc32 in front of dpkg-buildpackage
[08:13] <fabbione> apparently the /etc/disable_64_gcc is not enough
[08:19] <doko> you could disable the biarch compiler. (debian/rules.defs)
[08:26] <daniels> new from the forums: 'FGLRX sucks for ATI, why can't I get 3D?'
[08:26] <daniels> just look in the first part of your subject!
[08:27] <lamont_r> daniels: remind me to make you help me get taht working in spain...
[08:30] <daniels> lamont_r: fglrx ... working?
[08:30] <daniels> lamont_r: you'd better have some pretty incredible bribes lined up
[08:30] <daniels> lamont_r: what sort of video chipset do you have?
[08:36] <lamont_r> radeon 7500
[08:36] <lamont_r> that's the home desktop though...
[08:36] <bob2> hah
[08:36] <lamont_r> laptop is ati rage mobility p/m agp 2x...
[08:36] <lamont_r> which I gather might be 2d?
[08:43] <ik5pvx_> X Window System Version 6.8.1 (Ubuntu 6.8.1-1ubuntu1 20041109183716 root@terranova.warthogs.hbd.com)
[08:43] <ik5pvx_> great job!
[08:43] <fabbione> ehy ik5pvx_ !
[08:43] <fabbione> thanks :-)
[08:44] <fabbione> there are still a bunch of bugs to fix
[08:44] <fabbione> but tho
[08:44] <ik5pvx_> only gotcha I had, I had to manually install xserver-xorg. Is that intended for this testing phase ?
[08:45] <fabbione> no
[08:45] <fabbione> if you have ubuntu-desktop installed
[08:45] <fabbione> everything is smooth
[08:45] <fabbione> if you customize your desktop you are on your own
[08:48] <ik5pvx_> oh, that's it.. I think I removed ubuntu-desktp because it asked to install stuff I don't want. It's all right then. If I can find some time, I'll later try to upgrade the other install I have (the clean install for test purposes). BBL
[08:56] <daniels> lamont_r: hm, rage mobility, should get very, very basic 3d out of it
[08:56] <daniels> lamont_r: i'll check it out in spain, but no fglrx needed!
[09:18] <doko> fabbione: please email me the build/gcc/testsuite/*.log files 
[09:19] <fabbione> doko: i will if it keeps failing
[09:19] <fabbione> but i am pretty sure it's related to the call to sparc32
[09:19] <doko> started a build on an ultrasparc IIi ...
[09:20] <fabbione> doko: cool
[09:20] <fabbione> doko: with or without sparc32 ?
[09:21] <doko> with sparc32
[09:21] <fabbione> doko: it would probably be more useful without
[09:22] <fabbione> or both
[09:22] <fabbione> well up to you
[09:26] <doko> let's wait, the testsuite will finish on Friday, then I can check without.
[09:30] <fabbione> doko: i am faster on my netra :-)
[09:30] <fabbione> i will test both again and let you know
[09:30] <fabbione> if i only still had access to the e10k :-)
[09:30] <fabbione> make -j 32 ;)
[10:18] <fabbione> seb128: hey
[10:18] <fabbione> seb128: are you using a pure utf8 locale on hoary?
[10:18] <fabbione> (and x.org and co?)
[10:20] <seb128> fabbione: yes
[10:21] <seb128> oups, and hi fabbione ;)
[10:21] <seb128> fr_FR.UTF-8
[10:21] <fabbione> seb128: please try to revert to a non-utf8 locale
[10:21] <fabbione> and check the copy&paste again
[10:21] <seb128> ok
[10:21] <fabbione> a friend of mine doesn't have that problem at all
[10:21] <fabbione> gedit <-> emacs both directions work
[10:22] <tuo2> so, what's doing?
[10:24] <fabbione> apparently problems with copy and paste
[10:25] <seb128> fabbione: ok, no problem in fr_FR@euro
[10:25] <daniels> seb128: cool!  i say the problem is that xaw sucks, in that case
[10:25] <seb128> and I don't get these "Gdk-WARNING **: locale not supported by Xlib"
[10:25] <seb128> "Gdk-WARNING **: cannot set locale modifiers" 
[10:25] <seb128> neither
[10:27] <fabbione> i think utf8 code in x.org is too immature
[10:27] <seb128> anybody has a fc installation somewhere to test ?
[10:28] <seb128> they are using utf-8 for a while and X.org
[10:28] <fabbione> seb128: i did check all x.org patches in fedora
[10:28] <fabbione> there is nothing related to utf8 :(
[10:28] <fabbione> is it possible that applications requires a rebuild on top of x.org?
[10:29] <seb128> I'm not sure it works on fc, but it would be nice to test
[10:29] <seb128> that would be weird ...
[10:29] <daniels> which version of libXaw is emacs or whatever linked against?
[10:29] <daniels> but I suspect the killer is locale not supported by Xlib
[10:29] <seb128> daniels: that's a general problem with gtk+1.2 apps, not only emacs
[10:29] <daniels> i would love a chroot install of fedora to poke around in
[10:29] <fabbione> i don't have the CD of fc to check
[10:34] <rburton> daniels: ping?
[10:34] <daniels> rburton: yo, pong
[10:35] <rburton> daniels: why does Xproto explicitly define _XOPEN_SOURCE=500?
[10:35] <rburton> it's breaking my compiles!
[10:35] <rburton> (as with that the BSD and GNU extensions get turned off)
[10:35] <rburton> do i really have to add #define _GNU_SOURCE to everything?
[10:35] <daniels> no they don't :) you just need -D_BSD_SOURCE and -D_GNU_SOURCE also
[10:35] <daniels> um, yeah
[10:35] <daniels> hold on a sec
[10:36] <rburton> _GNU_SOURCE turns on _BSD_SOURCE
[10:36] <daniels>         * xproto.pc.in:
[10:36] <daniels>         Force define of _XOPEN_SOURCE; FD_SET et al depend on fds_bits
[10:36] <daniels>         presence, which is an X/Open special and thus only guaranteed with
[10:36] <daniels>         _XOPEN_SOURCE. I'd love to do this in Xpoll.h, but <sys/select.h> has
[10:36] <daniels>         a habit of being included earlier than Xpoll.h.
[10:36] <rburton> waaa
[10:36] <daniels> basically, we're shit out of luck if people manage to include <sys/select.h> before Xpoll.h, which happened a hell of a lot, as it were
[10:37] <daniels> (if you find a better solution, pleeeeeeeeeeeeease send me a patch because I hate it also)
[10:37] <rburton> let it break if people include stuff in the wrong order?
[10:37] <plovs_work> mdz, is there a hoary-wish page in the wiki?
[10:37] <daniels> rburton: given there's no defined order, there's no 'right' order as such ...
[10:55] <pitti> Morning
[10:56] <cenerentola> hi
[10:56] <daniels> pitti: morning
[10:59] <mvo_> morning pitti 
[11:00] <daniels> justdave: btw, what's the process for getting bz components resynced?
[11:01] <justdave> there's a script in the warty-bugs directory on macquarie, feed it a text file with the full package list, one per line, and it'll create components for any that don't have them yet.
[11:02] <justdave> I think it's addcomponents.pl or something like that
[11:03] <daniels> ok, don't have access to macquarie, will ping mdz when he wakes up.  cheers.
[11:04] <justdave> otherwise if there's one or two you're missing they can be added manually.
[11:04] <fabbione> justdave: only 3 packages
[11:04] <fabbione> hem no
[11:05] <fabbione> sorry
[11:05] <fabbione> a bit more than that
[11:05] <daniels> fabbione typoed
[11:05] <daniels> he typed '3', but really meant '67'
[11:18] <daniels> mdz: could you please resync bz components please?
[11:39] <pitti> Morning steve, doko, nmf, seb128!
[11:40] <seb128> hi pitti !
[11:40] <doko> morning
[11:50] <Mithrandir> thom: *prod*
[11:56] <Mithrandir> oh well, incoming glibc.
[12:05] <seb128> anybody has an opinion on 3550 ?
[12:06] <seb128> pmount is supposed to handle that ?
[12:07] <thom> Mithrandir: hiya
[12:07] <thom> thank you :-)
[12:07] <daniels> thom: 'morning sir
[12:08] <thom> ello
[12:09] <doko> elmo: do we sync packages from experimental as well, or unstable only?
[12:09] <Kamion> fabbione,daniels: was xlibs-static-dev meant to depend on the stuff you guys split out of it for transitional purposes?
[12:09] <seb128> hey Kamion 
[12:09] <Kamion> hi seb128
[12:09] <Kamion> let me stick that control-center package I did somewhere so you can tell me how much crack I'm on
[12:09] <elmo> doko: experimental only on demand
[12:09] <seb128> Kamion: the libxklavier problems, settings-daemon hanging are fixed in the GNOME head branch
[12:09] <daniels> Kamion: no
[12:09] <Kamion> where was the hang fix?
[12:09] <Kamion> I looked
[12:09] <seb128> Kamion: they just not have made a release for 2.9 ...
[12:10] <daniels> Kamion: we'll deal with the very few FTBFSes caused by missing B-Ds on the new packages
[12:10] <daniels> Kamion: like a year on, half of Debian still B-Ds on xlibs-dev, and that's crap
[12:10] <doko> elmo: please sync python2.4 (beta2) from experimental 
[12:11] <Kamion> seb128: the problem I had was that libgswitchit was using XklConfig*() without having called XklConfigInit()
[12:11] <Kamion> seb128: which results in a very obscure hang (or segfaults, depending) in the middle of libxkbfile
[12:12] <daniels> Kamion: sounds a lot like trying to use python-apt, except without all the clarity of instructions
[12:12] <Kamion> yep
[12:12] <Kamion> seb128: so I stuck XklConfigInit in gnome-settings-daemon/gnome-settings-keyboard-xkb.c right after XklInit
[12:13] <seb128> Kamion: one min, I'm looking in the changes
[12:14] <Kamion> seb128: http://people.ubuntu.com/~cjwatson/control-center/
[12:16] <daniels> Kamion: if the package fails because it can't find oldX.a or X10.h, it's time to talk to a little more than the Build_Deps with an axe
[12:16] <Kamion> daniels: problem with control-center was that the package subtly broke more than failing, with some of them
[12:17] <daniels> Kamion: was the c-c problem xklavier, missing b-ds, or both?
[12:18] <Kamion> both
[12:19] <daniels> crack
[12:19] <daniels> if you want to just assign me the bug for anything that ftbfs and b-ds on xlibs-static-dev (or xlibs-static-pic), i'd be happy to cop that
[12:25] <Kamion> seb128: shout if I should upload that or if you're taking care of it; I want to get a fix in ASAP so that I can finally build working CDs, though
[12:26] <seb128> Kamion: I'm working on it
[12:26] <Kamion> ok, thanks
[12:26] <seb128> Kamion: but I'm pretty sure they fixed that upstream too, so I'm considering to upload the CVS snapshot of the 2.9 branch
[12:26] <Kamion> I can't see it in CVS
[12:27] <seb128> my jhbuild used to hang a few days ago
[12:27] <seb128> and it doesn't anymore
[12:27] <Kamion> hmm
[12:27] <tuo2> can someone explain to me the difference between sounders and ubuntu-devel mailing lists?
[12:27] <seb128> and I've spoken about this problem with gnomevfs devel a few days ago who pinged me later to said it was fixed or at least workarounded
[12:27] <Kamion> fair enough
[12:27] <mvo_> we have quite a few package with section "contrib/section" (e.g. jde and lots of others). do you think that this may confuse users? I got a bug about it (#3369) and I'm unsure what to do about it
[12:27] <Kamion> tuo2: sounder == off-topic chat; ubuntu-devel == development
[12:28] <Kamion> tuo2: sounder was our beta testers list before we went public
[12:28] <Kamion> but that's historical now
[12:28] <tuo2> ah. ok.
[12:29] <seb128> Kamion: http://bugzilla.gnome.org/show_bug.cgi?id=156986
[12:29] <tuo2> Kamion: thanks. I kept seeing references to it on devel mailing list
[12:36] <Kamion> seb128: thanks
[12:40] <seb128> Kamion: apparently the fix is on libxklavier
[12:41] <seb128> 2004-10-31 21:00  svu
[12:41] <seb128>         * libxklavier/xklavier_config_xkb.c:
[12:41] <seb128>         Fixing the xkbcomp command line. Ubercool!
[12:42] <pitti> elmo: can you please sync "tiff" from sid?
[12:43] <mjg59> thom: We got suspend working for jdub
[12:44] <daniels> jdub: so that's why I get an X300, so I can wait like two months longer to get working suspend :P
[12:44] <Astharot> sid77: ma tu sei di piacenza ?
[12:44] <sid77> o_O
[12:44] <sid77> yeah
[12:44] <Astharot> az :P
[12:45] <sid77> who are you?
[12:45] <sid77> I'm thinking about someone in the lug
[12:45] <Astharot> yes ^_^
[12:45] <sid77> lol
[12:46] <thom> mjg59: holy crap
[12:46] <thom> a dell that works?
[12:46] <daniels> mjg59: what was the magic bullet?
[12:47] <fabbione> doko: gcc is failing again
[12:48] <Kamion> seb128: ah ...
[12:48] <fabbione> doko: do you want me to send you the log file now, or should i wait it will finish ?
[12:48] <Kamion> seb128: (I needed to change libxklavier's build-deps too: s/xlibs-static-dev/libxkbfile-dev/)
[12:48] <seb128> Kamion: I'm building your package now, if it works fine I'll upload that for the moment, time to sort that with upstream
[12:48] <mjg59> daniels: New kernel, my evil as fuck video reinit magic
[12:48] <seb128> Kamion: your solution seems to be right
[12:49] <Kamion> cool :)
[12:49] <seb128> thanks for tracking the problem :)
[12:49] <daniels> Kamion: wait -- do not upload c-c yet
[12:49] <Kamion> daniels: -> seb128
[12:49] <daniels> seb128: libxkbfile1's shlibs are sort of a little bit broken
[12:49] <daniels> xorg -1ubuntu2 coming in a bit
[12:49] <mjg59> thom: You should take a look at that acpi-support package
[12:50] <seb128> daniels: how short ?
[12:50] <elmo> pitti: done
[12:50] <mjg59> daniels: Is it easy to add xorg.conf options by default on a driver-dependent basis?
[12:50] <elmo> doko: for 'main' ?
[12:50] <daniels> seb128: dunno, probably about 3h by the time I eat lunch and upload it and the buildds get it
[12:50] <daniels> mjg59: yes
[12:50] <mjg59> daniels: It seems that we want Option vberestore on for i810
[12:50] <elmo> daniels: btw, that libstdc++5-dev was minor, I hope you have lots of other reasons to upload too :)
[12:50] <seb128> elmo: could you remove trashapplet from hoary ?
[12:50] <pitti> elmo: thx
[12:50] <mjg59> Edd isn't able to resume without it
[12:50] <seb128> daniels: ok
[12:50] <fabbione> seb128: that the aussie placed the wrong simlinks around
[12:50] <elmo> seb128: ? what replaces it ?
[12:51] <doko> currently on the phone ...
[12:51] <seb128> elmo: it's a part of gnome-applets now
[12:51] <daniels> mjg59: craaaack
[12:51] <seb128> elmo: and it already has the conflicts/provides/replaces for like 1 week
[12:51] <daniels> elmo: yes -- fix shlibs and symlinks across the board, add missing libxevie* files, fix libxext-dev vs libx{damage,fixes,composite,evie,dmx}-dev conflicts
[12:52] <mjg59> daniels: All it does is use VBE to save and restore video state, rather than just relying on what the driver thinks is useful
[12:52] <elmo> seb128: ok, cool
[12:52] <mjg59> daniels: The manpage claims it's broken in some places, but I haven't been able to find one yet
[12:52] <daniels> mjg59: oh cool
[12:53] <daniels> mjg59: that sounds sensible, because at last count there were 37 unique i8xx video BIOSes
[12:53] <Kamion> seb128: should trashapplet be removed from the desktop seed, then?
[12:53] <daniels> for which we have the docs for exactly none
[12:53] <seb128> Kamion: yes
[12:53] <elmo> seb128: done
[12:53] <seb128> thanks
[12:53] <Kamion> seb128: done
[12:53] <daniels> mjg59: so using vbe whereever possible (the entire i8xx mode-setting code is vbe) is eminently sensible
[12:53] <seb128> Kamion: thanks :)
[12:54] <elmo> gar.  python's strptime() can't parse 'date -R'
[12:54] <mjg59> daniels: This is disabled by default because it causes lockups on some platforms.
[12:54] <mjg59> It doesn't say /what/ platforms, irritatingly
[12:55] <daniels> mjg59: no, because that would be sensible
[12:55] <daniels> mjg59: although if you get lockups on VBE, i810 in general will be a total minefield
[12:55] <Kamion> elmo: craaaaaaaaaack
[12:55] <daniels> mjg59: tempting to just enable it per default and find out what breaks, partially in service to science and partially out of morbid curiosity
[12:56] <mjg59> daniels: Rock
[12:56] <thom> mjg59: should i be staying with 2.6.10pre or running the 2.6.9 you have up?
[12:56] <mjg59> thom: Does suspend/resume work with that 2.6.10pre?
[12:57] <mjg59> I'd strongly recommend the 2.6.9 for now
[12:57] <mjg59> It seems more solid than the other ones
[12:57] <elmo> seb128: dude, you so need a better internet connection :)
[12:58] <thom> sus/res works for me
[12:58] <thom> on 2.6.10
[12:58] <mjg59> Does cpufreq?
[12:58] <seb128> elmo: that's not my connexion, I've restarted my GNOME session to test Kamion's changed, but since I use a graphical IRC client ... :)
[12:59] <thom> if i have speedstep-centrino loaded, yes
[12:59] <thom> if i have acpi loaded, no
[12:59] <seb128> Kamion: ok, works fine. Do you want an upload now or should I wait on the new X.org upload ? (we can still do a second upload for the shlibs later)
[01:00] <Kamion> seb128: I guess waiting on xorg is the right thing, I don't know how broken the shlibs are :-/
[01:00] <mjg59> thom: Oh, anything in /proc/acpi/processor ?
[01:01] <thom> mjg59: no
[01:01] <seb128> Kamion: ok
[01:01] <Kamion> I have to leave in four-and-a-half hours today, so I suspect I won't get working CDs before I leave
[01:02] <mjg59> thom: Ah, ok - I know what version you have now :)
[01:03] <thom> heh.
[01:03] <mjg59> You won't be getting C2/C3 powersaving on the processor with that kernel
[01:04] <thom> righto
[01:05] <rburton> mjg59: you'll know this -- in 2.6 my x20 correctly clocks down to 466mhz when i take the mains out, but i can't seem to push it back to 700mhz if i want to. should i be able to with cpufreq?
[01:08] <mjg59> rburton: Depends if it's doing speedstep or throttling
[01:08] <mjg59> But yeah, in principle
[01:10] <rburton> oh hang on
[01:10] <rburton> it's clocked up still
[01:10] <rburton> if i don't run cpufreqd it doens't drop or something
[01:11] <mjg59> Don't use cpufreqd. It's rubbish.
[01:11] <mjg59> Use powernowd instead
[01:11] <rburton> l
[01:14] <rburton> powernowd gets the thumbs up from me
[01:19] <jdub> morning
[01:23] <seb128> hey hey jdub 
[01:27] <lupus_> jdub, are there plans to include lm-sensors in hoary?
[01:27] <lupus_> I see smartd is already planned
[01:28] <daniels> lm-sensors is very difficult to get right
[01:28] <daniels> loading the right module on my machine involves a lot of guesswork, and a solid lockup if you get it wrong
[01:30] <lupus_> Why are drivers for other devices easily found but not for i2c?
[01:32] <mjg59> lupus_: Because there's no standard way of device identification
[01:32] <mjg59> lupus_: Probing the i2c bus can destroy hardware
[01:32] <elmo> because they're the backstreet homeless of devices
[01:34] <lupus_> destroy hardware :s
[01:34] <lupus_> joy
[01:34] <jdub> lupus_: i think it's already listed on the wiki
[01:35] <thom> mjg59: looks good; i've added stopping mysql and dbus to prepare and restarting them in resume and that gets everything working here
[01:36] <daniels> thom: why stopping those two?
[01:37] <thom> daniels: cos mysql and NetworkManager especially don't allow you to suspend if they're running
[01:37] <mjg59> thom: Rocking
[01:37] <jdub> thom: (if we had dependency-based init scripts...)
[01:37] <mjg59> thom: Those scripts ought to be fairly generic
[01:38] <mjg59> (No idea if you've taken a look at them or not)
[01:38] <thom> mjg59: indeed, been reading through them
[01:38] <thom> nice work!
[01:38] <mjg59> So, that leaves us with the lid switch
[01:38] <mjg59> Which has two cases - on power and off power
[01:39] <mjg59> On power, we probably want to just blank the screen (unless the external video is in use, which we /ought/ to be able to tell once the video acpi support goes in)
[01:39] <daniels> thom: at this rate, he'd better not bring his X40 the next time he sees you, or he'll be edwarded
[01:39] <elmo> thom: WTF kind of crack is that - why would mysql care?
[01:39] <daniels> thom: NM is cracktastic
[01:39] <mjg59> elmo: It's something to do with signal handling
[01:39] <mjg59> The problem is how we blank the screen
[01:40] <mjg59> The easy solution would be to chvt away from X, do a dpms off and then on open do a dpms on and chvt back to X
[01:40] <mjg59> But:
[01:40] <mjg59> Not all hardware gives us the second lid event
[01:40] <thom> oh, lovely
[01:40] <thom> so we could end up never turning the screen back on?
[01:40] <mjg59> Yeah
[01:41] <mjg59> So, instead we can leave it up to X (since if we use X's dpms code, X will power it back up when someone hits a key)
[01:41] <mjg59> But X doesn't always have working DPMS, especially if you're using the vesa driver
[01:42] <daniels> s/ always//; s/, especially.*//
[01:42] <mjg59> daniels: WTF does the vesa driver not have DPMS support?
[01:42] <mjg59> The bright side is that /most/ hardware will blank the screen itself on lid close
[01:42] <mjg59> So the combination of X dpms and just letting the hardware get on with it should be fine
[01:42] <daniels> mjg59: i don't know, but I'd rather not find out
[01:42] <jdub> argh, bong, no gossip again
[01:43] <thom> mjg59: so in the on power case, we probably just want to lock the screen and throttle xscreensaver, and then let the hardware get on with it?
[01:44] <jdub> thom: can we send xscreensaver a 'show lock dialogue' or send some mouse/key events to the X server when the lid is opened again?
[01:44] <lupus_> gnome-screenshot is gone in hoary
[01:44] <lupus_> can someone verify this
[01:44] <jdub> lupus_: it's in gnome-utils, which hasn't been released yet
[01:44] <mjg59> thom: And do an xset dpms off
[01:44] <Kamion> lupus_: see ubuntu-users
[01:44] <lupus_> ah k
[01:45] <mjg59> thom: With luck, that'll get the backlight switched off
[01:45] <thom> ok
[01:46] <thom> and now the entertaining case, on battery
[01:47] <mjg59> thom: Also need to decide how to hook up the suspend to disk case, but that's a separate issue
[01:47] <mjg59> thom: Ok. The right thing to do is to suspend to RAM if the lid is closed and on battery.
[01:47] <mjg59> Except that some people would prefer this to happen after a few minutes rather than immediately.
[01:48] <thom> mjg59: presumably suspend-to-disk would wind up in Computer/Log Out as a menu option 
[01:48] <mjg59> thom: Yeah
[01:48] <mjg59> thom: In an ideal world, we have user-settable policy
[01:48] <thom> nod
[01:48] <mjg59> Which probably wants to be dbus based
[01:48] <mjg59> Then we can give them a nice little GUI
[01:48] <thom> this is hard until we have dbus based powermanagement
[01:48] <jdub> (yay yay yay)
[01:48] <thom> aye
[01:48] <jdub> elmo: ping
[01:49] <thom> that way we get consistent love over ppc/x86/amd64 too
[01:49] <mjg59> Yeah
[01:49] <elmo> jdub: ?
[01:49] <mjg59> amd64 uses acpi too, so that's easier
[01:49] <thom> anyway, until then, i guess we can have a config file so that people who _want_ a timeout can just set one
[01:49] <thom> but we default to just suspending instantly?
[01:50] <mjg59> Yeah
[01:50] <mjg59> So the real question now is how we do stuff by default...
[01:50] <mjg59> We probably ought to add support for S1 as well, since that'll work everywhere
[01:50] <mjg59> Well, except on hardware that doesn't support it, of course
[01:51] <mjg59> But S1 needs dpms calls either side of it, because it won't usually blank the screen otherwise
[01:51] <mjg59> The craptop works fine in S1
[01:52] <thom> (we also need to work out a policy for APM, too. although that _should_ be easier)
[01:53] <thom> windows suspend is S1 by default, right? 
[01:53] <daniels> thom: yes, you have to go start->shut down->standby(s3)/hibernate(s4)
[01:53] <daniels> so we'll be beating them in that regard if we pull this off
[01:54] <mjg59> It /is/?
[01:55] <mjg59> That's crack-tastic
[01:55] <Kamion> jdub: can you set me as maintainer for partman* in bugzilla?
[01:55] <doko> elmo: For python2.4, I would propose main, but I'm unsure if I'm allowed to. the final python2.4 release is scheduled for December.
[01:55] <thom> hm, just thinking it would be far less of a support hassle to go down the same road, but make it really easy for people to switch to S3
[01:55] <mjg59> daniels: The X40 doesn't do S1, so this certainly isn't always the case
[01:55] <mjg59> thom: S1 gives... little power saving
[01:55] <doko> fabbione: failing to build, or failing in the testsuite?
[01:55] <elmo> doko: can you mail/ask mdz/jdub and get sign off on a) importing it, and b) asking where to import it?
[01:56] <thom> mjg59: so i'm reading - Standby by default is S1, but if you set it in the bios it'll use S3 instead
[01:56] <thom> mjg59: nod
[01:56] <Kamion> jdub: also netcfg
[01:56] <mjg59> thom: Ah - I see what you mean. I think most laptops default to S3.
[01:56] <jdub> Kamion: ok
[01:56] <mjg59> But yeah, Award BIOSes tend to let you choose
[01:56] <doko> elmo: ok, jdub, listening?
[01:56] <thom> can we get the information out of the bios? is there a consistent "suspend me harder" flag?
[01:57] <jdub> doko: please mail devel, cc mdz/me
[01:57] <Kamion> hm, and debconf might not hurt either
[01:57] <daniels> thom: DAMNIT MAN
[01:57] <jdub> Kamion: hrm, perhaps email a list :)
[01:57] <doko> jdub: ok
[01:57] <daniels> thom: my t-shirt just became a multi-purpose coffee-removal-from-laptop tool
[01:57] <mjg59> thom: Not that I know of
[01:57] <thom> mjg59: figures
[01:58] <Kamion> jdub: where?
[01:58] <jdub> Kamion: oh, just to me
[01:58] <mjg59> thom: S3 is expected to Just Work on modern hardware (in the Windows world, anyway) so I suspect that if there is anything it'll be in the Windows driver files
[01:58] <Kamion> jeff.waugh@c.c?
[01:58] <jdub> yeah
[01:58] <thom> mjg59: ugh.
[01:58] <thom> mjg59: hardware database time, again
[01:58] <mjg59> Yeah
[01:58] <daniels> that and a large list of modules which are known to not cope well with power management
[01:59] <mjg59> I suggest we get this stuff into Hoary and default to S3, then pick up the pieces
[01:59] <mjg59> Revert it before release
[01:59] <Kamion> jdub: sent
[01:59] <thom> right, so test it as hard as possible, but not necessarily go through with it
[01:59] <thom> ughfull, but the sensible route
[01:59] <mjg59> thom: Sure, except possibly for whitelisting stuff
[02:00] <cenerentola> sorry but ive got connection problems..
[02:00] <daniels> (this is my current plan with Composite, if we can get it off the ground at all)
[02:00] <cenerentola> ive also reported thi error--- *** Couldn't look up your hostname
[02:00] <cenerentola> ...mmm sorry
[02:00] <elmo> suspend stuff seems so much harder on i386 - it "just works" on my powerbook now ;-)
[02:00] <mjg59> thom: Other thing that needs doing is adding apm to /etc/modules by default
[02:00] <daniels> elmo: you're speaking to three x40 owners here :)
[02:01] <cenerentola> it gives an error for eggdesktopentries.c line 223
[02:01] <mjg59> elmo: Haha. Yeah, to a large extent it /is/ harder on i386 - PPC leaves more up to OF
[02:01] <thom> cenerentola: dude, wrong channel
[02:01] <daniels> mjg59: (of also doing sane things like setting up your video hardware for you so you don't have to care anywhere near as much)
[02:01] <cenerentola> sorry
[02:01] <thom> mjg59: will that do the right thing consistently - ie, only give you apm suck if acpi is turned off?
[02:02] <mjg59> thom: Yes
[02:02] <daniels> thom: if module load order is guaranteed, then yes
[02:02] <mjg59> daniels: Doesn't matter - acpi has to be static
[02:02] <daniels> thom: if acpi is lodaed, apm goes 'oh shit i think that's acpi peace for real though' and buggers off
[02:02] <daniels> oh, in that case, yeah
[02:03] <mjg59> thom: In that case we also want a handy script that people can run in order to send us their DMI data along with whether it worked or not
[02:03] <thom> indeed
[02:04] <mjg59> I think we'll be in good shape on most modern hardware
[02:04] <mjg59> But it'll be interesting to see
[02:04] <thom> it should be fun, definitely
[02:04] <mjg59> thom: Oh, Edd reported functionality on his Sony
[02:05] <mjg59> He doesn't get text consoles back, but he gets X
[02:05] <thom> mjg59: score! that's a good start, anyway
[02:05] <mjg59> (As of yesterday)
[02:05] <mjg59> That's why we do the extra console-changing dance at the end
[02:05] <thom> yeah, i was wondering about that
[02:07] <mjg59> Oh, the dpms program uses vm86, so it won't run on amd64
[02:07] <thom> oh joy
[02:07] <mjg59> video_post has an x86 emulator, so it'll be fine
[02:08] <mjg59> Now that I understand what video_post actually does, it ought to be possible to put the dpms functionality in there
[02:11] <cenerentola> thom: you may be right but there's no one able to help in #ubuntu
[02:12] <Kamion> that's not a reason to bring support stuff here; if nobody can help on IRC, try the mailing list, or report a bug if that's appropriate
[02:12] <thom> mjg59: i'm going to attempt to bend the wiki to my will and write this stuff up
[02:12] <mjg59> thom: Rocking
[02:13] <daniels> 05:13 :::: Irssi: #ubuntu-devel: Total of 79 nicks 0 ops, 0 halfops, 0 voices, 79 normal
[02:14] <daniels> 05:13 :::: Irssi: #ubuntu: Total of 300 nicks 0 ops, 0 halfops, 0 voices, 300 normal
[02:14] <daniels> also, virtually everyone in #ubuntu-devel is in #ubuntu, so
[02:14] <daniels> thom: good luck on the first count
[02:15] <Kamion> how goes that xorg fix?
[02:16] <daniels> Kamion: just quadruple-checking *.links files before I scp to chinstrap
[02:16] <jdub> "Oxford University Computing Services (OUCS), which provides services to staff and students around the university, will complete its move to open-source PostgreSQL as the back-end database for most of its systems over the next year."
[02:17] <jdub> ^ nice!
[02:23] <sladen> presumbly they were using mysql before ;-)
[02:24] <elmo> yeah, but they found it couldn't survive a suspend/resume cycle :-P
[02:25] <mjg59> elmo: Oh, it survives - it's the suspend/resume cycle that doesn't
[02:26] <daniels> how tragic, their main database x300s won't be able to go into s3 :P
[02:26] <jdub> Kamion: done
[02:28] <Kamion> jdub: great, thanks
[02:30] <Kamion> elmo: please sync partman-lvm to unstable
[02:31] <sladen> mjg59: if lid_closed && on_battery && !kismet_running
[02:32] <daniels> sladen: not that you get to keep your centrino modules around a switch to s3, anyway
[02:32] <elmo> Kamion: done
[02:33] <sladen> thom/daniels: in XP, if you press shift at the Log-Out screen, the standby changes to hibernate (why they didn't put both, I don't know)
[02:33] <thom> EW
[02:34] <thom> (yay discoverability)
[02:34] <daniels> oh my god, crack
[02:34] <Kamion> elmo: partman-partitioning too
[02:34] <daniels> still, goes nicely with XP's 'someone just forced open my eyelids and poured speed in' UI
[02:35] <elmo> Kamion: done
[02:42] <cenerentola> daniels: http://www.pastebin.com/118552
[02:42] <Mithrandir> fabbione, daniels: you rock.
[02:43] <daniels> Mithrandir: what've we done this time?
[02:43] <thom> Mithrandir: http://people.ubuntulinux.org/~lamont/buildLogs/g/glibc/2.3.2.ds1-18ubuntu2/ :(
[02:43] <Mithrandir> it doesn't remember it should have middlemousecontenturl.
[02:44] <Mithrandir> thom: well, it's not _failed_ at least. :)
[02:44] <thom> true
[02:55] <Mithrandir> daniels: my xorg upgrade Just Worked.
[02:55] <daniels> Mithrandir: ill
[02:55] <Mithrandir> that's what you've done.
[02:56] <fabbione> amen
[02:56] <fabbione> daniels: I TOLD YOU TO CHECK THE ANTI-MITHRANDIR PATCH!
[02:56] <fabbione> :P
[02:57] <Mithrandir> fabbione: help me remember to buy you beer in .es
[02:57] <mjg59> Keybuk: Does your machine have ACPI S1?
[02:57] <fabbione> Mithrandir: ehehe
[02:57] <Keybuk> no... not that I'm aware
[02:57] <Keybuk> syndicate scott% cat /proc/acpi/sleep
[02:57] <Keybuk> S0 S3 S4 S4bios S5
[02:58] <mjg59> Ok
[02:58] <GeorgeD> daniels: beer or 3 for you next time i see you (luv meet i suppose)
[02:58] <sladen> mjg59: S1 is just basically putting the processor into HALT ?
[02:58] <fabbione> daniels: i guess we will spend 3/4 of DecConf drunk :P
[02:58] <mjg59> I'm planning on getting hold of tbm's and using his docking station to do some more debugging
[02:58] <daniels> GeorgeD: heh, not until January at least, thanks though
[02:58] <daniels> fabbione: heh
[02:58] <mjg59> sladen: Yeah, CPU state isn't lost
[02:59] <daniels> Kamion: 6.8.1-1ubuntu2 uploaded
[02:59] <Mithrandir> fabbione: you say that as if it's a bad thing.
[02:59] <fabbione> Mithrandir: i am not used to high alchoolic level :)
[02:59] <fabbione> not anymore at least
[02:59] <Mithrandir> well, you need training, then.
[03:08] <jdub> hahahaha
[03:08] <jdub>    * debian/patches/990_ubuntu_accept_enabled_for_extensions.diff: accept
[03:08] <jdub>      Enabled and Disabled for the Extensions section, so what I said in my
[03:08] <jdub>      -announce mail actually works.
[03:08] <jdub> 
[03:08] <jdub> daniels: SIPPER!
[03:08] <daniels> jdub: hey, you bitched at me for sending the *one* announce mail :P
[03:08] <Kamion> "I typoed. I know, let's change X"
[03:09] <daniels> Kamion: seemed sensible at the time
[03:09] <Kamion> :-)
[03:09] <jdub> heh
[03:09] <jdub> daniels: nah, just the list you chose ;)
[03:09] <cenerentola> daniels: youre way  doesnt work
[03:09] <daniels> jdub: ah, heh
[03:10] <mjg59> Hmm.
[03:12] <mjg59> thom: Heh. One issue...
[03:13] <mjg59> S1 seems to need the button module loaded in order to be able to wake up
[03:13] <thom> hahaha
[03:13] <thom> suck.
[03:13] <daniels> heh, oops
[03:14] <daniels> mjg59: if by 'fan', you mean 'speaker' ...
[03:14] <Keybuk> *giggle* ... "Cc 'elmo' didn't match anything"
[03:14] <daniels> Keybuk: troup
[03:16] <mjg59> thom: So the sleep script needs to check what state we're going to and deal with it appropriately
[03:16] <thom> fun. 
[03:16] <daniels> hooray
[03:16] <mjg59> thom: Not sure what the best fix is - IIRC, acpid serialises calls, so naive locking won't work
[03:18] <mjg59> Hurrah. So, I can get the craptop to suspend and switch off its screen.
[03:19] <mjg59> Of course, it has no way of switching the fan off from software.
[03:19] <Kosai> mjg59: Ooh.  I'm impressed that you've got somewhere with it.
[03:20] <mjg59> Kosai: This is by doing S1 rather than S3
[03:20] <mjg59> S3 is still fucked
[03:20] <Kosai> Ah.
[03:20] <Kamion> Keybuk: can you make the merge-o-matic look at openssh/experimental rather than unstable?
[03:20] <jdub> mjg59: the fan is necessary for the on-board flame detection feature.
[03:21] <zul> i was wondering how you go about fixing those merge-o-matic bugs on the bugzilla
[03:21] <mjg59> Heh. So, it stops the CPU, it switches off the screen and it stops the hard drive
[03:21] <mjg59> But there's no way we can pretend that it's suspending if the fan is still going
[03:21] <Kamion> zul: download merge candidate prepared by Scott, compare diffs side by side, make any necessary changes, upload
[03:21] <Keybuk> Kamion: I guess ... it'd need a config file somewhere, but it's do-able
[03:22] <zul> ok
[03:22] <Kamion> zul: occasionally give up on the automerge and do something else entirely
[03:22] <zul> hehe
[03:23] <Keybuk> basically apply the changes in .dropped by hand, then make sure that _ubuntu.{patch,debdiff} and _merged.{patch,debdiff} are identical, or you can explain anything missing
[03:25] <fabbione> Keybuk: can you kindly disable that automatic bug thing sync with debian stuff for xfree86?
[03:25] <zul> i dont have upload access so if anything breaks should i attach it to the bug report?
[03:26] <Keybuk> fabbione: no, elmo has to do that
[03:26] <fabbione> Keybuk: ok
[03:26] <Keybuk> I assume it'll stop automatically when we don't have xfree86 in the archive
[03:26] <fabbione> elmo: can you please do the above?
[03:26] <fabbione> Keybuk: no.. i am going to do another XFree86 upload
[03:26] <fabbione> but with time and quiteness
[03:26] <Keybuk> oh?  are we having both in our archive?
[03:27] <fabbione> only to have xserver-xfree86
[03:27] <daniels> we do not have an xfree86 source package for hoary
[03:27] <fabbione> daniels: yes we do
[03:27] <fabbione> the source is still there
[03:27] <fabbione> we uploaded xorg_6.8.1.orig.tar.gz
[03:28] <fabbione> that has nothing to do with xfree86_4.3.0
[03:28] <Keybuk> then don't we *want* to continue updating our xfree86 package against Debian?
[03:28] <fabbione> Keybuk: no
[03:28] <Keybuk> why not?
[03:28] <fabbione> it is only for a temporary amount of time
[03:28] <daniels> can someone run madison on the archive to verify whether or not we have xfree86 in the archive for hoary?
[03:28] <sivang> using hoary : anybody noticed how slow nautilus is? it's taking me about ages to navigate through the directory tree..
[03:28] <Keybuk> fabbione: how temporary?
[03:29] <jdub> sivang: have you upgraded adn not installed gamin?
[03:29] <fabbione> Keybuk: xserver-xorg is way new for us
[03:29] <daniels> sivang: install gamin
[03:29] <fabbione> and not that many people have tested it yet
[03:29] <fabbione> Keybuk: if something is really broken on xorg server
[03:30] <fabbione> the user is still able to install xfree86 (server) easily
[03:30] <fabbione> until we don't fix the problem and kill the old server
[03:30] <sivang> jdub : strange, it's been downloaded - but wasn't installed using dist-upgrade..
[03:30] <jdub> sivang: do you have ubuntu-desktop installed?
[03:30] <fabbione> xorg hasn't been around enough to be able to kill xfree86 from one day to another
[03:31] <fabbione> Keybuk: we are talking about a few weeks.. not years
[03:32] <sivang> jdub : was also not installed, although downloded. installing now
[03:33] <sivang> jdub : got some gtk assertions failing, when installing. from eggdesktopentries.c
[03:33] <sivang> but in the end, it's now back to speed :) 
[03:33] <sivang> thanks jdub
[03:35] <seb128> sivang: these assertions are coming from update-desktop-databasa probably
[03:36] <seb128> sivang: is there an hoary system ? do you have mplayer uptodate from multiverse ?
[03:37] <sivang> fabbione : do we get to set up funkey vertrefresh rates using the new xorg? or just use the same crafted modes lines from xfree..?
[03:37] <fabbione> sivang: xorg = xfree86+morebugs+morecracks
[03:37] <fabbione> i leave up to you the answer to your question :-)
[03:38] <sivang> fabbione : great! Starting to feel like sid again...:)
[03:38] <daniels> hopefully there's sufficient laptop timing detection code (maybe the stuff from ATI does it) that we can kill horizsync/vertrefresh in the config file altogether
[03:39] <daniels> ... but not in the very near future
[03:43] <Kamion> zul: hm, merges may be best left to the Ubuntu maintainer it's assigned to, but yeah, pretty much
[03:43] <zul> k
[03:43] <Kamion> zul: install patchutils and attach the debdiff against the Debian version, probably
[03:45] <Kamion> daniels: madison> yes, you do
[03:45] <Kamion> cjwatson@little:~$ madison-lite -s hoary -S xfree86
[03:45] <Kamion>    libxft1 | 4.3.0.dfsg.1-6ubuntu25 |         hoary | amd64, i386, powerpc
[03:45] <Kamion> libxft1-dbg | 4.3.0.dfsg.1-6ubuntu25 |         hoary | amd64, i386, powerpc
[03:45] <Kamion>    xfree86 | 4.3.0.dfsg.1-6ubuntu25 |         hoary | source
[03:45] <Kamion> xserver-xfree86 | 4.3.0.dfsg.1-6ubuntu25 |         hoary | amd64, i386, powerpc
[03:45] <Kamion> xserver-xfree86-dbg | 4.3.0.dfsg.1-6ubuntu25 |         hoary | amd64, i386, powerpc
[03:45] <daniels> Kamion: thakns
[03:45] <daniels> Kamion: i take it madison isn't accessible to mere mortals? (elmo?)
[03:46] <Kamion> madison itself requires direct database access => login on jackass
[03:46] <sivang> seb128 : checking..
[03:46] <Kamion> madison-lite can operate on any mirror
[03:47] <daniels> oh, cool
[03:48] <Kamion> it's the equivalent of grovelling through Packages and Sources files, but less boring
[03:52] <jdub> mjg59: go go go!
[04:00] <azeem> is http://www.ubuntulinux.org/wiki/ConferenceAttendees supposed to look unreadable?
[04:00] <Mithrandir> azeem: no
[04:02] <Keybuk> it's on the new Wiki ... so I guess "yes" :p
[04:03] <Mithrandir> the new wiki is doooog sloooow
[04:05] <Mitario> hi everyone
[04:05] <mvo_> hi Mitario 
[04:06] <Mithrandir> azeem: I'm trying to unbreak it.
[04:07] <azeem> thanks
[04:07] <Kamion> looks like it's set to the wrong markup type
[04:07] <Mithrandir> yeah, which broke all the line breaks.
[04:08] <Mithrandir> but the wiki is so slooooooooooooooow
[04:08] <Mitario> mvo_, i've been brainstorming a bit about a way to fetch the current upstream stable, I have not found a definit solution though :)
[04:08] <Mitario> i think we could have a file onlinw somewhere
[04:10] <mvo_> Mitario: I haven't yet thought about it
[04:15] <zul> that was quick :)
[04:16] <Mithrandir> somebody else can have the fun, zwiki and I are not friends, it seems.
[04:21] <Kamion> hmm, it's not clear that that helped
[04:21] <Kamion> does zwiki's moinmoin markup support tables?
[04:22] <Mithrandir> I couldn't get it to, but that gui widget Just Did The Wrong Things for me.
[04:22] <jdub> Kamion: ours is fixed to handle it, so i hear
[04:22] <Mithrandir> it worked before that last person added himself.
[04:24] <Kamion> ah, it's helpfully done an HTML->moin conversion for me, brokenly
[04:25] <Kamion> I'm fixing it again
[04:25] <lamont_r> morning
[04:25] <Keybuk> jdub: rock @ gnome-menus
[04:25] <Mithrandir> Kamion: that was probably what threw me off, and I'm impatient today.
[04:26] <seb128> Keybuk: have you tried it ?
[04:26] <Keybuk> no, I only just saw the mail
[04:26] <jvw> the annoying thing about this wiki is that it doesn't support outright reverts...
[04:27] <jdub> Keybuk: yeah :)
[04:27] <Mithrandir> jvw: the annoying this is it seems to be run on a 0.5MHz uC with 2k of ram which uses external donkey-based storage, so it's _dog_ slow.
[04:27] <Keybuk> jdub: did you read my crackful musing on nautilus/filechooser type-ahead btw?
[04:27] <jvw> Mithrandir: frustrated :-)?
[04:28] <jdub> Keybuk: having a bar like firefox/
[04:28] <Mithrandir> jvw: not the least. :P
[04:28] <Keybuk> jdub: yeah, so as you start to type an entry box appears at the bottom to match your typing
[04:28] <Keybuk> jdub: if you didn't put a /, it'd also highlight in the list whatever matched
[04:29] <jvw> Mithrandir: the editor doesn't even have vi-keybindings
[04:29] <rburton> Keybuk: i think jrb proposed that at some point
[04:29] <jdub> Keybuk: might be better than the current find box stuff
[04:29] <Mithrandir> jvw: editor?  You mean the form field?
[04:29] <jdub> Keybuk: have you used the gtk+ 2.5 file selector yet?
[04:29] <Keybuk> jdub: it's changed?
[04:29] <Kamion> Mithrandir: fixed
[04:29] <jvw> yeah. primitive, eh? vi was longer around that a form field :)
[04:29] <Mithrandir> Kamion: ty
[04:30] <thom> Mithrandir: the depressing thing is that's it's a dual xeon and is utterly unloaded
[04:30] <Keybuk> jdub: ah, neat, so that already does something like it :p
[04:30] <jdub> kinda
[04:30] <Mithrandir> thom: takes a while for anything to come through the pipeline on those beasts, you know.
[04:30] <jdub> plus you can just type / and it pops up the location box
[04:30] <Keybuk> though that doesn't complete quite the same way :-/
[04:30] <Mithrandir> thom: you should rather have gone for the amd64 boxes. :)
[04:31] <jdub> Keybuk: it's a bit rough, yeah
[04:31] <thom> yes.
[04:31] <Mithrandir> thom: and you must remember to remove those "sleep(5)" around in the code.
[04:31] <jvw> hm, it barfs on me logging in now...
[04:31] <Keybuk> hopefully by es-conf, I'll actually have some free time to code rather than hand-wave my ideas :o)
[04:32] <Keybuk> oh, #6 at http://lists.gnu.org/archive/html/libtool/2004-11/msg00132.html :o)
[04:33] <sivang> strabge, new copying from a cd to hd take shorter time, however it doesn effect the other system prformance. this is something I am not familiar with in linux..
[04:33] <jdub> Keybuk: is that a libtool goal?
[04:33] <sivang> wonder if this is connected somehow to that gamin thingy :)
[04:33] <Keybuk> jdub: it's a proposed one for 2.1 yes
[04:36] <Kamion> Keybuk: #7 *yay*
[04:37] <Kamion> is #2 the one that makes libtool disappear on Linux?
[04:37] <Keybuk> largely, it still has to do a fair bit of work on Linux to battle stupid developers
[04:39] <thom> seb128: you get a day off for "britain rescued us" day or something? ;-)
[04:40] <Kamion> seb128: control-center should be uploadable now
[04:46] <thom> AAARGH, epiphany's done the focussing-the-wrong-tab trick again
[04:46] <jdub> heh
[04:46] <daniels> thom: when's the UK's 'america saved us' day?
[04:47] <thom> daniels: same day as australia's one
[04:47] <KeyserSoze> hello ppl
[04:47] <daniels> thom: you're confusing that with our 'foreign policy rights firesale' day
[04:47] <jdub> haha
[04:48] <daniels> thom: so, recount to me the tale of WW2
[04:48] <fabbione> hey KeyserSoze 
[04:48] <thom> daniels: wrong war, dude
[04:48] <KeyserSoze> could someone please update the enlightenment package to 16.7.1?
[04:48] <KeyserSoze> sup fab
[04:49] <fabbione> KeyserSoze: hacking on x.org as usual
[04:49] <fabbione> KeyserSoze: is that version in debian already?
[04:49] <KeyserSoze> unstable I believe so
[04:49] <KeyserSoze> let me check
[04:49] <fabbione> jdub: do we any policy for not allowing syncs from sid?
[04:49] <daniels> thom: the one where you picked on the big kids and then ran out of money and sold your colonies off
[04:50] <fabbione> (when it goes to universe)
[04:50] <Kamion> daniels: 11 November = armistice day following WW1
[04:50] <Kamion> hi infinity
[04:50] <KeyserSoze> fabbione: nope
[04:50] <infinity> Hey.
[04:50] <daniels> Kamion: timely discussion, it seems
[04:50] <KeyserSoze> deb is still behind even on unstable
[04:50] <mvo_> pitti: do you mind if I upload a new aptitude this evening with changelog download enabled again?
[04:51] <Kamion> daniels: don't look at me, I'm from the colony that was unfortunate enough *not* to get sold off
[04:51] <thom> KeyserSoze: we're not going to package stuff that we don't care about, sadly. too much to do anyway
[04:52] <pitti> mvo_: no, why I should?
[04:52] <daniels> Kamion: as was my great-grandfather; something about potatoes
[04:52] <pitti> mvo_: if ubuntu changelogs are actually available now?
[04:52] <KeyserSoze> thom: thx... just trying to prove a point
[04:52] <thom> KeyserSoze: um, what point?
[04:52] <KeyserSoze> nothing its ok
[04:52] <mvo_> pitti: yes, for now on people.u.o/~mvo/changelogs
[04:52] <pitti> mvo_: nice :-)
[04:52] <mvo_> indeed :)
[04:53] <pitti> mvo_: this should revert many patches
[04:53] <mvo_> pitti: yes, I'm building right now :)
[04:53] <fabbione> thom: more than we don't care about. is that there are no debs in debian to sync from
[04:53] <pitti> mvo_: have fun, I have to go now. CU tomorrow!
[04:54] <thom> fabbione: yes, which is why i said "we're not going to package stuff" :-)
[04:54] <infinity> No debs of what, exactly?
[04:54] <KeyserSoze> no worries I'll roll my own .debs
[04:54] <fabbione> infinity: latest enlightment?
[04:54] <jdub> fabbione: for hoary, or warty?
[04:54] <seb128> Kamion: ok
[04:54] <fabbione> jdub: hoary
[04:54] <seb128> thom: ah ah :p
[04:54] <fabbione> jdub: last time i checked *WARTY* was released
[04:55] <jdub> fabbione: unless there's ubuntu changes, we ought to be able to sync whenever
[04:55] <jdub> fabbione: check with elmo/lamont if they've already got a sync routine going, though
[04:55] <thom> jdub: it's not in unstable yet, that's the point
[04:55] <jdub> fabbione: that's why i saked :)
[04:55] <fabbione> jdub: ok...
[04:55] <jdub> thom: oh
[04:55] <jdub> ok, now i don't grok
[04:55] <Keybuk> the sync routine is in full speed swing
[04:55] <Keybuk> elmo syncs stuff that's changed in unstable and we haven't changed
[04:55] <seb128> I've to go, bbr
[04:56] <Keybuk> and punts the list of things that changed in both to mom, which does the merge and files bugs
[04:56] <seb128> Kamion: I've to go now, if you want to do a control-center upload just drop the 23_.. patch and updated the build-dep on libxklavier to 1.11
[04:56] <seb128> Kamion: I'll do the upload when I come back if you don't do it
[04:56] <Kamion> seb128: ok, will do it now then, thanks
[04:57] <seb128> np
[04:57] <daniels> can we please blacklist xfree86 from the syncage? :)
[04:57] <jdub> thom: so what was the question about...?
[04:57] <daniels> Kamion: xorg 6.8.1-1ubuntu2 is in, should be safe to upload
[04:57] <daniels> Kamion: just check that anything using libxkbfile.so.1 gets a dep on libxkbfile1 before you upload though
[04:58] <Keybuk> Kamion: on, wrt to the experimental thing ... the trouble is that elmo only checks unstable; so as soon as we leap ahead in versions you won't get any further sync suggestions until unstable catches up with experimental
[04:58] <thom> jdub: KeyserSoze wanted enlightenment updated to the latest, which isn't in unstable
[04:58] <jdub> oh
[04:59] <elmo> eventually, I plan to keep better track of where we sync stuff from, then I can keep track of experimental stuff too
[04:59] <KeyserSoze> I'm building my own debs
[04:59] <KeyserSoze> its cool
[04:59] <fabbione> elmo: mind to check if that version of enlightment is in experimental?
[05:00] <elmo> fabbione: there's no enlightenment in experimental
[05:00] <fabbione> KeyserSoze: this is something that we might need in general later
[05:00] <fabbione> KeyserSoze: not just for enligh
[05:00] <fabbione> elmo: thanks
[05:04] <jdub> lamont_r: ping
[05:06] <infinity> When did lamont become treadsafe?
[05:06] <daniels> one thread for each buildd
[05:06] <elmo> AFAIK he isn't.  he knows martial arts, I wouldn't tread on him, IIWY
[05:07] <daniels> elmo: hey, I know martial arts also
[05:07] <daniels> elmo: unfortunately I am hopelessly out of shape and my knees won't let me sustain any form of usage whatsoever
[05:07] <daniels> elmo: is he *good* at it?
[05:08] <elmo> I dunno - why don't you piss him off and find out for us? :)
[05:09] <lamont_r> jdub: yo
[05:09] <jdub> hey lamont_r 
[05:09] <lamont_r> infinity: roving
[05:09] <jdub> lamont_r: what's the status of the DC livecd builds?
[05:09] <jdub> or should i be asking amu for the details?
[05:09] <Kamion> bleh, my new debootstrap is BROKEN
[05:09] <lamont_r> jdub: I need to check with amu on that
[05:10] <lamont_r> jdub: the status is that the last drop I'm currently aware of required that root run it in the real root, or it failed to build a working CD.
[05:10] <Kamion> or of debootstrap, I'm not sure which
[05:11] <daniels> elmo: that's a great idea!
[05:11] <Kamion> if you have a package that adds a diversion and installs a file in the same place, and you put that package in debootstrap's "required" section, then debootstrap will first extract it ignoring diversions, then unpack/configure it normally, which will give you both the file *and* the diverted copy
[05:11] <spazzy> Hi
[05:12] <Keybuk> that's just a debootstrap feature
[05:12] <Keybuk> it unpacks stuff by just untarring it
[05:12] <Kamion> if the copy that gets dropped in in place of the diverted file happens to be a wrapper script that calls the diverted file if it exists, you get an infinite loop
[05:12] <spazzy> How can we make request about adding software ?
[05:12] <Keybuk> rather than using dpkg, which knows about diversions
[05:12] <Kamion> Keybuk: yes, I know about that, but the comment I just made turns it from an expected feature into something really exciting :)
[05:12] <Mithrandir> Keybuk: it's kinda hard to use dpkg when it's not unpacked yet, no?
[05:13] <spazzy> because Ubuntu will be great if there was directly a CD, DVD burning application
[05:13] <Keybuk> spazzy: nautilus-cd-burner exists
[05:13] <jdub> spazzy: you can use nautilus-cd-burner now, we're looking at coaster for hoary.
[05:13] <spazzy> ok
[05:13] <Keybuk> the trouble with, e.g. k3b is: Depends: k3blibs (>= 0.11.12), kdelibs4 (>= 4:3.2.3), libart-2.0-2 (>= 2.3.16), libarts1 (>= 1.2.3), libasound2 (>> 1.0.5), libaudio2, libaudiofile0 (>= 0.2.3-4), libc6 (>= 2.3.2.ds1-4), libesd0 (>= 0.2.29-1) | libesd-alsa0 (>= 0.2.29-1), libfam0c102, libgcc1 (>= 1:3.3.4-1), libglib2.0-0 (>= 2.4.1), libice6 | xlibs (>> 4.1.0), libmad0 (>= 0.15.1b), libogg0 (>= 1.1.0), libpng12-0 (>= 1.2.5.0-4), libqt3c102-mt (>= 3:3
[05:13] <Keybuk> .2.3-3), libsm6 | xlibs (>> 4.1.0), libstdc++5 (>= 1:3.3.4-1), libvorbis0a (>= 1.0.1), libvorbisfile3 (>= 1.0.1), libx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0), libxrender1, libxt6 | xlibs (>> 4.1.0), zlib1g (>= 1:1.2.1), cdrecord (>= 4:2.0+a18-1), cdparanoia (>= 3a9.8), mkisofs (>= 1.10), kdelibs-data (>= 4:3.1.4-2), kdebase-bin
[05:14] <spazzy> and the googlefight between totem-xine and totem-gstreamer ? :)
[05:14] <Keybuk> that's a lot of stuff to drag in for just one app :p
[05:14] <jdub> spazzy: we can't ship totem-xine by default due to legal issues.
[05:14] <daniels> Keybuk: wow, impressive
[05:14] <spazzy> arf
[05:14] <spazzy> ok
[05:15] <spazzy> Hoary will include bootsplash ?
[05:15] <spazzy> did see on roadmap
[05:15] <Kamion> not by that name
[05:15] <daniels> usplash
[05:15] <spazzy> didn't see on the roadmap
[05:15] <spazzy> bootsplash not good ?
[05:15] <Kamion> nope
[05:15] <Kamion> it broke the installer when we tried to add it for warty
[05:15] <Kamion> don't go there.
[05:16] <daniels> god I hate the forum icons
[05:16] <spazzy> ok
[05:16] <sjoerd> jdub: if you can't ship totem-xine, you also can't ship gst-ffmpeg or ?
[05:16] <daniels> like one of a BIG GREEN ARROW pointing to the post
[05:16] <jdub> sjoerd: nup :)
[05:16] <jdub> sjoerd: same issue
[05:16] <daniels> what's the alternative?  a huge icon saying 'IGNORE THIS POST IT IS CRAP'?
[05:16] <jdub> sjoerd: (same code...)
[05:16] <spazzy> and last question sorry :)
[05:16] <spazzy> why not integrated xmms or zinf ?
[05:17] <spazzy> by default ?
[05:17] <fabbione> ah ok
[05:17] <fabbione> osp
[05:17] <fabbione> ECHAN
[05:17] <jdub> spazzy: rhythmbox
[05:17] <daniels> today's sage advice: 'Removing ubuntu-desktop will not ruin your the default "setup" of the OS. It is basically just a list of applications that make the install easier.
[05:17] <daniels> Its kind of like shopping .... you use the shopping list to help you get the food, but when your done putting all the food in your car after paying for it ... you don't need the list anymore. Or do you? Well ... I guess if you want to keep to the default shopping list! LOL'
[05:17] <spazzy> jdub : yes 
[05:17] <sjoerd> jdub: that's why i asked.. i'm curious about what debian is gonna do
[05:17] <sjoerd> we'll see in due time :)
[05:18] <elmo> jdub: btw, how's the polypaudio thing playuing out ?
[05:18] <spazzy> thank you for the answer
[05:18] <spazzy> great work you have done
[05:18] <jdub> elmo: lennart's fixing lots of stuff.
[05:18] <jdub> elmo: not sure atm
[05:18] <spazzy> I hope xfce 4.2 arrives soon on Ubuntu :)
[05:18] <jdub> elmo: have been playing with the possibility of jack+esound
[05:19] <Keybuk> spazzy: it should be in universe?
[05:19] <spazzy> 4.2 ??
[05:19] <spazzy> nope
[05:19] <Keybuk> is it in Debian?
[05:20] <spazzy> nope
[05:20] <spazzy> Paquet: xfce4
[05:20] <spazzy> Version: 4.0.5-1
[05:20] <spazzy> Priorit: optionnel
[05:20] <spazzy> Section: universe/x11
[05:20] <spazzy> Responsable: Martin Loschwitz <madkiss@debian.org>
[05:20] <Keybuk> ah, well ... that's just a package we take from Debian, so until the Debian maintainers upload it there it won't turn up in Ubuntu
[05:21] <spazzy> okidoki
[05:23] <sid77> flashy
[05:35] <Kamion> I'll be back for a bit later on this evening
[05:39] <daniels> have fun
[05:55] <stratus> Where can i see at wiki the list with requested packages for hoary? Packages that are at 'universe', for example.
[05:56] <lamont_r> stratus: universe is "everything else" - that is, things not on one of the lists
[05:56] <stratus> lamont_r, i know but have you a page at the wiki with requested packages for hoary?
[05:57] <lamont_r> stratus: wiki.ubuntu.com/HoaryHedgehog has links
[05:58] <stratus> lamont_r, thanks
[06:01] <thom> lamont_r: please can you sign glibc on crested? :-)
[06:02] <lamont_r> thom: gah
[06:02] <spazzy> there isn't a rescue mode on the cd, it would be great 
[06:02] <thom> lamont_r: i've fixed the mail config now 
[06:02] <spazzy> I have to make mkboot to rescue 
[06:02] <thom> did so this morning
[06:02] <daniels> lamont_r: how are you enjoying the xorg builds?  now with 2192-char Binary lines
[06:03] <lamont_r> thom: wanna fix king too, and see if yellow is configured at all?
[06:03] <daniels> anyway, I'm sure someone said something about fresh air and stuff
[06:03] <lamont_r> thom: done
[06:03] <thom> king is fixed, yellow isn't configured at all
[06:05] <lamont_r> daniels: ubuntu doesn't care
[06:06] <lamont_r> thom: uploaded
[06:06] <thom> danke
[06:16] <elmo> lol - #280632
[06:18] <infinity> I question his assertion that is works in /usr/bin/ and /tmp...
[06:18] <infinity> But I love the example in ~ :)
[06:30] <infinity> elmo : He's filed two of those.  #280491
[06:41] <mdz> morning
[06:42] <tim1> good evening
[06:44] <amu> hi mdz 
[07:00] <mdz> thom: here?
[07:01] <thom> mdz: mostly packing, but yeah
[07:01] <mdz> thom: could you resurrect your earlier email about the hardware database and send a copy to ubuntu-devel to start a proper discussion about the hardware database?
[07:02] <thom> mdz: it's already been linked in the thread, but sure
[07:24] <elmo> why does gnome-cups-icon take so much damn CPU time, and can I kill the damn thing?
[07:36] <mdz>     !!uri
[07:36] <mdz> PANIC: exiting on botched invariant
[07:36] <mdz> Keybuk: do you know the translation for that one?
[07:37] <Keybuk> what was the command?
[07:37] <mdz> Keybuk: make-archive
[07:37] <thom> isn't that arch's default "something bwoke" message?
[07:37] <mdz> tla make-archive apt@packages.debian.org--apt apt@packages.debian.org--apt
[07:38] <mdz> aha
[07:38] <mdz> apparently that's arch-speak for "I want the location parameter to be a fully-qualified path"
[07:38] <mdz> changing that last bit to `pwd`/... works
[07:38] <Keybuk> yeah
[07:38] <thom> heh
[07:38] <Keybuk> "not not a url"
[07:40] <jdub> mdz: s/arch/tla/
[07:40] <mdz> jdub: are you saying it's fixed in baz?
[07:40] <jdub> mdz: being fixed in baz, yeah
[07:40] <mdz> who's packaging baz for hoary, btw?
[07:40] <jdub> no one atm
[07:40] <jdub> there's a per-checkin repo
[07:41] <jdub> but no point doing a package until 1.0, according to lifeless
[07:42] <mjg59> I'm getting insufficient ACPI feedback love
[07:43] <jdub> I LOVE ACPI
[07:43] <Keybuk> jdub: dude, fix -changes
[07:43] <jdub> although my suspend button doesn't always work
[07:44] <jdub> Keybuk: see discussion elsewhere
[07:44] <Keybuk> jdub: nutwits keep mailing it
[07:44] <mjg59> jdub: Man, if you don't tell me these things, how am I supposed to increase your love quota?
[07:44] <jdub> look at your other tab
[07:44] <jdub> mjg59: but i just did!
[07:44] <mjg59> It doesn't always work
[07:45] <jdub> so you know how before, it didn't work with acpid running?
[07:45] <mjg59> Haha
[07:45] <lamont2> fabbione? 
[07:45] <lamont2> mjg59>?
[07:45] <lamont2> help!
[07:45] <elmo> if we manage to release hoary without baz, we should just all give up and go home
[07:45] <mjg59> lamont: Hello
[07:45] <lamont2> I close the lid, wait 10-20 minutes, and it won't unblank
[07:45] <lamont2> the other vt's all work just fine.
[07:45] <thom> elmo: dunno about you, but i'm already at home
[07:45] <elmo> err, well, the "go home" part doesn't really work, but YKWM
[07:45] <jdub> mjg59: now it doesn't even have an acpi event when acpid is not running
[07:46] <jdub> elmo: we'll have baz in hoary
[07:46] <jdub> elmo: 1.0 is very soon
[07:46] <mjg59> jdub: Hmm. If you rmmod button and then modprobe button, does it start generating events?
[07:46] <jdub> sudo rmmod button just hung
[07:46] <mjg59> lamont2: That's very, very odd
[07:46] <mjg59> jdub: Bong
[07:46] <jdub> 16366 pts/2    D+     0:00  |               |   \_ rmmod button
[07:46] <mjg59> jdub: Anything in dmesg?
[07:47] <jdub> no, just more usb noise
[07:47] <mjg59> Gar
[07:47] <jdub> Buffer I/O error on device uba, logical block 0
[07:47] <jdub>  unable to read partition table
[07:47] <mjg59> I suspect some sort of interrupt or timing issue
[07:47] <mjg59> If you reboot the machine, do you get button events again?
[07:47] <jdub> oh man
[07:47] <jdub> :)
[07:47] <mjg59> lamont2: When did this start?
[07:48] <lamont2> mjg59: has always been the case
[07:48] <mjg59> Weird.
[07:48] <lamont2> acpid processes the lid open event, but screen stays blank
[07:48] <mjg59> What sort of hardware?
[07:49] <mjg59> lamont2: If you comment out the xscreensaver calls in /etc/acpi/lid.sh, does it stop misbehaving?
[07:49] <lamont2> sony vaio pcg-fxa53
[07:50] <lamont2> mjg59: I'll comment them out now and see what happens the next time I accidentally leave the lid closed too long. :-)
[07:50] <lamont2> currently the only known recovery is ctl-alt-backspace, which is a little bit annoying
[07:52] <jdub> mjg59: works fine after a reboot
[07:52] <jdub> mjg59: btw, on resuming, the lcd-dying-glow started happening, until it switched to X
[07:52] <jdub> back soon
[07:52] <amu> Sun released a live CD of Java Desktop System
[07:53] <mdz> amu: interesting, URL?
[07:53] <amu> it's a morphix ;) 
[07:53] <mjg59> jdub: Yeah, it will do
[07:53] <amu> mdz: http://www.osnews.com/
[07:53] <sivang> hmm..printing doesn't work on hoary? seems the gui cups admin in gnome is badly unresponsive...
[07:54] <amu> mdz: download need the hole day :) now i got it ..  
[07:54] <Mithrandir> amu: they had one of those a long time ago as well, didn't they?
[07:54] <jdub> yeah, they have
[07:55] <amu> Mithrandir: yap, still the same.... 
[07:56] <Mithrandir> well, then it's nothing interesting.  Nothin java about it.
[07:56] <Keybuk> mdz: no luck with apt-rpm
[07:56] <Keybuk> cvs [login aborted] : connect to cvs.conectiva.com.br(200.140.247.68):2401 failed: Connection refused
[07:57] <mvo_> Keybuk: IIRC they  have a svn repository
[07:57] <amu> Mithrandir: just loopmounted the iso, and i saw its a knoppixlike :) 
[07:58] <Keybuk> mvo_: it starts off from half way through the development
[07:58] <Keybuk> they never imported the CVS history into it, fwict
[07:59] <mvo_> Keybuk: I can talk to the apt-rpm maintainer about it if it's importend
[07:59] <amu> Mithrandir: suse is the only one, who think before they do something. It's also a with cloop, but the boot and startprozess much more better than the knoppix isos
[07:59] <mdz> Keybuk: gah
[07:59] <mdz> Keybuk: so they killed the cvs repository and started svn from scratch, not using cvs2svn or whatever?
[08:00] <elmo> aiee.  it's so so wrong that modern emacs can do inline images
[08:00] <mdz> mvo_: if you could try to get a tarball of the CVS repository, that would be incredibly helpful
[08:00] <Keybuk> mdz: *looks* like it
[08:01] <mvo_> mdz: sure, I will ask gustavo. is it to import the stuff into an arch branch?
[08:01] <mdz> mvo_: it is to get the change history in order to merge some stuff and bring the forks closer
[08:02] <mdz> we need to be able to go all the way back to where they forked from Debian
[08:02] <ChrisH> btw, is arch a lot different than svn?
[08:02] <mdz> yes
[08:02] <mvo_> mdz: I ask him
[08:03] <Keybuk> notably http://cvs.conectiva.com.br/ thinks it's a mailman server now :p
[08:04] <Keybuk> mdz: yeah, confirmed; they just imported the upstream APT into SVN and then imported their CVS HEAD over the top of it
[08:04] <Keybuk> no history there
[08:04] <mdz> GAH
[08:04] <mdz> corrupt pristine (failed inode signature validation)
[08:04] <Keybuk> nuke it
[08:05] <mdz> it should not even be looking in that directory
[08:05] <mdz> it is complaining about an archive in some subdirectory of my cwd
[08:05] <Keybuk> oh, arch goes wandering across your filesystem looking for pristine trees :p
[08:05] <mdz> this was a tla tag command
[08:05] <mdz> did it fail?
[08:05] <Keybuk> yup
[08:05] <mdz> one never knows with arch
[08:06] <Keybuk> I've often wondered whether it climbs back up the filesystem, and if so whether it'd steal other user's pristines
[08:09] <Keybuk> descent pyarch% tla missing -Dscf $(<{arch}/+upstream)
[08:09] <Keybuk> ^ I swear, some of the "every day" tla commands are obscene
[08:10] <Keybuk> if I get RSI, I'm sueing Tom Lord
[08:12] <mvo_> gustavo is looking for the old repository now. let's hope he finds it :)
[08:12] <mdz> mvo_: great, thanks
[08:13] <mvo_> n
[08:13] <mvo_> np
[08:13] <mvo_> :)
[08:15] <carlos> jdub: polypaudio is doing bad things
[08:16] <carlos> jdub: I'm getting noise instead of the "normal" sounds
[08:16] <jdub> has it eaten anyone yet?
[08:16] <carlos> yes, my event sounds :-)
[08:16] <jdub> :)
[08:16] <jdub> weird, haven't seen that before
[08:16] <carlos> until today, it just stop playing sounds
[08:16] <carlos> but today instead of that it makes sounds
[08:17] <carlos> like the doom ones :-P
[08:17] <jdub> if you want to ping lennart about it, that'd be cool - we're still not officially committing to it yet :)
[08:17] <carlos> it's not a joke
[08:18] <carlos> jdub: ok
[08:18] <carlos> jdub: will do this weekend, too busy now. Thanks
[08:18] <carlos> I'm too used to jabber...
[08:18] <carlos> grr
[08:18] <jdub> heh
[08:21] <mdz> Keybuk: http://chinstrap/~mdz/cvsballs/apt-rpm.tar.bz2
[08:21] <mdz> Keybuk: courtesy of gustavo via mvo
[08:24] <Keybuk> exxxxcellent
[08:29] <Keybuk> 2002.07.23.18.00.00 ... looks like the branch point :p
[08:29] <Keybuk> isn't CVS's "give me the base of the branch" feature GREAT
[08:30] <Keybuk> because -r1.1 is bad, precious
[08:31] <mdz> isn't the "give me the base of the branch" "feature" equivalent to "decode the RCS version number"? :-)
[08:31] <Keybuk> not if you want to checkout trunk as it was imported
[08:31] <Keybuk> -r1.1 will give you every single file at it's first revision
[08:31] <Keybuk> including those added later
[08:31] <mdz> ah
[08:32] <Keybuk> so you have to grep through the ,v files and find a time which was after the initial import, but before the first change ... then check that out with -D
[08:32] <mdz> so which arch changeset does 2002.07.23.18.00.00 correspond to?
[08:32] <Keybuk> dunno yet
[08:32] <Keybuk> that's the "difficult" bit <g>
[08:32] <mdz> if the answer is "none", do we cry?
[08:32] <Mithrandir> Keybuk: you can't know for sure that -r1.1 exists for all files, even. :)
[08:32] <Keybuk> still waiting for rookery to checkout 1,303 revisions
[08:34] <mdz> I don't suppose tla has a handy "checkout relative to <this> and use hardlinks where nothing changed" feature
[08:35] <mdz> oh, it does have "hardlink to revision library" though
[08:37] <Keybuk> I've often wondered whether that takes into account permission changes
[08:37] <Keybuk> ie. will it break the hardlink if the permissions change?
[08:37] <Keybuk> and that might explain why I have so many random permission fiddles when using tla
[08:43] <daniels> mdz: yo, dude
[08:43] <rcaskey_> daniels: mucho thanks for beating xorg into shape
[08:43] <daniels> rcaskey_: no worries -- props to fabbione also
[08:44] <daniels> ah, that's what I wanted to ask you
[08:44] <rcaskey_> it enabled a luser like me to compile eye candy that crawls my system to a crawl, for that a sincere thank you
[08:46] <rcaskey_> compmgr is very fun with built in i810 video
[08:47] <daniels> (yeah, I have an i855)
[08:50] <lamont_r> mjg59: should I uncomment the -unthrottle as well?
[08:50] <lamont_r> er, comment that is.
[08:51] <lamont_r> mjg59: hrm.. should proc/acpi/ac_adapter/*/state say off-line, despite the fact that the power is plugged in?
[08:51] <daniels> lamont_r: no
[08:52] <mjg59> lamont_r: No, but that's not unusual
[08:53] <lamont_r> acpi
[08:53] <lamont_r>      Battery 1: charging, 100%, charging at zero rate - will never fully charge.
[08:53] <lamont_r> lamont@rover3:~ $ cat /proc/acpi/ac_adapter/*/state
[08:53] <lamont_r> state:                   off-line
[08:53] <rcaskey_> Are the bottlenecks mostly composite bottlenecks?
[08:53] <lamont_r> which basically means that lid.sh is not unthrottling...
[08:54] <mjg59> lamont_r: Ah
[08:54] <mjg59> lamont_r: Is that the stock Warty kernel?
[08:54] <lamont_r> OTOH, doing that manually from another vt doesn't tend to unstick things
[08:54] <lamont_r> mjg59: stock warty everything
[08:55] <lamont_r> it even has ubuntu-desktop installed. :-)
[08:55] <Keybuk> mdz: oh, man!
[08:55] <mjg59> lamont_r: Might be worth trying my test kernel
[08:55] <lamont_r> ok.
[08:55] <mdz> Keybuk: hmm?
[08:55] <Keybuk> descent arch-test% ls -l foo
[08:55] <Keybuk> -rwxrwxr-x    1 scott    scott          25 2004-11-10 19:51 foo*
[08:55] <Keybuk> descent arch-test% tla changes
[08:55] <Keybuk> * looking for scott@netsplit.com--test/test--test--0--patch-2 to compare with
[08:55] <Keybuk> * comparing to scott@netsplit.com--test/test--test--0--patch-2
[08:55] <Keybuk> -- 
[08:55] <Keybuk> foo is executable, and there's no local changes
[08:56] <Keybuk> but, wait!
[08:56] <Keybuk> descent scott% tla get scott@netsplit.com--test/test--test--0
[08:56] <Keybuk> * ensuring library has scott@netsplit.com--test/test--test--0--patch-2
[08:56] <Keybuk> * from revision library: scott@netsplit.com--test/test--test--0--patch-2
[08:56] <Keybuk> * tree version set scott@netsplit.com--test/test--test--0
[08:56] <Keybuk> descent scott% ls -l test--test--0--patch-2/foo
[08:56] <Keybuk> -rw-rw-r--    1 scott    scott          25 2004-11-10 19:56 test--test--0--patch-2/foo
[08:56] <mdz> how did you arrive at that state?
[08:57] <mdz> rookery certainly seems to be enjoying itself
[08:57] <Keybuk> init-tree, import, changes, touch foo, add foo, commit, changes, chmod +x foo, commit
[08:57] <Keybuk> ie. just made sure at each step of the way that I had it in my revision library
[08:58] <mdz> Keybuk: you shouldn't need to checkout _all_ 13xx revisions; we know that conectiva branched sometime before 0.5.5
[08:58] <mdz> <=0.5.5, that is
[08:58] <Keybuk> the changes is probably redundant, because commit would've done the equivalent anyway
[09:02] <mdz> how do I cherry-pick changes with tla?  replay?
[09:02] <Mithrandir> mdz: star-merge?
[09:02] <mdz> Mithrandir: won't that get me everything that came before?
[09:03] <Mithrandir> I thought not, not if you specify the patch
[09:04] <Keybuk> replay
[09:04] <Keybuk> replay blah@blah--blah--blah--patch-999
[09:04] <Keybuk> will just apply that one patch
[09:04] <mdz> thanks
[09:05] <mdz> hmm
[09:05] <mdz> mvo__: I got conflicts in merging your patch-3
[09:05] <daniels> mdz: yah, replay usage for cherrypicking is on ArchCheatSheet IIRC
[09:05] <mdz> my understanding of tla conflict handling is that now I get to SUFFER
[09:06] <mvo__> mdz: sorry for that
[09:06] <daniels> mdz: s/conflict handling // and you're starting to get somewhere
[09:06] <mdz> mvo__: I don't understand why
[09:07] <mvo__> mdz: in what files?
[09:07] <mdz> that changeset should only have 0.5.27->0.5.27.1, no?
[09:07] <mdz> mvo__: debian/rules
[09:07] <mvo__> could it be the "dh_installcron" I added?
[09:07] <mdz> mvo__: why would that be part of patch-3?
[09:07] <mdz> patch-3 seems to contain a ton of changes which were not part of 0.5.27->0.5.27-1
[09:07] <mdz> er, .1
[09:07] <mvo__> ah, ok. 
[09:08] <mvo__> it was 0.5.26->0.5.27.1
[09:08] <mvo__> tla was at 0.5.26 IIRC
[09:09] <mdz> hmm, that's odd
[09:09] <mdz> lifeless won't be up yet
[09:09] <mdz> but that sounds like the import is not running
[09:09] <mdz> there is much more in CVS beyond 0.5.26
[09:12] <Keybuk> on the MAIN trunk?
[09:13] <mdz> yes
[09:13] <mdz> apt--MAIN--0 has up to 0.5.26
[09:14] <mdz> but there was since a 0.5.27, and is a 0.5.28 in progress
[09:14] <mdz> none of which is in arch
[09:14] <mdz> it's as if it stopped syncing
[09:14] <Keybuk> [DIR]  apt--MAIN--0/             20-Sep-2004 18:37    -   
[09:15] <Keybuk> drwxrwsr-x   14 jgg      aptcvs       4096 Nov 10 13:15 apt
[09:15] <Keybuk> yeah, looks like it
[09:16] <daniels> culus commits to apt still?
[09:17] <mdz> lifeless: when you wake up ^^^^
[09:17] <mdz> daniels: no
[09:17] <mdz> he owns the directory, though
[09:17] <Keybuk> (file) sk.po 	(graph) 	  1.3 	 7 days 	 piefel 	 Updated Slovak from Peter Mann (Closes: #279481)
[09:17] <Keybuk> (file) nl.po 	(graph) 	  1.13 	 12 days 	 piefel 	 Updated Dutch from Bart Cornelis (Closes: #278697)
[09:18] <Keybuk> there's definitely updates since the 20th Sep
[09:18] <Keybuk> 0.5.27 predates that though
[09:19] <mdz> mvo__: one thing I had consisdered was that some folks might want to check for updates more than once per day
[09:19] <mdz> e.g., security
[09:20] <mvo__> elmo will not like a e.g. 4h cron job I guess
[09:20] <Keybuk> mvo__: 4 hour cron jobs don't play well with anacron
[09:21] <mvo__> mdz: but we can do it of course
[09:21] <Keybuk> mdz: to me it looks like the APT Arch sync hasn't happened since mid-June
[09:22] <Keybuk> which is odd, because we didn't even start them until August/September, heh
[09:23] <mdz> mvo__: do you know how frequently the RH tool checks for updates?
[09:24] <mvo__> mdz: no, but I can find out :)
[09:35] <mvo__> mdz: the suse default seems to once per night
[09:36] <mdz> mvo__: I suppose once/day is sufficient, and we can give them a "check now" menu option if they want to check immediately
[09:36] <mvo__> mdz: agreed
[09:36] <mdz> mvo__: I sent you email with a few small changes
[09:37] <mvo__> mdz: thanks!
[09:37] <Keybuk> mdz: btw, can I reopen the question of anacron for hoary?
[09:37] <mdz> mvo__: I think there is a wishlist bug open against apt for this, if you can find it we can close it :-)
[09:37] <mdz> Keybuk: sure, ubuntu-devel@
[09:37] <mvo__> mdz: :)
[09:45] <Keybuk> * Checking patch-1071
[09:45] <Keybuk>   - Fuzzy match (6)
[09:45] <Keybuk> that looks the absolute closest
[09:45] <Keybuk> (for apt-progeny)
[09:46] <mdz> Keybuk: what's the fuzz?
[09:46] <Keybuk> apt-progeny apt--MAIN--0--patch-1071 (fuzzy 6)
[09:46] <Keybuk> that's the only result for that one
[09:48] <Keybuk> >>> (changed, new, gone, moved) = dirsums.diff(arch_sums, dir_sums)
[09:48] <Keybuk> >>> new
[09:48] <Keybuk> ['doc/fr/manpage.refs', 'doc/manpage.links', 'doc/manpage.log', 'doc/manpage.refs', 'doc/pt_BR/manpage.refs', 'doogie.txt'] 
[09:54] <elmo> mvo: checking for updates is pretty cheap
[09:56] <Keybuk> must...not...agree...with...lifeless
[09:56] <Keybuk> / $Id: acquire-item.cc,v 1.1 2002/07/23 17:54:50 niemeyer Exp $
[10:01] <mvo__> elmo: so we could do a "apt-get update" every say 4h ?
[10:01] <Keybuk> mvo__: why that regularly?  once a day sounds sufficient to me
[10:01] <elmo> mvo: I think the servers could cope, yeah
[10:02] <elmo> just don't GMT the crontab :)
[10:02] <Keybuk> where's jackass gone?  oh, right, UPDATE TIME!
[10:03] <Keybuk> mvo__: every 4 hours just sounds a bit "... MUST!HAVE(*$UPDATES!*$*OH YEAH! ..."
[10:03] <Keybuk> and would be deadly for people on reduced bandwidth, like a modem or GPRS laptop users
[10:03] <mvo__> Keybuk: totally agreed 
[10:03] <elmo> keybuk: heh, GPRS laptop users, i.e. you and the other two ;P
[10:03] <Keybuk> and an "Update Now" button for the obsessed
[10:03] <Keybuk> elmo: heh, it works pretty well :p
[10:04] <mvo__> Keybuk: the update intervall is a config option anyway
[10:04] <Keybuk> mvo__: how does it do it?
[10:04] <mvo__> Keybuk: it basicly write a "stamp" file that is checked then
[10:04] <Keybuk> you need to be root to run apt-get update ... so how do you elevate ?
[10:05] <mvo__> Keybuk: the cron-job will be part of apt and run as root
[10:05] <mvo__> for the "update now", we will run it with gksudo
[10:05] <Keybuk> right ... can we not have an ordinary cron job please?
[10:06] <Keybuk> unless it checks on_ac_power
[10:06] <mvo__> Keybuk: you think "apt-get update" takes too much power?
[10:06] <Keybuk> mvo__: it'll spin all the disks up
[10:06] <Keybuk> so yes
[10:06] <Keybuk> "all the disks", heh
[10:06] <Keybuk> "the disk"
[10:07] <mvo__> is there a easy way to find out if we are on power? 
[10:07] <jdub> RAID-5 in your HP? :)
[10:07] <Keybuk> on_ac_power
[10:08] <Keybuk> I'm assuming we're shipping this with "off" as the default anyway?
[10:08] <mvo__> Keybuk: correct
[10:08] <mvo__> unless you install "upgrade-notifer" that turns it into "once per day"
[10:08] <mvo__> I'll add the "on_ac_power" check
[10:08] <jdub> jdub@lazarus:~ $ on_ac_power
[10:08] <jdub> jdub@lazarus:~ $ echo $?
[10:08] <jdub> 255
[10:09] <jdub> ^ expected result on a desktop machine?
[10:09] <mvo__> jdub: same here :)
[10:09] <Keybuk> jdub: yeah, you check $? -eq 1 for a laptop on battery
[10:09] <Keybuk> cf. /etc/init.d/anacron
[10:10] <daniels> on_ac_power returns 1 on my batteried x40
[10:10] <jdub> Keybuk: nice
[10:10] <Keybuk> mvo__: I still vote for just sticking it in cron.daily personally
[10:11] <mvo__> Keybuk: that's the current plan
[10:11] <mvo__> I was just asking for opionions for the alternatives :)
[10:11] <Keybuk> that way it'll be deferred correctly if laptop users have anacron installed
[10:12] <mvo__> out of curiosity, does cron.hourly behave sane too?
[10:12] <Keybuk> no
[10:12] <jdub> do we run anacron on acpi ac plugin events?
[10:12] <Keybuk> jdub: anacron isn't in main, cf. ubuntu-devel
[10:12] <jdub> yeah
[10:12] <Keybuk> mdz has a wishy-washy dislike for it *ducks&runs* :p
[10:13] <jdub> mean does anacron
[10:13] <Keybuk> jdub: it adds an /etc/apm/event.d thing, not ACPI
[10:13] <Keybuk> thom could add -x /usr/sbin/anacron && /etc/init.d/anacron stop/start thing to acpi-support though
[10:13] <jdub> so when i plug in, upgrade-notifier should say "you have updates, powered one!"
[10:14] <Keybuk> jdub: yup
[10:15] <Keybuk> mvo__: is the notification icon going to sit in the panel being annoying, or just appear when there are updates?
[10:15] <mvo__> it will only appear if updates are available
[10:15] <mvo__> and vanish once you installed them
[10:16] <Keybuk> nice
[10:16] <Keybuk> can it download the .debs and put them in /var/cache/apt/archives while it waits for you to get around to clicking it? :p
[10:17] <mvo__> yes, it's pretty nice I think. it listens to dbus events and will update it's status if it gets them
[10:27] <thom> it's actually a _notification_ *shock*
[10:27] <thom> but yes, only running anacron when on battery would seem reasonable
[10:28] <daniels> heh.  having local xorg debs does you wonders: Need to get 15.5MB/174MB of archives.
[10:29] <mdz> Keybuk: looks like a CVS vs. tarball diff
[10:29] <elmo> what's the equivalent of .xinitrc for a gnome session ?
[10:29] <mdz> Keybuk: (apt)
[10:29] <mdz> elmo: ~/.gnome2/session
[10:30] <mdz> computer->desktop preferences->sessions is the preferred way to edit it
[10:30] <lamont_r> libxklavier...  missing build-deps, sadly
[10:31] <elmo> mdz: mmk
[10:31] <lamont_r> elmo: is the unknown section stuff something that I could help figure out?
[10:33] <thom> mdz: thanks for doing the initial ZDHW wiki page
[10:35] <elmo> LOL
[10:35] <elmo> if you move the top panel to the right, you get fist-size super-blurry icons
[10:35] <thom> yes
[10:35] <thom> it's a FEATCHUR
[10:36] <daniels> heh
[10:36] <elmo> lamont: not really - I know what it is - I'll have another ago in a bit - I just need to finish migrating my desktop to gnome proper
[10:36] <daniels> 'yeah, a Big Mac meal thanks' 'would you like small, large, or FIST?'
[10:36] <lamont_r> elmo: I know that productivity bump too well - wasn't too long ago that I did it myself... :-(
[10:37] <elmo> so.. I really don't want to give up gkrellm.. is there anyway to integrate this thing somehow?
[10:40] <mdz> there are various applets which should fulfill the same basic control freak needs
[10:40] <mjg59> thom: Uh, only running anacron when on battery?
[10:41] <elmo> mdz: nah I've tried them on my laptop - they suck
[10:41] <elmo> but then the laptop doesn't have the res to justify gkrellm over them
[10:42] <thom> um, um. i know what i mean :-)
[10:44] <thom> mjg59: ^
[10:46] <daniels> mjg59: by the way, have you ever noticed how insanely, stupidly, slow mode switches are on i810?
[10:46] <mjg59> daniels: Video mode switches? Nope.
[10:47] <daniels> mjg59: when I start another Xorg instance (with -novtswitch, mind), changing over to the other VT takes a good seven seconds
[10:47] <daniels> mjg59: and about five seconds for subsequent switches
[10:47] <daniels> mjg59: that's same res/depth
[10:47] <mjg59> How long from X to console?
[10:47] <lamont_r> elmo: gkrellm looks cool.. thanks for mentioning it.
[10:47] <daniels> mdz: AH! that was it
[10:47] <daniels> mdz: would you be happy with a default dhclient policy of 'don't set a hostname'?
[10:48] <daniels> mdz: (or, 'leave the hostname alone')
[10:48] <mdz> Keybuk: so is that all that lifeless will need to set up the import?
[10:48] <mjg59> It's damn cold here tonight
[10:48] <daniels> mdz: i'm currently unsure whether ?dms will survive a hostname change (the authentication stuff on that side of the world is crack, planning to go test by fire when I get kicked out here in 10min), so that would allow us to start gdm before dhclient fo'sho
[10:48] <lamont_r> daniels: ew!
[10:49] <daniels> lamont_r: *shrug*, getting hostnames via DHCP in anything other than the initial setup is crack anyway imo
[10:49] <lamont_r> daniels: what you need isa 'change my hostname' event for X, eh?
[10:49] <daniels> lamont_r: ha ha
[10:49] <lamont_r> daniels: true - and really should be trying to give dhcp a hostname
[10:49] <daniels> lamont_r: oh man
[10:49] <daniels> lamont_r: as in, killall Xorg && Xorg?
[10:49] <mdz> daniels: hmm, I didn't even remember that it would do that
[10:49] <mdz> daniels: yes, I think it's sane to default to leaving it alone
[10:50] <Keybuk> mdz: for apt-progeny, yes ... if he starts it there and imports following all the hundreds of copies they did, it'll go in
[10:50] <daniels> mdz: ill, thanks
[10:50] <lamont_r> daniels: no, no.  without killing - just "fix everything" :)
[10:50] <daniels> mdz: i'll give it a going over tonight
[10:50] <Keybuk> mdz: apt-rpm will come up shortly, once sed has finished stripping all the $Id...$ from everything :p
[10:50] <Keybuk> rookery is my bitch <g>
[10:50] <lamont_r> Keybuk: so that's why it's been dog slow lately.
[10:50] <daniels> lamont_r: sure, but when I emerge, you can buy me a beer, because I'll be of legal drinking age in the US
[10:50] <lamont_r> heh
[10:50] <daniels> mdz: -novtswitch is done, btw
[10:51] <lamont_r> that's what, 6 years from now? :-)
[10:51] <daniels> mdz: oh wait, I already told you
[10:51] <daniels> lamont_r: ease up ;) half that
[10:51] <lamont_r> lol
[10:54] <Kosai> Hm.  Any plans for a PPC live CD?
[10:54] <thom> we'd love one. thanks ;-) 
[10:56] <daniels> thom: triple play!
[11:10] <lamont_r> bbl
[11:12] <sjoerd> daniels: with the latest xorg debs, using usefb = false and usefwpll = true works
[11:27] <mdz> thom: when are you coming through LA, again?  do you want to send me a copy of your itinerary?
[11:28] <thom> mdz: sure, will ping it you now
[11:29] <thom> i think you're out of la for most of the time i'm there, but lets see :-)
[11:34] <lifeless> mdz: pong
[11:34] <lifeless> ah, apt syncing, let me look into that right now.
[11:34] <thom> mdz: biff
[11:38] <elmo> thom/mdz: mozilla-firefox-locale-es has been removed in debian - ok to remove it from hoary/main ?
[11:39] <thom> elmo: seems reasonable to me
[11:39] <mdz> elmo: yeah, update the seed as well
[11:40] <elmo> mdz: gar, fascist
[11:40] <mdz> elmo: pinko
[11:42] <elmo> oh, well, I guess I can repropose all the the stuff I'm still using from universe
[11:44] <thom> elmo: just don't get ideas about whacky GREEN TERMINALS, retro boy! ;-)
[11:46] <elmo> thom: meh, you're just jealous of my hardcore old skool skillz
[11:46] <thom> old skool rapping skillz, maybe
[11:48] <bob2> MC ELMO
[11:50] <thom> shoutin' out to the L3 massive!
[11:51] <elmo> thom: I'm pretty sure those guys in the cage next to us are entirely convinced I'm insane - esp. when I really did start shouting at and physically abusing that broken green cat5 the other week
[11:52] <thom> elmo: yeah, we do get some massively funny looks when they have sun engineers in the house