[12:01] <jdub> seb128: yes, thanks
[12:01] <seb128> np
[12:01] <jdub> check if they're sane, of course ;)
[12:01] <jdub> but the current releases look ok
[12:02] <seb128> jdub: ah, and a guy asked for a gmane archive of ubuntu-fr, I guess that's ok ? :)
[12:02] <seb128> don't worry, for big package I run them one day one my box before uploading most of the time
[12:02] <seb128> or at least time to reboot and make basic tests
[12:02] <jdub> seb128: i think it's already on gmane
[12:02] <jdub> some dude mailed me to say some of the posts were missing ;)
[12:02] <seb128> oh, ok, cool :)
[12:03] <seb128> 37 people on the -fr list, that's a good start :)
[12:10] <jdub> cool
[12:10] <jdub> you are beating spain and germany ;)
[12:13] <seb128> he he
[12:32] <mdz> Kamion: still here?
[12:38] <lamont> T-Bone: you modify the source...
[12:39] <T-Bone> this is what i did, eventually ;)
[12:39] <T-Bone> unfortunately gcc takes _time_ to build
[12:47] <lamont> but build deps get dealt with early...
[12:48] <lamont> Rejected: file 'linux-686-smp_2.6.8.1-10_i386.deb' has invalid priority 'restricted/optional' [contains '/'] .
[12:48] <lamont> sigh
[12:49] <Kamion> mdz: current daily is candidate
[12:50] <mdz> Kamion: ok, I'll download and test
[12:50] <Kamion> you can probably make amd64 your bottom priority, I've tested that
[12:54] <mdz> lamont: can you and/or elmo arrange for those messages to go someplace useful?
[12:55] <lamont> mdz: will do
[12:55] <mdz> lamont: warty-changes should be a reasonable place
[12:56] <lamont> you want all REJECT mail to go there?
[12:56] <mdz> yes, unless there's a bunch of spam I don't know about
[01:03] <Kamion> hm, WinXP boots for me after installing Ubuntu
[01:03] <lamont> mdz: all katie mail that would have gone direct to me now goes to warty-changes.
[01:05] <mdz> lamont: thanks much
[01:05] <mdz> lamont: new linux-meta happier?
[01:06] <jdub> WHOA NEW EXCITING KERNEL TO INSTALL
[01:07] <lamont> mdz: give it 2.6 minutes.
[01:07] <mdz> jdub: new exciting sounder CD candidate to test
[01:07] <lamont> either warty-changes should get the reject mail shortly after 16:10 your time,
[01:07] <jdub> sweeet
[01:07] <Kamion> i386 WFM
[01:07] <lamont> or the new linux-meta -11 package will hit the archive at 16:33
[01:08] <mdz> ran out of disk space, restarted rsync
[01:08] <Kamion> heh
[01:08] <Kamion> disk is cheap :)
[01:08] <mdz> yeah, but adding disks is not
[01:09] <Kamion> just testing daily+new-parted for good measure, even though I can't reproduce the problem with old-parted
[01:09] <mdz> all my disk is being eaten by mythtv
[01:09] <jdub> mdz: btw, what's the status of mythtv in sid or universe?
[01:09] <Kamion> Free  PE / Size       14499 / 56.64 GB
[01:09] <jdub> Kamion: what was the package update cutoff point for the new sounder?
[01:10] <azeem> did you guys see the latest gnoppix announcement?
[01:10] <mdz> jdub: waiting for elmo to bring in lame
[01:10] <Kamion> jdub: about 1300 GMT or something
[01:10] <azeem> "You'll find a new 0.8.1beta ( codename Ubuntu ) with bugfixes and Gnome 2.8 at: ftp://194.94.72.226/linux/gnoppix/gnoppix_0.8.1b4.iso"
[01:10] <jdub> mdz: "oh."
[01:10] <jdub> azeem: haha
[01:10] <jdub> Kamion: cool, ta
[01:11] <jdub> mdz: so the non-free universe is still going to be called 'multiverse'?
[01:11] <jdub> we *so* need livecds for testing :|
[01:11] <jdub> mdz: i punted alex bugging to you, btw.
[01:11] <mdz> jdub: noticed, followed up
[01:12] <jdub> cool
[01:12] <azeem> perhaps gnoppix is the first case of a CUD, as opposed to CDDs
[01:12] <jdub> azeem: it is all in the CDD family :)
[01:12] <Kamion> jdub: actually later than that
[01:12] <Kamion> cjwatson@little:~$ head -n 2 cdimage/log/daily-20040928.1.log
[01:12] <Kamion> [01:12] <Kamion> Tue Sep 28 15:55:48 BST 2004
[01:12] <jdub> azeem: but yes, CUD explosion is very much in the plans ;)
[01:13] <azeem> I talked to amu about gnoppix for quite a while at LinuxTag, and he said they entirely repackage GNOME for gnoppix. Perhaps now with ubuntu he finally got driven to sanity :)
[01:15] <mdz> mako: will there be an ubuntu traffic coming soon?
[01:21] <mdz> Kamion: what do you think we should do about #1608 (some CD-ROM drives screw up DMA)?
[01:22] <mdz> Kamion: disabling DMA on all CD-ROM drives seems awfully heavy-handed, but it's simple and safe to implement
[01:22] <Kamion> there was a bug in Debian about this ...
[01:22] <Kamion> I think
[01:22] <Kamion>   * Osamu Aoki
[01:22] <Kamion>     - When CD mount fails, unmount it and try again, to work around DMA
[01:22] <Kamion>       issues. Closes: #255128
[01:23] <Kamion> that was an error on mount, though
[01:24] <sabdfl> Kamion: ok, nothing in the syslog about firmware loading
[01:25] <Kamion> mdz: killing DMA on failure works for me, don't like the idea of doing it unconditionally
[01:26] <Kamion> sabdfl: have you run the hw-detect stage yet?
[01:27] <sabdfl> Kamion: interesting, detect hardware comes after configure network
[01:27] <sabdfl> but even after jumping through it, nothing about the firmware load
[01:28] <Kamion> sabdfl: um ... configure the network definitely has a higher menu-item-number than detect network hardware
[01:29] <Kamion> sabdfl: ok, well, it was untested code, guess it doesn't quite work :-/
[01:29] <Kamion> mdz: didn't you have an ipw2100 you could play with too?
[01:30] <sabdfl> T-Bone: wow, good progress?
[01:30] <sabdfl> Kamion: on my system it is showing:
[01:30] <sabdfl> ...
[01:30] <sabdfl> Load installer components from CD
[01:31] <sabdfl> Detect network hardware
[01:31] <sabdfl> Configure the network
[01:31] <Kamion> that's not what you said above ...
[01:31] <Kamion> 00:27 < sabdfl> Kamion: interesting, detect hardware comes after configure network
[01:31] <sabdfl> then
[01:31] <sabdfl> Detect hardware
[01:31] <Kamion> oh, that's detect disks
[01:31] <sabdfl> nice :-)
[01:32] <sabdfl> "configure the network" shows the wifi card
[01:32] <Kamion> should fix the string there
[01:32] <Kamion> Template: debian-installer/hw-detect-full/title
[01:32] <Kamion> Type: text
[01:32] <Kamion> #  Main menu item
[01:32] <Kamion> _Description: Detect hardware
[01:32] <sabdfl> but it doesn't seem to work
[01:32] <sabdfl> still, it's not screaming spam log messages :-)
[01:33] <sabdfl> to console
[01:33] <T-Bone> sabdfl: i'll post the m-l as soon as i start "stage2" (ie: building warty main against warty binaries, stage1 was building warty main against debian binaries)
[01:33] <T-Bone> sabdfl: this should hopefully happen tomorrow
[01:33] <sabdfl> awesome
[01:34] <Kamion> sabdfl: guess it just egregiously failed to load firmware then. does that machine have PCMCIA?
[01:34] <sabdfl> yes
[01:34] <sabdfl> can i force a firmware load?
[01:34] <Kamion> I hacked the firmware loading stuff onto the side of PCMCIA, which is kind of broken but I figured would work for now
[01:34] <mdz> Kamion: I have only a 2200
[01:34] <Kamion> not sure; mdz, do you know?
[01:34] <Kamion> mdz: that would do
[01:35] <mdz> Kamion: I'm not sure that there's a condition we can detect to automatically disable DMA
[01:35] <T-Bone> sabdfl: another that should happen soon is my beginning to work on the installer for ia64. probably before the end of the week, or in the worst case next week
[01:35] <mdz> you can force a firmware load by loading the driver
[01:35] <T-Bone> +thing
[01:35] <Kamion> chinstrap:~cjwatson/warty-i386-hacked.iso if you want to give this a go, no firmware on that image so you'll have to bring it in by USB stick or whatever
[01:35] <sabdfl> mdz: already did that, but nothing showed up in syslog
[01:35] <Kamion> T-Bone: give me a shout if you need help, some ia64 love with the Ubuntu customizations will be needed
[01:36] <T-Bone> Kamion: that's noted, and I will undoubtly bother you alot ;)
[01:36] <mdz> sabdfl: it doesn't log anything when it's successful
[01:36] <Kamion> mdz: it so does
[01:36] <mdz> mine doesn't
[01:36] <Kamion>                         log "Firmware for $FIRMWARE loaded successfully."
[01:36] <Kamion> mdz: it does in d-i
[01:37] <T-Bone> sabdfl: side note, i've started "for fun" an hppa builder. But that's "for fun". For now ;)
[01:37] <Kamion> sabdfl: what's in /proc/sys/kernel/hotplug at the moment?
[01:37] <mdz> Kamion: oh, that
[01:37] <mdz> I'm pretty sure it loads the firmware every time the ipw2200 module is loaded
[01:38] <sabdfl> it says /sbin/hotplug
[01:38] <mdz> aha
[01:38] <mdz> shouldn't that be /sbin/hotplug-special-d-i-variant?
[01:39] <sabdfl> which doesn't exist
[01:39] <mdz> I think it's hotplug-pcmcia
[01:39] <sabdfl> neither of those exist
[01:39] <Kamion> the special d-i variant is /bin/hotplug-pcmcia, and that's only loaded for brief periods while the PCMCIA queue is run
[01:39] <Kamion> I think that's probably the bug
[01:39] <sabdfl> can i reset that and try to reload the driver?
[01:39] <Kamion> there's no rmmod in d-i, you'd have to reboot
[01:40] <mdz> ewww
[01:40] <sabdfl> oooookkkkkkk
[01:40] <T-Bone> that's probably the biggest pain in d-i, actually
[01:40] <sabdfl> i really need to spend some face time with my launchpad code
[01:40] <Kamion> sabdfl: after reboot, you could try copying /bin/hotplug-pcmcia to /sbin/hotplug and removing the non-firmware parts (since I think those will have unintended side-effects if run with non-PCMCIA)
[01:42] <Kamion> sorry for awkwardness, will clean it up once an approach has been demonstrated to work
[01:43] <mdz> Kamion: I did this experiment a while back; it does work
[01:44] <mdz> if I poked all the bits in the right places, the firmware was loaded
[01:44] <Kamion> mdz: in d-i?
[01:44] <mdz> Kamion: yes
[01:44] <Kamion> mdz: is your ipw2200 card PCMCIA?
[01:44] <mdz> Kamion: no
[01:44] <mdz> miniPCI
[01:44] <Kamion> mdz: then you must have had to set up /sbin/hotplug?
[01:44] <Kamion> or possibly make /bin/hotplug-pcmcia the hotplug handler temporarily
[01:45] <mdz> Kamion: I did echo /bin/hotplug-pcmcia > /proc/sys/kernel/hotplug or whatever
[01:45] <Kamion> aha
[01:45] <mdz> that was one of the bits that needed poking :-)
[01:46] <Kamion> how about I create a hotplug-misc which sits in /sbin/hotplug for the rest of the time, then?
[01:46] <Kamion> we don't have time to port proper hotplug now, will be doing that for hoary
[01:48] <mdz> sounds fine to me
[01:49] <sabdfl> what are the non-standard firmware parts
[01:49] <Kamion> patch is trivial, I'll upload if there are no objections
[01:49] <Kamion> non-standard?
[01:50] <sabdfl> your comment above... remove the "non-firmware parts"....
[01:50] <sabdfl> sorry, not non-standard, non-firmware
[01:50] <sabdfl> so i've got the firmware in /lib/firmware and /usr/lib/hotplug/firmware for good measure
[01:50] <Kamion> network events and cardbus events
[01:50] <mdz> Kamion: is #1586 RC for Warty?
[01:51] <sabdfl> i've echo >/bin/hotplug-pcmcia /procy/sys/kernel/hotplug
[01:51] <mdz> Kamion: no objections to having an /sbin/hotplug
[01:51] <jdub> Kamion: sounder + current daily are the same today?
[01:51] <Kamion> mdz: it's RC for me to look at it at the very least
[01:51] <sabdfl> now can i just modprobe the ipw2200?
[01:51] <Kamion> I just haven't had time :(
[01:51] <sabdfl> what about the depmod?
[01:51] <Kamion> if modprobe doesn't work then depmod ...
[01:52] <Kamion> the build was hacked-up, hopefully shouldn't act that way if built normally
[01:52] <sabdfl> FATAL: module ipw2200 not found
[01:52] <Kamion> jdub: aye, not that I've actually blessed S9 yet
[01:52] <sabdfl> ok, now:
[01:52] <Kamion> burning powerpc now, I've tested the others
[01:52] <sabdfl> hotplug pcmcia says it detected pcmcia network interface eth0
[01:53] <sabdfl> then ieee80211_crypt gets loaded
[01:53] <sabdfl> then the driver comes on stream
[01:53] <sabdfl> but says nothing about firmware being loaded
[01:53] <sabdfl> ah, hold on this is interesting
[01:53] <Kamion> 00:51 < sabdfl> i've echo >/bin/hotplug-pcmcia /procy/sys/kernel/hotplug
[01:53] <sabdfl> if i dmesg i see a message at the end:
[01:54] <Kamion> hope the position of the > there was a typo
[01:54] <sabdfl> Kamion: yes it was, that's all correct afaics
[01:54] <Kamion> ok
[01:54] <sabdfl> but listen to this
[01:54] <jdub> Kamion: cool, thanks
[01:54] <sabdfl> it says "Radio frequency kill switch is on"
[01:54] <sabdfl> which was also in the syslog
[01:54] <sabdfl> then it says:
[01:55] <sabdfl> Kill switch must be turned off for wireless networking to work"
[01:55] <sabdfl> hmm
[01:55] <mdz> that'll be the wifi button/switch on the laptop somewhere
[01:55] <Kamion> +To determine if you have such a switch, you can check the contents of:
[01:55] <Kamion> +
[01:55] <Kamion> +       /proc/net/ipw2100/eth1/state
[01:56] <sabdfl> i don't have /proc/net/ipw2100
[01:56] <sabdfl> this is a 2200
[01:56] <Kamion> probably same difference
[01:57] <hazmat> is there a formal mechanism to suggesting a package for inclusion in ubuntu?
[01:58] <Kamion> or maybe not, the ipw2200 driver's /proc-handling code seems different, oh well
[01:58] <lamont> Kamion: is there an option to debootstrap to tell it that the archive is not in a {dists,pool} form?
[01:58] <mdz> hazmat: email to ubuntu-devel
[01:58] <hazmat> okay.. thanks.
[01:59] <Kamion> lamont: debootstrap couldn't care less about pool, it uses Filename: fields
[01:59] <lamont> it cares about Release, though. :-(
[01:59] <Kamion> lamont: it does indelibly want dists/$SUITE/Release
[02:00] <lamont> which needs to have the packages md5sums?
[02:00] <Kamion> and dists/$SUITE/$COMPONENT/binary-$ARCH/Packages*
[02:00] <Kamion> right
[02:00] <lamont> ok
[02:00] <Kamion> I usually just fill the right values into the Release file from whatever CD image I have handy
[02:01] <mdz> sabdfl: /sys/bus/pci/devices/xxxx/rf_kill
[02:01] <mdz> seems like the right place
[02:01] <sabdfl> mdz: just found it too
[02:01] <sabdfl> using the fn-f8 sequence doesn't seem to affect that
[02:01] <Kamion> 00:51  * joeyh notices we just got ntfsresize support
[02:01] <mdz> nice
[02:02] <sabdfl> BUT i can echo 1 > /sys/..../rf_kill
[02:02] <sabdfl> or vice versa
[02:02] <sabdfl> will play with that
[02:03] <mdz> I don't think my laptop has a switch; the sysfs flie says 0
[02:03] <mdz> several of the test laptops in oxford had switches
[02:03] <mdz> some of them in unlikely places
[02:08] <mdz> Kamion: I think we need to change the default sources.list again
[02:08] <mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=1469
[02:08] <mdz> should have one line with main and restricted
[02:08] <mdz> and then another line, commented out, with only universe
[02:08] <Kamion> I thought I already fixed that
[02:09] <mdz> oh?
[02:09] <mdz> I'll find out soon, doing a new install
[02:09] <Kamion> it was part of the universe changes a couple of days ago
[02:09] <Kamion>   * Remove 'main restricted' from the universe line, so people don't end up
[02:09] <Kamion>     with duplicate sources.list entries.
[02:10] <sabdfl> cunnin
[02:10] <sabdfl> g
[02:10] <sabdfl> the switch was well hidden, in the off position
[02:10] <sabdfl> WELL hidden
[02:11] <sabdfl> Kamion: please could you file a bug to detect those rf-kill switch situations, and alert the user, because i *bet* a lot get bitten by that
[02:11] <mdz> Kamion: oh, ok
[02:11] <mdz> you even updated the bug
[02:11] <mdz> oh, you did that just now. cheat :-)
[02:11] <Kamion> yes :)
[02:11] <lamont> sabdfl: if you configure postfix, edit main.cf, and say 'dpkg-reconfigure postfix', do you (a) expect it to overwrite your changes, or (b) preserve them? (for questions that we ask in configure, that is)
[02:11] <Kamion> sabdfl: ok
[02:12] <sabdfl> lamont: it's too late for me to give you a reliable answer to that :-)
[02:12] <lamont> sabdfl: ok.  something to ponder in the morning then?
[02:13] <sabdfl> perhaps it should figure out you've made changes, offer to (a) show you a diff, (b) forget about it, (c) forge ahead
[02:13] <sabdfl> and backup the old config?
[02:13] <lamont> today we preserve them.  which is why postfix is broken (see 1711)
[02:13] <Kamion> sabdfl: sounds like ucf
[02:13] <lamont> that'd be ucf
[02:14] <lamont> what postfix actually does is to set the defaults to what you have configured currently.
[02:14] <lamont> so that hitting return all the way through produces no change.
[02:14] <sabdfl> that's pretty neat
[02:14] <lamont> and then debconf and base-config run: debconf does the wrong things because we haven't set things up yet, and base-config does nothing because the defaults are all what you said in debootstrap  time...
[02:15] <mdz> elmo: PowerEdge 2650 is on the HardwareSupport page, but without a comment about whether it worked.  did it?
[02:15] <mdz> elmo: we have a success report from a user on one
[02:15] <lamont> sabdfl: neat, but breaks ubuntu install of postfix
[02:15] <jdub> http://www.es.gnome.org/~telemaco/
[02:15] <jdub> ^ :-)
[02:16] <Kamion> lamont: the debconf/debootstrap fix would work around this, AIUI ...
[02:16] <Kamion> I worked out the problem with my earlier change after talking to joeyh; I'd just implemented noninteractive multiselect wrong
[02:16] <lamont> ah, ok.  that was the default vs seen thing?
[02:17] <Kamion> trying to get debconf to set the seen flag on questions that would be asked if the frontend weren't noninteractive
[02:17] <Kamion> my earlier fix caused all systems to have the aa_DJ locale configured
[02:17] <Kamion> didn't upload that one :)
[02:18] <sabdfl> WOOHOOO!
[02:18] <sabdfl> custom install just went all the way through with wifi on ipw2200 and just worked
[02:19] <lamont> Kamion: it would be nice if debootstrap would accept Packages.gz in place of Packages. :-(
[02:19] <mdz> messages read in 2004-08: 6288, messages read so far in 2004-09: 13296
[02:19] <sabdfl> actually, that's fnny
[02:19] <mdz> I was wondering why it took mutt so much longer than usual to open this month's read-mail folder
[02:19] <sabdfl> during the pre-boot it configure eth0 (wired)
[02:19] <sabdfl> then it rebooted, and ifup'd the wifi
[02:19] <sabdfl> which Just Worked
[02:19] <mdz> sabdfl: I guess you got lucky and the ipw2200 is later on the pci bus
[02:20] <sabdfl> no, it's earlier
[02:20] <mdz> really?
[02:20] <mako> mdz: it's almost done
[02:20] <mako> mdz: UT taht is
[02:20] <sabdfl> pre-boot, it didn't detect it, and configured eth0 (wired) for dhcp
[02:20] <lamont> mdz: where'd you get that stat?
[02:20] <mdz> mako: cool, that's a ton of mail to process
[02:20] <mdz> lamont: bzgrep -c '^From '
[02:20] <lamont> heh
[02:20] <mako> ~17k messages :)
[02:20] <sabdfl> then post-boot, the kernel finds ipw2200 and makes that eth0
[02:20] <sabdfl> but now, with the rf_kill switch on, it actually boots
[02:21] <mdz> oh, heh
[02:21] <sabdfl> so the solution to the bug is turn off the rf_kill, or turn on the radio
[02:21] <mdz> so it wrote a config for eth0 for the wired net
[02:21] <mdz> and then used that config for the wireless?
[02:21] <sabdfl> yes
[02:21] <sabdfl> which just worked
[02:21] <mako> the friday-friday stat is 17k
[02:21] <mako> it's picked up
[02:21] <sabdfl> interestingly it doesn't need the essid
[02:21] <mdz> mako: 17k what?
[02:21] <sabdfl> it seems to just go with the closest / best ap
[02:21] <sabdfl> dhcp
[02:21] <sabdfl> and go
[02:21] <mako> ergh.. 1.7k
[02:21] <mdz> sabdfl: the 0.8 driver grabs whatever has the strongest signal if it's set to scan
[02:21] <mako> decimal error
[02:22] <sabdfl> hmm...
[02:22] <mako> 1.7k mesasges
[02:22] <sabdfl> i'll update the bug,and file upstream
[02:22] <sabdfl> holy crap you guys need a more time-efficient sabdfl
[02:22] <Kamion> sabdfl: kill-switch bug is #1877
[02:23] <sabdfl> i can't belive i spent two whole nights on this at this stage :-)
[02:23] <mako> sabdfl: i'm just going through user now and picking up the last few threads i flagged for possible inclusion
[02:23] <mako> ergh.. for mdz
[02:23] <sabdfl> but it feels good to find the bug ;-)
[02:23] <sabdfl> possible inclusion?
[02:23] <mako> sabdfl: don't worry about it, it was misdirected
[02:23] <sabdfl> mako: btw, thanks for the lurker tip
[02:24] <sabdfl> http://lists.ubuntu.com/lurker/
[02:24] <mako> awesome
[02:27] <mdz> sometimes I want to strangle the genius at apple who eliminated the cd-rom eject button
[02:27] <mdz> the system is powered off, and I want to boot it from CD
[02:28] <mdz> I have to boot it up, software-eject the CD, and then reboot it
[02:28] <m_tthew> mdz: or have the always-useful paperclip handy.
[02:29] <Kamion> you mean you want to boot it from a different CD from the one already in the drive?
[02:29] <mdz> m_tthew: they even put a door in front of the thing, making the hole difficult to get to (it's below the lip)
[02:29] <mdz> Kamion: the drive is empty, and I want to put in a CD and boot from it
[02:29] <Kamion> oh your drive isn't slot-loading
[02:29] <mdz> correct
[02:29] <Kamion> mdz: try 'eject cd' in Open Firmware
[02:29] <mdz> it's a tray with a door in front of it
[02:30] <m_tthew> mdz: a door? ugh
[02:30] <mdz> ah, I'll keep that in mind next time
[02:30] <Kamion> then mac-boot
[02:30] <Kamion> never tried this myself but it's what the net claims
[02:30] <jdub> is ndiswrapper in the current -3 kernel?
[02:31] <Kamion> mdz: one rumour claims holding down the left mouse button during boot also ejects the CD ...
[02:31] <mdz> ooh, DMA is working on the hard disk now
[02:32] <mdz> I didn't think that was working before
[02:32] <sabdfl> bummer
[02:32] <mdz> jdub: yes it is
[02:32] <sabdfl> mdz: you won't believe this
[02:32] <sabdfl> with hotplug setup, and the firmware there
[02:32] <sabdfl> the installer sees the wifi and lets you use it
[02:32] <Kamion> hey, warty-powerpc.iso burnt, time to reboot and try this stuff out myself
[02:32] <sabdfl> but it configures it as eth1
[02:32] <mdz> Kamion: i386 and powerpc in progress now
[02:32] <sabdfl> i suspect, after reboot, it will be eth0
[02:32] <sabdfl> why?
[02:33] <mdz> discover vs. hotplug
[02:33] <sabdfl> could it be because discover ran first?
[02:33] <sabdfl> argh.
[02:33] <mdz> discover must scan in a different order
[02:33] <mdz> maybe even exactly the reverse; wouldn't that just be grand?
[02:34] <sabdfl> well, discover goes first, doesn't find the wifi
[02:34] <mdz> sabdfl: give it a try; it really should preserve them
[02:34] <sabdfl> then hotplug could go, and find it
[02:34] <sabdfl> ifrename?
[02:34] <mdz> if they're both detected in the installer, ifrename should be able to do its job
[02:34] <sabdfl> ok
[02:34] <mdz> check that they're both in /target/etc/iftab
[02:34] <sabdfl> kamion, this is looking good to me (hotplug)
[02:34] <sabdfl> mdz: yes
[02:35] <mdz> hmm, so let's just switch d-i over to use hotplug exclusively, shall we?
[02:35] <sabdfl> mdz: you can stay. you've clearly got the cohones for the position :-)
[02:36] <sabdfl> mdz: (also, you're ifrename magic seems good so far, they are both in there)
[02:36] <mdz> in theory, when hotplug finds them after the reboot, it'll look in that file and switch the name before bringing it up
[02:36] <mdz> so it'll find the wifi first, but call it eth1, then find the wired and name it eth0
[02:36] <sabdfl> we'll see in about 15 minutes :-)
[02:36] <mdz> this may be the first valid test of that code, ever :-)
[02:37] <mdz> that was an "oh, look, all the bits are already there, we just need to write iftab and it'll work" sort of job
[02:37] <sabdfl> so if it works this time, we ship it?
[02:37] <sabdfl> duck
[02:37] <sabdfl> well it wrote iftab
[02:37] <mdz> i386 stage 1 successful
[02:40] <mdz> gah, 12M of updates on top of the daily CD already
[02:43] <sabdfl> mdz: do you know which was the bug i filed on the ipw200 loop of death? can't find it
[02:43] <sabdfl> Kamion: final dialo pre-boot still says "Finishing the installation"
[02:44] <sabdfl> can it say "Rebooting to finish installation"?
[02:44] <mdz> sabdfl: #1751
[02:45] <sabdfl> mdz: thanks
[02:45] <mdz> jdub: can I get the name and address of the person who tied gnome-system-tools to wvdial, so I can send them a lump of coal?
[02:52] <jdub> heh
[02:52] <jdub> you trying to untie them?
[02:57] <tseng> hi
[02:57] <jdub> yo tseng 
[03:17] <Kamion> sabdfl: all depends how many translations you want to trash :)
[03:17] <Kamion> sabdfl: but sure, can do
[03:17] <Kamion> mdz: powerpc worked for me, xresprobe apparently hung solid on i386 ...
[03:18] <Kamion> suspect it's specific to that machine, it's one of the Vias
[03:19] <Kamion> mdz: incidentally that hold-down-left-mouse-button-during-boot-to-eject-CD trick worked for me too
[03:20] <mdz> Kamion: I tried it during the reboot for stage 2, but either I was too late, too early, or it didn't work
[03:20] <Kamion> mdz: shout if i386 works for you
 Kamion: i386 install is a success
 Kamion: powerpc as well
