[12:09] <lamont__> doko about, by chance?
[12:10] <doko> lamont__, yep
[12:11] <lamont__> doko: any chance you would know what section gets created in an i386 ld output when there are non-PIC relocations?
[12:14] <lamont> doko: found it.
[12:14] <lamont> but thanks
[12:14] <lamont> (TEXTREL)
[12:16] <moquist> seriously; to whom do I Assign a new bug?
[12:16] <lamont> moquist: generally, you don
[12:16] <lamont>  t
[12:17] <lamont> for several of the packages, there are pre-assigned defaults, for the others mdz (or someone else, but generally mdz in my experience) assigns it to an appropriate victim, if one of us doesn't jus tdeal with it anyway
[12:17] <lamont> debzilla@no-name-yet.com
[12:17] <lamont> works if nothing else.
[12:17] <moquist> lamont: that's what I expected, but when I left "Assign To" blank, ... NM.  Now when I selected "gnome-system-tools" the Assign To field got filled in for me.
[12:18] <lamont> although it should be filled in - I've never needed to type anything there...
[12:18] <doko> lamont, sorry, didn't see.
[12:18] <lamont> you must assign a category..  UNKNOWN is the catchall when you can't find the right package
[12:18] <lamont> doko: np.  I knew that I had a bug that had the needed info in it, just couldn't find it for a bit.. (was closed a while back..)
[12:19] <moquist> lamont: also, the options list under component shrinks to nothing as soon as I've clicked in it once.  that may be part of why I got "undefined" (or whatever it was) in "Assign To" last time.
[12:19] <moquist> lamont: thx
[12:19] <lamont> moquist: I just start typing - if it goes to nothing, then clear the field and type 'UNKNOWN'
[12:20] <moquist> lamont: Yeah, I figured out after a bit that I could just start typing, rather than trying to scroll through the list.
[12:21] <moquist> maybe I should just ask here before submitting a bug... what is the plan concerning root authentication for things like configuration?
[12:21] <moquist> I went to configure my wireless card, and Gnome System Tools wanted the root password.  This is a livecd, so I have no idea what the root password is (leaving it blank did not work).
[12:21] <lamont> gksudo
[12:21] <tvon|x31> to code in sudo use instead of su
[12:21] <tvon|x31> for now you can run "sudo passwd root" to give root a pass
[12:22] <lamont> root gets a starred out password during install
[12:22] <lamont> and sudo is your friend.
[12:22] <lamont> if you know enough to give root a password, then all is happyu
[12:22] <moquist> ok; but this is a known issue.  will a bug submission be helpful just to track this instance of the issue?  no need to add useless bugs...
[12:22] <lamont> and during single user bootup for disaster repair, the password is unused (unless you've given root one)
[12:22] <tvon|x31> No need for the bug
[12:23] <moquist> ok. no bug.
[12:23] <lamont> I think there's already a bug in the system about it.
[12:23] <moquist> thanks for the help
[12:23] <lamont> #943
[12:23] <moquist> I saw another bug about gksudo not working for something else (gnome-cups-something-or-other), but not for Gnome System Tools.
[12:24] <moquist> ok; that's generic enough to cover it all.  :)
[12:24] <seb128>  gnome-system-tools (0.92.0-0ubuntu2) warty; urgency=low
[12:24] <seb128>  .
[12:24] <seb128>    * debian/patches/02_use-gksudo.dpatch:
[12:24] <seb128>      - launch all the system tools with gksudo, avoiding the need for a root
[12:24] <seb128>        password.
[12:24] <seb128> 
[12:24] <seb128> this fix is not good for your problem ?
[12:24] <tvon|x31> ooh, fancy
[12:50] <jdub> moquist: yeah, i'm currently fixing a bunch of stuff for those
[12:51] <jdub> sweet baby jebus
[12:51] <jdub> Setting up at (3.1.8-11ubuntu1) ...
[12:51] <jdub> Installing new version of config file /etc/init.d/atd ...
[12:51] <jdub> [ ok ] rting deferred execution scheduler...
[12:51] <moquist> jdub: cool
[12:51] <jdub> Installing new version of config file /etc/init.d/acpi-support ...
[12:51] <jdub> invoke-rc.d: initscript acpid, action "restart" failed.
[12:51] <jdub>  * Checking battery state...
[12:51] <jdub> [ ok ] /proc/acpi/ac_adapter/*/state: No such file or directory
[12:52] <Clint> mark0: depends; can you chroot to your installed system?
[01:00] <mdz> argh
[01:00] <mdz> circuit breaker keeps tripping
[01:06] <tvon|x31> "black on light yellow" gnome-terminal settings should be default with the ubuntu theme :-D
[01:09] <jdub> hrm
[01:09] <jdub> i don't have a /dev/dsp
[01:10] <tvon|x31> buttercreme vim colorscheme matches well also
[01:10] <tvon|x31> jdub: have alsa/whatnot modules loaded?
[01:11] <jdub> snd_pcm, snd_intel8x0, etc., etc.
[01:12] <mdz> jdub: do you have /dev/snd/*?
[01:13] <jdub> yeah
[01:13] <mdz> sounds like you don't have OSS emulation
[01:13] <mdz> modprobe snd-pcm-oss, snd-mixer-oss
[01:13] <tvon|x31> snd_pcm
[01:13] <tvon|x31> er
[01:13] <tvon|x31> yeah, those
[01:13] <jdub> still no dev/dsp though
[01:14] <mdz> works for me
[01:14] <mdz> in fact they get automatically loaded at boot by default
[01:14] <mdz> this is current warty?
[01:14] <jdub> yeah
[01:14] <mdz> I'm even using the same driver
[01:15] <mdz> jdub: udevd running?
[01:15] <jdub> yeah
[01:16] <jdub> haven't rebooted in a while anyway
[01:16] <jdub> speed of ubuntu development makes me want to reboot!
[01:18] <Gman> you're such a corporate whore ;)
[01:19] <jdub> ribbed for your pleasure
[01:19] <Gman> heh
[01:23] <Clint> mdz: if you can get a hold of the logs, there's stuff from mark0 about his inability to install amd64
[01:24] <mdz> Clint: I'll check fabbione's log, thanks
[01:25] <mdz> Clint: sounds like he had the same problem I did
[01:25] <mdz> I've emailed Mithrandir
[01:26] <jdub> ohmygodmyeyes
[01:27] <jdub> okay, i have a dev/dsp now
[01:27] <jdub> and four mixer tabs! hooray!
[01:28] <tvon|x31> Usability (tm)
[01:28] <jdub> but esd still claims that there's no such /dev/dsp device
[01:29] <hrdwrbob> permissions?
[01:29] <jdub> i'm in the audio group
[01:29] <hrdwrbob> logged in/out since you were added?
[01:29] <jdub> no, first user gets those groups by default
[01:30] <hrdwrbob> ah
[01:30] <hrdwrbob> odd
[01:30] <jdub> Error: Cannot open device oss.
[01:30] <jdub> ALSA lib pcm_hw.c:1155:(snd_pcm_hw_open) open /dev/snd/pcmC0D0p failed: No such file or directory
[01:30] <jdub> ALSA snd_pcm_open error: No such file or directory
[01:30] <jdub> Error: Cannot open device alsa09.
[01:32] <Clint> card 0, device 0?
[01:33] <jdub> perhaps, how about the c vs. p?
[01:33] <jdub> because i only have the c, not the p ;)
[01:33] <jdub> oh
[01:34] <jdub> maybe the usb camera (with mic) is C0
[01:34] <jdub> and the sound card is C1
[01:34] <jdub> p == play, c == record/something
[01:34] <mdz> that would make sense
[01:34] <jdub> ?
[01:34] <jdub> dunno
[01:34] <mdz> since the camera probably doesn't have a mixer
[01:34] <mdz> jdub: c == capture
[01:34] <jdub> good call
[01:34] <jdub> terrible ordering though
[01:36] <jdub> hrm
[01:52] <jdub> so the oss emulation must just take whatever's the first device
[01:55] <mdz> hmm
[01:55] <mdz> so you have a /dev/dsp[1-9]  or something?
[01:58] <jdub> hold on, just trying to close stuff and reload in a sane order
[02:01] <jdub> mdz: i wasn't going to fix those because new ones will appear shortly anyway
[02:02] <mdz> jdub: it's been breaking the daily CDs for two days; we need for those to be working
[02:06] <mdz> it was a trivial fix
[02:10] <jdub> perhaps we should always sort usb last when loading sound drivers or something
[02:10] <jdub> if that's even doable given that it's hotplugging
[02:33] <daniels> jdub: kdrive is a good choice for the installer, but i don't think it's good for usplash, tbh
[02:35] <daniels> jdub: btw, arrive 1635 on the 15th, dep 1415 on the 16th
[02:35] <jdub> tops
[02:36] <jdub> daniels: yeah, we already have an xserver available :)
[02:36] <daniels> jdub: yeah ... starting two x servers makes little sense to me
[02:37] <mdz> jdub: alsa needs some udev love to consistently name its devices
[02:38] <mdz> /etc/modules makes baby jesus cry
[02:38] <jdub> yeah
[02:38] <jdub> oddly, it has a bunch of stuff in it alreayd
[02:38] <jdub> sr_mod
[02:38] <jdub> ide-cd
[02:38] <jdub> ide-generic
[02:38] <jdub> sbp2
[02:38] <daniels> i thought we were going with pissing oss off in favour of alsa?
[02:39] <jdub> daniels: we have, but we're using oss compat because it's less buggy than current app use of alsa
[02:40] <daniels> right
[02:40] <mdz> jdub: where did sr_mod and sbp2 come from?
[02:40] <jdub> no idea
[02:40] <mdz> the installer adds ide-cd and ide-generic
[02:40] <daniels> it's just that istr having the via82cxxx module loaded for sound, in addition to alsa
[02:40] <mdz> I suppose it could add the others too
[02:41] <mdz> daniels: that was a bug
[02:41] <daniels> mdz: was/is?
[02:41] <mdz> alsa _or_ oss should be loaded (almost exclusively alsa)
[02:41] <mdz> was
[02:41] <daniels> ah
[02:41] <daniels> this was colin's crazy hacked-up-at-4am cd
[02:42] <mdz> it used to be that hotplug loaded the alsa driver, and then discover loaded the oss one
[02:42] <mdz> this was pre-wartyconf
[02:42] <daniels> this cd was generated pretty much at the end of wartyconf
[02:42] <mdz> oh, you said via82cxxx, not via82cxxx_audio
[02:42] <daniels> i think it might have been _audio
[02:42] <daniels> but i'm not running that kernel, 'cause i like my /home
[02:42] <mdz> if it is, then that's a bug
[02:42] <mdz> but it seems more likely that it was via82cxxx
[02:43] <daniels> either way, the right module is snd-via82xx
[02:43] <daniels> because without having access to 40 mixer channels, i can't get sound
[02:43] <daniels> (no, really; i need to tweak iec958, iec958 output, iec958 playback, and analogue to optical duplication)
[02:50] <daniels> does anyone here have an ati non-video device? (e.g. agp bridge)
[02:53] <mdz> wasn't it Keybuk who posted to the list with one?
[02:55] <daniels> it's also keybuk who's not here
[02:55] <daniels> he's rather selfishly living on his natural timezone
[02:56] <whiprush> random thought/idea on a fresh ubuntu install:
[02:57] <whiprush> I pick a timezone, I launch evolution, pick a timezone, I launch the weather applet, pick a timezone.
[02:58] <jdub> heh, yeah, annoying to fix
[02:58] <whiprush> yeah I can imagine
[02:58] <jdub> maybe for the next release :)
[02:58] <jdub> (too late for us now)
[02:58] <whiprush> just mentionign it
[02:58] <whiprush> yeah
[02:58] <jdub> should really be fixed upstream
[02:58] <whiprush> indeed.
[02:59] <jdub> privilege elevation stuff is completely shite
[02:59] <jdub> everyone's using different stuff
[03:08] <jdub>  * Stopping Advanced Configuration and Power Interface daemon...                       [ ok ] 
[03:08] <jdub>  * Loading ACPI modules...
[03:08] <jdub>  * Module already loaded: asus_acpi
[03:08] <jdub>  * Module already loaded: ac
[03:08] <jdub>  * Module already loaded: thermal
[03:08] <jdub>  * Module already loaded: processor
[03:08] <jdub>  * Unable to load module: toshiba_acpi
[03:08] <jdub>  * Module already loaded: button
[03:08] <jdub>  * Module already loaded: fan
[03:08] <jdub>  * Module already loaded: battery                                                      [fail] 
[03:08] <jdub> 
[03:08] <jdub> if we're going to have these things in, they really have to mean something ;)
[03:08] <mdz> that's the same stuff it was displaying before, just formatted differently
[03:09] <jdub> but now i don't know what it means ;)
[03:09] <jdub> [fail]  -> the battery?
[03:13] <tvon|x31> after the batter I'd think
[03:14] <jdub> (yes, it's indicating that acpid failed to start)
[03:14] <jdub> (but i only know that because i'm a smarty-pants, not because it told me)
[03:15] <mdz> it is?
[03:16] <mdz> the script seems to be written such that it will issue a [fail]  if any of the modules fails to load
[03:16] <mdz> which I think is a bit excessive, and worthy of a bug report
[03:16] <jdub> i only have kacpid
[03:16] <jdub> and my battery applet hates me
[03:19] <mdz> kacpid??
[03:19] <jdub> the kernel thread
[03:19] <mdz> ah
[03:19] <mdz> visions of KDE swam through my head...
[03:19] <jdub>     3 ?        S<     0:00 [events/0] 
[03:19] <jdub>     5 ?        S<     0:00  \_ [kacpid] 
[03:20] <jdub> hrm
[03:20] <jdub> all these bluetooth daemons are running
[03:20] <jdub> but afaik, i don't have any bluetooth ;)
[03:20] <jdub>  4323 ?        Ss     0:00 hcid: processing events
[03:20] <jdub>  4329 ?        S<     0:00 [krfcommd] 
[03:20] <jdub>  4331 ?        Ss     0:00 /usr/sbin/sdpd
[03:21] <mako> in terms of archive layout, 'restricted' doesn't exist yet, right?
[03:21] <mako> will it?
[03:21] <mdz> sdpd doesn't start here
[03:21] <mdz> mako: it will soon
[03:22] <mdz> I just sent elmo a nagging email about it a few minutes ago
[03:22] <mako> ok, i'm writing the documentation that explains what is and wanted to make sure it was describing something that actual exists :)
[03:22] <mako> or will
[03:23] <mdz> root      1848  0.0  0.0     0    0 ?        S    Sep01   0:00 [kIrDAd] 
[03:23] <mdz> that is kRaD
[03:23] <jdub> heh
[03:23] <jdub> [khpsbpkt] 
[03:23] <mdz> hehe
[03:23] <mdz> kspittled
[03:25] <jdub> hrm
[03:25] <jdub> some funny things aren't working
[03:25] <jdub> clearing recent documents
[03:25] <jdub> totem settings
[03:26] <tvon|x31> clear
[03:27] <mdz> jdub: file associations...
[03:27] <jdub> bong, when i restart the panel it's fine
[03:27] <jdub> or at least, the recdocs menu is clear
[03:28] <jdub> now it's actually working
[03:28] <mdz> jdub: I do not think that word means what you think it means :-)
[03:28] <jdub> hrm
[03:28] <mdz> eek, I just got that awful ACPI error dialog
[03:28] <jdub> heh
[03:29] <jdub> is anyone's wifi applet saving its preference properly?
[03:29] <mdz> whoa, my wifi applet is active now
[03:29] <mdz> magic herbert kernel :-)
[03:29] <mako> mdz: is there going to be a prompt on the cd about restricted?
[03:29] <mdz> mako: current directive is "no"
[03:29] <mako> right
[03:31] <mdz> ah, file associations are fixed
[03:33] <mako> mdz: what is the interface to universe
[03:33] <mdz> mako: edit /etc/apt/sources.list by hand and We Hope You Know What You're Doing
[03:44] <mako> right :)
[03:46] <jdub> ARHG
[03:46] <jdub> cock!
[03:46] <jdub> the battstat images are in a header file
[03:47] <jdub> fascist
[03:47] <tvon|x31> hah
[03:48] <daniels> XPM IS YOUR FRIEND
[03:50] <daniels> XAW ISN'T DEAD
[03:50] <daniels> ALSO XPRINT IS NICE
[03:50] <jdub> that's right
[03:50] <jdub> the bsds still ship it
[03:50] <daniels> ha ha, no
[03:50] <jdub> ;)
[03:50] <daniels> anholt has called xprint an abortion in public and flagged his intention to kill it
[03:50] <jdub> #if needed
[03:50] <jdub> /* XPM */
[03:50] <daniels> oh, xaw
[03:51] <daniels> we still ship xaw
[03:51] <daniels> i think debian still ships libxaw6
[03:51] <mdz> xaw
[03:51] <jdub> ...
[03:51] <mdz> cleverly named for the expression of disgust one uses when encountering it
[03:51] <mdz> "aw..."
[03:51] <daniels> hell, it ships a library called 'oldX' for X10
[03:51] <daniels> mdz: my reactions to xaw are usually less printable :P
[03:52] <daniels> xaw and xprint: two great tastes that taste great together
[03:53] <daniels> that was just the hit i needed to go back to discover's internals
[03:54] <daniels> we should just replace discover with a really stupid wrapper
[03:55] <daniels> if (pci->vendor == 1002 && pci->class == VIDEO) printf("ati");
[04:39] <jdub> mdz: who did you see about the ifconfig/ip retraining?
[04:39] <jdub> mdz: i tried hypnosis and electric shock therapy, but so far, no go
[04:40] <jdub> mdz: maybe it's dietary?
[04:40] <Clint> it requires russian food?
[04:40] <mdz> jdub: printf '#!/bin/sh\n\necho ip, you idiot\n' > ~/bin/ifconfig && chmod 755 ~/bin/ifconfig
[04:41] <mdz> the same technique can be applied to apt-get->aptitude
[04:41] <jdub> not prepared to do a religious conversion at this time of the afternoon
[04:41] <mdz> jdub: it also helps to remind yourself that ip is _way_ fewer characters :-)
[04:42] <jdub> heh
[04:42] <Clint> someone  should make ifconfig do all the relevant things that ip does, and also make all the linux nic drivers support ifconfig media type selection
[04:42] <jdub> every time i type 'ip' to consider trying the switch
[04:43] <jdub> it turns me off
[04:44] <mdz> Clint: ew, why?
[04:44] <mdz> jdub: drink the kool-aid
[04:44] <hrdwrbob> ip route 100x better than 'route'
[04:44] <Clint> mdz: compatibility and sanity?
[04:44] <hrdwrbob> esp when you have mysql accounts for the IP, you add another IP - all of a sudden the outbound IP changes
[04:44] <jdub> Clint: see a dietician.
[04:45] <Clint> jdub: I hate those people.
[04:45] <jdub> let's eat them
[04:45] <jdub> that'll confuse the crap out of them
[04:45] <jdub> "NO! I AM FULL OF CARBS! LET ME GO!
[04:45] <jdub> *chomp*chomp*chomp*
[04:45] <jdub> mdz: no dietician for you!
[04:45] <Clint> hungry?
[04:46] <Kamion> somebody please give 'ip' a man page already
[04:46] <Kamion> I tend not to use programs without man pages
[04:46] <jdub> Kamion: i just looked at one - does it suck?
[04:46] <Kamion> where is it?
[04:46] <jdub> i've already done some retraining this week anyway
[04:46] <Kamion> it ain't in unstable, anyway
[04:46] <jdub> Kamion: man ip, i'm using warty
[04:46] <Clint> holy shit, there's one in sarge
[04:46] <Kamion> ah, hold on, that would be because I don't have it installed :)
[04:46] <Kamion> it used to be crap ...
[04:46] <mdz> Clint: a feature-overloaded ifconfig wouldn't be compatible with anything else anyway
[04:47] <Clint> mdz: I hear a lot of whining from FreeBSD users
[04:47] <mdz> Kamion: ip has had a man page for _ages_
[04:47] <mdz> that argument was moot almost before it happened
[04:47] <Kamion> maybe I'm thinking of tc
[04:47] <mdz> you just have to skip the 4 screens of BNF
[04:47] <Clint> hardly anyone needs to use tc
[04:47] <jdub> heh
[04:47] <jdub> such a turnoff
[04:47] <Kamion> I got burnt extremely badly by having to grok tc at work back in late 2000
[04:47] <mdz> Clint: yeah, I hear a lot of whining from FreeBSD users, too.  I tend to tune it out :-P
[04:48] <Kamion> makes me extremely leery of using anything by that author ever
[04:48] <mdz> ip(8) would benefit from about 5 good examples
[04:48] <Kamion> (of course, I have to use the Linux networking stack ...)
[04:48] <Clint> mdz: I find the fact that I can add extra IP addresses and change duplex a plus
[04:48] <Kamion> tc(8) is better than it used to be but still not great
[04:48] <Clint> and I find the ip runtime help more readable than this manpage
[04:49] <mdz> Kamion: what's your opinion on the sbin question?
[04:50] <Kamion> I lean towards fixing the things that are in the wrong place, since that benefits the rest of the community as well
[04:50] <Kamion> admittedly I put sbin in my $PATH everywhere, but I'm a geek ...
[04:51] <mdz> so is everyone else who uses the command line, to some extent
[04:51] <mdz> which is the only place that PATH really matters
[04:51] <Clint> and zsh's sudo completion looks in sbin even when it isn't in your $PATH now :)
[04:51] <mdz> Clint: ooh!
[04:51] <Kamion> hm, people keep saying that but I'm not convinced
[04:51] <tvon|x31> Could take #1 and file bugs upstream to work towards #2
[04:52] <mdz> some of that stuff is never going to go upstream, ever
[04:52] <Kamion> I know plenty of people who use the command line at a trivial level because that's what the university computer systems offered
[04:52] <mdz> I'll never convince anyone that fsck and mkfs should be in /bin
[04:52] <tvon|x31> upstream is generally not going to be fun methinks
[04:52] <Kamion> but who definitely aren't geeks
[04:52] <mdz> but I use them as unprivileged users _all the time_
[04:52] <Kamion> fsck? really?
[04:52] <mdz> yes
[04:52] <jdub> mdz: so the mousedev thing - what can we do to fix that?
[04:52] <Kamion> oh, uml?
[04:52] <mdz> for UML filesystems
[04:52] <jdub> mdz: (always loading mousedev)
[04:52] <Kamion> that's so a weird special case :)
[04:52] <mdz> jdub: have it added to /etc/modules at install
[04:53] <jdub> Kamion: do you think that's crack?
[04:53] <Kamion> what does the mousedev module do?
[04:53] <jdub> it makes /dev/input/mice appear
[04:53] <mdz> which lets X work sanely
[04:53] <tvon|x31> is /dev/psaux old school?
[04:53] <mdz> tvon|x31: in the worst way
[04:53] <mdz> I think it's still needed for synaptics, though
[04:54] <jdub> tvon|x31: totally. it's not even old school cool.
[04:54] <Kamion> well, we load psmouse for some powerpc systems already, so I guess not
[04:54] <tvon|x31> heh
[04:54] <Kamion> I'd beware arch-specificness, though
[04:54] <mdz> Kamion: mousedev is totally generic input layer goodness
[04:54] <mdz> I think it should load everywhere, regardless of hardware
[04:54] <Kamion> if it works everywhere, we can go for it
[04:54] <Clint> mdz: needed how?
[04:55] <mdz> Clint: in that when X autoconfigures a synaptics device in XF86Config, it points at psaux
[04:55] <Kamion> $ find /lib/modules/2.6.8-powerpc -name mousedev\*
[04:55] <Kamion> $ 
[04:55] <mdz>         Driver          "synaptic"
[04:55] <mdz>         Option          "SendCoreEvents"        "true"
[04:55] <mdz>         Option          "Device"                "/dev/psaux"
[04:55] <mdz>         Option          "Protocol"              "auto-dev"
[04:55] <tvon|x31> heh
[04:55] <mdz> Kamion: :-(
[04:55] <Kamion> ./config/common.stub:1077:CONFIG_INPUT_MOUSEDEV=y
[04:55] <tvon|x31> Option          "Device"                "/dev/psaux"
[04:55] <Clint> ah
[04:55] <mdz> ah
[04:55] <mdz> compiled in
[04:56] <Clint> i'm using driver "ImPS/2" and /dev/input/mice
[04:56] <tvon|x31> That was created by dpkg-reconfigure xserver-xfree86
[04:56] <mdz> Clint: with Driver "synaptics"?
[04:56] <Kamion> it would be a shame to force it to be loaded and have something spit out an error on every boot
[04:56] <Clint> no, driver "ImPS/2"
[04:56] <Kamion> OTOH it's kind of hard to detect that case in hw-detect
[04:56] <mdz> ah
[04:56] <mdz> Kamion: there really should be a sane kernel-level way to handle this
[04:56] <mdz> modules which are compiled in should register themselves in some way that lets modprobe treat the compiled-in and module-already-loaded cases identically
[04:57] <Kamion> in the meantime loading mousedev seems to be the least evil thing, I guess
[04:58] <mdz> Kamion: we could just compile in mousedev everywhere, too
[04:58] <mdz> Kamion: why is it done that way on powerpc, anyway?
[04:58] <tvon|x31> ooh
[04:58] <Kamion> mdz: because you always want it? who knows
[04:59] <mdz> hmm, powerpc is built with CONFIG_INPUT_KEYBOARD=y as well
[04:59] <tvon|x31> is that HID?
[05:00] <tvon|x31> eg, macs have usb keyboards...?
[05:00] <Kamion> well, in the meantime ddetect 1.03ubuntu3 unconditionally loads mousedev post-reboot
[05:00] <jdub> thanks Kamion 
[05:00] <mdz> tvon|x31: no, it has CONFIG_USB_HID=m
[05:00] <jdub> here's hoping it doesn't suck
[05:00] <mdz> Kamion: thanks
[05:01] <Kamion> sticking something in /etc/modules post-install from hw-detect is incredibly easy, you just call register-module and it all gets taken care of
[05:02] <jdub> yo Riff 
[05:02] <tvon|x31> mdz: ah
[05:04] <Riff> hey
[05:04] <Riff> I'm trying to work out if we can do a GNOME reality TV show
[05:05] <Riff> GNOME in a Bubble
[05:05] <Riff> where we put the core hackers in a transparent container in the middle of melbourne for a month
[05:05] <Riff> and see if they can get a GNOME release done
[05:05] <daniels> mdz: ln -s $(which sl) ~/bin/ifconfig
[05:05] <daniels> mdz: annoying, but effective
[05:06] <Kamion> jdub: what bizarro way are you building packages that results in Maintainer: Jeff Waugh <jeff.waugh@canonical.com>?
[05:06] <Kamion> (in the .changes)
[05:06] <Clint> daniels: guh, just alias it
[05:06] <daniels> Clint: er, yeah
[05:07] <jdub> Kamion: which package?
[05:07] <Kamion> jdub: if you're using -m, that's unnecessary
[05:07] <Kamion> file-roller, gnome-netstatus, gnome-system-tools, synaptic that I noticed
[05:08] <jdub> bong, so i am
[05:08] <jdub> removed :)
[05:09] <Kamion> ta, will reduce my cognitive dissonance :)
[05:11] <spiv> Hmm, we don't seem to have offlineimap.
[05:11] <jdub> spiv: eeek!
[05:12] <jdub> spiv: man, good catch
[05:12] <spiv> I vaguely recall installing it direct from debian way back when I installed this laptop, and forgot to report it, but now hypatia just tripped over the same thing.
[05:12] <jdub> spiv: does it work from universe?
[05:13] <spiv> Nope.
[05:14] <jdub> it might just need minor build fixes
[05:14] <jdub> or dep things
[05:14] <spiv> jdub: Thanks :)
[05:14] <jdub> can you put it on one of the hoary pages to remind us?
[05:14] <spiv> Ok.
[05:15] <jdub> lamont: ping
[05:15] <spiv> jdub: Hmm, which page would be appropriate?
[05:15] <jdub> spiv: probably DesktopSeed
[05:16] <spiv> "Create this page"
[05:16] <jdub> brill :)
[05:16] <spiv> Ok then :)
[05:16] <jdub> just put ' * offlineimap # suggested by AndrewBennetts' in there
[05:17] <jdub> mdz: how've you put stuff on www.nny.com/~mdz?
[05:17] <mdz> jdub: rookery:~/public_html
[05:17] <jdub> sftp?
[05:17] <jdub> oh
[05:18] <jdub> hrm, i don't seem to have an ssh key on there
[05:19] <jdub> spiv: http://www.gnome.org/~jdub/random/offlineimap_4.0.4_all.deb
[05:19] <spiv> jdub: Hmm, reading a bit, the instructions under the "PROPOSED" heading of WartyWarthog/DesktopSeed suggest I should do something slightly different.
[05:20] <spiv> jdub: Does that just mean the text there is out of date?
[05:20] <jdub> spiv: kind of
[05:20] <jdub> spiv: we should be maintaining those on the hoary pages now
[05:20] <spiv> That's what the instructions say too ;)
[05:21] <spiv> "If your proposal is not a major priority, please put it in HoaryHedgehogSupportedSeed under PROPOSED"
[05:21] <jdub> heh
[05:21] <spiv> Except for consistency, it should be HoaryHedgehog/SupportedSeed...
[05:21] <spiv> And you told me /DesktopSeed :)
[05:21] <jdub> but for offlineimap it really should be DesktopSeed ;)
[05:21] <spiv> Thus, I am forced into making a decision!
[05:22] <spiv> (I choose to pester you ;)
[05:22] <jdub> eh
[05:22] <jdub> heh
[05:22] <spiv> Ok, fine with me.
[05:22] <spiv> I'll also update the link to point to HoaryHedgehog/SupportedSeed, seeing as that page doesn't exist yet.
[05:31] <daniels> GAH ATI DEATH STAB
[05:31] <mdz> spiv: the instructions there, about the type of bullet point and all, are still applicable
[05:31] <mdz> daniels: nvidia 4 life!!11
[05:32] <daniels> mdz: boooo
[05:32] <daniels> mdz: i'm working from the pciids.sf.net, ati devrel, x.org driver, and discover lists of all ati pci cards
[05:32] <daniels> they're all incomplete
[05:33] <mdz> drivers are hard, let's go shopping
[05:34] <daniels> this isn't even the driver :P
[05:35] <mdz> it's choosing the driver
[05:35] <jdub> mdz: so, atm, gstreamer0.8-mad and friends end up in supported via extra
[05:35] <mdz> dude, it could be so much worse
[05:35] <mdz> they could be ISA cards
[05:35] <jdub> mdz: they're not blacklisted out into universe
[05:35] <daniels> mdz: fwiw, i'm adding all the r4xx series (x600/x800/et al), but setting them to the vesa driver while we still lack support
[05:35] <mdz> jdub: extra stuff doesn't automagically go into supported; it ends up in universe
[05:36] <jdub> hrm
[05:36] <mdz> it should, anyway.  if something moved recently, elmo needs to process it
[05:36] <mdz> daniels: why? won't it fall back to vesa anyway?
[05:36] <jdub> i've moved some of those recently;
[05:37] <jdub> shouldn't be related though from germinate's perspective
[05:38] <daniels> mdz: no
[05:38] <daniels> mdz: ati will say 'OH SHIT I DON'T KNOW ABOUT THIS CARD TOO BAD SUCKAH'
[05:39] <spiv> mdz: Well, I added it to DesktopSeed, as instructed by jdub, but I did put it under a PROPOSED heading with an a. bullet.
[05:39] <jdub> that's way perfect
[06:03] <tvon|x31> In reading the latest kernel thread on the list, it mentions wireless issues iwth the current kernel.  Is the 'current' kernel considered to be 2.6.7-1?
[06:05] <dieman> heh
[06:05] <dieman> daniels: i've been using nvidia at work for the most part.
[06:05] <dieman> daniels: the ati closed source drivers are impossible to support as they currently stand, imo
[06:05] <dieman> the nvidia ones are surprisingly easy
[06:07] <jdub> tvon|x31: yes
[06:07] <jdub> tvon|x31: no drivers/firmware atm
[06:08] <tvon|x31> jdub: ah, okay
[06:10] <daniels> the ati closed-source drivers are total shit from a user's point of view
[06:10] <dieman> yeah
[06:10] <daniels> from my point of view, they are only interesting for r4xx 3D support (x600/x800/et al), the Macrovision bits and TV Out for all Radeons
[06:10] <dieman> i've basically told people who buy the cards to get something else
[06:10] <daniels> and ... that's it
[06:11] <daniels> still, ATI are working to rectify the situation, and they play really well with X.Org from a vendor's point of view
[06:11] <daniels> if nVidia died tomorrow, I wouldn't care much at all
[06:11] <daniels> we'd get about as much co-operation from them
[06:11] <Riff> nvidia don't care about X.org?
[06:11] <Riff> or don't care about the community at all?
[06:12] <tvon|x31> all they care about is nugs and grindage
[06:13] <daniels> there is a magic number floating around relating to deployments of Linux and other open systems; when that number is hit, nVidia will re-examine that strategy
[06:13] <daniels> but, put it this way: their 'open source' driver is total shit, and unusable
[06:13] <daniels> there are no symbols.
[06:14] <daniels> all the register pokes are poking random constant hex values into random constant hex values
[06:14] <daniels> i've no idea whether that's enabling the primary head in the crtc, or instructing the card to suicide
[06:15] <Riff> would nvidia license their source?
[06:16] <Riff> not to include in X.org
[06:16] <Riff> but for you to look at and make work
[06:17] <daniels> no
[06:17] <daniels> nvidia will not give us specs, docs, or anything
[06:17] <daniels> ati have given us specs, cards (beyond what's in x.org), and dev access
[06:17] <hrdwrbob> but they didn't write a large chunk of their driers apparently either
[06:17] <daniels> basically, everything short of strippers and beer
[06:17] <Riff> not even for large wads of cash?
[06:17] <daniels> hrdwrbob: no
[06:17] <daniels> Riff: no
[06:17] <Riff> I wonder what they're trying to protect
[06:18] <daniels> it's just like intel; they gave tungsten some early-release i915 boards and docs, and tungsten shot a driver over to x.org
[06:18] <tvon|x31> but booze & hookers would help
[06:18] <jdub> Riff: let me know what you think about the battstat/wifi icons
[06:18] <Riff> Since I didn't really think they had the market lead at the moment anyway
[06:19] <daniels> apparently they don't want anyone else to put out a driver, since they currently have a canonical (sorry) nvidia driver out there that everyone uses and loves (except x hackers, who despise it)
[06:19] <Riff> jdub: I haven't seen them yet, are they going upstream?
[06:19] <Riff> daniels: I can understand that, it probably fits their business model
[06:19] <daniels> god I hate the nv driver :\
[06:20] <Riff> however, it seems surprising that they won't let X developers tell them where they are going wrong
[06:20] <Riff> they don't employ any X developers per se, do they?
[06:21] <daniels> they employ mark vojkovitch, who does the nv driver, and was the main architect of xaa
[06:21] <jdub> Riff: if they don't suck
[06:22] <Riff> jdub: I haven't used updated ubuntu yet, so I haven't seen them
[06:22] <Riff> I would reinstall my laptop if I had time
[06:22] <Riff> and I would install it on my desktop if I had a screen handy
[06:22] <tvon|x31> jdub: where might they be?
[06:22] <jdub> nah, they just went in
[06:23] <jdub> don't think the package is finished building yet
[06:23] <Riff> and possibly a videocard, I'm not sure if I have one of those either
[06:23] <Riff> I need to get onto the HAL mailing list
[06:23] <Riff> and chat with the HAL guys about getting battery support in HAL
[06:23] <jdub> http://www.gnome.org/~jdub/random/battstat-and-wireless-icons.png
[06:23] <jdub> yeah
[06:23] <jdub> that'd be rad
[06:23] <Riff> HAL is now a hard dependancy on the desktop isn't it?
[06:24] <jdub> pretty much, with gnome-volume-manager
[06:24] <mdz_> all hail hal
[06:24] <jdub> i don't think anyone would have an issue with further use
[06:24] <jdub> MEATY HAL!
[06:24] <mdz_> all your devices are belong to hal
[06:24] <jdub> except the solaris guys
[06:24] <Riff> jdub: I want to see gnome 2.10 with HAL for gnome-vfs
[06:24] <jdub> and the freebsd guys
[06:24] <mdz_> jdub: ...and it has to work on Solaris, too
[06:24] <Riff> it will solve a lot of weirdarse problems
[06:24] <jdub> Riff: well, 2.8 has support for it, but i'm not entirely confident is stable :)
[06:24] <Riff> it's HAL, IT ABSTRACTS HARDWARE
[06:24] <mdz_> jdub: just kidding!
[06:25] <jdub> "just kidding!"
[06:25] <Riff> jdub: I'm using it at the moment
[06:25] <Riff> it mostly works
[06:25] <Riff> I'm going to hack on it later on
[06:25] <jdub> hal+gnome-vfs?
[06:25] <Riff> mmm
[06:25] <jdub> ahr
[06:25] <jdub> we haven't enabled it for warty
[06:25] <jdub> Riff: see that image?
[06:25] <Riff> in "always display devices mode" it doesn't display the devices for the first time till you mount them
[06:25] <mdz_> I wonder when Mithrandir wakes up
[06:26] <Riff> and in "only display mounted devices, ala MacOSX mode" it doesn't seem to work properly at all
[06:26] <Riff> I want the second one to work
[06:26] <jdub> heh
[06:26] <Riff> it should also detect drives can't can't detect insertions/hotplugs
[06:26] <Riff> like my floppy drive
[06:26] <Riff> jdub: the images seem cool
[06:27] <Riff> how does the battery applet work now?
[06:27] <jdub> wrt?
[06:27] <Riff> I assume greyed out means it's empty or not there
[06:27] <jdub> yeah
[06:27] <jdub> instead of the red exclamation mark
[06:27] <Riff> what does it look like when charging?
[06:27] <jdub> same
[06:27] <mdz_> jdub: not sure I like the red in the disabled mode; did you already say you were changing that?
[06:27] <jdub> this is just the one icon change
[06:27] <jdub> mdz_: yeah
[06:27] <Riff> oh right, have you turned off the giant battery image that goes next to it?
[06:28] <jdub> mdz_: i can't just be grey, because 'no link' is also grey ;)
[06:28] <jdub> Riff: yeah
[06:28] <mdz_> jdub: this stuff doesn't seem to be built in Warty yet, so I can't see it here
[06:28] <jdub> mdz_: nah, just uploaded
[06:28] <Riff> jdub: so it's not as "insanely" cool as I'd thought
[06:28] <Riff> the wireless stuff looks easier to read though
[06:29] <mdz_> would hal in gnome-vfs mean that gnome-volume-manager could go away?
[06:29] <Riff> mdz_: no
[06:29] <jdub> mdz_: no
[06:29] <mdz_> what's the use case?
[06:29] <Riff> mdz_: gnome-volume-manager manages the volumes
[06:29] <Riff> compared to gnome-vfs-daemon which isn't always running
[06:29] <mdz_> what would gnome-vfs do with hal apart from manage volumes?
[06:29] <Riff> I _guess_ they could be merged
[06:30] <Riff> mdz_: it's simply talking to HAL to get the volume names and properties
[06:30] <Riff> rather then reading fstab
[06:30] <Riff> it only changes two files iirc
[06:30] <jdub> Riff: not really, gnome-vfs (and thus gnome-vfs-daemon) can be used in non-gnome apps
[06:30] <Riff> jdub: excellent point
[06:31] <jdub> policy engine should be separate to a certain extent, at least in this case
[06:31] <jdub> we do have a BUTTLOAD of session daemons though
[06:31] <Riff> it's part of our MODULAR DESIGN
[06:32] <jdub> (i wonder how many will die off as we start using d-bus more...?)
[06:32] <Riff> I have 42 live processes
[06:32] <jdub> gconfd *could* die off, if libgconf did most of the work
[06:32] <Riff> ignore galeon, evolution, gnome-terminal (and bash)
[06:33] <Riff> that takes my desktop down to 38 processes
[06:33] <Riff> oh wait, ignore 3 more on a tty
[06:33] <Riff> 35 processes
[06:33] <Riff> jdub: gconfd does a lot of caching and deals with policy shit
[06:33] <Riff> it's probably a good idea
[06:34] <jdub> libgconf *could* do that
[06:34] <Riff> it also makes our backend pluggable if we ever go down that path
[06:34] <Riff> jdub: how would you do multiple session caching?
[06:34] <jdub> http://www.gnome.org/projects/gconf/plans.html
[06:34] <Riff> perhaps I've been hanging out with UNIX too long to think of a way that doesn't involve some sort of daemon or resident program
[06:39] <daniels> sweet mother of god
[06:39] <daniels> #if defined(__powerpc__)
[06:39] <daniels>   { 0x10DE0179, "GeForce4 MX (Mac)" },
[06:39] <daniels> #else
[06:39] <daniels>   { 0x10DE0179, "GeForce4 440 Go 64M" },
[06:39] <daniels> #endif
[06:39] <daniels> bad nVidia
[06:39] <daniels> bad!
[06:44] <tvon|x31> anyone have issues with the latest fam starting?
[06:44] <tvon|x31> postinst is failing for me
[06:46] <tvon|x31> dies on invoke-rc.d fam start (which fails)
[06:47] <tvon|x31> though it does start fam...
[06:47] <jdub> tvon|x31: same here
[06:50] <tvon|x31> start-stop-daemon --stop --quiet --exec /usr/sbin/famd
[06:50] <tvon|x31> taint workin
[06:56] <jdub> ahr, new evo release in unstable
[06:56] <tvon|x31> 94?
[06:56] <jdub> 94.1, yeah
[06:57] <jdub> now i can rebuild all mine :)
[06:57] <tvon|x31> nice
[06:57] <tvon|x31> I like the wifi icon
[06:57] <tvon|x31> btw
[06:57] <jdub> of course, now i don't have an unstable machine
[06:57] <jdub> cool
[06:58] <tvon|x31> granted my wifi status still doesnt work
[07:00] <tvon|x31> doesnt work in netapplet either
[07:01] <jdub> (that one's netstatus, the novell crazy suse thing is netapplet)
[07:01] <jdub> (just for clarity)
[07:01] <tvon|x31> yeah
[07:01] <tvon|x31> crazy nuse thing is installed
[07:02] <jdub> oh yeah, i have an unstable chroot on my notebook
[07:03] <tvon|x31> is the 2.6.8 kernel usable without much tweaking?
[07:03] <jdub> the one on matt's site? i'm using it, no tweaking
[07:04] <tvon|x31> ah, cool
[07:13] <fabbione> morning guys
[07:14] <tvon|x31> well that didn't change much
[07:14] <tvon|x31> jdub: might want to update the icon in the battery applet preview (prefs)
[07:16] <tvon|x31> jdub: were you getting the acpid failure as well?
[07:17] <tvon|x31> ah
[07:18] <tvon|x31> nm
[07:18] <tvon|x31> and ignore what I said about the batt app
[07:18] <jdub> tvon|x31: the one in the prefs is accurate for-- aha :)
[07:25] <mdz> Kamion: you're still awake?? or up early?
[07:28] <daniels> mdz: kamion is hardcore
[07:28] <daniels> fabbione: morning
[07:29] <Riff> the world is upsidedown and on it's head
[07:31] <fabbione> daniels: stupid question.. how complex would it be to make nv/nvidia driver wrapper ala ati?
[07:32] <jdub> hrm, how does firefox lock a profile now?
[07:32] <fabbione> so that we can always call it nv
[07:32] <fabbione> but it uses the real driver according to what is available?
[07:32] <fabbione> like: nvidia first, otherwise use the real nv from xfree86?
[07:32] <daniels> fabbione: sweet mother of god, dude
[07:32] <daniels> i could do it tomorrow, but shit
[07:32] <daniels> that's nasty
[07:33] <fabbione> thom: fresh install of crack of the day: gdm login -> "can't access ACPI bla bla bla"
[07:33] <fabbione> daniels: no.. no need to do it. i am just curious how complex would it be
[07:33] <fabbione> because it would solve hellalot of problems
[07:33] <mdz> fabbione: yeah, it's already in bugzilla
[07:34] <daniels> fabbione: not horrifically. the biggest part would just be function() { invokeotherfunction(); }
[07:34] <mdz> I think..
[07:34] <daniels> unless ... oh dear
[07:34] <daniels> yeah, you could do some abysmal hackery involving replacing its moduleinforec within the loader
[07:34] <fabbione> daniels: think carefully... than gimme an answer :-)
[07:34] <mdz> fabbione: if it's not there, please report it
[07:35] <mdz> not sure whether it's jdub or seb's domain
[07:35] <fabbione> mdz: i will check in a sec...
[07:35] <tvon|x31> mhm...ah, but it was due to /etc/defaults/acpid having 'all' for the module list...which caused isues
[07:35] <tvon|x31> issues
[07:35] <daniels> fabbione: could be down to ~30 lines if you wanted
[07:35] <fabbione> i am still injecting coffee in my blood stream
[07:35] <fabbione> daniels: i mean something that WORKS :P
[07:35] <daniels> fabbione: but you'd probably need to replace the config handler with your own custom one that silently threw out nvidia options when you were using nv
[07:35] <daniels> fabbione: sure you mean coffee and not smack?
[07:35] <Riff> smack, coffee
[07:35] <Riff> it's all the same
[07:36] <jdub> mdz: i reported the acpi thing earlier, assigned to seb with thom cced
[07:36] <Riff> he's waiting for them to fedex his Special K
[07:36] <daniels> because, while it would work, it's ... sweet mother of god
[07:36] <daniels> Riff: what, so he can get great legs?
[07:36] <Riff> daniels: the other special K
[07:36] <mdz> jdub: where is it? I'm not finding it
[07:37] <daniels> Riff: a man is not a cam^Whorse
[07:37] <jdub> mdz: i don't have a web browser atm, give me a minute... ;)
[07:37] <fabbione> daniels: ok.. it's already too complex for warty
[07:37] <fabbione> daniels: if i can't see it simple in the morning, it's not going to be better later
[07:37] <Riff> http://en.wikipedia.org/wiki/Ketamine
[07:37] <daniels> fabbione: i could do it in two hours, but especially given i not only don't own an nvidia card, but have no desire to, i can't test it
[07:38] <daniels> Riff: yes, hence the man's not a horse thing (complete with frenzal rhomb reference)
[07:38] <fabbione> daniels: i can test it with no problems and anyway i think the config options are the same
[07:38] <fabbione> daniels: i need to check the README from nvidia.com
[07:39] <Riff> daniels: I didn't get it
[07:39] <fabbione> daniels: tho i still think it won't make it in time for warty
[07:39] <daniels> fabbione: basically, init would be about ten lines, trying to open nvidia and then nv, and then storming into the loader's internal structures, replacing its own moduleinfoptr with that of the one you just generated for the real submodule
[07:39] <daniels> Riff: ketamine -> horse tranquiliser, unless i'm much mistaken
[07:39] <fabbione> daniels: that's more or less what i had in my mind
[07:39] <daniels> Riff: (and one of frenzal's albums is called a man's not a camel)
[07:39] <Riff> daniels: among other things, yeah
[07:39] <daniels> fabbione: yeah. easy, but fuck me it's ugly.
[07:39] <Riff> aah
[07:40] <fabbione> daniels: isn't what ati does (more or less)?
[07:40] <daniels> fabbione: guess why i always campaign for using r128/radeon directly :P
[07:40] <daniels> fabbione: ati isn't quite on that level of nasty, anyway
[07:41] <fabbione> daniels: yeah i could guess so...
[07:43] <Riff> woo, I have added something to Wikipedia
[07:44] <mdz> wikipedia is amazing
[07:46] <fabbione> daniels:   * Allocated 10 patch slots (989-998) for warty.
[07:46] <daniels> fabbione: rad
[07:47] <fabbione> so we don't clash with debian patches
[07:49] <fabbione> ahhh
[07:49] <fabbione> this is funny
[07:49] <fabbione> as soon as you start Totem:
[07:50] <fabbione> "Error: GStreamer developers were too lazy to assign an error code to this error. Please file a bug"
[07:50] <daniels> haha
[08:11] <lamont> jdub: yo
[08:12] <jdub> lamont: i forget
[08:12] <jdub> oh yeah
[08:12] <jdub> lamont: why isn't offlineimap building in universe?
[08:13] <jdub> i pulled source and it built here fine
[08:17] <lamont> dh_python: Python is not installed, aborting. (Probably forgot to Build-Depend on python.)
[08:17] <lamont> that'd be "missing build-depends for $200, Bob"
[08:18] <fabbione> do we stil have the suede(??) icon problem?
[08:18] <fabbione> or is it supposed to be fixed?
[08:18] <jdub> oh, it build-deps on python2.3-dev, but probably not python itself ;)
[08:18] <lamont> right
[08:18] <jdub> fabbione: fix on its way
[08:18] <lamont> it _used_ to be that python2.3-dev Depended python, but no more.
[08:19] <jdub> i hate it when that happens 
[08:19] <lamont> jdub: there are about 20-30 packages that have that issue (in universe)
[08:20] <fabbione> jdub: thanks
[08:21] <lamont> fabbione: have you been working on ximian-connector, btw?
[08:21] <jdub> i will
[08:22] <jdub> mdz fixed the current version prob
[08:22] <jdub> i've just been waiting for the new packages
[08:22] <fabbione> lamont: only evolution-webcal
[08:22] <jdub> which i thought were coming two days ago ;)
[08:22] <jdub> mdz already fixed it
[08:23] <lamont> cool
[08:23] <fabbione> lamont: i did a test on ximimian-connector but it was a FTBFS and i gave up.. 
[08:23] <fabbione> lamont: not knowing it at all, i didn't feel like messing with it
[08:25] <fabbione> lamont: i am already busted enough with X
[08:25] <fabbione> if you feel like doing an exchange :P
[08:25] <doko> lamont: do you know, what probably is wrong with gcc-3.4's sonames?
[08:26] <lamont> doko: no clue 
[08:26] <fabbione> diff -Nur xc.orig/ xc > ../debian/patches/989_warty_add_extra_modelines_from_xorg.diff
[08:26] <fabbione> daniels: ^^
[08:26] <daniels> fabbione: cool
[08:27] <fabbione> now i need to remember how to add the $Id prop in svn...
[08:27] <daniels> svn ps svn:keywords foo Id
[08:27] <daniels> iirc
[08:27] <fabbione> i was never able to get it right at the first time
[08:27] <daniels> bbiab
[08:34] <jdub> tarballs of themes? eek!
[08:35] <jdub> should've uploaded my original u-a :|
[08:36] <lamont> Kamion: ln: accessing `./tmp/netboot_2.6/cd_tree/linux': No such file or directory
[08:37] <lamont> that's from _20040801ubuntu4
[09:18] <fabbione> mdz: i found the reason why you were getting that strange resolution/virtual desktop problem
[09:24] <daniels> i need Keybuk
[09:24] <daniels> about 100% more Keybuk
[10:20] <ik5pvx> question: is "suspend-to-something" supposed to work out of the box on i386 ?
[10:45] <daniels> fabbione: the discover1-data and discover1 uploads should take care of the last of our discovery worries
[10:45] <daniels> fabbione: if there are any more problems, they're in your configure scripts :P
[10:46] <fabbione> daniels: yeah sure...
[10:48] <daniels> except for i810 which is partially x's fault, and partially the fault of everyone that bought an x40
[10:48] <daniels> heh
[10:55] <seb128> hello
[10:58] <jdub> morning seb128 
[10:58] <seb128> hey hey jdub 
[11:00] <pitti> seb128: Morning! Do you have some time to help me with adding USB device support to Nautilus?
[11:01] <pitti> seb128: I've never seen the code before, it'll take me a while to find the proper start. Do you already know where the changes must be made?
[11:01] <seb128> which USB support ?
[11:02] <seb128> I don't know a lot about the nautilus code, I've look to fix some bugs but no real big hack on it
[11:03] <pitti> seb128: if an USB volume is plugged in, gvm mounts it, but Nautilus does not show the device/allows to umount it again
[11:03] <pitti> seb128: do you know who I can ask about Nautilus code?
[11:04] <seb128> you can try on #nautilus@irc.gnome.org, usually alex is helpful but he's away right now apparently
[11:04] <seb128> but I though you wanted to use mtab instead of fstab
[11:04] <seb128> it doesn't solve the issue ?
[11:05] <fabbione> DIE freenode!
[11:05] <fabbione> DIE freenode!
[11:05] <fabbione> DIE freenode!
[11:05] <fabbione> ok... how many lines went trough?
[11:05] <Hrdwr_BoB> none
[11:05] <seb128> daniels: was a bug in hal finally ?
[11:05] <seb128> 0
[11:05] <fabbione> goody
[11:07] <fabbione> DANIEL!
[11:07] <fabbione> why the hell did you upload X?
[11:07] <fabbione> do you want to tell me at least?
[11:07] <fabbione> i ahve 2 tons of changes pending
[11:08] <fabbione> bah
[11:08] <pitti> seb128: the word 'fstab' does not occur in the code 
[11:08] <fabbione> the symlink is not correct... see the bug report. it is not enough to fix that problem
[11:08] <pitti> seb128: (but for some Changelogs and inclusion of <fstab.h>
[11:08] <fabbione> the file needs to be shipped on its own
[11:11] <pitti> jdub: do you happen to know which part of the Nautilus source manages the umountable devices?
[11:12] <daniels> seb128: yah
[11:14] <jdub> pitti: nup :)
[11:31] <pitti> elmo: do you have any idea why the download of manpages-dev from auckland always stucks at 313 kB (32%)?
[11:32] <elmo> pitti: no?  works for me...
[11:32] <elmo> Get:1 http://auckland.warthogs.hbd.com warty/main manpages-dev 1.67-1 [1045kB] 
[11:32] <elmo> Fetched 1045kB in 9s (112kB/s)                
[11:33] <pitti> elmo: that's odd. I tried it six times now.
[11:33] <pitti> elmo: the package from debian works, though, so it's not a big problem. Thanks!
[11:33] <fabbione> pitti: it happened to me but for another package long time ago
[11:34] <fabbione> pitti: somewhere in the middle is dropping packets
[11:34] <pitti> elmo: BTW, do you have any reservations regarding sync'ing postgresql?
[11:34] <pitti> fabbione: but it always stopped at exactly the same point
[11:34] <elmo> pitti: not particularly?  if you mean why hasn't it been done yet, I can only sync stuff once it reaches a public mirror
[11:35] <fabbione> pitti: yup.. just coincidence
[11:35] <fabbione> elmo: do you have any eta for restricted and security? without the changes in the archive we cannot change base-config
[11:36] <pitti> elmo: packages.d.o has 7.4.5-3 in sid
[11:36] <elmo> pitti: yes, as of today? it hit ftp.uk.debian.org at about 2am my time.  sorry, I didn't get up to sync it then and there :P
[11:37] <elmo> fabbione: as soon as I can
[11:37] <fabbione> elmo: danke
[11:38] <pitti> elmo: sorry, I did not want to urge. I uploaded yesterday, that's why I thought that there was a problem with it.
[11:50] <fabbione> what is a good package to do technical drawing, like house plants and such?
[11:52] <seb128> qcad ?
[11:53] <fabbione> seb128: anything simple that works is fine. i don't need anything fancy
[11:53] <fabbione> i just need to do a house map
[11:53] <Hrdwr_BoB> dia?
[11:54] <seb128> qcad should be ok ... out of this dunno
[11:54] <fabbione> ok thanks
[11:54] <fabbione> i will just install both :P
[12:01] <fabbione> seb128: qcad looks good :)
[12:02] <seb128> nice :)
[12:11] <Mithrandir> mdz: pong.
[12:11] <Mithrandir> mdz: I'm aware that grub is broken, I didn't want to upload the version I changed, because I haven't had the time to test it yet.
[12:12] <seb128> hey ross 
[12:12] <ross> hi seb128
[12:13] <jdub> yo ross 
[12:13] <ross> yo yo jdub
[12:18] <pitti> elmo: thanks for syncing! I'll try to be less impatient next time.
[12:21] <jdub> what's the variable that stores the end result names of _in_files?
[12:54] <ross> seb128: does your gtk filechooser patch default to ~/Documents?
[12:54] <seb128> ross: if it exists, yes
[12:54] <seb128> why ?
[12:55] <ross> its a little weird when the evo import filechooser goes to ~/Documents
[12:55] <seb128> rmdir Dociments :p
[12:55] <seb128> s/i/u/
[12:55] <ross> i might just do that actually
[01:00] <jdub> seb128: yaaaaay evo! :)
[01:01] <seb128> yeah ;)
[01:02] <seb128> gtkhtml3.2_3.2.0-1ubuntu1_source.changes is NEW
[01:02] <seb128> just need to get this one accepted
[01:02] <ross> seb128: is that the experimental release, or did you and takuo update at the same time?
[01:02] <jdub> i love make distcheck
[01:02] <seb128> ross: I was waiting for Kitame
[01:03] <seb128> ross: less work :)
[01:03] <seb128> ross: and apparently he was waiting to get the new libsoup and gal out of NEW ... they have been accepted yesterday evening, I've waited the night to see if the was going to upload the rest and it was in incoming this morning :)
[01:10] <seb128> elmo: here ?
[01:10] <seb128> elmo: could you accept gtkhtml3.2 which is in warty/NEW ?
[01:21] <Kamion> lamont: there've been two uploads since then, one of which should have fixed exactly that issue ...
[01:29] <thom> hullo craige
[01:30] <TongMaster> heya thom.
[01:44] <elmo> seb128: done - is someone (jdub?) going to be recompiling exchange* for the new gal/soup?
[01:47] <jdub> elmo: yeah
[01:47] <seb128> elmo: thanks
[01:59] <jdub> [01:59] <jdub> ubuntu-artwork-0.2.0.tar.gz is ready for distribution
[01:59] <jdub> [01:59] <jdub> that's what i'm talking about!
[02:00] <Kamion> mdz: don't think I was still awake by 6:25, but I was up depressingly late for no very good reason
[02:06] <ross> hn
[02:07] <ross> when i press Synaptic nothing happens
[02:07] <ross> when i run the .desktop command in a shell this happens:
[02:07] <ross> $ gksudo /usr/sbin/synaptic
[02:07] <ross> We trust you ha
[02:07] <jdub> ugh
[02:07] <jdub> first time sudo
[02:07] <jdub> can you file a bug about first time sudo prompt?
[02:07] <jdub> that's vicious
[02:07] <ross> i don't want to be in the sudo group, i want it to ask for the root password
[02:09] <ross> #987 filed
[02:11] <Kamion> uh, didn't we kill that prompt in sudo?
[02:11] <Kamion> Defaults !lecture
[02:12] <ross> will gksudo fall back on asking for the root password?
[02:12] <Kamion> ross: upgrading or fresh install?
[02:12] <ross> Kamion: upgraded install
[02:12] <Kamion> aha; you need to set Defaults !lecture. fresh installs are fine
[02:12] <ross> righto
[02:13] <ross> where do i do that?
[02:13] <Kamion> conventionally between "# Cmnd alias specification" and any user privilege specs
[02:13] <Kamion> the warty default is "Defaults !lecture,tty_tickets"
[02:14] <ross> fab
[02:16] <jdub> ross: there is no root password :)
[02:16] <ross> this is an upgrade, there is
[02:17] <jdub> ross: (i don't believe gksudo falls back even if there is.)
[02:17] <ross> urgh
[02:17] <jdub> that is an interesting state of affairs
[02:17] <Kamion> that's going to be ... amusing
[02:17] <jdub> btw, privilege elevation stuff is total b0rk in gnome
[02:17] <Kamion> gk-get-root-privileges-somehow :-P
[02:17] <ross> could gtksudo fallback on root?
[02:18] <Kamion> I think it would have to ask for the user password first, otherwise information leak ...
[02:18] <Kamion> (you could use gksudo to find out whether a user is allowed to sudo to root without having to know their password; you could then invest more time in attacking that user)
[02:19] <Kamion> maybe this should be configured in /etc/default/
[02:19] <Kamion> (su or sudo for the desktop)
[02:19] <Kamion> or maybe a per-user preference, even
[02:19] <ross> hm
[02:20] <ross> at the end of the day, the aim is that all users here but three don't have sudo. me and two others will have sudo to reduce the number of times we type the root password
[02:20] <Kamion> do you actually want to be logging in as root from the unprivileged users' desktops?
[02:21] <Kamion> what if they install a keylogger?
[02:21] <ross> we generally ssh into the machine to avoid physical movement :)
[02:21] <jdub> mmm, sudo is the right way to elevate privileges
[02:21] <jdub> but man, there so needs to be a consistent infrastructure for it in gnome
[02:24] <ross> whats the default sudoers line for the first user?
[02:24] <thom> # Added by Ubuntu installer
[02:24] <thom> thom    ALL=(ALL) ALL
[02:24] <ross> rock on
[02:25] <thom> Kamion: i'm assuming mdz means _initial_ install in #467; is taking a similar approach as scrollkeeper reasonable do you think?
[02:27] <fabbione> "last" bug and X ubuntu14 is ready to rock and roll
[02:28] <lamont> fabbione: great!
[02:28] <fabbione> a lot of improvements
[02:28] <fabbione> and a lot of bug fixes
[02:28] <fabbione> acutally i wonder how ubuntu12 could detect frequencies with the crap i found
[02:28] <fabbione> a completely missing db_get
[02:30] <Kamion> thom: was thinking about it, but not entirely sure I want to overload that mechanism
[02:30] <fabbione> lamont: anyway don't worry.. i won't upload before monday
[02:30] <fabbione> i need to do more regression tests
[02:31] <Kamion> python postinsts do somewhat grungier things than just 'scrollkeeper-update', IIRC
[02:31] <fabbione> lamont: and complain to daniels for ubuntu13 :P
[02:31] <lamont> heh
[02:31] <thom> Kamion: $PYTHON /usr/lib/$PYTHON/compileall.py -q $i
[02:31] <fabbione> Ubuntu 13, Ubuntu 13: this is houston.. we are ready to go!
[02:31] <lamont> monday is US bank holidy, btw
[02:31] <fabbione> houston to ubuntu 13: go to hell^Wthe moon
[02:32] <Kamion> thom: can hardly divert python :-)
[02:32] <fabbione> lamont: i was just worried about your mirror :-)
[02:33] <fabbione> AHH GOT IT!
[02:33] <fabbione> i found it
[02:33] <lamont> fabbione: don't worry too much -OO.o just came through yesterday.  It really just affects how often I can upgrade
[02:33] <Kamion> fabbione: note Sounder 8 on Monday
[02:33] <fabbione> Kamion: you said that it could be moved to tuesday
[02:34] <lamont> fabbione: which means that you really wanna upload no later than sunday
[02:34] <thom> Kamion: not planning to; just divert the script to a trivial one that returns true
[02:34] <fabbione> Kamion: i need to get ubuntu14 in
[02:34] <fabbione> lamont: i can't. I am leaving for the weekend in like 1 hour or so
[02:34] <Kamion> fabbione: Tuesday> true, but only if I really, really have to
[02:34] <Kamion> thom: ugh
[02:34] <fabbione> Kamion: i have been working a shit load of hours this week and i am need to take a little break.
[02:34] <thom> Kamion: not saying i like it
[02:35] <fabbione> Kamion: i will be a work monday like 5 am UTC
[02:35] <Kamion> fabbione: sure, but delayed Sounder releases mean *I* work a shitload of hours :(
[02:35] <Kamion> hence why I try to avoid them :)
[02:35] <fabbione> Kamion: it's just question of 1 or 2 hours
[02:35] <fabbione> Kamion: time that i complete the regressions and upload
[02:35] <fabbione> Kamion: if lamont fixes the buildd to do X without manual kick we are ok
[02:36] <thom> Kamion: it's a better short term fix than trying to rewrite every postinst
[02:36] <Kamion> thom: what happens to maintainer scripts that use python modules between the diverted-so-doesn't-happen compileall and the point when base-config actually does it?
[02:36] <Kamion> fabbione: as long as it doesn't mean me staying up all night and ignoring my girlfriend
[02:36] <thom> Kamion: python modules get compiled at first use
[02:36] <fabbione> lamont: ???
[02:36] <thom> Kamion: the postinst is just an optimisiation, it's not necessary
[02:36] <fabbione> lamont: what's the status of the buildd?
[02:36] <fabbione> lamont: can they handle X on their own?
[02:36] <lamont> fabbione: empirical evidence suggests that amd64 is the only one I have to kick manually, and 6am UTC isn't even bed time...
[02:37] <Kamion> thom: I guess ... ok, fine by me as long as you do it :)
[02:37] <fabbione> lamont: i will need to complete the tests before i upload
[02:37] <fabbione> lamont: than it's up to you
[02:37] <thom> heh :-)
[02:37] <fabbione> Kamion: do you need to release for amd64 too?
[02:37] <jdub> hrm, i just want to install an entire tree of files with automake
[02:37] <Kamion> yes
[02:37] <jdub> can i avoid writing crackrock install-data-local foo?
[02:37] <Kamion> we're one week from preview release, dude, dropping architectures isn't an option
[02:38] <elmo> lamont: why do you have to kick amd64?
[02:38] <lamont> Kamion: meaning amd64 officially made it back into the list.  cool.
[02:38] <Kamion> lamont: speaking of, is daily-installer-amd64 working?
[02:38] <lamont> elmo: that's what I'm going to figure out today.  it's a postfix config diff
[02:38] <fabbione> ok
[02:38] <lamont> Kamion: this mornings ran fine.
[02:38] <fabbione> i will try to upload before i leave
[02:38] <lamont> yesterday, um..  don't ask.
[02:40] <Kamion> ok, yeah, I see it in the list now. cool!
[02:40] <thom> Kamion: oh, what's the status of amd64 cds? should the current daily even remotely work?
[02:40] <Kamion> thom: functional; apparently grub issues
[02:41] <thom> ok, not fussed about grub
[02:41] <Kamion> minor details like a bootloader, eh? :)
[02:41] <elmo> yeah, bootloaders are for losers
[02:41] <Kamion> real men toggle the OS in on the front panel
[02:41] <Kamion> IN TERNARY
[02:41] <thom> *g*
[02:42] <Hrdwr_BoB> real men have keyboards with one key and an innate sense of timing
[02:42] <Kamion> it's tab, and they all run zsh
[02:43] <Kamion> thom: so, what are you trying to do, if not install a bootable system? :)
[02:43] <thom> Kamion: i have a bootloader already, since this dual boots with i386 ubuntu
[02:44] <Kamion> you'll need to convince d-i not to install a broken one then
[02:44] <Kamion> expert mode might be a plan
[02:44] <thom> it runs and breaks, or just doesn't run at all?
[02:44] <Kamion> don't recall, see sounder@
[02:45] <thom> ah, screw it. i'll burn an x86 cd as well; if it all goes tits up i can reinstall that too
[02:45] <Kamion> hm, or not
[02:45] <Kamion> maybe it was on this channel or something
[02:58] <fabbione> ok.. this should work
[03:10] <fabbione> YES YES
[03:10] <fabbione> Kamion: no phear
[03:10] <fabbione> i am going to upload now
[03:10] <fabbione> but if the shit hit the fan we will have to deal with it on monday
[03:21] <fabbione> npmccallum: what did you use to edit xfree86-common?
[03:21] <fabbione> it was full of ^M
[03:31] <fabbione> there
[03:31] <fabbione> ubuntu14 is up
[03:33] <lamont> fabbione: amd64 postfix config tweaked to match the other machines.  should upload hands-free now.
[03:39] <fabbione> lamont: Ub3r c00l
[03:39] <fabbione> i am off for the weekend
[03:39] <fabbione> cya monday guys
[03:39] <thom> ciao, slacker :-)
[03:39] <fabbione> thom: you don't want to be me...
[03:40] <fabbione> a weekend with my gf and my mother in law
[03:40] <fabbione> no net access
[03:40] <fabbione> nothing can be more boring than that
[03:40] <fabbione> other than pubs closing at 11pm :P
[03:40] <fabbione> cya
[03:40] <thom> hahah
[03:41] <thom> pub closes at midnight here on the weekend ;P
[03:42] <Mithrandir> that's just silly.
[04:00] <Kamion> hm, with today's daily I get "Can't access ACPI events in /var/run/acpid.socket!" at login
[04:00] <pitti> HOOORAY! After hours of code reading and patching, gnome-vfs (and Nautilus) finally works with pmount
[04:03] <thom> pitti: rock
[04:03] <tvon|x31> Kamion: check /etc/defaults/acpid
[04:04] <tvon|x31> if it has MODULES="all" try changing it to just what you need/want
[04:04] <Kamion> yeah, that's probably it
[04:04] <thom> Kamion: yeah, known problem. it's fixed in the archive
[04:15] <tvon|x31> fam still wont pass postinst
[04:24] <tvon|x31> hrm...is a new evo on its way up?
[04:24] <tvon|x31> ish
[04:25] <ross> i noticed synaptic thought it better to remove evo than to upgrade gtkhtml
[04:25] <ross> thus i thought it was broken at first
[04:26] <thom> tvon|x31: have you filed a bug about fam?
[04:26] <tvon|x31> thom: not yet, figured I'd wait a day
[04:26] <tvon|x31> which...would be today :)
[04:28] <thom> tvon|x31: please file before the weekend :-)
[04:29] <tvon|x31> hrm, where is the zilla?
[04:31] <tvon|x31> thought I tried that...
[04:31] <tvon|x31> or not..  Thanks
[05:00] <tvon|x31> #988
[05:22] <thom> mdz is gonna hate me for #886
[05:26] <lamont> thom: why not just binNMU libapache2_mod_python?
[05:27] <lamont> "So this works fine with just a recompile in warty."
[05:27] <thom> lamont: need to sync apache2 anyway
[05:27] <lamont> oh. ok.
[05:27] <lamont> um, why?
[05:27] <thom> security vulns
[05:28] <ross> bah
[05:28] <ross> ship them a week after you release, it looks like the security team are doing work then
[05:29] <thom> lamont: subversion needs fixes from a2, so that should be fixed. and i'd prefer to keep python and php in sync whilst we still can
[05:32] <lamont> hrm... brb
[05:35] <thom> tvon|x31: do you have the newest lsb-base? 
[05:37] <kagou> hi
[05:39] <seb128> hello kagou 
[05:40] <kagou> lo seb128 :)
[05:40] <mdz> morning
[05:40] <kagou> acpid don't launch on boot since upgrade
[05:40] <kagou> morning mdz :p
[05:41] <mdz> thom: 886 is resolved...?
[05:41] <mdz> thom: more apache2 vulnerabilities? gah
[05:41] <thom> mdz: it probably shouldn't be, actually.
[05:42] <thom> but yes, there are 2 fixed in 2.0.50-11
[05:45] <thom> hey dude
[05:45] <ross> whoops!
[05:45] <edd> they thom.
[05:45] <lamont> ross needs a better bra. :-)
[05:45] <edd> how's today's daily image? i need one to take to oreilly with me.
[05:46] <ross> lamont: that wasn't what popped out, dammit ;)
[05:46] <lamont> hehe
[05:54] <thom> kagou: upgrade lsb-base and acpid
[05:54] <kagou> i'm up to date
[05:55] <thom> what error do you get?
[05:55] <kagou> i don't find error :/ where do i search from ?
[05:56] <kagou> acpid works, but i must launch it manually in a root sterm
[05:56] <kagou> s/sterm/xterm
[05:57] <thom> run "/etc/init.d/acpid stop;/etc/init.d/acpid start" on the terminal
[05:58] <thom> (as root)
[05:58] <thom> sudo -s first, if necessary
[05:59] <kagou> ok i have error on start
[05:59] <kagou>  * Unable to load module: toshiba_acpi
[06:00] <thom> confirm that you've got acpid 1.0.3-19ubuntu8 installed? (dpkg -l acpid)
[06:00] <kagou> yes
[06:01] <kagou> yes it is
[06:02] <thom> in /etc/defaults/acpid, change MODULES to 'MODULES="battery ac processor button fan thermal" '
[06:09] <thom> kagou: ok, fixed. just uploading
[06:10] <kagou> thom, it's ok
[06:10] <kagou> commented MODULES="all" and uncommented  MODULES="battery ac processor button fan thermal"
[06:11] <kagou> restart acpid by init script . It's ok
[06:14] <kagou> thom, please close this https://bugzilla.no-name-yet.com/show_bug.cgi?id=991
[06:17] <thom> no, that's a workaround, not a fix
[06:21] <mdz> thom: so in 886, you said it works fine in Warty, and then proposed syncing 3 packages? :-/
[06:25] <thom> mdz: i said it worked once recompiled. 
[06:26] <mdz> thom: yeah, so can't we just recompile it instead? ;-)
[06:27] <thom> mdz: we _can_, yes
[06:28] <mdz> thom: which packages did you recompile in your test?
[06:28] <thom> libapache2_mod_python2.3
[06:30] <npmccallum> mdz: we'll need to raise the kernel logging threshold to clean up the boot process, where does debian traditionally do that?
[06:30] <thom> mdz: ok. we _have_ to sync apache2. i strongly recommend that we sync subversion and php4 at the same time
[06:30] <thom> mod_python can probably just be recompiled after that sync
[06:31] <mdz> npmccallum: /etc/sysctl.conf
[06:33] <mdz> thom: the apache2 changelog scares the hell out of me
[06:35] <mdz> thom: why subversion and php4 at the same time?
[06:35] <thom> mdz: subversion relies on at least one of the changes in -11 (the sticky bit fix to apr)
[06:37] <thom> php4 has some serious issues which can be security/privacy related (the way session files are handled and GCd)
[06:37] <mdz> thom: all three of those seem to have ubuntu-specific versions
[06:40] <thom> mdz: the change in apache2 is the same as 2.0.50-8
[06:41] <thom> subversion is 1.0.5-1 in warty
[06:41] <mdz> subversion | 1.0.6-1.2ubuntu1 | http://ftp.no-name-yet.com warty/main Sources
[06:42] <mdz> arrgghh
[06:43] <mdz> who broke evolution again, right after I fixed it?
[06:43] <mdz> ubuntu-desktop is uninstallable again
[06:44] <Keybuk> seb
[06:44] <mdz> did we get one working daily in between?
[06:44] <Keybuk> new versions of evo are pretty much coming out hourly at the moment :-/
[06:46] <thom> mdz: i'm happy to sync across just the security related fixes, but i don't think that's a good option given that we can trivially sync the changes. 
[06:47] <mdz> thom: I think we need to break down the issues here...I didn't understand why we needed to sync new versions of 4 packages in order to fix something which was apparently rectified by recompiling libapache2-mod-python
[06:47] <mdz> thom: so apache2 needs security fixes
[06:48] <thom> ok. i shouldn't have conflated the two things
[06:48] <mdz> thom: libapache2-mod-python could be recompiled, but there's other stuff we want to sync?
[06:48] <thom> mod-python can be recompiled
[06:48] <mdz> thom: subversion  in sid seems to be identical, modulo changelog
[06:48] <mdz> and the build-dep we fixed for ubuntu
[06:49] <mdz> php4...*faints*
[06:49] <mdz> thom: yes, let's handle them one at a time
[06:50] <mdz> thom: let's do apache2 first; you want to request a sync?
[06:50] <mdz> I have to say I'm nervous about it
[06:51] <mdz> the entire -12 changelog sounds like stuff that is not needed for the warty release
[06:51] <Keybuk> mdz: looks like seb uploaded evo, and the new gtkhtml -- but the new gtkhtml packages aren't in ubuntu-desktop, the old ones are, and *of course* they conflict
[06:51] <mdz> seb128: can this be fixed today?  it's very important to me that our daily CD builds work at this point
[06:52] <seb128> what ?
[06:52] <mdz> The following packages have unmet dependencies:
[06:52] <mdz>   evolution-exchange: Depends: evolution1.5 (>= 1.5.93) but it is not installable
[06:53] <seb128> let me look why evolution1.5 is no installable
[06:53] <seb128> it should be
[06:53] <thom> mdz: ok. the issues are this. -11 fixes three security problems.
[06:53] <Keybuk> seb128: gtkhtml3.2 conflicts with gtkhtml3.1
[06:53] <Keybuk> the latter is in ubuntu-desktop, the former isn't
[06:53] <seb128> just drop 3.1 so and replaces it by 3.2
[06:53] <seb128> ok, just change the seed so
[06:53] <mdz> it's not a seed problem
[06:53] <seb128> what's the problem so ?
[06:53] <Keybuk> something's missing a Task: line ?
[06:53] <Keybuk> or is that done in overrides?
[06:54] <thom> CAN-2004-0748, CAN-2004-0751 and debian #266198
[06:54] <mdz> seb128: evolution1.5 and evolution-data-server cannot be installed simultaneously
[06:54] <seb128> mdz: gni ?
[06:54] <mdz> The following packages have unmet dependencies:
[06:54] <mdz>   evolution-data-server: Conflicts: evolution1.5 (< 1.5.94) but 1.5.93-1 is to be installed
[06:54] <mdz>   evolution1.5: Conflicts: evolution-data-server (>= 0.0.99) but 0.0.99-1ubuntu1 is to be installed
[06:54] <seb128> apt-cache policy evolution1.5 ?
[06:55] <thom> the latter is a fix to stop apr creating all directories with the sticky bit set
[06:55] <mdz>   Installed: 1.5.93-1
[06:55] <mdz>   Candidate: 1.5.93-1
[06:55] <seb128> http://ftp.no-name-yet.com/no-name-yet/pool/main/e/evolution1.5/evolution1.5_1.5.94.1-1ubuntu1_i386.deb
[06:55] <Keybuk> mdz: update ... evo 1.5.94.1-1ubuntu1 is in the archive right now
[06:55] <mdz> thom: I am 100% OK with those changes
[06:55] <seb128> mdz: I've uploaded all the piece in the same time this morning
[06:55] <mdz> ok, I guess I need an apt-get update
[06:56] <Keybuk> there does need to be a task change, and gtkhtml3.1 needs to be kicked into oblivion, I think that's an elmo problem though?
[06:56] <mdz> tasks are set in overrides
[06:57] <thom> mdz:  #264645 can be a denial of service. 
[06:57] <Keybuk> which reminds me, I have a "leaktraver" in the "c-dev" task in my list ... it's the only thing in it ... is that a bodge?
[06:58] <thom> oh, and -11 ensures mod_proxy works correctly.
[06:58] <thom> -12 is entirely trivial cleanups and correctness
[06:58] <mdz> thom: that's ok with me too
[06:58] <mdz> thom: I think I would in fact be OK with -11
[06:59] <mdz> thom: -12 is "gee, wouldn't it be nice to start messing with the default config files about now?"
[07:00] <thom> mdz: not sticlty true. it modifies the default site, and ensures that the documentation works
[07:00] <thom> the actual server config file is unchanged
[07:00] <seb128> mdz: seems to be fine for evolution here, do you still have some problem with an update ?
[07:01] <mdz> seb128: no, fine now
[07:01] <seb128> ok
[07:01] <mdz> looks like my last update was in the middle of your uploads
[07:01] <seb128> my uploads was about 6 hours ago
[07:01] <seb128> but time to get all built I guess
[07:01] <mdz> yes, that's about when my cron job runs
[07:01] <seb128> ok
[07:05] <thom> mdz: for php, i'm happy to recommend we just bring across the changes for session files
[07:05] <Kamion> mdz: today's daily worked, anyway
[07:05] <mdz> thom: by all means
[07:05] <mdz> thom: I'm going to eyeball the -12 changes
[07:05] <mdz> Kamion: oh, good
[07:06] <[Clint] > any amd64 news?
[07:06] <thom> ok
[07:06] <Kamion> I had an idea for working around the way base-config nukes stuff archive-copier has copied into the apt cache, in a slightly more pleasant way than before
[07:06] <Kamion> copy base .debs into /target/var/cache/apt/archives/, but copy non-base .debs into /target/var/cache/archive-copier/
[07:07] <Kamion> in base-config (after nuking the cache), move the contents of /var/cache/archive-copier/ to /var/cache/apt/archives/
[07:08] <Kamion> that way we don't need any messy debconf question propagation at all, and the cache ends up slightly smaller 'cos you can lose the contents of base
[07:08] <Kamion> (I have this about three-quarters implemented and am about to test it)
[07:09] <thom> npmccallum: please ensure that you have the dependencies on lsb-base correct when you upload init scripts
[07:09] <npmccallum> thom: please read the update I posted to your bug
[07:09] <npmccallum> thom: lsb-base is part of base
[07:10] <npmccallum> thom: all the sysvinit stuff depends on it
[07:10] <Keybuk> npmccallum: but file-rc doesn't ?
[07:10] <Kamion> you still need versioned dependencies if you're relying on new features of it
[07:10] <npmccallum> Kamion: I'll double check that
[07:11] <Kamion> the same goes for Essential packages in Debian
[07:11] <npmccallum> Keybuk: that is a bug, we can change that
[07:11] <thom> npmccallum: i have it installed. you haven't ensured that i have the correct version
[07:11] <thom> thus, you're breaking my system
[07:11] <thom> (and lots of other peoples)
[07:11] <Keybuk> it's always better to over-specify your dependencies than under-specify them
[07:13] <npmccallum> so what needs to be done? does each package with a script need to depend on a certain version of lsb-base (thats a lot of packages)? is there a better way to handle it?
[07:14] <Kamion> I think each one needs to depend, yes; we're trying to support upgrades as well as fresh installs
[07:14] <thom> if you're changing them all anyway, you can do the control file changes as you do it
[07:14] <npmccallum> thom: they're already all done is the problem
[07:16] <npmccallum> thom: though, I suppose we may be able to script it
[07:16] <Kamion> there're about a dozen done at the moment, aren't there?
[07:17] <Kamion> if you give me a list and the dependencies they need to have I can rattle through them fairly easily
[07:17] <npmccallum> and 21 in the queue
[07:20] <npmccallum> I'll script it
[07:22] <Kamion> (The best alternative I can think of, BTW, is to make it work even if lsb-base is totally missing; but I'm guessing that's too much work.)
[07:22] <npmccallum> Kamion: thats the whole reason why we created the lsb-base package (so its available in base)
[07:24] <Kamion> indeed
[07:24] <Kamion> there's a good reason for it to be in base outside of dependencies, though
[07:24] <npmccallum> yeah
[07:24] <Kamion> it means that the first reboot after installation does the same as all subsequent reboots
[07:26] <npmccallum> So what is the best way to handle the current situation?  Do all packages with initscripts need to depend on lsb-base?  Or is there a more central solution?
[07:27] <Kamion> they have to have a dependency on something that ensures that what they need is available; there's no way around that
[07:27] <npmccallum> thom: btw, the new initscripts uncovered a bug -- acpi-support loads before acpid.  however, acpid loads the modules for acpi, which acpi-support needs to grep the battery status
[07:28] <thom> ah, file a bug. i'll fix that
[07:28] <npmccallum> Kamion: ok, I'll have to wait until they all enter the archive before I can really script a fix
[07:29] <Kamion> I mean, the same goes for new features in coreutils or whatever; you don't have to depend on coreutils just because you need ls, but if you're using ls --new-funky-option then you need a versioned dependency
[07:29] <Kamion> (there was a slightly more sensible real-life example with rmdir a few years back)
[07:29] <Kamion> --ignore-fail-on-non-empty
[07:30] <mdz> thom: ok, if you're confident, let's do apache2 -12
[07:31] <mdz> thom: go ahead and send the request
[07:31] <npmccallum> thom: what email address do I assign it to?
[07:31] <npmccallum> thom: (the acpi-support bug)
[07:31] <thom> mdz: will do
[07:31] <thom> npmccallum: just put thom in the field, bugzilla will do the rest
[07:58] <mdz> thom: so do we know for certain what the breakage is with mod-python?  I thought we missed out on the ABI skew that Debian apache2 underwent
[07:59] <Kamion> gaaaah, the CD I just burnt had a ONE-BYTE mistake on it
[08:06] <thom> mdz: we did. 
[08:35] <mdz> npmccallum: is there a way to dump the hal properties for a specific device, similar to what you get in the "Advanced" tab in h-d-m, but from the command line or otherwise cut-and-pasteable?
[08:38] <npmccallum> mdz: there is, I just don't remember off the top of my head, let me check
[08:41] <npmccallum> mdz: lshal
[08:41] <mdz> npmccallum: ah, thanks
[08:42] <npmccallum> mdz: though, not for a specific device, but you can cut and paste
[08:42] <mdz> good enough
[08:48] <thom> mdz: i'll check into exactly what the breakage is on monday
[08:58] <npmccallum> Kamion: do the udebs need a depend on lsb-base too? (do they include an initscript?)
[09:15] <mdz> npmccallum: no, udebs don't have init scripts
[10:01] <debianist> howdy all
[10:01] <debianist> my first time here :)
[10:01] <thom> hi there
[10:01] <debianist> would like to know if testing the live cd give a good idea of the hd installed system
[10:02] <debianist> hi thim
[10:02] <debianist> thom
[10:02] <mdz> debianist: not really, at present
[10:02] <mdz> debianist: the live CD is quite out of date compared to the install CD
[10:02] <mdz> that should be rectified early next week
[10:03] <debianist> I see
[10:03] <pitti> mdz: regarding #996 (wow, does bug #1000 get a price?): what do you mean by "correct permissions on the device"?
[10:03] <debianist> there should be no problem installing ubuntu next to my alredy installed debian sid right ?
[10:03] <pitti> mdz: are the permissions of the root mountpoint wrong?
[10:03] <mdz> pitti: no, the permissions on the block device
[10:03] <mdz> pitti: they come up as root/disk 660
[10:04] <mdz> like other SCSI disks
[10:04] <mdz> but they should probably be plugdev or similar
[10:05] <pitti> mdz: hmm. Why should users write directly to the device?
[10:05] <pitti> mdz: shall they be able to create partitions?
[10:05] <npmccallum> mdz: I'm fixing the grub splash thing now (removing grub splash)
[10:05] <pitti> mdz: BTW, I just got a reply from hald upstream. He eventually adopted my changes :-)
[10:06] <npmccallum> mdz: however, there is a bug in the old package that makes update-grub be called *before* splash.xpm.gz is removed, therefore it doesn't update the config properly on removeal
[10:06] <mdz> pitti: hal should be able to poll it to notice when media is inserted
[10:06] <mdz> pitti: as it does for cdrom and floppy
[10:06] <npmccallum> mdz: please advise :)
[10:06] <pitti> mdz: ah! That is, the device needs to be in a group that hald also runs in, right?
[10:07] <mdz> npmccallum: hmm?  I thought the image was shipped as part of the ubuntu-artwork deb
[10:07] <mdz> and update-grub called in the postinst
[10:07] <mdz> pitti: correct
[10:07] <pitti> mdz: so pmount could change the group to plugdev?
[10:07] <pitti> mdz: okay, if that helps, I can do that. I cannot test it, though
[10:07] <npmccallum> mdz: yes, but we are removing grub-splsah
[10:07] <pitti> mdz: I have to upload a new version anyway to fix that mount point "permission denied" problem
[10:08] <mdz> npmccallum: if it is part of the deb, it will be removed during the unpack phase, and then when postinst runs it should be gone already
[10:08] <Keybuk> not quite true ...
[10:08] <npmccallum> mdz: I just tested it, and it didn't work on my system
[10:08] <pitti> Okay guys, weekend. I'm going to bed now. Have a nice weekend!
[10:08] <mdz> pitti: no, that would not fix the problem
[10:08] <Keybuk> but close enough :)
[10:08] <mdz> pitti: the devices are only readable by group disk
[10:08] <pitti> mdz: oh?
[10:08] <mdz> pitti: that needs to be fixed to be a different group, and then hal can be added to that group
[10:09] <mdz> pitti: I thought plugdev made sense, but it doesn't much matter. cdrom is just as good, though the name is misleading
[10:09] <pitti> mdz: but if pmount changes the group to plugdev and hald additionally runs in plugdev?
[10:09] <mdz> pitti: pmount will never be called unless hal can read the device
[10:09] <npmccallum> mdz: when ubuntu-artwork is upgraded, it *does* run update-grub, but before the splash file is removed, then it removes the splash file
[10:09] <npmccallum> mdz: the dangling referance to that file will cause grub to freak out
[10:10] <mdz> hold on, I'll look at the package
[10:10] <pitti> mdz: Argh. So this actually means that hald has to run in group disk? I would not like that because it means that hald could actually write to all disks
[10:10] <pitti> mdz: if we change the devices to group plugdev, this would be the job of udev, right?
[10:11] <mdz> npmccallum: hmm, didn't we talk about this already?
[10:11] <mdz> npmccallum: the way that ubuntu-artwork does its postinst/postrm is not correct
[10:11] <mdz> npmccallum: #501
[10:12] <mdz> npmccallum: you marked it fixed, but it doesn't look like the changes are in -14
[10:12] <npmccallum> mdz: argh, I'll get it fixed
[10:15] <mdz> npmccallum: added some notes to the bug with my thoughts; I thought I had already said more, but either I wrote it outside of bugzilla, or maybe commented on the wrong bug or something
[10:17] <pitti> mdz: so shall I try to modify udev to assign plugdev group to usb and firewire devices?
[10:17] <pitti> mdz: IDE and fixed SCSI devices should stay in disk, of course
[10:17] <mdz> pitti: can udev tell the difference?
[10:17] <mdz> I thought it might need to be done in hotplug
[10:18] <mdz> but either way, yes
[10:18] <jdub> holy crap
[10:18] <mdz> pitti: really, all removable scsi devices should be owned by cdrom or similar
[10:18] <mdz> oh, they are
[10:18] <jdub> npmccallum: hrm, ignore ubuntu-artwork bugs for the moment
[10:18] <mdz> pitti: yes, they don't show up as scsi removable
[10:18] <pitti> mdz: do you actually know a program that relies on the fact that devices are writeable by group disk?
[10:18] <mdz> pitti: they show up as scsi fixed disks (sd)
[10:18] <jdub> npmccallum: on my way towards uploading a substantially different package
[10:18] <mdz> pitti: no, I don't
[10:18] <pitti> mdz: maybe it is enough to just chmod the devices to 640
[10:19] <npmccallum> jdub: ok
[10:19] <pitti> mdz: then hald could run in group disk, could do media detection and even filesystem detection
[10:19] <mdz> jdub: does it incorporate #501?
[10:19] <pitti> mdz: I'll think over it and try that out. I report back on Monday.
[10:19] <npmccallum> jdub: I have plenty of other bugs to fix at the moment :)
[10:19] <pitti> Good night everybody!
[10:19] <mdz> pitti: I would email Kamion about it
[10:19] <pitti> mdz: I'll do
[10:20] <jdub> mdz: will do
[10:20] <mdz> pitti, jdub: thanks
[10:25] <npmccallum> mdz: portmap should start in S and stop in 0 and 6, but nothing else, correct?
[10:25] <mdz> npmccallum: that is what I suspect, but I urge you to find confirmation
[10:26] <npmccallum> mdz: the rules file is pretty funky regarding the initscript
[10:31] <mdz> npmccallum: portmap (5-2.2) unstable; urgency=low
[10:31] <mdz>   * Start portmap in runlevels 2 to 5, at priority 18. Also stop it for
[10:31] <mdz>     runlevel 1 before it is killed by `single'
[10:31] <mdz>     (closes: #159925, #216107, #60367, #93599, #101726, #130360).
[10:31] <debianist> is there a possibility to do hd install from the livecd and than upgrade?
[10:31] <mdz> debianist: no
[10:32] <debianist> ok, thanks mdz
[10:32] <npmccallum> mdz: yeah, I was just reading those actual bug reports
[10:32] <debianist> how's support for lowmem, lowend machine ?
[10:33] <debianist> i'd like to install it on a p4 512mb system, 256mb piii 800mhz system. and pi 100mhz 32mb 
[10:33] <npmccallum> mdz: basically we need a test to see if portmap is already running and then exit gracefully
[10:33] <debianist> 3 test machines
[10:33] <npmccallum> mdz: in the initscript itself
[10:33] <mdz> debianist: I would not recommend attempting GNOME with 32M
[10:33] <jdub> that's just going to bite
[10:33] <debianist> gnome is installed by default?
[10:33] <jdub> yes
[10:34] <debianist> oh, so server console only install is still not available?
[10:34] <npmccallum> mdz: is that resolution for portmap ok with you?
[10:34] <jdub> debianist: boot with 'custom' to do a minimal install
[10:34] <debianist> ok jdub, thanks 
[10:34] <jdub> debianist: where minimal == our large base of the good stuff :)
[10:35] <debianist> is there "tasks" to select from? or plain package lists?
[10:35] <jdub> nup
[10:35] <jdub> just custom and desktop
[10:35] <seb128_> jdub: hey
[10:35] <debianist> ok, that'll do for now :)
[10:35] <jdub> yoseb
[10:35] <seb128_> jdub: we want dynamic changes for the Documents place ?
[10:35] <jdub> seb128_: what changes?
[10:35] <seb128_> I've it working without dynamic changes for the moment (it tests at nautilus startup)
[10:36] <seb128_> show off on rmdir ~/Documents
[10:36] <mdz> npmccallum: I am not absolutely sure that it is correct for it not to start in 2-5
[10:36] <mdz> npmccallum: what did you find in those bug reports?
[10:36] <jdub> seb128_: oh, the special Documents icon in nautilus?
[10:36] <jdub> ugh
[10:36] <jdub> hrm
[10:36] <seb128_> jdub: yes, I've it working with test on nautilus startup and gconf key
[10:36] <mdz> jdub: Kamion implemented an undocumented option to just install base
[10:37] <mdz> jdub: preserving the rest of the install experience
[10:37] <jdub> mdz: yeah, booting with custom, that's what i suggested
[10:37] <seb128_> jdub: but dynamic changes according to the real fs need to monitor HOME all the time apparently
[10:37] <mdz> jdub: no, custom drops the debconf priority to low
[10:37] <jdub> seb128_: that's going to bite
[10:37] <mdz> oh, I lied
[10:37] <mdz> you're right, it's custom
[10:37] <npmccallum> mdz: I just added more info to the bug report
[10:37] <jdub> not that i've actually tried that
[10:38] <jdub> seb128_: oh man
[10:38] <jdub> seb128_: baby jesus is crying :|
[10:39] <Keybuk> and if $HOME/Documents is a mount-point, that wouldn't show up if $HOME was being monitored
[10:39] <Keybuk> *ducks and runs for cover* :p
[10:39] <mdz> aw, bug #1000 got snatched up by a bad bug report
[10:40] <debianist> what is the "testing" cd image for? (reading through the wiki)
[10:41] <mdz> debianist: that is the most recent milestone
[10:41] <mdz> I recommend the current daily, though
[10:45] <doko> seb128: I'm missing the "drawer" icon for nautilus (however there is an entry for its preferences)
[10:46] <doko> what kind of configuration interface does warty promote for dialin/internet access?
[10:46] <seb128> drawer icon ?
[10:47] <doko> well, nautilus with the tree view on the left side.
[10:47] <jdub> doko: network-admin (from gnome-system-tools)
[10:47] <jdub> mdz: which reminds me... wvdial...
[10:48] <seb128> jdub: I'm going to upload nautilus with the Documents place (check on startup and gconf key) for the moment
[10:48] <jdub> seb128: ok, thanks :)
[10:48] <seb128> I want to speak with alex about the dynamic stuff before doing more on this
[10:49] <debianist> ofcourse I'd use the daily ones, just wanted to know what kind of snapshot the "testing" represents, knowing form debian, "testing" is more of a code freeze, bug squashing in progress thingy :)
[10:49] <debianist> the tasks with "seeking cadidate" are open to Sounder members?
[10:49] <jdub> debianist: the sounder cds are just fortnightly builds we know will work
[10:50] <npmccallum> jdub: love the new wifi icon, but it makes me want to left click on it (like mac) :)
[10:50] <jdub> heh
[10:50] <jdub> needs to be in the gnome style though
[10:50] <npmccallum> jdub: I've actually already clicked on it like 3 times
[10:50] <npmccallum> jdub: I just mean I love the simplicity of it
[10:51] <jdub> yeah
[10:51] <seb128> npmccallum: what's a "pretty initscript" ? (ie: what are you changing in the script ?)
[10:51] <debianist> is there anyware on the wiki a "definition" for seed? as in group of packages etc?
[10:51] <npmccallum> seb128: all output in all initscripts is being change to use the output functions from /lib/lsb/init-functions
[10:51] <seb128> oh ok, the output
[10:52] <jdub> debianist: there should be, forget where though
[10:52] <jdub> debianist: a seed is a list of high-level package requirements we build the archive from
[10:52] <npmccallum> seb128: actually, I've secretly encoded picures of beautiful women into the initscript code ;)
[10:52] <debianist> jdub : like a list of dependencies?
[10:52] <seb128> npmccallum: cool :)
[10:54] <Keybuk> I suspect it isn't defined on the Wiki actually
[10:54] <jdub> debianist: essentially, yeah
[10:54] <debianist> ok, shall I through in the definition?
[10:54] <debianist> :)
[10:54] <jdub> debianist: looks like Keybuk is about to
[10:54] <debianist> ok, great
[10:54] <Keybuk> jdub: I'm trying to *find* the definition I wrote
[10:54] <debianist> send me the link keybuk
[10:54] <debianist> when you find it
[10:54] <Keybuk> apt-get install google
[10:54] <Keybuk> ^ if only
[10:55] <jdub> Keybuk: it'd be on Glossary
[10:55] <jdub> Keybuk: i know i wrote one there
[10:56] <Keybuk> jdub: I'm trying to find the one with mdz's l33t dot madness
[10:59] <debianist> now that seed thingy is an abstract notion, or is implemented into the code of the package management / task selection mechanism?
[10:59] <jdub> mostly abstract
[10:59] <jdub> though base defines what's always installed
[10:59] <jdub> desktop defines what's installed with the desktop
[10:59] <jdub> ship defines what's included on the cd as well as desktop
[11:00] <jdub> supported defines what's also in main, that we support
[11:01] <jdub> Kamion: custom install rocks
[11:01] <jdub> Kamion: intersting observation -> it asks for the at the end,
[11:02] <jdub> Kamion: but only to grab the package file or whatever,
[11:02] <jdub> Kamion: and then reconfigures postfix and that's it.
[11:02] <jdub> seems weird
[11:02] <jdub> but that's a daily from a few days ago in case anything's changed in the mean time
[11:03] <Keybuk> http://wiki.no-name-yet.com/SeedManagement
[11:03] <Keybuk> ^ try that
[11:04] <debianist> whaat are the plans regarding VPN support? think it's a good idea to add some network pptp config engine, to shiled users from writing pptp initiating scripts for the dialer oriented countries.
[11:04] <debianist> (that is, using VPN for adsl / cable broadband)
[11:04] <jdub> unknown at this stage
[11:04] <edd> hmm, doesn't the kernel need a patch for pptp for some MS feature?
[11:05] <debianist> i think so
[11:05] <debianist> am not sure
[11:05] <edd> i assume there are some reasons that that patch isn't in the mainline kernel
[11:06] <edd> pretty sure i had to do it for my 2.6.6 kernel
[11:06] <debianist> I had managed to install it using bf2.4 using a manually downloaded pptp updated package.
[11:07] <jdub> mako_: twat twat!
[11:08] <jdub> "Since two of my machines, and two of the hardest to rename, were already named after animals, I've decided to use animal names for the naming scheme. To keep it from being too generic, I'll use only mythical creatures for laptops, and test machines will be named after invertebrates."
[11:08] <debianist> anyway people, i'm headed to bed. good night all.
[11:09] <debianist> do add the seed definition, it may not be so trivial at starters.
[11:10] <debianist> there can be like, a terminology page on the wiki which explains the policy building block.
[11:10] <debianist> just a suggestion.
[11:10] <debianist> nighters
[11:10] <mako_> jdub: twat twat
[11:11] <jdub> http://lwn.net/Articles/100536/
[11:11] <jdub> ^ BLOOOOOOOB!
[11:12] <debianist> tabase had been converted and stored on the Linux hard disk as a collection of some 100,000 files. " !!!
[11:12] <debianist> :)
[11:21] <Kamion> mdz: custom-expert (name sucks, I know) is base-only and low priority, in case you ever need that
[11:22] <Kamion> jdub: yeah; I've been ignoring that 'cos the plan is to move that apt-cdrom add to the first stage and totally remove the requirement for the CD in the second stage
[11:22] <jdub> oh, goodie
[11:23] <jdub> would a custom install still do the package copy?
[11:23] <Kamion> I've just got the rest of archive-copier/base-config integration finished
[11:23] <Kamion> jdub: yes (at present, only if you boot with the relevant magic option)
[11:23] <Kamion> actually, you raise a good point there, I'll make it only copy Base
[11:24] <jdub> is it worth copying anything at all?
[11:24] <Kamion> debootstrap would do that anyway so it's just for CD-reading speed
[11:24] <jdub> oh, it happens before base install?
[11:24] <Kamion> yes
[11:24] <jdub> ahar!
[11:25] <jdub> Kamion: so now
[11:25] <jdub> Kamion: we should put all the deb files into a zip file
[11:26] <Kamion> hey, we could call it a .cab! :-P
[11:26] <jdub> :-)
[11:31] <Kamion> 2004-09-03 21:28:07 GMT Colin Watson <colin.watson@canonical.com>       patch-12
[11:31] <Kamion>     Summary:
[11:31] <Kamion>       Don't copy non-base packages in the custom install mode.
[11:31] <Kamion> there we go
[11:34] <mdz> Kamion: just trying an install with the current daily
[11:34] <mdz> default hostname came up different for some reason
[11:34] <mdz> maybe dhcp's fault
[11:34] <Kamion> or the seeding from DNS
[11:35] <Kamion> different how?
[11:35] <mdz> different as in previously it had been 'ubuntu'
[11:35] <mdz> and now it's 'andy'
[11:36] <Kamion> just lucky, I guess
[11:36] <Kamion> look at what the IP address reverse-lookups to?
[11:36] <mdz> yeah, it came from dhcp/dns
[11:36] <mdz> some stale dynamic record it looks like
[11:37] <jdub> oh, my desktop did that
[11:37] <jdub> i thought it was cool
[11:50] <Kamion> mdz: I think you're right that it's the directory ordering on the CD that's slowing things down
[11:50] <Kamion> 22115 18:18:26.680295 lstat64("/cdrom/pool/main/t/ttf-bangla-fonts/ttf-bangla-fonts_0.5-1_all.deb", {st_mode=S_IFREG|0444, st_size=263324, ...}) = 0
[11:50] <Kamion> 22115 18:18:26.946938 stat64("/target/var/cache/archive-copier/ttf-bangla-fonts_0.5-1_all.deb", 0x7ffffc00) = -1 ENOENT (No such file or directory)
[11:50] <Kamion> then the read is
[11:50] <Kamion> 22115 18:18:26.947502 read(6, "!<arch>\ndebian-binary   10910590"..., 8192) = 8192
[11:50] <mdz> I don't know that much about the layout of isofs
[11:50] <Kamion> 22115 18:18:27.248758 write(7, "!<arch>\ndebian-binary   10910590"..., 8192) = 8192
[11:50] <mdz> it could be that the directories are all stuffed into one part of the disc or something
[11:51] <Kamion> they appear to have their own extent numbers in the same number space as files
[11:51] <mdz> hmm
[11:51] <mdz> but the sort ordering in mkisofs doesn't seem to help?
[11:51] <mdz> or did you try that yet?
[11:51] <mdz> (ordering the directories explicitly I mean)
[11:51] <Kamion> haven't tried that yet, I wanted to get this profile data first
[11:51] <mdz> ah
[11:51] <Kamion> (insofar as timed strace qualifies as profile data)
[11:52] <Kamion> here's a better example
[11:52] <Kamion> 22135 18:18:30.488341 lstat64("/cdrom/pool/main/t/ttf-kochi/ttf-kochi-gothic_1.0.20030809-2_all.deb", {st_mode=S_IFREG|0444, st_size=4575814, ...}) = 0
[11:52] <Kamion> 22135 18:18:30.755166 stat64("/target/var/cache/archive-copier/ttf-kochi-gothic_1.0.20030809-2_all.deb", 0x7ffffc00) = -1 ENOENT (No such file or directory)
[11:52] <Kamion> 22140 18:18:33.799937 lstat64("/cdrom/pool/main/t/ttf-kochi/ttf-kochi-mincho_1.0.20030809-2_all.deb", {st_mode=S_IFREG|0444, st_size=5381872, ...}) = 0
[11:52] <Kamion> 22140 18:18:33.800093 stat64("/target/var/cache/archive-copier/ttf-kochi-mincho_1.0.20030809-2_all.deb", 0x7ffffc00) = -1 ENOENT (No such file or directory)
[11:52] <Kamion> observe the second stat in the same directory being much quicker
[11:52] <mdz> yeah
[11:52] <mdz> I can tell just from watching debootstrap run
[11:52] <Kamion> just wanted to make sure it wasn't an illusion
[11:52] <mdz> between libc6 and i686 the drive is quiet and fast
[11:52] <mdz> libc6 and libc6-i686 I mean
[11:53] <mdz> but with two tiny debs from different source packages there are a couple of loud seeks and it's much slower
[11:54] <mdz> Kamion: what should we do about archive-copier vs. apt-cdrom?
[11:54] <mdz> is it at all reasonable to run apt-cdrom before the reboot?
[11:54] <Kamion> I have plans for that that involve running apt-cdrom from prebaseconfig
[11:54] <mdz> ah, ok
[11:55] <Kamion> probably apt-setup, in fact
[11:55] <Kamion> just need to figure out the details of that; I could borrow code from baseconfig-udeb, perhaps
[11:55] <Kamion> hope to get all that finished by the next Sounder release
[11:56] <Kamion> hm, annoyingly debian-cd's .filelist_* files don't have a / at the end of directories, so it's kind of hard to test directory vs. file
[11:56] <mdz> the one on Monday? or the following one?
[11:56] <mdz> hmm, the following one would be the Preview :-)
[11:56] <Kamion> this Monday
[11:56] <Kamion> depends whether I work at the weekend though :)
[11:57] <jdub> it's 8am saturday here :-)
[11:57] <jdub> but i am a glutton for punishment
[11:57] <jdub> actually, it's really weird - i've been keeping sane hours in my local timezone
[11:57] <Hrdwr_BoB> 8am saturday is an evil time
[11:58] <Hrdwr_BoB> I should be in the snow, but instead I'm here working
[11:59] <Kamion> Hrdwr_BoB: the snow? what country are you in?
[11:59] <Hrdwr_BoB> Kamion: AU
[11:59] <Kamion> duh, yeah, /whois would've told me that one
[12:00] <Hrdwr_BoB> :)