[03:20] <Kamion> mdz: it's at the same time as you would have to hold down 'c' to boot from CD
[03:21] <mdz> I'm never sure exactly when that time is, since my monitor switches on and off a few times during the boot and I can't see anything
[03:21] <mdz> I just hold it down forever
[03:21] <mdz> I usually end up with about 3 'c's at the prompt by the time I can see again
[03:22] <jdub> whoa, keymap question
[03:23] <Kamion> for me there's a clear moment when it switches from black screen to white and starts reading the CD
[03:23] <jdub> at least ppp is out, that keeps us below quota
[03:23] <Kamion> jdub: arch, CD date?
[03:23] <jdub> i386, today
[03:23] <Kamion> oh, you mean in the first stage?
[03:23] <jdub> yeah
[03:23] <Kamion> yes, that was deliberate
[03:23] <Kamion> good, thought you were talking about a bug :)
[03:24] <Kamion> yes, 'xresprobe via' hangs
[03:24] <Kamion> I'll file a bug and ship anyway, seems chipset-specific
[03:24] <mdz> Kamion: hangs during which bit?
[03:24] <Kamion> mdz: can't tell, it blanks the screen and leaves the system inaccessible
[03:24] <mdz> Kamion: oh, _that_ sort of hang :-)
[03:25] <Kamion> the fatal kind :)
[03:25] <mdz> must be while it's starting the X server
[03:32] <mako> mdz: around?
[03:32] <mdz> mako: yep
[03:33] <mako> can you clarify the conclusion of the universe multiverse thing from the meeting?
[03:33] <mako> i think i have it but want to make sure i got it right
[03:33] <mako> and also, is theere no problem with putting that in traffic?
[03:33] <mako> i'm assuming anything in ubuntu-* is fair game
[03:33] <mdz> the conlcusion was that non-free/sketchy stuff should go in a separate component, named 'multiverse'
[03:34] <mako> but it has no connection to origin?
[03:34] <mdz> yeah, as far as I know it's fair game
[03:34] <mdz> no connection to the origin: header
[03:34] <mako> alright, that's what i thought
[03:34] <mako> fixed conclusions can be hard to get sometimes re-reading irc meetings
[03:37] <jdub> hrm
[03:37] <mako> jdub: oi!
[03:37] <jdub> i should redirect archive.ubuntu.com to my local apt-proxy ;)
[03:37] <jdub> morning mako
[03:40] <tseng> ala abcde
[03:40] <tseng> checkmarks in the prefs instead of a radio
[03:40] <jdub> that would be... odd
[03:40] <jdub> although i grok the reason
[03:40] <tseng> i use flac at home.. mp3 on ipod
[03:46] <jdub> zooom
[03:46] <jdub> nice and fast install on my desktop
[03:46] <Kamion> mdz: linux-restricted-modules-2.6-386 is uninstallable in the current daily, just noticed
[03:47] <Kamion> mdz: (I know you've fixed it since then)
[03:47] <mdz> drat
[03:47] <Kamion> mdz: do you think I can ignore this, given that it's not used by default yet?
[03:47] <mdz> the current daily that we just tested for sounder 9?
[03:47] <Kamion> right
[03:47] <mdz> oh, it isn't?
[03:47] <mdz> sure
[03:47] <mdz> no problem, then
[03:47] <Kamion> yeah, we use the concrete package currently
[03:47] <Kamion> ok
[04:02] <lamont> hrm.. guess the postfix discussion belongs here more..
[04:09] <lamont> Kamion: want to look at a diff and comment?
[04:18] <Kamion> lamont: will have to be tomorrow, sorry
[04:18] <Kamion> mdz: is the warty-changes list public?
[04:18] <lamont> Kamion: np. about to sleep here too.
[04:18] <Kamion> (-ly advertised)
[04:19] <jdub> Kamion: yes
[04:19] <Kamion> so I can mention it in the Sounder announcement, then
[04:19] <jdub> sure
[04:19] <lamont> oooh... new sounder?
[04:19] <lamont> kewl
[04:20] <tseng> sounder?
[04:20] <lamont> test cd
[04:20] <Kamion> tseng: will explain on ubuntu-users shortly
[04:20] <tseng> mmm.
[04:20] <tseng> thanks
[04:20] <lamont> sounder is the collective noun for warthogs
[04:21] <jdub> oink
[04:21] <lamont> gcc-3.4 is making t-bone's life a pain, and therefore affecting me as well.... sigh.
[04:21] <lifeless> jdub: thanks for that :)
[04:22] <jdub> lifeless: you might want to ask edd about the bluetooth ones
[04:22] <jdub> (wrt imports)
[04:23] <lifeless> the bluez ones?
[04:23] <jdub> yeah
[04:23] <lifeless> ?
[04:23] <lifeless> oh lol.
[04:24] <daniels> lifeless: when do I get to announce xorg? :)
[04:24] <lifeless> daniels: when its cooked.
[04:47] <mdz> Kamion: yes, warty-changes is entirely public
[04:58] <lamont> so how do I (1) de-mimeify something, or (2) get a usable patch from bugzilla?
[04:59] <lifeless> lamont: mimutils
[05:01] <fabbione> morning
[05:07] <mdz> Kamion: I thought therm-windtunnel was supposed to be detected and loaded now
[05:07] <mdz> (wasn't for me)
[05:49] <fabbione> mdz: permission to upload radvd for 1868
[05:49] <fabbione> http://people.no-name-yet.com/~fabbione/radvd.diff
[05:49] <fabbione> diff is here
[05:49] <fabbione> 2 cosmetic + the real bug fix
[05:50] <fabbione> cosmetic are 1 typo and add one line to the output (looks better in case o failure)
[05:50] <mdz> yep, OK by me
[05:50] <mdz> is ||true more appropriate than --oknodo?
[05:50] <mdz> I suppose so
[05:50] <fabbione> mdz: --oknodo has no effect there
[05:50] <fabbione> already tested
[05:50] <fabbione> start-stop-daemon will still die
[05:54] <mdz> I wonder about start-stop-daemon sometimes
[05:54] <mdz> I expect it to do many things because they are the right thing to do
[05:54] <mdz> but it simply doesn't
[05:57] <mdz> fabbione: if you run out of RC bugs, I think that kamion and seb128 currently have more than their share and could use an extra pair of eyes
[06:00] <fabbione> mdz: yes i know.. i keep tracking bugs..
[06:00] <fabbione> mdz: also the one "assigned" to debzilla ;)
[06:00] <mdz> there are very few unassigned RC bugs now, and two of them are sort of fuzzy bugs
[06:01] <mdz> one is tollef's bug that I have no idea about
[06:01] <mdz> going to get some food, back later
[06:01] <fabbione> later
[06:03] <fabbione> make[5] : *** [libglx.a]  Illegal instruction
[06:03] <fabbione> ops
[06:03] <daniels> fabbione: ... nice one
[06:05] <fabbione> that's the ppc buildd on x -8
[06:11] <lamont> fabbione: Illegal instruction on ppc is something that "just happens".  That is, it's a kernel bug that no one is working on...  Just gotta retry it..
[06:14] <fabbione> lamont: it still sucks tho :-)
[06:14] <lamont> yep.
[06:20] <daniels> isn't that the exec_shield crack?
[06:20] <lamont> not on ppc
[06:20] <daniels> ahr
[06:21] <jdub> daniels: ppc has bugs to do that for you
[06:23] <daniels> jdub: huzzah
[06:23] <tseng> the edge gets sharper !
[06:25] <jdub> ;)
[06:25] <tseng> cdbs is rock.
[06:26] <tseng> i replaced the monodevelop rules w/ yours
[06:26] <tseng> it was doing some nasty stuff.
[06:28] <hazmat> has anyone noticed that powerbook sleep seems to be broken with the latest iso nightlies ?
[06:32] <justdave> mine sleeps but I've been having trouble getting it to wake up on occasion
[06:33] <tseng>  Depends: ${gdi:Depends}, ${wine:Depends}, ${shlibs:Depends}, mono-assemblies-base-${m ono:upversion}
[06:33] <tseng> what does that mean
[06:34] <hazmat> hmm.. i saw a few refs to that on the list... i just did an install on a tibook gen4 (ati mobility) wiping an existing gentoo setup.. which did sleep properly (2.4 kernel though).. i'm wondering if its a 2.6.8 kernel regression, i see a few refs to the not waking up issue while googling around in relation to that kernel version 
[06:35] <justdave> I'm wondering if it's airport card related...
[06:35] <justdave> there's an error about attempting to access the wireless when the wireless isn't active in the middle of the output it gets on the screen before it hangs
[06:36] <justdave> and that message isn't there on the times when it wakes up properly
[06:37] <hazmat> justdave, what powerbook version do you have? 
[06:37] <justdave> dual USB 500MHz iBook (white)
[06:37] <hazmat> so its ati radeon mobility (>9100) ?
[06:38] <hazmat> for the gfx card
[06:38] <justdave> yeah.
[06:40] <lamont> does apt-ftparchive just run dpkg-scanpackages eventually, or does it do it's own thing?
[06:40] <fabbione> i think the latter
[06:40] <tseng> it does the same thing, but its own way i believe
[06:41] <fabbione> lamont: if you try dpkg-scanpackage and apt-ftparchive on one package you also notice that the output is slightly different
[06:41] <justdave> ATI RAGE Mobility M3
[06:41] <fabbione> lamont: like the order of the fields
[06:41] <lamont> fabbione: ah, ok
[06:43] <hazmat> justdave, do you see any ati related error messages on bootup?
[06:44] <hazmat> i see a few and i'm suspicious since they werent present with gentoo previously..
[06:45] <justdave> aty128fb: Invalid ROM signature e78c should be 0xaa55
[06:45] <justdave> aty128fb: BIOS not located, guessing timings
[06:45] <justdave> aty128fb: Rage128 LF M3 AGP [chip rev 0x0]  8M 128-bit SDR SGRAM (1:1)
[06:46] <justdave> Registered "ati" backlight controller, level: 15/15
[06:46] <hazmat> yah.. i have the same invalid rom sig line with atiradeonfb
[06:47] <daniels> apparently these suspend problems could well be caused by radeonfb
[06:47] <daniels> huzzah!
[06:48] <hazmat> it could be a red herring.. but i'm suspicious
[06:50] <hazmat> http://www.mail-archive.com/debian-boot@lists.debian.org/msg59641.html
[06:51] <hazmat> the follow up has some more analysis
[06:54] <justdave> hmm, there's a bunch of new bugs assigned to me on Bugzilla that I never got bugmail for
[06:57] <daniels> oh wow, no edid. that sucks horribly.
[06:59] <lamont> x needs 4.5 GB to build?  sheesh
[06:59] <daniels> lamont: ya-huh
[06:59] <fabbione> lamont: only if you build -all
[06:59] <lamont> well, I have 6gb - hope that's enough.
[06:59] <daniels> lamont: every time there's a sid upload, we have to poke the arm and s390 folks to build on a box with enough space
[06:59] <daniels> lamont: plenty
[07:00] <fabbione> lamont: if you build -B it will be a 500Mb less
[07:00] <fabbione> lamont: or probably more.. i can't remember
[07:00] <lamont> fabbione: this is -B
[07:00] <lamont> on ia64, though
[07:00] <fabbione> lamont: ah
[07:00] <fabbione> hmmm
[07:01] <lamont> so is P1 more urgent than P2?
[07:05] <lamont> fabbione: btw, you can/should drop the > make_world.build.log hack on your next upload of X...
[07:05] <fabbione> lamont: just a sec
[07:05] <fabbione> Finished at 20040721-1250
[07:05] <fabbione> Build needed 02:21:38, 4685680k disk space
[07:06] <fabbione> Finished at 20040928-1818
[07:06] <fabbione> Build needed 02:09:09, 4454612k disk space
[07:06] <lamont> yeah
[07:06] <fabbione> i guess ia64 doesn't really benefit of the BuildFonts=NO
[07:06] <lamont> is it building the fonts?
[07:06] <fabbione> the first one is -6 that was still building the fonts
[07:07] <fabbione> the second is -7 that does not build fonts and docs
[07:07] <lamont> heh
[07:07] <lamont> 200MB, 12 minutes
[07:07] <fabbione> but for instance on m687k it saves up to 30% of time
[07:07] <fabbione> night lamont 
[07:52] <daniels> lamont: night dude
[07:54] <fabbione> mdz: 1485 permission to upload base-config
[07:54] <mdz> fabbione: yes
[07:54] <fabbione> mdz: useless reassing ;) i am done already :P
[07:54] <mdz> fabbione: you never know; it could get rejected :-)
[07:55] <fabbione> tsk :P
[07:59] <fabbione> done
[08:00] <mdz> 1 down, 38 to go
[08:02] <fabbione> i am on another one
[08:02] <mdz> the ones I am really concerned about are #1724 and #1632
[08:03] <mdz> and #1854
[08:03] <mdz> 1854 and 1724 I have no idea what is broken
[08:03] <mdz> #1632 I can at least reproduce and start adding printks
[08:08] <fabbione> 1834 <-
[08:08] <fabbione> i will check the others in a few minutes
[08:09] <mdz> I think 1834 is a dupe of that bug where seb fixed it by adding a dependency
[08:10] <mdz> but I wasn't sure
[08:10] <fabbione> yeps.. i am checking that..
[08:12] <fabbione> Depends: libpt-plugins-alsa | libpt-plugins-oss
[08:12] <fabbione> it's not versioned
[08:13] <fabbione> so for a pure warty that's not an issue, but it can be in mixed environment
[08:13] <fabbione> mdz: do you want me to strict the dependencies?
[08:14] <mdz> does it need to be versioned?
[08:15] <mdz> I don't know anything about libpt
[08:15] <fabbione> neither do i, but according to the maintinaer it needs to be
[08:15] <mdz> the plugins have an exact versioned dep on libpt
[08:15] <mdz> and gnomemeeting has a >= dep
[08:15] <fabbione> "Pwlib is not compatible among different versions.
[08:16] <mdz> pwlib?
[08:16] <fabbione> Comment #2
[08:17] <mdz> I don't think pwlib is related; he must have meant libpt
[08:17] <fabbione> probably
[08:17] <mdz> mizar:[/tmp]  apt-cache show libpt-plugins-alsa | grep-dctrl -nsDepends ''
[08:17] <mdz> libasound2 (>> 1.0.5), libc6 (>= 2.3.2.ds1-4), libgcc1 (>= 1:3.3.4-1), libstdc++5 (>= 1:3.3.4-1), libpt-1.6.3 (= 1.6.5-3ubuntu1)
[08:17] <mdz> it already has an exact dependency, so I don't see how it could be tighter
[08:17] <fabbione> ok
[08:17] <fabbione> i missed that :-)
[08:18] <fabbione> ok.. so it's a duplicate.. let's figure of which bug ;)
[08:19] <mdz>   * debian/control.in: Added a Dependency on video plugins, so at least one is
[08:19] <mdz>     going to be always installed (Warty: #1542).
[08:22] <fabbione> ok.. gone
[08:23] <fabbione> 1724 smells of nvidia crack
[08:24] <fabbione> that's something i debugged a while ago and added info to the relevant bugs
[08:25] <fabbione> as soon as you have nvidia-glx installed, the system becomes.. hmm funny
[08:25] <fabbione> X -> FTBFS
[08:25] <fabbione> pyopengl -> as X
[08:26] <mdz> one of the comments in 1724 swears they removed nvidia
[08:26] <mdz> but even if it is nvidia, many people posted to ubuntu-users saying xmms did not work
[08:27] <mdz> I wonder if I can reproduce it just by installing nvidia-glx, not using the driver
[08:27] <fabbione> mdz: yes you can
[08:27] <fabbione> with kernel 2.6
[08:27] <fabbione> the nvidia-glx creates /usr/lib/tls
[08:27] <fabbione> and boom
[08:28] <fabbione> the libraries provided by nvidia-glx are pure crack
[08:28] <mdz> hmm, yes, I can
[08:28] <mdz> wtf is nvidia doing providing libraries which are used by xmms??
[08:28] <fabbione> 1632 <- i don't have 2GB of ram.. if Mark wants to sponsor them i can buy another Giga and give serial access to Xu ;)
[08:29] <fabbione> mdz: no no.. it doesn't
[08:29] <fabbione> ldso goes on crack with tls
[08:29] <fabbione> because the libs are pure crack
[08:29] <fabbione> there is another package that puts stuff in there (can't remember shich one)
[08:29] <mdz> but everything else works fine for me
[08:29] <fabbione> that you can use as test case
[08:29] <mdz> when I don't install nvidia-glx
[08:29] <mdz> it is still using tls libraries
[08:29] <fabbione> remove nvidia-glx, install that package and that's it
[08:30] <fabbione> yu will see that xmms works fine
[08:32] <mdz> hmm
[08:32] <mdz> removing /usr/lib/tls/* and running xmms gives a nice segfault
[08:33] <mdz> what is nvidia-glx changing which breaks it?
[08:33] <fabbione> it installs some tls libs required for the driver to work on kernel 2.6
[08:34] <mdz> which ones?  how do they end up linked into xmms?
[08:34] <mdz> ohhh
[08:34] <mdz> it is the opengl spectrum plugin
[08:34] <fabbione> xmms overabuses dlopen
[08:35] <mdz> rm /usr/lib/xmms/Visualization/libogl_spectrum.so
[08:35] <mdz> and it works fine
[08:35] <mdz> ok, that makes much more sense now
[08:36] <mdz> I didn't know that xmms used GL stuff
[08:36] <fabbione> if it there is something available, xmms uses it :P
[08:38] <mdz> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221401
[08:38] <mdz> xmms is not doing anything wrong; nvidia seems buggy
[08:38] <fabbione> as i said before :-)
[08:39] <fabbione> there is a scary override in nvidia-glx
[08:39] <fabbione> like: lib not linked with libc6 or something
[08:44] <mdz> Mithrandir: ping?
[08:50] <fabbione> mdz: 1859. you already disabled the init script completely
[08:50] <fabbione> mdz: that kinda avoid discover1 to trash /media
[08:52] <fabbione> mdz: but i think we can safely add joeyh fix to change the default in the template
[08:53] <fabbione> as extra safety
[08:53] <mdz> fabbione: I think d-i might call discover to create that stuff, I'm not sure
[08:53] <mdz> or it might create it itself
[08:54] <fabbione> mdz: See comment #14
[08:55] <fabbione> and comment 9
[08:55] <fabbione> Sorry for the late reply. It seems to mee that discover1 is the culprit
[08:55] <fabbione> and it probably deleted the directories created in prebaseconfig.
[08:56] <fabbione> 90prepare-base-config 
[08:57] <fabbione> # Set up /dev/cdrom link to point to the device used for /media/cdrom0 in
[08:57] <fabbione> # /target; various programs including base-config want a /dev/cdrom.
[08:57] <fabbione> [SNIP] 
[09:02] <jdub> oh man
[09:02] <jdub> g-s-m has a "run as root" thing all of its own
[09:03] <mdz> sounds bad
[09:03] <jdub> so mcuh cock
[09:03] <mdz> it doesn't have any setuid stuff in it, though
[09:03] <mdz> so it must eventually call out to su or something
[09:03] <fabbione> mdz: so should we leave discover1 as it is?
[09:04] <jdub> mdz: yeah, it does
[09:04] <jdub> eventually
[09:04] <jdub> i can evilly hack around it
[09:05] <mdz> fabbione: hmmm
[09:05] <mdz> fabbione: I thought someone had reported this in ubuntu
[09:05] <mdz> fabbione: but now that I am looking, I only see Debian reports
[09:05] <fabbione> mdz: i am more to apply the patch from joeyh
[09:05] <mdz> so I think you are right, and it is just discover wiping out the links at boot time
[09:06] <mdz> in which case it may be NOTWARTY
[09:06] <mdz> fabbione: joeyh's patch has no effect because it only changes the init script behaviour
[09:07] <mdz> fabbione: I think we can close it NOTWARTY
[09:07] <fabbione> mdz: ok
[09:08] <fabbione> mdz: gone
[09:08] <mdz> 36 to go
[09:09] <fabbione> we ARE ROCKING!
[09:10] <mdz> for #1301, I really think we should just tell the user not to use XFS for root
[09:10] <mdz> Linux XFS is crap anyway
[09:10] <fabbione> wtf happened to bugzilla????
[09:10] <mdz> fabbione: justdave is changing things
[09:10] <fabbione> the fonts become GIANT in a sec?
[09:10] <fabbione> ah ok
[09:10] <mdz> the CSS and such
[09:10] <mdz> all of the hyperlinks became not-visited for some reason
[09:11] <fabbione> mdz: i have 38 to go here
[09:11] <jdub> yay! kill xfs, reiser and jfs! yay!
[09:11] <mdz> justdave: did you change the visited link color to be the same as the not-visited color?
[09:11] <mdz> fabbione: I have 36 WartyWarthog bugs >= major
[09:11] <mdz> fabbione: maybe you are getting website bugs as well?
[09:11] <justdave> no, visited should be purple, non-visited blue
[09:12] <mdz> justdave: both are blue
[09:12] <fabbione> oh could be yes
[09:12] <mdz> as of a few minutes ago
[09:13] <justdave> ok, the ones in the header are working, nothing else is.
[09:13] <justdave> must be something overriding the main one
[09:14] <justdave> no other mentions of visited in the stylesheet...  hmmmm
[09:17] <justdave> there we go, got it.
[09:18] <justdave> there was no explicit declaration for :visited or :active outside of a <p>
[09:18] <justdave> so it was inheriting the generic <a> style
[09:18] <justdave> which was explicitly declared as blue
[09:19] <justdave> that stylesheet is really funky :)
[09:19] <justdave> no offence intended to the main website :)
[09:20] <pitti> Morning guys!
[09:26] <fabbione> hem
[09:26] <fabbione> sound-juicer just decided to hang completely
[09:27] <mdz> pitti: morning
[09:27] <mdz> pitti: what is your feeling on the new utopia packages?  I am quite happy with them so far
[09:27] <pitti> mdz: Did you try again to burn a CD? Should work better now
[09:27] <mdz> pitti: I see you have not read your mail yet ;-)
[09:28] <pitti> mdz: with yesterday's changes, they work really good
[09:28] <pitti> mdz: no, I just got up. Stayed up too late last night; 
[09:28] <pitti> mdz: I'm at the bugzilla mail stage :-)
[09:28] <mdz> pitti: see my comments in #1234
[09:30] <pitti> mdz: the new packages already work quite well, but there are still problems:
[09:30] <pitti> mdz: for once, I experienced a hal crash yesterday; I cannot reproduce it, though
[09:30] <pitti> mdz: the second thing is that hal now correctly detects volumes on raw (i. e. unpartitioned) devices
[09:31] <pitti> mdz: but if you had an unpartitioned device before, and then partition it and put a new file system on the partition, hal detects _two_ volumes: sda and sda1
[09:31] <pitti> mdz: this causes overwriting of one volume by write operations on the other and kills the stick
[09:32] <pitti> mdz: I already asked upstream about this and dived deeply into the hal code, but I was not yet able to solve that
[09:32] <pitti> mdz: could you reproduce your hal crash after CD burning?
[09:34] <mdz> pitti: I never saw hal crash
[09:34] <mdz> with the previous packages, nautilus-cd-burner crashed
[09:34] <mdz> this time, I only saw g-v-m crash, and I think it was because of the upgrade
[09:35] <pitti> mdz: Hmm, my brain told me that hal crashed yesterday; I even asked you whether you run it as --daemon=no
[09:35] <mdz> fabbione: hmm, sounds like you are finding new bugs, that does not help the bug count :-)
[09:35] <pitti> mdz: but maybe this was a misunderstanding
[09:35] <pitti> mdz: after installing the new packages, the user must log out and relogin
[09:35] <mdz> pitti: oh, that was unrelated
[09:36] <mdz> the hal crash was something else
[09:36] <pitti> mdz: I'm not sure how we can achieve that
[09:36] <pitti> mdz: but even if it was sth else, it should not crash :-/
[09:36] <mdz> I think it was the old version of hal
[09:36] <pitti> mdz: ah, so much the better :-)
[09:37] <mdz> anyway it was a corner case, powering off a USB device, much less important than #1234
[09:37] <pitti> mdz: there is a possibility to restart much of the user's session: killall gnome-vfs-daemon nautilus
[09:37] <pitti> mdz: but I don't think that we should write this into the postinst script...
[09:37] <mdz> pitti: I did log out and log in, but I was impatient
[09:37] <mdz> and I was logging in already before the login completed
[09:37] <mdz> I am not sure at what point g-v-m starts
[09:38] <mdz> s/login/upgrade/
[09:38] <pitti> mdz: pretty early
[09:38] <mdz> probably my fault, then
[09:38] <mdz> as I said in bugzilla
[09:38] <pitti> mdz: so the conclusion is: in principle they work well
[09:39] <pitti> mdz: I only need to solve this corner case of a repartitioned device
[09:39] <mdz> I think the only way they will get more testing is if we put them into warty
[09:39] <mdz> pitti: yes, that sounds dangerous
[09:39] <mdz> pitti: why does it cause writes to the disk, though?  I don't understand that
[09:39] <pitti> mdz: if it breaks too badly, we could upload a 0.2.98+really0.2.92 or so, not?
[09:39] <mdz> hal doesn't even have permission to write to the disk, does iT?
[09:40] <mdz> yes, we can always fix it if we find something terrible
[09:40] <pitti> mdz: if both sda and sda1 are recognized as volumes, g-v-m mounts _both_
[09:40] <pitti> mdz: but sda is not really a volume any more, it's just the first block (where the MBR belongs)
[09:40] <pitti> mdz: so as soon as something writes to sda, it will destroy the file system on sda1
[09:41] <pitti> mdz: the problem is that the partition detection code in hal is wrong: it reports 0 partitions for such an USB stick
[09:41] <mdz> pitti: how can it mount sda if there is no filesystem there?
[09:42] <pitti> mdz: okay, again: I format /dev/sda with VFAT  (as I used to do earlier; this works well with fstab-style mounts)
[09:42] <pitti> mdz: then I come to Ubuntu and see that the old hal does not recognize raw devices
[09:42] <mdz> oh, I see, so you are switching from raw to partitions without blanking it
[09:42] <pitti> mdz: so I put a partition on the stick and format it as VFAT
[09:42] <mdz> that seems like an invalid format to me
[09:42] <mdz> there is no way to tell which one is valid
[09:42] <pitti> mdz: this alone could be regarded as a corner case, yes
[09:43] <pitti> mdz: but plovs tried it yesterday with a ZIP drive (which he never touched, partitionwise)
[09:43] <pitti> mdz: and also for this thing _two_ volumes were detected
[09:43] <mdz> ZIP disks come with two partitions from the factory I think
[09:43] <pitti> mdz: he was not able to unmount it again, file writes did not sync; he had to rip it out and reboot
[09:43] <mdz> one for PC and one for Mac, something like that
[09:44] <pitti> mdz: but then they share the files written to it?
[09:44] <pitti> mdz: we are able to mount both partitions... (we are too good :-) )
[09:45] <mdz> On the other hand, ZIP disks prepared by IOMEGA utilities actually have a partition table (usually having a single entry, the fourth, spanning the whole disk, so that access to such disks with partition table goes via mounting /dev/sda4 (in the SCSI case, say)). On disks for the Mac one has 6 partitions, and again the fourth can be mounted, with filesystemtype "hfs".
[09:45] <mdz> so actually it is only one partition
[09:45] <pitti> odd
[09:45] <mdz> but it is partition #4
[09:46] <mdz> I remember there was some PC/mac compatibility thing
[09:46] <fabbione> mdz: no worries :-)
[09:46] <fabbione> my cdrom is either dirty or broken
[09:46] <mdz> fabbione: well that is good news in a way
[09:46] <fabbione> but i found a new bug in the kernel
[09:46] <pitti> mdz: ah, I got a mail from plovs with his lshal listing
[09:46] <mdz> fabbione: STOP FINDING BUGS
[09:46] <mdz> fabbione: :-)
[09:47] <fabbione> mdz: if i leave the cdrom tray open, when cd<something> module is loaded, it will start spawning a lot of errors
[09:47] <fabbione> (this is at boot time)
[09:47] <fabbione> and i can reproduce it on 2 machines
[09:47] <fabbione> if i revert to the previous kernel there are no problems
[09:47] <mdz> hmm, doesn't happen with my usb one
[09:47] <fabbione> it's ide-cdrom probably
[09:47] <mdz> which previous kernel?
[09:48] <fabbione> title           Ubuntu, kernel 2.6.8.1-3-686 
[09:48] <fabbione> actual
[09:48] <fabbione> title           Ubuntu, kernel 2.6.8.1-2-686 
[09:48] <fabbione> old
[09:48] <mdz> weird
[09:48] <mdz> no ide stuff has changed since then
[09:49] <fabbione> i know...
[09:49] <fabbione> but it's not fatal or anything
[09:49] <fabbione> it is just scary :-)
[09:49] <pitti> mdz: yep, with plov's ZIP drive both sda and sda4 are mounted
[09:50] <mdz> pitti: I suppose the safe thing is to not mount the device itself if it contains a partition table
[09:51] <pitti> mdz: yep; actually this should be fixed in hal; if there are partitions, skip the raw device and do not report it as block.is_volume
[09:51] <mdz> pitti: agreed
[09:51] <pitti> mdz: I try again today to fix that; if this one works, I think we could throw it at the public
[09:52] <mdz> pitti: does the current hal in warty not have the same problem?
[09:52] <pitti> mdz: it does not detect volumes on raw devices at all
[09:52] <mdz> ah
[09:53] <pitti> mdz: this was the sole reason why I put a patrition on my stick
[09:53] <pitti> mdz: a quick fix would be to disable volumes on raw devices completely :-)
[09:57] <mdz> pitti: if that is simple and safe, I am not opposed
[09:57] <mdz> that would let us get the new utopia into warty and then you can continue to work on the raw device problems
[09:57] <pitti> mdz: we could sell it as "compatible to 0.2.92 :-)"
[09:57] <pitti> mdz: it would be a dirty hack, but it should be not too intrusive/unsafe
[09:58] <pitti> mdz: on every occasion where block.is_volume is set to TRUE, I would leave it to false if the device is raw
[09:58] <pitti> (that's my first idea)
[09:58] <pitti> mdz: the hal code is a mess, I cannot find a clean solution quickly
[10:02] <sjoerd> pitti: is the block.no_partitions property correct on such devices ?
[10:02] <pitti> sjoerd: unfortunately not
[10:03] <pitti> sjoerd: at least this flag does not work properly, its always false
[10:03] <pitti> sjoerd: (IIRC)
[10:03] <sjoerd> it's true on my cdrom drive
[10:03] <pitti> sjoerd: the partition detection in hal is screwed, it always returns partition_count = 0 for such devices
[10:03] <pitti> sjoerd: all the flags are based on this number
[10:05] <sjoerd> pitti: try moving the msdos partition detector to the beginning in the volume_id code
[10:06] <pitti> sjoerd: you mean in the big switch VOLUME_ID_ALL case?
[10:06] <sjoerd> pitti: yes
[10:06] <pitti> sjoerd: first probe for msdos, then for raid/ntfs?
[10:06] <pitti> sjoerd: worth a try
[10:07] <sjoerd> pitti: it was moved to the end because i had an empty msdos partition signature on my /dev/sda1 :)
[10:07] <pitti> sjoerd: which does not have VFAT?
[10:07] <pitti> sjoerd: argh, an msdos part?
[10:08] <sjoerd> pitti: msdos partition map, not vfat of some other fs
[10:08] <pitti> sjoerd: hmm; I don't like to fix a bug by unfixing another...
[10:08] <sjoerd> pitti: no it's safe. the msdos partition prober check if a partition table is empty and doesn't recognize it
[10:09] <sjoerd> pitti: see the 2004-08-23 of key siever
[10:09] <sjoerd> s/key/kay
[10:09] <pitti> sjoerd: okay, thanks for that hint. I will try that after breakfast
[10:40] <fabbione> mdz: why 1805 is a major?
[10:41] <mdz> fabbione: inflated from Debian
[10:42] <fabbione> mdz: ok -> enanchement
[10:42] <mdz> however since the only change is to add some files to the package which are already built, i think it would be nice to have in Warty
[10:42] <fabbione> mdz: ok, i can take care of it. is that ok for you?=
[10:43] <mdz> fabbione: argh, my saved search was not including bugs marked NEEDINFO or UNCONFIRMED or PENDINGUPLOAD because those are new
[10:44] <fabbione> mdz: i only search for severity
[10:44] <mdz> so now I see 45 bugs
[10:44] <fabbione> argh
[10:44] <fabbione> no
[10:44] <fabbione> you are right!
[10:44] <mdz> searching only severity would find closed bugs too
[10:45] <pitti> Hi seb128!
[10:45] <fabbione> mdz: same here
[10:45] <elmo_> mdz: you put linux-$SUBARCH in restricted?
[10:45] <mdz> elmo_: yep
[10:45] <fabbione> mdz: ok i am on that samba stuff
[10:45] <mdz> elmo_: they depend on the restricted-modules
[10:45] <seb128> morning
[10:45] <elmo_> ;P
[10:45] <mdz> elmo_: I thought hard about it, and it is pretty much the right thing
[10:46] <mdz> our default kernel offering is the combination of the image and the restricted modules
[10:46] <mdz> so the combination is restricted
[10:46] <mdz> elmo_: if you have another idea which makes more sense, I am interested
[10:48] <mdz> justdave: I think the simple search has the same bug
[10:48] <mdz> justdave: I don't think it recognises NEEDINFO as an open state
[10:49] <justdave> mdz: ok, should be fixed now, probably have to shift-reload to dump the old js from your cache
[10:50] <mdz> thanks
[10:56] <elmo_> Kamion: ?
[10:56] <elmo_> mdz: low-ping about wvdial, btw
[10:56] <elmo_> and mozilla-locale
[10:57] <elmo_> oh, there's an assigned bug about the latter so nm that
[10:59] <mdz> elmo_: what about mozilla-locale?
[10:59] <mdz> the uninstallable stuff? yeah, that's known
[11:00] <pitti> mdz: I patched gnome-system-tools for #1485 (trivial patch); can you please approve?
[11:00] <mdz> pitti: go ahead
[11:01] <elmo_> mdz: yeah
[11:14] <fabbione> mdz: permission to upload samba for 1805
[11:14] <mdz> fabbione: only for 1805, or the other samba bug also?
[11:15] <fabbione> mdz: only 1805
[11:15] <fabbione> are there more samba bugs?
[11:15] <mdz> yes, 1433
[11:15] <mdz> I think that we probably need to disable sendfile by default unless there is a patch available
[11:15] <mdz> but it needs some investigation
[11:17] <fabbione> i am reading
[11:17] <pitti> mdz: yes! yes! yes! I fixed hal!!!
[11:18] <pitti> mdz: sorry for the noise
[11:18] <mdz> pitti: the mounting problem?
[11:18] <pitti> mdz: yep; now it correctly detects only sda1
[11:18] <mdz> excellent
[11:18] <pitti> mdz: and if there are no partitions, it still detects sda
[11:18] <pitti> mdz: now it works as it should
[11:19] <mdz> yes, that was quick
[11:19] <pitti> mdz: I prepare an updated package and put it onto my unofficial repo
[11:20] <mdz> pitti: let me know when to upgrade, and I will give it some testing
[11:20] <mdz> and then I should probably sleep
[11:20] <pitti> mdz: it will take me another 20 minutes to clean my debugging stuff and prepare a clean package
[11:21] <fabbione> mdz: well i think the default should be set to no
[11:21] <pitti> mdz: I will try to catch plovs to test the new package with his ZIP drive
[11:22] <mdz> fabbione: yes, I think sendfile is probably only interesting for high-volume servers and such
[11:23] <fabbione> mdz: yeah i will see what's the best way to revert the default
[11:23] <fabbione> mdz: if there is a way to change it in the code rather than in the config
[11:25] <mdz> fabbione: I found an upstream bug report, might be worth looking at
[11:25] <mdz> https://bugzilla.samba.org/show_bug.cgi?id=1643
[11:25] <mdz> (emailed to debian as well)
[11:26] <fabbione> cheking
[11:27] <mdz> fabbione: upstream says 2.4.x is broken and 2.6.x is OK, while Debian says the reverse
[11:27] <fabbione> yes i can see that
[11:28] <fabbione> i trust neither of them :-)
[11:28] <fabbione> we will just switch sendfile off ;)
[11:28] <mdz> did 3.0.6 enable it by default, while in 3.0.5 it is disabled?
[11:32] <pitti> mdz: the new hal crack is up
[11:32] <mdz> upgrading
[11:32] <mdz> pitti: the only change is this partition stuff, right?  so I shouldn't need to retest everything I did today
[11:32] <fabbione> mdz: i am not sure.. i am checking how this crack works
[11:32] <pitti> mdz: yes, I only changed partition/fs detection
[11:33] <pitti> mdz: even more precise, I just changed the _order_ of the detection
[11:33] <justdave> hmm...  thought...  when a bug is NEEDINFO, should we have the radio button default to "make the bug ASSIGNED" so the next time someone touches it the needinfo goes away, unless they set it to "leave as NEEDINFO" before submitting?
[11:33] <pitti> mdz: now it first attempts to detect a partition table and then raw file systems
[11:33] <seb128> yes please
[11:33] <seb128> a lot of people add comment and let the bug as NEEDINFO
[11:34] <mdz> justdave: however, another common case is for the assignee to make another comment
[11:34] <mdz> justdave: reiterating the request for more info before closing the bug
[11:34] <mdz> and the state should not be reset in that case
[11:35] <justdave> could change the default only if the viewer is the reporter...   but that won't work if they aren't logged in when they view it
[11:35] <mdz> I can't think of any way to DTRT automatically
[11:36] <justdave> maybe a checkbox right next to the comment area "I am providing the requested information"
[11:37] <mdz> justdave: that sounds reasonable
[11:37] <mdz> pitti: hmm, it seems unhappy
[11:37] <mdz> pitti: I plugged in my card reader and it isn't appearing in hal
[11:37] <justdave> or with the default radio button change, you could assume the assignee is more likely to remember to change it to "leave as NEEDINFO" before submitting
[11:38] <pitti> mdz: you need to relogin
[11:38] <pitti> mdz: if hal is restarted, this gnome stuff stops to work 
[11:38] <pitti> mdz: (I assume because of the lost dbus connection)
[11:38] <mdz> pitti: this is not gnome stuff; it doesn't show up in lshal
[11:38] <mdz> but I did logout and login
[11:38] <pitti> mdz: hmm. Had it partitions before?
[11:39] <pitti> mdz: can you please replug?
[11:39] <mdz> pitti: it has a single partition
[11:39] <pitti> mdz: I also noticed that: the very first time after package upgrade my devices are not recognized as wekk
[11:39] <pitti> mdz: s/wekk/well/
[11:39] <pitti> mdz: I have no idea why
[11:39] <mdz> I have replugged several times
[11:39] <mdz> no change
[11:39] <pitti> mdz: damn
[11:40] <mdz> pitti: I think that the init script is buggy
[11:40] <pitti> mdz: of hal?
[11:40] <mdz> pitti: when running /etc/init.d/dbus-1 restart, hal is not restarted
[11:40] <mdz> hal      22730  0.0  2.6  8048 6776 ?        Ss   Sep28   0:09 /usr/sbin/hald --drop-privileges
[11:40] <mdz> that is the old hald process from before the upgrade
[11:40] <pitti> mdz: stop and start should work
[11:41] <pitti> mdz: but thanks for that hint, I will look at the dbus init script
[11:41] <mdz> mdz@potpal:~ $ sudo /etc/init.d/dbus-1 stop
[11:41] <mdz>  * Stopping system message bus...
[11:41] <mdz>  * Stopping Hardware Abstraction Layer...                                [ ok ] 
[11:41] <mdz> mdz@potpal:~ $ !ps
[11:41] <mdz> ps aux | grep hald
[11:41] <mdz> hal      22730  0.0  2.6  8048 6776 ?        Ss   Sep28   0:09 /usr/sbin/hald --drop-privileges
[11:41] <pitti> still the old process...
[11:41] <mdz> /var/run/hal/ is empty
[11:41] <mdz> I assume there should be a pid file in there
[11:41] <mdz> perhaps it was deleted by the failed restart
[11:41] <pitti> indeed, it should
[11:41] <pitti> it is from start-stop-daemon
[11:42] <pitti> next thing on my TODO list :-)
[11:42] <mdz> I will restart it by hand so I can test
[11:42] <mdz> yes, restarting hald let it pick up the device
[11:43] <mdz> I had a similar problem before
[11:43] <mdz> but I blamed it on g-v-m
[11:43] <pitti> mdz: so dbus tries to stop hald, but that fails somehow?
[11:44] <mdz> pitti: it displays [ok] , but apparently does not succeed
[11:44] <mdz> fabbione: X is segfaulting on me :-(
[11:44] <mdz> fabbione: sabdfl was seeing this, too (should be in scrollback)
[11:45] <mdz> oh, I know what it is
[11:45] <mdz> I installed nvidia-glx
[11:45] <mdz> to test that bug
[11:45] <sabdfl> mdz: my glitch was fglrx
[11:45] <pitti> mdz: odd, the init script works for me...
[11:45] <mdz> fabbione: apparently, if nvidia-glx is installed, it breaks the X server even if it is using ati
[11:45] <mdz> pitti: try it with a package upgrade
[11:46] <fabbione> mdz: ah
[11:46] <fabbione> mdz: going back to send file
[11:46] <pitti> mdz: okay, I can reproduce it
[11:46] <fabbione> vn diff -r 1312:1262 svn://svnanon.samba.org/samba/tr
[11:46] <fabbione> bah
[11:47] <fabbione> svn diff -r 1312:1262 svn://svnanon.samba.org/samba/trunk/source/param/
[11:47] <fabbione> that's the commit that turns on sendfile by default
[11:47] <fabbione> i can just revert it
[11:47] <mdz> pitti: hal is not finding my partition volume :-(
[11:47] <fabbione> mdz: if that's ok with you
[11:47] <pitti> mdz: on the card reader?
[11:48] <mdz> fabbione: that is fine, also fine to change in the config file
[11:48] <mdz> pitti: correct
[11:48] <mdz> pitti: the volume does not seem to show up at all
[11:48] <fabbione> mdz: there is no need to change the config file
[11:48] <fabbione> mdz: a user that wants sendfile will have to explicitly say so
[11:48] <fabbione> otherwise it's off
[11:50] <mdz> pitti: ok, so I logged out
[11:50] <mdz> pitti: shut down dbus/hal
[11:50] <mdz> pitti: started dbus/hal
[11:50] <mdz> pitti: logged in
[11:50] <mdz> and now it works
[11:50] <mdz> perfectly, just as before
[11:51] <sabdfl> lamont: mdz: im getting a ton of postfix errors in syslog after a fresh install
[11:51] <sabdfl> seems related to /etc/aliases.db not being present
[11:51] <mdz> yes, me too
[11:51] <mdz> Sep 29 02:51:05 localhost postfix/local[13672] : fatal: open database /etc/aliases.db: No such file or directory
[11:51] <mdz> Sep 29 09:51:06 localhost postfix/master[3624] : warning: process /usr/lib/postfix/local pid 13672 exit status 1
[11:51] <mdz> Sep 29 09:51:06 localhost postfix/master[3624] : warning: /usr/lib/postfix/local: bad command startup -- throttling
[11:52] <fabbione> mdz:
[11:52] <sabdfl> pitti: also, hald has a habit of suckng 99% cpu for a few minutes on startup
[11:52] <mdz> fabbione: sounds fine
[11:52] <pitti> sabdfl: minutes? another thing I cannot reproduce :-(
[11:52] <fabbione> samba (3.0.7-1ubuntu3) warty; urgency=low
[11:52] <fabbione>   * Apply patch from https://bugzilla.ubuntu.com/show_bug.cgi?id=1805
[11:52] <fabbione>     and start shipping mount.cifs.
[11:52] <fabbione>     (Closes: #1805/#227791)
[11:52] <fabbione>   * Set sendfile default to no, reverting upstream change:
[11:52] <fabbione>     svn diff -r 1262:1312 \
[11:52] <fabbione>     svn://svnanon.samba.org/samba/trunk/source/param/loadparm.c
[11:52] <fabbione>     (Closes: #1433/#261917)
[11:53] <pitti> sabdfl: you also have the most recent hal package? 
[11:53] <fabbione> mdz: permission to upload ;)
[11:53] <mdz> fabbione: yes
[11:53] <fabbione> ok!
[11:53] <pitti> sabdfl: 0.2.98-1ubuntu2?
[11:53] <mdz> pitti: I think it has always done this
[11:54] <mdz> it is the getty/vc/hotplug/hal race
[11:54] <mdz> all 6 consoles do it at once
[11:54] <pitti> mdz: ah, this would explain it
[11:54] <sabdfl> mdz: is the postfix problem a known one?
[11:54] <pitti> mdz: I think the source of this is udev, isn't it?
[11:55] <fabbione> mdz: going back to the X <-> nv problem... 
[11:55] <fabbione> mdz: it means that X segfaults with nvidia-glx installed?
[11:56] <fabbione> mdz: indipendently of the driver?
[11:56] <fabbione> s/of/from?
[11:56] <mdz> fabbione: correct
[11:56] <fabbione> mdz: hold on a sec
[11:56] <mdz> fabbione: easy way to reproduce for me: apt-get install nvidia-glx, then log out of GNOME
[11:56] <mdz> X doesn't come back
[11:56] <mdz> purge nvidia-glx -> OK again
[11:57] <fabbione> Package: nvidia-glx
[11:57] <fabbione> Status: install ok installed
[11:57] <fabbione> i am running ubuntu22
[11:57] <mdz> this is using Driver "ati"
[11:57] <fabbione> and i am in X
[11:57] <fabbione> i am not using nvidia binary driver
[11:57] <fabbione> i am using the nv free driver
[11:58] <mdz> perhaps someone else here can try with a non-nvidia card
[11:58] <fabbione> that's an option
[11:58] <m_tthew> I have an ati
[11:58] <fabbione> otherwise we should really install nvidia stuff only if there is an nvidia card
[11:58] <fabbione> m_tthew: can you try installing nvidia-glx and the latest X packages?
[11:58] <m_tthew> apt-get install nvidia-glx ; logout. see what happens?
[11:58] <m_tthew> fabbione: absolutely. lemme update && dist-upgrade
[11:59] <fabbione> mdz: and btw the last upload didn't change anything fancy on the driver side
[11:59] <fabbione> m_tthew: thanks
[11:59] <fabbione> mdz: it was only a fix contained into the nv driver
[11:59] <mdz> fabbione: yes, I remember
[11:59] <mdz> i don't think it is specific to the latest X
[12:00] <mdz> I have never tried installing nvidia-glx before (obviously I had no use for it)
[12:01] <mdz> pitti: yes, udev is at the core of the problem
[12:01] <mdz> getty needs to learn to wait for udev I think
[12:01] <m_tthew> fabbione: ii  xserver-xfree8 4.3.0.dfsg.1-6 the XFree86 X server
[12:01] <fabbione> m_tthew: are you on Debian or Ubuntu?
[12:01] <m_tthew> fabbione: so, I should apt-get install nvidia-glx and the n logout, login to gnome to test?
[12:02] <m_tthew> fabbione: ubuntu
[12:02] <fabbione> m_tthew: that it should be -6ubuntu22
[12:02] <m_tthew> hmmm
[12:02] <m_tthew> I am on amd64, if that is a factor here
[12:02] <fabbione> m_tthew: logout -> switch to console -> stop gdm -> start gdm
[12:02] <mdz> there is no nvidia-glx for amd64
[12:02] <fabbione> m_tthew: ah
[12:02] <fabbione> ok
[12:02] <mdz> you'd need an i386
[12:02] <fabbione> never mind
[12:02] <m_tthew> crap
[12:03] <m_tthew> I can test x86
[12:03] <m_tthew> "give me about 20 minutes
[12:03] <fabbione> m_tthew: thanks
[12:04] <mdz> I knew this nvidia binary driver was crack, but I did not realize the extent
[12:04] <mdz> breaking things when you don't even use it
[12:04] <mdz> it will need to be some kind of taint flag in all bug reports
[12:04] <m_tthew> mdz: the binary driver thing is such a drag and I didn't really grok that until I read all this stuff about nvidia
[12:05] <m_tthew> fabbione: np, just waiting on the iso; it is my pleasure to help
[12:05] <fabbione> m_tthew: i really really appreciate it
[12:05] <mdz> we will collect all such bug reports in a special place and point people there when they ask about binary drivers
[12:05] <m_tthew> fabbione: daily iso the right stuff?
[12:06] <m_tthew> mdz: haha
[12:06] <m_tthew> fabbione: more like 45 minutes, but we'll get there
[12:08] <fabbione> mdz: daily iso should do fine, otherwise install from the net ;)
[12:08] <fabbione> ops
[12:09] <fabbione> ^^m_tthew
[12:09] <m_tthew> I'll do the mini-iso to make this as fast as possible
[12:10] <fabbione> m_tthew: don't worry
[12:10] <fabbione> take the time you need
[12:10] <sabdfl> mdz: the only postfix bug i can find that mentions aliases is not the one about /etc/aliases.db not be there
[12:10] <fabbione> i need to get some food and take a shower
[12:10] <elmo_> will the gnome auto-magic stuff not work for my camera if it uses usb-storage?
[12:11] <mdz> sabdfl: yes, I think that one is still around
[12:11] <elmo_> ('cos it appears as /dev/sda1)
[12:11] <mdz> elmo_: by default, it'll launch the photo application, which should DTRT
[12:12] <mdz> elmo_: if it doesn't, you can uncheck the box for that, and it'll just mount it instead
[12:13] <azeem> btw, gnoppix really uses ubuntu GNOME packages in their latest beta, dunno if somebody tried it already, I did last night
[12:15] <fabbione> oh fuck.. i just closed 2 bugs and debzilla reports one more
[12:17] <fabbione> mdz: 1872 - 1881: duplicates?
[12:18] <fabbione> or should we leave them separate (for $arch)
[12:22] <mdz> fabbione: I am not sure if they are the same bug or not
[12:22] <mdz> even if they are both missing discover data, they are probabyl different devices which need to be added
[12:28] <mdz> bed
[12:28] <mdz> night
[12:31] <fabbione> good night
[12:37] <pitti> mdz: good night!
[12:58] <ross> pitti: does eject use pmount etc now?
[01:08] <fabbione> daniels: ping
[01:08] <sivang> Hi fabbione
[01:08] <fabbione> hi sivang 
[01:08] <sivang> I'd like to continue the Xfree discussion, #ubuntu then?
[01:09] <fabbione> sivang: yes, but i am almost off for today
[01:09] <sivang> oh
[01:09] <fabbione> sivang: woke at 4:50 am and it's almost 13:10 ;)
[01:10] <m_tthew> whomever made the pxe installer Just Work, I owe you a pint.
[01:10] <sivang> fabbione : boy why so early?
[01:10] <sivang> m_tthew : you still need to config mac address on the server? :)
[01:11] <fabbione> sivang: insomnia
[01:11] <m_tthew> sivang: dhcp server? yes, but I have one of those and I've been doing pxe installs of open&netbsd all week
[01:11] <m_tthew> sivang: sooo ... it was more of a filename ""; change than a MAC thing :)
[01:12] <m_tthew> fabbione: before you go, what bug # is this nvidia library mess I am working to duplicate?
[01:12] <sivang> m_tthew : i want to do the same! (I've been fighting with PXE for 2 days and gave up, even with mac address it didn't work)
[01:12] <fabbione> m_tthew: no bug number.
[01:12] <fabbione> m_tthew: they told me here on irc
[01:12] <fabbione> m_tthew: i know as much as you do :)
[01:12] <m_tthew> fabbione: delightful :) ; I'll mail mdz, what should I cc: you at?
[01:13] <pitti> ross: npmccallum said so, yes (sorry for the delay; lunch break)
[01:13] <fabbione> m_tthew: you need to install nvidia-glx and see if X crashes given that you are not using a nvidia card
[01:13] <m_tthew> fabbione : yeah, I understand (logout, restart gdm after apt-get install nvidia-glx)
[01:13] <ross> pitti: when i do eject /dev/sda to "eject" my ipod, it blocks until i physically unplug. the old eject returned straight away so i could still charge
[01:14] <pitti> ross: I did not touch that package, but I can take a look at it; can you please file a bug?
[01:14] <fabbione> m_tthew: that's it :-)
[01:15] <m_tthew> sivang: for me, the key has always been a host <hostname> { hardware ethernet <MAC>; address <IP>; filename "pxelinux.0"; next-server <my tftp server IP>; }; block in dhcpd.conf
[01:15] <pitti> ross: I'm currently busy with fixing hal, and that's high priority :-/
[01:15] <m_tthew> fabbione: ack, will email mdz with results, can CC: you once you give me an email address.
[01:15] <ross> pitti: sure
[01:15] <pitti> ross: thanks
[01:15] <fabbione> m_tthew: fabbione@canonical.com
[01:15] <pitti> ross: please assign it straigt to me (martin.pitt@canonical.com)
[01:16] <sivang> fabbione : any tasty X bugs to reproduce if we arelady talking about it? :-)
[01:17] <fabbione> sivang: not really because you have a nvidia card
[01:17] <m_tthew> fabbione: ack, will CC:
[01:17] <fabbione> m_tthew: thanks
[01:17] <sivang> fabbione : Ah! Darn, I knew I would be better off with ATI ;->
[01:26] <pitti> ross: nautilus really shows "eject" instead of "unmount" in the context menu for your iPod?
[01:26] <pitti> ross: and this hangs?
[01:37] <pitti> see you later, guys
[01:39] <thom> interdiff -z mozilla-firefox_0.99+1.0PR-0ubuntu3.diff.gz mozilla-firefox_0.99+1.0PR-0ubuntu4.diff.gz|wc -l
[01:39] <thom> 11595
[01:39] <thom> *sigh*
[01:40] <thom> more interestingly:
[01:40] <thom> interdiff -z mozilla-firefox_0.99+1.0PR-0ubuntu3.diff.gz mozilla-firefox_0.99+1.0PR-0ubuntu4.diff.gz|grep "^-|^\+\+" |wc -l
[01:40] <thom> 11232
[01:40] <thom> go mozilla, your distclean target works really well
[01:40] <thom> really.
[01:42] <elmo_> should I have to 'pmount /dev/sda1' or should it automagically mount?
[01:42] <ross> elmo_: my ipod automatically mounts if it isn't plugged in when gnome starts
[01:42] <ross> if its in when i boot it doesn't
[01:46] <elmo_> do hal/dbus write logs anywhere?
[01:49] <lamont> anybody know what CD image sabdfl was seeing the aliases.db issue with?
[02:11] <lamont> seb128: is moz-firefox yours?
[02:11] <lamont> nope.  thombos
[02:11] <lamont> s/s/st/
[02:19] <Kamion> thombost?
[02:26] <lamont> Kamion: I got tired of "fixing" it. :-(
[02:30] <Kamion> lamont: including ia64?
[02:30] <lamont> yeah
[02:31] <Kamion> can you make sure the changes are done via the required-base.py script?
[02:31] <lamont> bad juju
[02:32] <Kamion> adding 'exclude-ia64: hfsplus hfsutils libhfsp0' and excludes for the bootloader to warty.overrides should get you started, and you'll need to suck the right bits of the base system down into warty.base
[02:32] <Kamion> this way just means that it's maintainable automatically from germinate output
[02:32] <lamont> Kamion: I'm still just bootstrapping the chroot...
[02:33] <lamont> this is in warty.overrides, yes?
[02:34] <lamont> required-ia64: libc6.1
[02:34] <lamont> exclude-ia64: libc6
[02:34] <lamont> like that?
[02:36] <Kamion> don't need to exclude-ia64 that, since it isn't present on ia64
[02:37] <Kamion> you could just add libc6.1 to required in fact, less maintenance for alpha later :)
[02:37] <lamont> ah, ok.
[02:37] <lamont> what about warty.base: does it need to clone the entries?
[02:37] <lamont> or is it autogenerated?
[02:37] <Kamion> warty.base should contain what germinate spits out for your architecture
[02:37] <Kamion> in 'base'
[02:37] <Kamion>     < base tail -n +3 | head -n -2 | cut -d' ' -f1 | xargs >> "$OUT"
[02:39] <Kamion> er, prefixed with base-ia64: of course
[02:40] <Kamion> lamont: might be best to get permission to add all the ia64 entries back to the seeds?
[02:40] <Kamion> should just be kernels and bootloaders and stuff
[02:40] <lamont> Kamion: yeah, but that's not really a warty thing...
[02:41] <Kamion> yeah, but it'll make it manageable :)
[02:41] <lamont> point.  I'll chat with jdub/mdz later today about it.
[02:41] <lamont> but t-bone will be the one finding most of the missing packages...
[02:41] <Kamion> (normally, updating the debootstrap package for a seed change is a one-command operation for me)
[02:42] <Kamion> editing the script by hand was too error-prone
[02:42] <lamont> very
[02:42] <lamont> does the script build foo.buildd as well?
[02:42] <lamont> or just foo?
[02:43] <Kamion> just foo at the moment
[02:43] <Kamion> could be updated
[02:44] <lamont> Kamion: although that probably requires a buildd seed?
[02:45] <Kamion> or manual overrides for what goes in the buildd base
[02:45] <Kamion> you want the same required and a different base, right?
[02:46] <lamont> buildd's required is quite a bit shorter too
[02:46] <Kamion> oh, ok
[02:46] <Kamion> hmm
[02:47] <Kamion> might be worthwhile having the buildd list seeded somewhere, I guess, for buildd-ng ...
[02:48] <lamont> on that note, I think I'll leave it with the warty.overrides changes (libc6.1 in required, exclude-ia64 entry), and let t-bone come up with the rest of the edits as he actually bootstraps ia64.
[02:48] <lamont> Build needed 07:46:14, 4467964k disk space
[02:49] <T-Bone> lamont: gcc-3.4 won't build
[02:50] <T-Bone> lamont: and my box is fucked up. Awaiting aw to see with him whether he wants to take a look at it
[02:50] <T-Bone> lamont: i'm setting up another one on a zx2000
[02:50] <lamont> T-Bone: ok.  I'm up to dealing with gtk+2.0, etc.
[02:50] <T-Bone> lamont: well; if you have a workaround that would allow me to bootstrap stage2 without gcc-3.4, that'd be nice
[02:51] <lamont> T-Bone: fwiw, stage2 chroot debootstrapped with just gcc-3.3, coreutils, and perl carried forward.
[02:51] <T-Bone> oh
[02:51] <T-Bone> care to tell me how to do that? ;)
[02:51] <lamont> ln snapshot/*3.3.4-2*_ia64.deb stage1
[02:52] <lamont> then rename *%3a*3.3.4* to *:*3.3.4*
[02:52] <lamont> and smashArchive
[02:52] <T-Bone> gack
[02:52] <lamont> (rule 1 being "never get involved with someone more messed up than yourself" :-)
[02:53] <T-Bone> lol
[02:53] <Kamion> is rule 2 broken as often as rule 1?
[02:53] <lamont> Kamion: rule 2 is the prefix to each step of the process: "Do whatever it takes to ..."
[02:53] <lamont> bootstrapping an architecture is an _UGLY_ business. :-)
[02:54] <T-Bone> lamont: come to think of it, your trick is ugly: we're not going to bootstrap stage2 against clean warty binaries, that way...
[02:54] <lamont> right.  It's actually stage 1.5
[02:54] <T-Bone> *G*
[02:54] <T-Bone> considering how often i kill my boxes... (who said ia64 had a stable kernel??)
[02:54] <lamont> we declare stage 2 as soon as we can debootstrap _WITHOUT_ sarge binaries.
[02:54] <lamont>  06:54:48 up 15 days, 10:05,  2 users,  load average: 0.10, 0.58, 1.01
[02:54] <lamont> and that was a power outage
[02:55] <T-Bone> lamont: itanium1?
[02:55] <lamont> i2000
[02:55] <T-Bone> lamont: that doesn't count
[02:55] <T-Bone> i2000 _IS_ stable
[02:55] <T-Bone> i can kill pretty well any itanium2 box
[02:55] <lamont> I'll remember that
[02:55] <T-Bone> =)
[02:55] <T-Bone> lamont: remember my killing-fu ;)
[02:56] <T-Bone> lamont: did you succeed on building perl eventually?
[02:56] <lamont> er, and perl.
[02:56] <lamont> :-)
[02:56] <T-Bone> lol
[02:57] <T-Bone> give me 5mn to finish the setup on the zx2000
 T-Bone: fwiw, stage2 chroot debootstrapped with just gcc-3.3, coreutils, and perl carried forward.
[02:57] <T-Bone> hmm right. I didn't catch the meaning of "carried forward" in the first place
[02:57] <T-Bone> lamont: there's an interesting mail from thierry awaiting moderator approval on u-devel, fyi ;)
[03:01] <lamont> Kamion: so with libc6.1 in required, I shouldn't need to add the subst_package to warty.template, correct?
[03:02] <T-Bone> lamont: is db.d.o deadN
[03:02] <T-Bone> s/N/?/
[03:02] <lamont> looks that way from here, but that'd be that other channel... :)
[03:03] <T-Bone> heh
[03:03] <T-Bone> lamont: it's just that i can't fetch sbuild :P
[03:03] <lamont> wonder if it's one of these machines in disguise: down until further notice: raff, debussy, rameau, bruckner, lully
[03:04] <lamont> ia64?
[03:04] <T-Bone> yap
[03:04] <T-Bone> lamont: db is newsamosa
[03:05] <lamont> hrm.. no copy lying around on caballero.
[03:07] <lamont> semt
[03:11] <T-Bone> From:	Debian/IA64 non-US Build Daemon <buildd@caballero.debian.org>
[03:13] <T-Bone> shit happens ;^)
[03:13] <lamont> this happens, you mean?? :-)
[03:13] <T-Bone> lol
[03:14] <T-Bone> lamont: i guess i should run your script before doing the symlink stuff, right?
[03:14] <lamont> what symlink stuff?
[03:14] <T-Bone> ln snapshot/ ...
[03:14] <lamont> do _you_ see a -s there?
[03:15] <lamont> (apache won't follow symlinks...
[03:15] <T-Bone> right, i misexpressed myself
[03:15] <T-Bone> anywya, should i run your script first?
[03:15] <lamont> smashArchive creates Packages, so you'll need to do it after each change to the archive directory
[03:16] <T-Bone> oic, smashArchive is your script
[03:16] <lamont> yes
[03:16] <T-Bone> i didn't have its name in the mail, since it's inlined, my stupid webmail won't show the filename
[03:16] <lamont> poor name, but it was late...
[03:16] <T-Bone> lol
[03:17] <lamont> debootstrap uses Filename, but requires Release and an md5sum for Packages
[03:18] <lamont> anything else from you (or anyone else, for that matter) before I disappear for a few hours?
[03:19] <lamont> Kamion: I assume sounder 8 was pre-"seen debootstrap", yes?
[03:20] <lamont> T-Bone: mind you, I _tried_ symlinks first, too. :-)
[03:20] <T-Bone> lamont: heh
[03:21] <Kamion> lamont: was observing that rule 1 is broken just under half the time :)
[03:21] <Kamion> lamont: hmm, actually this might be tricky ...
[03:22] <T-Bone> lamont: asa aw has settled with my buggy box, i'll wipe /home out and rebuild it
[03:22] <Kamion> lamont: making libc6 be per-arch required (and therefore later in the required list) has been known to break things in Debian
[03:23] <T-Bone> lamont: i hope i'll have less troubles with stage 1.5. I'll only be building missing packages, for stage 1.5, i guess (gcc-3.4, perl & coreutils)?
[03:23] <Kamion> lamont: maybe sticking with the subst_package hack for now, given how close we are to warty, would be a better plan
[03:23] <Kamion> lamont: pre-"seen debootstrap"? don't understand
[03:24] <lamont> Kamion: before your fix that I need for postfix
[03:25] <Kamion> lamont: everything's before that fix, since it doesn't exist except in my home directory yet ...
[03:26] <lamont> Kamion: hence my assumption
[03:27] <lamont> Kamion: rule 1 is broken in 100% of relationships. :-)
[03:27] <lamont> generally only by one party, though. :-)
[03:31] <T-Bone> lamont: sbuild postinst is silly: doesn't check for a proxy, btw
[03:31] <lamont> sbuild assumes a functional (and apt-get update'd) chroot
[03:31] <T-Bone> lamont: nah
[03:31] <T-Bone> i'm talking about the package postinst
[03:32] <lamont> sbuild's postinst shouldn't be fetching anything, I thought.
[03:32] <lamont> or you mean /etc/source-depend*
[03:32] <T-Bone> it's trying to run update-sourcedeps, which fails if no direct internet connection is possible
[03:32] <lamont> well,actually :>
[03:32] <lamont> ubuntu doesn't believe in hacking around broken source packages
[03:33] <lamont> the mantra is "fix the package, don't kludge it"
[03:33] <T-Bone> this sounds good to me ;)
[03:33] <lamont> hrm...  I think I fixed our sbuild package...
[03:33] <lamont> yeah, but we have more ftbfs's that way...
[03:34] <T-Bone> true
[03:35] <lamont> T-Bone: off to the shower, will try to kick a gcc-3.4 build off on my chroot before I run away
[03:35] <T-Bone> lamont: that'd be nice, just in case i fail ;)
[03:36] <lamont> making the change to the sources.list line for my archive should get you where I am.
[03:36] <lamont> well, a few hours later, damn throttles.
[03:37] <T-Bone> lamont: woops, i wiped out your home on envy, i'll rebuild your .ssh folder
[03:37] <lamont> thus reminding us of the meaning of "crash and burn" machine.
[03:37] <lamont> :-)
[03:37] <T-Bone> envy:~# journal_bmap_R618276b0: journal block not found at offset 3334 on sd(8,7)
[03:37] <T-Bone> Aborting journal on device sd(8,7).
[03:37] <lamont> back in a few, then will be gone...
[04:13] <pitti> jdub: #1769, permission to upload?
[04:59] <T-Bone> lamont: dude; i thought you were off!
[04:59] <lamont> yeah, well...  I got distracted.
[04:59] <T-Bone> lamont: i'm building gcc-3.4 on my own too, just in case ;)
[04:59] <T-Bone> lol
[04:59] <lamont> really going to leave shortly
[05:00] <lamont> (or she'll kill me..)
[05:00] <T-Bone> lamont: i know that feeling ;^)
[05:01] <lamont> and you haven't met my wife. :)
[05:02] <T-Bone> lol
[05:04] <Kamion> hm, that's odd, the diff between debootstraps with old and new debconf only consists of newly set values, not newly set seen flags
[05:04] <trukulo> fabbione, e u there?
[05:08] <Kamion> oh, DUH
[05:08] <Kamion> missing 'export'
[05:19] <Kamion> now notes *don't* get marked as seen, but everything else does?!
[05:29] <Kamion> oh, of course, I turned off DEBCONF_ADMIN_EMAIL
[05:35] <myk> carlos: ping
[05:36] <carlos> myk: pong
[05:36] <myk> is there any way to distinguish between releases in mirroring the package archive?
[05:37] <myk> well, i guess my question is
[05:37] <myk> will the growth in size be in the package archive or the ISO archive?
[05:37] <carlos> myk: I don't know those details
[05:37] <carlos> elmo_?
[05:37] <myk> carlos: who should I ask?
[05:38] <carlos> or perhaps mdz, I'm not sure
[05:39] <elmo_> carlos: yeah?
[05:39] <carlos> elmo_: myk is preparing a ubuntu mirror
[05:39] <carlos> and wants to mirror only warty
[05:39] <carlos> but not hoary 
[05:39] <elmo_> unfortunately there isn't an easy way to do that - the easiest solution is probably 'debmirror'
[05:39] <elmo_> that should at least be in 'universe'
[05:40] <myk> debmirror?
[05:40] <myk> elmo_: the problem is limited space.  i only have about 25 gigs to play with
[05:40] <elmo_> myk: it's a mirroring script that allows you to mirror by suite (== warty, hoary etc.)
[05:40] <elmo_> myk: we're going to be changing the mirror layout, RSN so that it'll drop to more like 12Gb
[05:40] <trukulo> why not rsync?
[05:40] <elmo_> trukulo: debmirror can use rsync
[05:41] <myk> elmo_: i've never heard of RSN.  what is it?
[05:41] <elmo_> myk: basically archive.ubuntu.com will become 'main' (6Gb)+cdimages (4Gb)  and universe.ubuntu.com will contain the real space killer (17Gb)
[05:41] <elmo_> myk: ==> Real Soon Now
[05:41] <myk> haha
[05:42] <trukulo> elmo_: ok
[05:42] <myk> elmo_: ahh, okay.  sounds like i should just wait until that happens
[05:42] <myk> elmo_: will that be announced on any of the ubuntu lists?
[05:42] <trukulo> myk, you can mirror main part only, if you want
[05:42] <trukulo> and let universe out
[05:43] <elmo_> myk: yes, before and after
[05:43] <elmo_> (to pre-warn existing mirrors)
[05:43] <myk> which list? devel?
[05:43] <elmo_> myk: both, and -announce if we have it (I can't recall off hand)
[05:44] <myk> awesome
[05:44] <Kamion> the preview release announcement went to -announce I believe
[05:50] <elmo_> myk: what trukulo suggests is also an option, btw - it's as easy as adding --exclude=universe/ to the rsync command line
[05:50] <trukulo> elmo_: you need to write that in wiki
[05:51] <trukulo> of course, when you are ready for that
[05:53] <myk> elmo_: /pool/universe, eh?
[05:54] <elmo_> yeah, that's what's taking all the space
[05:54] <sivang> we ought to find a way to make nv use 100hz for ver refresh rate on FLATRONs
[05:54] <sivang> although I have overcome my flickering problem, was a nasty AC adaptor that caused this.
[06:03] <myk> oof.  20 k/s.  this'll take a bit
[06:10] <Kamion> anyone GNOMEish notice that evolution failed to build?
[06:12] <Kamion> lamont: marking noninteractive questions as seen during debootstrap doesn't seem to have any effect on postfix at all
[06:12] <Kamion> lamont: I suspect they're being asked at a priority lower than high
[06:14] <elmo_> kamion: am I good to remove old kernels?
[06:15] <Kamion> elmo_: aye
[06:16] <trukulo> umm, how can we put new packages in ubuntu?
[06:16] <trukulo> as atmel wireless drivers
[06:17] <trukulo> like this one: http://at76c503a.berlios.de/
[06:31] <npmccallum> trukulo: the atmel drivers are already in Ubuntu
[06:32] <trukulo> npmccallum, not these one
[06:32] <npmccallum> trukulo: they are in the 2.6 kernel upstream and the firmware is in our kernel package
[06:32] <trukulo> these one are for USB wifi cards
[06:32] <trukulo> as mine
[06:32] <trukulo> i can compile it, it's not a problem
[06:32] <trukulo> but it would be better to be in a repository
[06:34] <npmccallum> trukulo: send an email to the dev list propsing that we add it to the linux-restricted-modules package.  It probably won't go in until Hoary though (we are in deep freeze)
[06:35] <trukulo> npmccallum, umm, the good ones are in CVS, i'm afraid
[06:35] <trukulo> forget it, too much problems
[06:36] <npmccallum> why is that a problem? We are using the madwifi drivers from CVS
[06:36] <trukulo> ah, so i'll send email
[06:36] <npmccallum> that package is not supported anyway, so if there is a bug, tough luck :)  Its provided as a convenience
[06:37] <trukulo> :) yes, i understand
[07:36] <mdz> morning
[07:54] <thom> mdz: marnin'
[07:56] <Kamion> mdz: anyone looking at fixing the evolution build failure? #ubuntu is buzzing about it
[07:56] <mdz> Kamion: I have only begun reading bugzilla mail
[07:57] <mdz> I didn't know we had a new evolution yet either
[07:57] <mdz> is seb not aware of it?
[07:58] <Kamion> I think he's gone for the day; his upload failed to build
[08:08] <Kamion> seb128: ah, you're back
[08:08] <Kamion> mdz: #1618, ping?
[08:08] <Kamion> seb128: you know about the evolution build failure?
[08:09] <seb128> Kamion: no
[08:10] <seb128> hum
[08:10] <seb128> just looking on the build log
[08:10] <Kamion> you do now I guess :)
[08:10] <Kamion> unfortunately it makes evolution uninstallable so #ubuntu has been confused
[08:11] <seb128> yes, ok, need to bump the depends on libgtkhtml
[08:11] <seb128> fixing right now
[08:11] <Kamion> ta
[08:11] <seb128> still the same problem with eds/evolution
[08:13] <mdz> Kamion: sorry, I thought I gave blanket approval for discover1-data updates. go ahead
[08:14] <mdz> (additions anyway; those are pretty low-risk)
[08:14] <Kamion> alrighty, thanks
[08:15] <mdz> Kamion: do you intend to run the 1781 patch by joeyh?
[08:16] <Kamion> he's fine with the general idea, but yeah, I'll drop the bug a mail
[08:17] <mdz> Kamion: I stared at the debconf patch a bit, and it seems right
[08:18] <mdz> debootstrap stuff is obviously correct
[08:18] <Kamion> it turned out to be a hairier problem than I'd expected
[08:18] <mdz> having to add all those noninteractive modules is...unfortunate
[08:18] <Kamion> we need to do the same DEBCONF_ADMIN_EMAIL thing in debian-installer-utils, BTW, but that's a separate bug
[08:18] <Kamion> (apt-install)
[08:19] <Kamion> should squash all those /dead.letter complaints
[08:22] <mdz> Kamion: any clever way I can verify the fix for #1895 (alsa-base modprobe thing)?
[08:22] <mdz> I'd like to verify that debootstrap works, but I don't have a local mirror or such
[08:22] <Kamion> ah, it's awkward without a local mirror
[08:22] <Kamion> you could debootstrap on a Debian system and then install the new .deb, that might do it
[08:23] <Kamion> mdz: alternatively send me the patch and I'll try it out
[08:23] <Kamion> I'm well set up to do that kind of thing after the debconf/debootstrap testing
[08:26] <trukulo> mdz, using qemu
[08:26] <trukulo> there's a "installing ubuntu in qemu" in the wiki
[08:26] <Kamion> trukulo: wouldn't be any easier
[08:27] <trukulo> Kamion, just a hint, don't know the problem
[08:27] <Kamion> trukulo: mdz is asking for an easy way to inject a single modified package into the base system
[08:27] <Kamion> trukulo: for the problem at hand, debootstrap is already considerably easier than qemu
[08:27] <mdz> Kamion: trivial patch for 1895 sent to you
[08:27] <trukulo> umm, i agree
[08:28] <mdz> Kamion: thanks for spotting that; I had run into that but couldn't see past the end of my nose
[08:28] <trukulo> debootstrap is easier for that than qemu (and faster)
[08:28] <mdz> Kamion: I thought it was update-modules which was bombing, and meant to look at it later
[08:28] <Kamion> trukulo: and more likely to show up the problem to boot, since qemu would probably have you using the Ubuntu kernel
[08:28] <mdz> (it would be nice if the module-init-tools tools printed their names with errors...)
[08:29] <Kamion> mdz: it was kind of a guess that modprobe was failing, I hadn't really dug into it
[08:30] <trukulo> Kamion, well qemu it's an emulation of a machine, you can install debian in suse i.e. but uses ubuntu kernel
[08:30] <trukulo> (i'm not very good at english, forgive me if i am understanding wrong)
[08:30] <trukulo> sorry, you can install debian in suse, and uses debian kernel in qemu
[08:30] <mdz> Kamion: well, it was obvious once you said it, because I added modprobe commands to postinst
[08:31] <Kamion> trukulo: sure, but then you'd have to construct some kind of installation image with the Debian kernel, probably a bunch of Debian udebs to cope with that, and the Ubuntu base system; I doubt it would work very well at all.
[08:31] <Kamion> (and it would take somebody who knew the installer very well to do it)
[08:31] <mdz> trukulo: if you look at #1895, it should be clear why debootstrap is a better test environment
[08:31] <trukulo> going to see #1895
[08:31] <mdz> qemu wouldn't exhibit the problem because it only happens in a chroot with no kernel installed in it
[08:32] <Kamion> trukulo: I'm familiar with qemu, and it is indeed cool
[08:32] <trukulo> :) just trying to help
[08:32] <Kamion> np
[08:33] <trukulo> ah, i see
[08:33] <trukulo> here qemu has nothing to do
[08:33] <trukulo> ok, ok, i'll get the idea
[08:34] <trukulo> it's only debootstrap related, ok
[08:38] <Mithrandir> mdz: pong
[08:51] <mdz> Mithrandir: wanted to try to get more info out of you about that futex problem
[08:51] <mdz> but need to reboot, brb
[08:53] <Kamion> justdave: um, I don't seem to be able to select a component that isn't in the first page of the scrolly drop-down box thing
[08:53] <Kamion> I know what the component *is*, why can't I just type it?
[08:54] <Kamion> a single click on the scrollbar makes the drop-down disappear
[08:58] <mdz> if firefox could save and restore all its tabs as part of my gnome session, I would be such a happy guy
[08:58] <trukulo> mdz, no, but you can save a "group of tabs"
[08:59] <trukulo> i imagine you know that
[08:59] <mdz> I had been using the tabbrowser extensions to do that sort of thing
[08:59] <mdz> but it broke with some firefox upgrade
[08:59] <trukulo> firefox can make it without extensions, as i know
[08:59] <Mithrandir> mdz: opera does that for me, one of the reasons I'm sticking with it.
[09:00] <Mithrandir> mdz: what do you want me to debug wrt the futex bug?
[09:00] <mdz> I believe the word is BONG
[09:00] <mdz> Mithrandir: find out what caused it to start happening, and why it doesn't happen to anyone else? :-)
[09:00] <Mithrandir> mdz: strace makes the problem go away; we don't have snapshot.ubuntu.com, do we?
[09:01] <mdz> Mithrandir: we don't have it all apt-ified and nice, but we have copies of all packages
[09:01] <trukulo> mdz, if you save bookmarks in a folder
[09:02] <trukulo> you can open folder directly
[09:02] <trukulo> and there you have, grouped tabs
[09:02] <trukulo> Mithrandir, same for you
[09:02] <trukulo> right button on folder and: open in tabs
[09:03] <Mithrandir> trukulo: bookmarks don't preserve history.
[09:03] <Mithrandir> so it's useless.
[09:03] <Mithrandir> and it's a large number of clicks when I restart the browser, which is annoying.
[09:04] <Mithrandir> mdz: can I get to them?  If so, I could install into another drive on the same machine and do a binary search.. possibly, at least.
[09:04] <trukulo> Mithrandir, that's right
[09:08] <Mithrandir> mdz: assuming that the patch in http://lists.debian.org/debian-amd64/2004/08/msg00162.html works for fixing autofs -- permission to upload? (#1880)
[09:14] <mdz> Mithrandir: yes
[09:15] <mdz> Mithrandir: regarding the morgue, you'll need to ask elmo
[09:15] <Kamion> mdz: Setting up alsa-base (1.0.5a-1ubuntu5) ...
[09:15] <Kamion> I: Configuring alsa-base...
[09:15] <Kamion> FATAL: Could not load /lib/modules/2.6.8-powerpc/modules.dep: No such file or directory
[09:15] <mdz> Mithrandir: I'd try backing out your kernel first
[09:15] <Kamion> but it then continues successfully
[09:15] <Kamion> (as expected)
[09:15] <mdz> ah, phew
[09:16] <mdz> thanks for the test
[09:16] <mdz> uploaded
[09:16] <Mithrandir> mdz: iirc, it's the one I installed with.
[09:17] <Kamion> hm, I'd like to have the component name listed in bug lists
[09:17] <mdz> Mithrandir: oh, you've never let apt upgrade your kernel?
[09:17] <mdz> Kamion: yeah, that's a weird bugzilla-land difference
[09:17] <Mithrandir> I don't think so, but I don't remember, this is just my workstation at the university.
[09:18] <Mithrandir> mdz: I can look at it when I sit down tomorrow
[09:18] <mdz> Mithrandir: ok, thanks
[09:21] <T-Bone> lamont: ping?
[09:25] <mdz> Kamion: any reason not to move pcmcia-cs out to ShipSeed for the next daily?
[09:26] <Kamion> mdz: not that I know of
[09:28] <mdz> done
[09:28] <thom> mdz: permission to upload for #1349 ?
[09:29] <mdz> thom: yes, thanks
[09:29] <thom> mdz: ta.
[09:30] <Kamion> #1826 raises a good point, distinct from the very-hard-to-solve general problem of figuring out whether all partitions are big enough
[09:30] <thom> although space is no longer at a premium, so it's not so urgent to get rid of source packages :-)
[09:30] <Kamion> mdz: mind if I make archive-copier stop copying Supported? It's useless until we have better integration in base-config to set up a proper apt archive for it, and all it achieves right now is to eat space by copying stuff that will just be deleted later
[09:31] <mdz> Kamion: right
[09:31] <mdz> no objection
[09:33] <mdz> hmm
[09:33] <mdz> samba-common just asked me a bunch of questions when it was upgraded
[10:14] <sivang> what's the state of the FAT32 fsck bug?
[10:14] <sivang> or it's bug#
[10:17] <Kamion> sivang: see ubuntu-users
[10:18] <Kamion> I'm assuming you mean the problem where Windows no longer boots after an Ubuntu install?
[10:26] <sivang> Kamion : this also :-)
[10:27] <mdz> Kamion: I think he meant the bit where fsck.vfat complains all the time
[10:27] <sivang> mdz : hmm, yes. sorry for being so obscure.
[10:28] <sivang> The thing with fat32/windows installations boot up already worked, I mean grub knew how to detect it.
[10:28] <sivang> or whatever script that did ut
[10:28] <sivang> it
[10:28] <sivang> I'll test again with today's daily
[10:31] <sivang> mdz : is there a known list for the nv driver limitation list? (the opensource one)
[11:26] <sivang> Kamion : any way to rerun the script that supposed to configure grub automagically for other OSs ?