[12:01] <mako> comments before i send this to thombot?
[12:02] <mdz> mako: why are the install CDs bold, but not the live CD?
[12:02] <mako> because you made them that way?
[12:02] <mako> i think it's a plone stylsheet thing
[12:02] <mako> because the tope ones are <dt> and the bottom one i just a link
[12:02] <mako> i can bold the bottom one too
[12:03] <crimsun> it might also be useful to succinctly note if the live cd differs from the installation cd
[12:05] <mako> mdz: ok.. fixed
[12:05] <mako> i think that looks quite nice actually :)
[12:05] <mdz> mako: looks TOTALLY FRICKIN AWESOME
[12:06] <pitti> mako: why is there only a link to the amd64 cd?
[12:06] <mdz> mako: fwiw, I think you might be able to hand it to Kamion, if he comes around before thom
[12:06] <mako> pitti: because that's not hte archive.. that's just a file i touched to make sure the directory index showed up and looked ok
[12:06] <elmo> mdz: do you happen to have flac somewhere that has a Sources.gz ?
[12:06] <pitti> mako: ah, ok
[12:07] <elmo> if not, don't worry
[12:07] <ogra> mako: nice page :)
[12:07] <mako> ogra: most credit goes to mdz
[12:08] <ogra> pitti: click it, its quite a small iso ;)
[12:09] <mdz> elmo: I don't, but I could do it trivially
[12:09] <mdz> mako,ogra: my design skills suck; all the credit goes to the plone CSS
[12:10] <mako> mdz: seriously :)
[12:10] <mako> mdz: that is a wonderful little tools i've used a few times
[12:10] <ogra> heh
[12:11] <elmo> mdz: doesn't matter - done
[12:11] <ogra> mako: the jigdo link has two backslashes too much
[12:11] <elmo> I've also disabled syncing for now - I'll fix it to still update MOM tomorrow
[12:12] <mako> ogra: thanks
[12:13] <mako> ogra: i was just about to send that off
[12:13] <pitti> night everybody
[12:13] <mdz> elmo: perfect, thanks
[12:13] <mdz> pitti: night
[12:13] <ogra> pitti:  night
[12:19] <mdz> ogra: was your network interface detected on the live CD?
[12:20] <ogra> yup, both :-D
[12:20] <ogra> prism2 11mbit and a e100 onboard 
[12:20] <amu> mdz: ethernet yes, ipw2200 no 
[12:21] <mdz> ok, so this is a problem with the non-monolithic build
[12:21] <mdz> it looks like busybox depmod is broken
[12:24] <mjt> in what way it is broken?
[12:25] <mjt> it does not look at /lib/modules/../modules.alias, and it does not handle *?[]  wildcards in aliases
[12:25] <mjt> and it does not check if a module is already loaded... and it does not transform - into _ as module-init-tools depmod does.
[12:25] <mjt> Anything else? ;)
[12:25] <mjt> er
[12:26] <mjt> s/depmod/modprobe/.  stupid /me ;)
[12:26] <mjt> (i don't expect depmod in busybox to work at all)
[12:27] <mdz> mjt: depmod
[12:27] <mjt> yeah -- that's why i said i'm stupid ;)
[12:28] <mdz> it doesn't seem to update the map files
[12:28] <mjt> it does not know about them 
[12:28] <mdz> at least not completely
[12:28] <mjt> just avoid using it, use real depmod from m.i.t.
[12:28] <mjt> ;)
[12:29] <elmo> oh, that's cool, I don't need to do anything for the MOM stuff - it's already separate
[12:29] <mdz> is it already part of the udeb?
[12:30] <mjt> depmod?  Should it?
[12:30] <mjt> i mean, there's no real need to use depmod "from" d-i, is it?
[12:31] <mdz> how does it work presently?
[12:31] <mdz> is depmod run ahead of time and placed in one of the udebs?
[12:31] <mdz> (its output)
[12:31] <mjt> no idea ;)
[12:31] <mdz> in d-i, the modules are split up into many udebs
[12:32] <mdz> I'm not sure where the modules.dep and friends come from
[12:32] <mdz> gah, just discovered that the version of alsa-base on the image is missing the unmuting code
[12:32] <mdz> particularly annoying for the live CD
[12:33] <mdz> lamont: how are things on your front?
[12:33] <chrisa> dato: heard from julian yet?
[12:35] <mjt> mdz: i really dunno how it works now. but i think it's pretty simple to either get real depmod (there should be udeb for mit, as busybox module stuff is quite.. problematic on 2.6 kernel anyway), OR by providing partial modules.*map files in kernel udebs
[12:35] <mdz> yes, there is a udeb
[12:35] <mdz> I don't think it makes sense to try to provide partial ones and merge them
[12:35] <mdz> I'm just wondering how this ever worked
[12:36] <mjt> using discover to determine which modules to load?
[12:36] <mjt> (instead of those .*map files)
[12:37] <mdz> I mean now
[12:37] <mdz> in hoary
[12:37] <mdz> this has worked for me
[12:37] <mdz> but on this test image, my ethernet driver isn't even listed in pcimap
[12:37] <mjt> btw, now modules.*map files may be declared obsolete it seems, because of modules.alias which holds everything in *map files
[12:38] <mjt> (and more)
[12:38] <mdz> it does not hold everything in pcimap
[12:38] <mdz> at least not in 2.6.10
[12:38] <mjt> too bad i never ever installed debian or ubuntu (but use debian for several years now)
[12:38] <jdub> elmo: ping
[12:38] <jdub> hi all
[12:39] <mjt> what's "everything" ?
[12:39] <karim> where does dpkg stores wich file are on hold ?
[12:39] <azeem> karim: that's a question for #ubuntu
[12:39] <mdz> mjt: what's ambiguous about "everything"?
[12:39] <mdz> there is information in pcimap which is not in modules.alias
[12:39] <karim> azeem: that will not be answered there
[12:39] <mjt> mdz: the last column you mean -- driver data?
[12:39] <karim> unless you answer there :)
[12:40] <elmo> jdub: ?
[12:40] <jdub> elmo: anything in NEW atm?
[12:40] <azeem> win25
[12:40] <azeem> bah
[12:40] <elmo> jdub: nope
[12:41] <jdub> elmo: did you see ubuntu-calendar come through?
[12:41] <mdz> the masks
[12:41] <elmo> jdub: no, I pre-added all the months?
[12:41] <jdub> for some reason, u-c didn't come through; u-c-j did though
[12:42] <elmo> oh
[12:42] <mjt> mdz: the masks ARE in modules.alias
[12:42] <elmo> I'm spethial
[12:42] <lifeless> elmo: hey there
[12:42] <elmo> jdub: sorry, I only did u-c-j; the "masssage into w-s from w-u" is stil lBYHAND
[12:42] <mjt> mdz: "transformed" into *?[] -style wildcards
[12:42] <elmo> lifeless: hey
[12:42] <jdub> elmo: upload again?
[12:43] <lifeless> you know that the admins address is bustified ?
[12:43] <elmo> jdub: no, i'm doing the B YAND now
[12:43] <jdub> elmo: ok, thanks :-)
[12:43] <elmo> lifeless: it's kind of busted ;) but  yeah
[12:43] <jdub> that'll make people happy
[12:43] <lifeless> did you get my mail about davis ?
[12:43] <lifeless> cause I'm gonna nag you about davis.
[12:43] <jdub> changelog date for that package is like, 22nd or something ;)
[12:43] <mdz> the class mask seems to be broken up into three fields
[12:43] <mdz> this is so much less readable
[12:44] <jdub> mdz: permission to upload new version of gamin? two fixes only
[12:44] <mdz> and less parseable
[12:44] <mdz> jdub: new upstream, you mean?
[12:44] <jdub> mdz: yeah
[12:44] <mdz> jdub: you read the diff?
[12:44] <mdz> as long as you know what's going in, yeah, sure
[12:44] <elmo> lifeless: yeah, I'm at the DC atm tho, and have to go in 15 mins - I'll look at it tomorrow tho
[12:45] <elmo> spethial hotel I'm at wants something like 4UKP an hour for wireless too. freaks.
[12:45] <lifeless> elmo: thanks! then I can resume ppc builds.
[12:45] <mdz> daniels: I am still looking for you
[12:49] <mjt> mdz: it's baseclass, subclass, interface (all 1-byte)
[12:50] <mjt> mdz: for fnmatch() (which is used in modprobe), it's trivially parseable ;)  And trivially "expandable" from fields in /sys too.
[12:51] <ogra> n8
[12:53] <opi> :)
[12:53] <opi> man, exchanging servers is a nice party ;)
[12:54] <mjt> hell.  grep is spending 88% of time in mbrtowc(), inside scary auto-generated routine named __gconv_transform_utf8_internal() ...  Ugh.
[12:55] <mjt> ...and ony 8% time in bmexec() -- which is the main re-execute loop
[12:56] <jdub> mdz: the installability report for the cd - can we generate a report like that for any set of packages without a huge chunk of work?
[12:56] <elmo> mjt: there's been a bunch of patches upstream to fix utf-8 and re speed regressions btw - I dunno what you're working off, but I thought I'd mention it
[12:56] <mjt> upstream = glibc?
[12:56] <mjt> mbrtowc() is glibc code
[12:57] <mjt> (multi-byte to wide char it is)
[12:57] <elmo> yeah
[12:57] <elmo> the posts were probably from paolo bozinni (sp?, the sed guy)
[12:58] <mjt> yeah, sed suffers badly from that prob too
[12:58] <mjt> where's the glibc-devel (?) list?
[12:59] <elmo> List-Archive: <http://sources.redhat.com/ml/libc-alpha/>
[12:59] <mjt> aargs... i was afraid it's there... :(
[01:00] <mjt> they've blocked access from our network to their server about half a year ago, and i *still* can't find anyone there who can explain what happened.
[01:02] <mjt> Paolo Bonzini
[01:02] <mjt> (going via an open proxy in .br ;(
[01:03] <elmo> gotta go get a tube.. night all
[01:03] <lamont> hrm.. 5410 inodes in the root that are not root:root.  so much for genext2fs, at least without mods.
[01:10] <mjt> elmo: well.. yeah, there's quite some optimizations in regex stuff in glibc.  Too bad grep does not use that (or, rather, it performs its own optimizations).. and mbrtowc() implementation for utf8 hasn't changed (except of small bugfixes) in a long time...  Anyway, thanks for the pointer.
[01:10] <mdz> jdub: yeah, should be simple to apply it to a given set of packages
[01:11] <mdz> lamont: yeah, I thought I mentioned before, you're really going to need root
[01:15] <lamont> mdz: yeah - trying to avoid requiring loopfs on the buildd machine
[01:19] <mdz> I think it's unavoidable
[01:20] <lamont> sparse files OK?
[01:20] <mjt> why it's needed?  
[01:20] <mdz> yeah
[01:20] <mdz> sparse files are fine for loop
[01:20] <mdz> you're just going to throw it away anyway, after compressing it
[01:21] <mjt> "`genext2fs' is meant to generate an ext2 filesystem as a normal (non-root) user. It doesn't require you to mount the image file to copy files on it. It doesn't even require you to be the superuser to make device nodes."
[01:21] <mdz> mjt: been there already
[01:21] <mjt> heh
[01:21] <lamont> ide drive performance sucks
[01:21] <mjt> maybe fakeroot can help here?
[01:21] <mdz> lamont: you're not doing this at the DC?
[01:22] <lamont> atm I'm doing the script development at my house.
[01:22] <lamont> because development is not done on the DC machines.
[01:27] <lamont> root     26721 86.5 83.1 2001472 970020 pts/10 R+   17:20   5:28 genext2fs
[01:29] <lamont> pitti?
[01:30] <amu>  pitti moved to /dev/bed 
[01:33] <lamont> mdz: did you want to know that flac_1.1.1-2 is ftbfs some places?
[01:34] <mdz> lamont: yes
[01:35] <lamont> bad assembly on ppc
[01:36] <lamont> mdz: do you even want to try a genext2fs image?
[01:36] <mdz> lamont: no
[01:36] <mdz> I've been down this road
[01:36] <lamont> ok..
[01:37] <mdz> Keybuk: around?
[01:37] <Keybuk> nope, asquare
[01:37] <mdz> Keybuk: is bugzilla up to date as far as MOM is concerned?
[01:37] <mdz> Keybuk: if so, it's time to turn off the bug filing bit
[01:38] <Keybuk> uh, no; it crashed today (slight typo) ... want me to run it now?
[01:38] <mdz> sure
[01:41] <Keybuk> gah, elmo's broken lorraine *shocker*
[01:41] <Keybuk> shall we just declare it up to date? :p
[01:43] <Keybuk> whatever he did to turn off syncs, also broke the list of needing-merge packages
[01:43] <mdz> odd, he said something about it before he left which sounded hopeful
[01:43] <mdz> Jan 06 15:29:46 <elmo>  oh, that's cool, I don't need to do anything for the MOM stuff - it's already separate
[01:44] <mdz> Keybuk: anyway, yeah, just draw a line in the sand
[01:44] <Keybuk> when shall we draw the line?
[01:44] <mdz> 'now' sounds about good
[01:46] <lamont> mdz: on the + side, this doesn't build the entire FS in core.
[01:47] <Keybuk> mdz: ok, no more bugs
[01:47] <mdz> lamont: doing so isn't a half bad idea, for the DC machines ;-)
[01:47] <mdz> Keybuk: thanks
[01:47] <lamont> yeah - I only have 1.12GB in my machine.
[01:48] <lamont> mdz: but _you_ can explain the lofs to elmo...
[01:49] <mdz> lofs?
[01:50] <lamont> loop
[01:50] <lamont> lo fs.
[01:50] <lamont> sorry
[01:52] <lamont> you want the script, or the compressed image?
[01:53] <mdz> right now? or for the ongoing process?
[01:53] <mdz> I could use a compressed image right now
[01:53] <mdz> going forward, it should go someplace where Kamion can get at it to do daily CD builds
[01:53] <mdz> either way, the script can be your dirty little secret
[01:54] <jdub> one of many
[01:54] <mdz> jdub: dude, we are going to have a DVD with all of main + a live image for hoary
[01:54] <mdz> for every arch
[01:58] <lamont> mdz: and it defaults to live, or install?
[01:59] <jdub> mdz: and massive torrent love ;-)
[01:59] <lamont> right.  I still need to wrap a debian package around the beast, etc, etc
[01:59] <mdz> lamont: the eternal question
[01:59] <lamont> I'll get you the compressed image once I run the script in the DC>
[01:59] <jdub> mdz: hrm, wonder how much dvds would cost to ship...
[02:00] <lamont> overall 33%
[02:00] <mdz> jdub: I have a feeling we'd come out ahead, compared to 2xCD
[02:00] <mdz> less packaging, less weight
[02:00] <mdz> more expensive media
[02:00] <lamont> -rw-r--r--  1 root root 519336845 2005-01-06 18:00 livecd.cloop
[02:00] <lamont> that gonna fit???
[02:00] <mdz> wow, that's smaller than the one I have here
[02:00] <mdz> but yeah, no problem at all
[02:01] <mdz> I'd be grateful if you could give it some sanity checks before I download the beast
[02:01] <mdz> chroot into it, make sure everything looks OK
[02:01] <lamont> hrm.. wonder if this'll run in a chroot...
[02:01] <jdub> ooh, i could actually run a livedvd
[02:01] <jdub> mdz: could you install packages from the dvd when running the livedvd portion? that'd be rad ;)
[02:03] <Kamion> mdz: um, depmod works just fine on the install CD
[02:03] <Kamion> mdz: hw-detect calls it each time it's run, it's great
[02:03] <Kamion> mdz: we already include both busybox-cvs and module-init-tools on the install CD's initrd ...
[02:03] <Kamion> mdz: this is why I want you guys using the same initrd as the install CD :)
[02:05] <mdz> jdub: absolutely
[02:05] <mdz> Kamion: grep e1000 /lib/modules/`uname -r`/modules.pcimap turned up nothing
[02:05] <Kamion> unfortunately I'm only here for about one more minute because I'm being harassed to go to bed :)
[02:05] <mdz> though e1000.ko was in the module tree
[02:06] <Kamion> check that module-init-tools-udeb is being unpacked after busybox-cvs-udeb
[02:06] <mdz> how do I check that?
[02:06] <Kamion> initrd build log, you can watch it
[02:06] <mdz> oh
[02:06] <Kamion> and the normal d-i initrd build process furthermore calls depmod itself
[02:06] <mdz> I'm using the initrd that came on the CD
[02:06] <mdz> and hacking it up
[02:06] <mdz> not building one at all
[02:07] <Kamion> that's more trouble than it's worth in the long run, in my experience
[02:07] <Kamion> too error-prone
[02:07] <mdz> Kamion: sure, but it needs to be called after new modules are unpacked
[02:07] <Kamion> it is
[02:07] <Kamion> 01:03 < Kamion> mdz: hw-detect calls it each time it's run, it's great
[02:07] <mdz> but it isn't doing the right thing
[02:07] <mdz> I called it by hand
[02:07] <mdz> and the pcimap was still not up to date
[02:08] <mdz> where does the m-i-t depmod end up?
[02:08] <Kamion> if this were happening on the install CD, installs would not be working correctly
[02:08] <mdz> I only see /sbin/depmod which points to busybox
[02:08] <Kamion> it just overwrites the busybox one
[02:08] <mdz> ok, then it's not in the initrd
[02:08] <mdz> ohhh
[02:08] <mdz> I unpacked a new busybox-cvs over it
[02:08] <mdz> because I needed the new version
[02:08] <mdz> that explains it
[02:08] <Kamion> that would be it :)
[02:09] <Kamion> right, build initrds the normal way and you won't have a problem. :)
[02:09] <mdz> how long before my changes propagate into a d-i build?
[02:10] <Kamion> daily-installer builds happen nightly, each one waits for byhand processing
[02:10] <Kamion> elmo's usually pretty prompt with them
[02:10] <Kamion> I've just changed the cdimage config to use daily-installer, it had temporarily been using the uploaded one
[02:10] <Kamion> anyway, I really have to go now, back c. 9:30 UTC
[02:11] <Kamion> I'll be doing a new proper build for 2.6.10 and rescue-check soonish anyway
[02:11] <Kamion> tomorrow if all the required stuff is in main
[02:24] <lamont>   linux-386: Depends: linux-restricted-modules-386 but it is not going to be installed
[02:24] <lamont> hoary ain't happy in the DC atm.
[02:25] <mdz> generating a proper initrd will require a useful /dev and /proc in the chroot
[02:25] <mdz> (assuming that's the issue)
[02:25] <lamont> mkinitrd == bin/true
[02:25] <lamont> this is purely dependency issues
[02:27] <lamont>  linux-restricted-modules-2.6.10-1-386 doesn't exist in the archive, but linux-meta points there.
[02:27] <mdz> oh, oops
[02:27] <mdz> no, I think it truly doesn't exist yet
[02:27] <mdz> daniels was working on it, as I recall
[02:28] <mdz> Jan 03 16:53:11 <daniels>       mdz: l-r-m is my first priority after xorg, so should be tomorrow by the time I've run it around all the buildds
[02:28] <mdz> Jan 03 16:53:53 <daniels>       mdz: (i also have an engagement tonight, so losing a couple of hours off today, making it up tomorrow, so probably won't quite get to a new upstream l-r-m, especially as it needs patches for nvidia)
[02:29] <mdz> jdub: it's a reasonable hour over there, right?  could you ring daniels for me?
[02:29] <lamont> worst case, I'll buz the neighbor's driveway to upload bits for you mdz
[02:30] <mdz> lamont: as a workaround, you can install linux-{image,restricted-modules}-2.6.9-1-386 for now
[02:30] <mdz> instead of linux-386
[02:31] <lamont> linux-image-2.6.9-1-386 should depend restricted-modules?  or I need to install both?
[02:32] <lamont> running with both
[02:33] <mdz> you need to install both
[02:33] <mdz> the linux-386 metapackage is there to tie image and restricted-modules together
[02:34] <lamont> ah, ok
[02:37] <mxpxpod> is there a reason after using a certain theme for a long time and trying to switch it, gnome-settings-daemon needs to be restarted to switch?
[02:37] <lamont> mdz: scp chinstrap:~lamont/livecd.sh for giggles/gagging
[02:39] <lamont> mdz: there's still a little cruft left in it, and a lot of commenting needed
[02:39] <lamont> and yes, 99% of the steps require root, so the whole script does. :-()
[02:49] <lamont> Keybuk: about?
[02:49] <jdub> mdz: ok
[02:49] <jdub> mdz: moby's off
[02:50] <azeem> lamont: I'm not sure what it meant, but he 'bounced upstairs' three hours ago
[02:50] <mdz> jdub: pardon?
[02:50] <jdub> mdz: his mobile is off
[02:50] <mdz> hmm
[02:51] <mdz> any other number to try?
[02:51] <jdub> nup
[02:52] <lamont> any udevd literate folks here?
[02:52] <mdz> yes
[02:53] <lamont> why does it start in the DC when I debootstrap it, but not on my home machine, even in a chroot?
[02:55] <lamont> it's not running outside the chroot in the DC either, if that means anything
[02:56] <mdz> I wouldn't expect it to start in either case
[02:56] <lamont> I _suppose_ I could see if it was running before I start, and then kill it if it wasn't...  But that's just plain _UGLY_
[02:56] <mdz> assuming you're disabling init scripts
[02:56] <lamont> yeah - well, it did.
[02:56] <lamont> debootstrap
[02:57] <lamont> what does /sbin/udevstart do?
[02:57] <mdz> starts udevd and processes events
[02:57] <mdz> creates initial device nodes
[02:57] <lamont> it seems to be invoked directly from the udev postinst
[02:58] <Keybuk> lamont: yeah
[02:58] <mdz> ick
[02:58] <mdz> probably want to divert that, then
[02:58] <lamont> Keybuk: I need to make udev's postinst not start udevd... is that easy?
[02:58] <lamont> divert --> remove from debootstrap, add to the apt-get. blech
[02:59] <Keybuk> it doesn't, does it?
[02:59] <mdz> it didn't used to, but now it does
[02:59] <mdz> maybe_run_udevstart() {
[02:59] <mdz>   [ -e /dev/run-udevstart ]  || return 0
[02:59] <mdz> lamont: touch /dev/run-udevstart?
[02:59] <Keybuk> udevstart != udevd
[02:59] <mdz> er
[02:59] <mdz> rm -f
[02:59] <lamont> machine without udevd running (running warty, custom kernel, dc machine...), chroot'ed, debootstrapping a chroot inside that.
[02:59] <mdz> Keybuk: doesn't running udevstart cause udevd to be started?
[02:59] <Keybuk> mdz: no, udevstart runs udev directly
[03:00] <lamont> udevd winds up owning chroot/chroot/dev, and things get sicker from there
[03:00] <Keybuk> udevd gets started on the first event that doesn't happen through udevstart
[03:00] <Keybuk> (at least that's how it was a couple of weeks ago)
[03:00] <lamont> I can't imagine any events for udevd in the DC machine...
[03:01] <lamont> Keybuk: I need to wind up with udev installed, but not actually _doing_ anything until the _NEXT_ reboot... is painful?
[03:02] <lamont> mdz: I think the 'see if it's running and kill it afterwards if it wasn't' trick is starting to sound more sane...
[03:03] <mdz> Keybuk: nothing should be triggering events within the chroot, surely
[03:04] <mdz> lamont: anything a good fuser -mk wouldn't cure?
[03:05] <Keybuk> only udevsend will start udevd
[03:05] <Keybuk> are you sure it's not just running from before?
[03:06] <Keybuk> UDEV_NO_UDEVD=1  ... does that help?
[03:11] <zul> i know i probably asked this already at one point but for the merge bugs in bugzilla what do you need to be attached to the bug for it to be accepted?
[03:11] <lamont> mdz: sounds like it could./
[03:23] <lamont> mdz: we'll see how fuser -mk does in just a couple of minutes
[03:28] <daniels> fabbione: still haven't got my phone back :\
[03:28] <lamont> daniels: they still found you, eh?
[03:28] <daniels> mdz: consider me found.  connection has been utterly shitty, so I went to uni to attempt to find connectivity there, but I can't SSH out any more.
[03:29] <daniels> yeah, I've got l-r-m 2.6.10
[03:30] <daniels> it's here and I think it's good to go, just needs another quick build test across all architectures
[03:30] <daniels> 2.6.10 broke a few things :\
[03:35] <daniels> fabbione: any news on xorg/sparc?
[03:35] <daniels> fabbione: oh, GO.  thanks.
[03:37] <lamont> mdz: so, once this finishes here, I'll run the image down the street and upload it for you...
[03:37] <lamont> I'm disinclined to see if I can crash a second machine in the DC...
[03:38] <lamont> mind you, I don't _KNOW_ that's it...
[03:39] <daniels> FUCK ME
[03:39] <daniels> MJG59
[03:39] <daniels>         - DRI suspend/resume support
[03:39] <daniels>         - Detection of monitor changes on VT switches
[03:39] <daniels>         - Support custom video modes if available in the Video BIOS
[03:39] <daniels> mjg59: tungsten just made i810 LOVE
[03:49] <lamont> mdz: on the end system, do the cdrom's fs size and numinodes matter?
[03:57] <lamont> -rw-r--r--  1 root   root    519336845 2005-01-06 18:00 livecd.cloop
[03:57] <lamont> bbiab
[03:59] <daniels> lamont: you didn't notice that xorg was ftbfs on ia64?  surely this is the lamont of legend?
[04:00] <lamont> daniels: don't even go there.
[04:00] <mdz> daniels: does this batch of Xorg stuff also have what I need for the live CD?
[04:00] <lamont> daniels: I didn't get any email, you see...
[04:01] <mdz> lamont: end system?
[04:01] <lamont> liveCD as it finally shows up for the user
[04:01] <lamont> that is, livecd.cloop is the start of that filesystem, do we care what it's size/numinodes is?
[04:01] <lamont> are, even
[04:02] <mdz> it should be as small as possible while still containing everything we want
[04:03] <mdz> the absolute upper bound is about 620M or so
[04:03] <mdz> but that would leave no room for the opencd stuff at all
[04:03] <mdz> doesn't matter how many inodes it has
[04:03] <mdz> er
[04:03] <lamont> it's currently a 1500000*1024 byte file, with default numinodes.
[04:03] <mdz> are you talking about the compressed size or the uncompressed size?
[04:03] <mdz> ah, uncompressed
[04:03] <lamont> uncompressed
[04:03] <mdz> the entire desktop system fit in 1.5 gigs?
[04:03] <lamont> compressed is 519MB
[04:04] <lamont> 1.43Gb
[04:04] <mdz> that's odd
[04:04] <mdz> last I checked, it was more like 1.8
[04:04] <lamont> ls -ls livecd.fsimg 
[04:04] <lamont> 1463952 -rw-r--r--  1 lamont lamont 1536001024 2005-01-06 17:45 livecd.fsimg
[04:04] <mdz> how much free space on it?
[04:05] <lamont> /dev/loop0             1476384   1438916         0 100% /home/lamont/chroots/a/livecd.mnt
[04:05] <mdz> ok
[04:06] <mdz> bump it up to an even 2G to leave some space to breathe
[04:06] <lamont> having it full kinda hurts towards the ends.
[04:06] <daniels> mdz: not quite.
[04:06] <lamont> yeah, will do that as I pretty things up
[04:06] <lamont> but I'm gonna go upload this image now.
[04:06] <daniels> mdz: i've been doing the sync from debian + outstanding patch sweep for xorg plus a couple of other fixes, and l-r-m after that
[04:06] <daniels> mdz: but i'm wandering one day into the weekend, so i still have time to check it out this week
[04:07] <lamont> daniels: let me know when you upload l-r-m, eh?
[04:07] <mdz> I'm not sure that image will even boot
[04:07] <daniels> mdz: i'm expecting to do an upload next week with all the i8xx love, so we can finally support widescreen laptops properly
[04:07] <lamont> mdz: ah, so no point in uploading?  it's cold outside, you see...
[04:07] <mdz> lamont: no point
[04:07] <lamont> ok
[04:07] <mdz> lamont: I would like an updated image, but can't you build it at the DC?
[04:08] <daniels> mdz: if you export XORGFORCEPROBE (or whatever it is) and run dpkg-reconfigure -pcritical xserver-xorg, you should get a decent approximation of what you want
[04:08] <mdz> or does that need admin hands?
[04:08] <mdz> daniels: I don't
[04:08] <daniels> mdz: arse
[04:08] <daniels> mdz: i'll take a look at tonight/tomorrow
[04:09] <daniels> mdz: could I also please get an exemption from UVF for lrm?
[04:09] <daniels> mdz: i'm sitting on a beta of fglrx now with xorg, amd64, and proper pcie support
[04:09] <daniels> as well as a hojillion bugfixes
[04:10] <crimsun> mdz: out of curiosity, the flac 1.1.1-2 packages in incoming requires all packages to be rebuilt against the new libflac-dev, correct?
[04:10] <mdz> daniels: l-r-m is a breakage that needs to be fixed
[04:11] <mdz> crimsun: requires in what way?
[04:12] <crimsun> mdz: I have a libFLAC++.so.4 and a libFLAC.so.6 (and their corresponding dev symlinks). Thus the packages that rely on the existence of libFLAC.so.4 need to be recompiled?
[04:13] <crimsun> (e.g., the soname bump for the C++ wrapper makes sense; I'm just trying to ensure I'm not missing any strange symlinks)
[04:14] <mdz> oh, I see what you mean
[04:14] <mdz> normally, this wouldn't be a problem, except for the mistake
[04:14] <mdz> so there is no valid libflac4 package anymore
[04:15] <mdz> so yes, everything needs to be recompiled
[04:15] <crimsun> gotcha, thanks muchly.
[04:17] <daniels> mdz: yes.  i have 2.6.10-1 now pretty much ready to go and will upload that very soon, but after that there's a new fglrx (i.e. 2.6.10.1-1)
[04:18] <daniels> mdz: so we'll have lrm 2.6.10 today, but i can't release new fglrx until next week or such
[04:22] <mdz> daniels: what bugs does the new fglrx fix?
[04:24] <daniels> mdz: a) lack of amd64 support, b) lack of xorg support (i.e. complete no-go for hoary), c) many rendering issues (i.e. random polygons, crashes, and random misshapen textures) in a fair few games, e) adds support for pci express cards
[04:25] <stub> I need to get postgresql-contrib moved to main for hoary. We are using it internally in launchpad for full text indexing.
[04:26] <daniels> mdz: unfortunately, being binary, i don't have total visibility into the driver, but from what I've seen of the feedback on the list so far, it seems to be quite solid and far more reliable than the old
[04:28] <lamont> mdz: of course, the image would be bigger if I didn't 'apt-get clean' before building it... :-)
[04:39] <mdz> daniels: lack of l-r-m 2.6.10 is blocking lamont's work on building live cd stuff, so be sure to get it in today
[04:41] <usual> hi
[04:41] <daniels> mdz: understood
[04:44] <lamont> mdz: btw, places I see with hardcoded hostname: /etc/hostname, /etc/mailname, /etc/postfix/main.cf
[04:44] <lamont> and resolv.conf is kinda custom
[04:45] <mdz> lamont: hostname will be taken care of by d-i
[04:45] <mdz> mailname and main.cf, ick
[04:45] <mdz> resolv.conf gets fixed up for us too
[04:45] <lamont> base-installer does a dpkg-reconfigure of postfix, iirc.
[04:45] <mdz> we want this image to be as vanilla/unconfigured as possible
[04:46] <lamont> but Kamion knows for sure
[04:46] <mdz> we don't use base-installer in the live cd
[04:46] <mdz> so probably I need to emulate that
[04:46] <lamont> I know - meant for the logic
[04:46] <mdz> Kamion: ^^^ when you're back
[04:47] <lamont> for meta data and such
[04:49] <mdz> lamont: how much free space does that leave?
[04:49] <mdz> should be at least a few hundred meg
[04:50] <lamont> that was the question I had earlier - they do inherit what we gave them, then?
[04:50] <lamont> so leaving them with 20 inodes or so would be unreasonable, I expect...
[04:52] <lamont> should we go with 10000 inodes, 700MB (free, in both cases)?
[04:52] <lamont> or closer to 400MB?
[05:46] <daniels> new lrm orig tarballs are nasty.
[05:46] <lamont> mdz: livecd also has to force a paper selection based on locale, I expect.
[05:48] <mdz> lamont: leave the default inodes, say 400MB free
[05:48] <mdz> I don't think many folks have enough RAM to make use of more
[05:49] <mdz> I wouldn't mess with the inodes
[05:49] <lamont> it used 77000 of the 180000 inodes that the default gave it... I'm inclined to shrink it just to see how much we save - that build is just about to the point of compressing the fs
[05:50] <lamont> inum calc was easier than the size calc anyway...
[05:50] <lamont> SZ=$(python -c "print int($(du -sk $ROOT|sed 's/[^0-9] .*$//')*1.1+$USZ)")
[05:50] <lamont> INUM=$(python -c "print $(find ${ROOT} | wc -l)+$UINUM")
[06:01] <lamont> hrm.. then again, 10000 inodes and 400MB is 40KB/inode
[06:05] <lamont> -rw-r--r--   1 root   lamont  524056539 2005-01-06 22:04 livecd.cloop
[06:05] <lamont> that's with 10000 inodes and 400MB
[06:05] <daniels> shit
[06:05] <daniels> elmo_away: can I please have linux-headers-2.6.10-* in concordia/davis chroots as a matter of urgency?
[06:14] <lamont> daniels: I guess that means I can get some sleep, eh?
[06:14] <lamont> daniels: fwiw, I'm not blocked on what I'm doing, but I am blocked on building usable images for mdz.
[06:15] <lamont> and I almost have the script packaged
[06:15] <lamont> then I _will_ be blocked on lrm
[06:16] <daniels> lamont: yeah, lrm's just blocked on getting l-h-* installed
[06:16] <daniels> lamont: and will be until elmo wakes up, so go get some sleep
[06:19] <lamont> yeah
[06:19] <lamont> gonna finish this measurement first
[06:19] <daniels> measurement?
[06:20] <lamont> effect of playing with numinodes on the root fs
[06:20] <lamont> for the livecd
[06:20] <lamont> [ 9]  Block#  6163 size  65536 ->     84 [compression ratio   0%, overall:  24%] 
[06:20] <lamont> I love those
[06:24] <lamont> daniels: if you run out of other things to work on... mpeg2dec dies with -lXt not found.
[06:25] <fabbione> morning
[06:25] <daniels> lamont: blegh, will check it out
[06:25] <daniels> fabbione: hey dude
[06:25] <fabbione> daniels: hey
[06:25] <lamont> morning fabbione
[06:25] <fabbione> sup?
[06:25] <fabbione> hey lamont 
[06:25] <sivang> fabbione: morning
[06:25] <fabbione> morning sivang 
[06:25] <lamont> daniels: europe's waking up.  clearly bedtime. :-)
[06:26] <fabbione> lamont: did you talk with ggg?
[06:26] <daniels> lamont: heh :) night dude, cheers
[06:26] <sivang> lamont: I just didn't go to sleep.. :) bedtime for me also :)
[06:26] <lamont> fabbione: willy was going to look at it - never heard back, but didn't poke either.
[06:26] <fabbione> ok thanks
[06:26] <lamont> quite possibly either ggg or willy is awake now
[06:27] <lamont> willy last seen 15 ago, pestering him
[06:27] <fabbione> The changelog says we are creating 2.6.10, but I thought the version is 2.6.10-1-32
[06:27] <fabbione> lamont: i think i need also kernel-package from ubuntu
[06:28] <lamont> obviously noise.
[06:28] <lamont> mdz: they can have all their inodes
[06:29] <lamont> Free blocks:              487299
[06:29] <lamont> Free inodes:              247797
[06:29] <lamont> sounds about right. :-)
[06:29] <lamont> and ~525 MB total size
[06:31] <lamont> fabbione: in the chroot, yes?
[06:31] <fabbione> ogra: i think i understand the bug noe
[06:31] <daniels> agh, once again the house is devoid of food
[06:31] <fabbione> lamont: yes
[06:31] <fabbione> that error message is something coming from it
[06:32] <fabbione> daniels: did you read my message yesteday?
[06:32] <daniels> fabbione: xorg is go on sparc?
[06:33] <daniels> fabbione: i just caught an important message about horizsync/vertrefresh options being busted when we did choose to write them out
[06:33] <daniels> fabbione: so i'm running around again
[06:33] <lamont> fabbione: hoary kernel-package installed
[06:33] <fabbione> daniels: yes. it is GO on sparc
[06:33] <fabbione> lamont: thanks
[06:33] <fabbione> lamont: testing now
[06:33] <daniels> fabbione: btw, look up -- alanh/keithw just committed sweet i8xx stuff to cvs, so we don't need 855wrap/855resolution and all that crap now :D
[06:33] <lamont> fabbione: well, the dpkg is _almost_ done. :-()
[06:33] <fabbione> daniels: i am way behind on xorg mailing lists
[06:34] <lamont> done
[06:34] <fabbione> lamont: thanks..
[06:34] <fabbione> no they didn't fix the I/O problem i
[06:34] <fabbione> it will take at least a couple of hours to get there again
[06:39] <daniels> fabbione: xorg-commit, alanh, today
[06:39] <daniels> fabbione: ignore xorg@, it's crap
[06:39] <fabbione> daniels: ENOTIME
[06:39] <daniels> fabbione: yeah
[06:40] <daniels> fair enough
[06:40] <fabbione> lkml is now my bitching ml
[06:40] <fabbione> over 300 mss/day
[06:40] <fabbione> it's insane
[06:45] <daniels> sheez
[06:45] <daniels> sounds dire
[06:50] <fabbione> [PATCH]  ALPS touchpad detection fix
[06:50] <fabbione> uhuh
[06:50] <fabbione> it's a one liner :-)
[06:51] <daniels> could you please bounce it to me?
[06:52] <daniels> anything that touches psmouse needs SERIOUS testing
[06:52] <daniels> triply so if it's alps
[06:52] <daniels> which, last I checked, grabbed a few IBM TrackPoints and random PS/2 mice as being ALPS :\
[06:52] <daniels> as well as most every Synaptics device, ALPS or not
[06:53] <fabbione> on the way
[06:53] <daniels> cheers
[06:53] <daniels> back in a few, grabbing the bus to the supermarket to acquire food (not eaten yet today)
[07:27] <jdub> http://blogs.sun.com/roller/resources/eschrock/halcyon.png
[07:27] <jdub> worst time to be sick -> summer in sydney :|
[07:28] <sivang> jdub: you poor thing..go get some timtams and tea! :)
[07:28] <jdub> oof
[07:31] <sivang> jdub: is it ever winter in sydney ?
[07:32] <jdub> yeah
[07:33] <jdub> our seasons are very different
[07:33] <sivang> jdub: I see, does it switch nicely comparing to our seasons?
[07:33] <sivang> I mean, when it's winter for me, summer for you and the other way around?
[07:34] <jdub> yes
[07:42] <sivang> jdub: cool :-)
[07:54] <daniels> mmm, food
[07:55] <daniels> jdub: xsun is very quick.  we can get the X server starting blindingly quickly on proper hardware (e.g. Radeons, nVidias -- most everything except i8xx).
[07:58] <sladen> daniels: I'm wondering if to a certain point that can be disguised.  How much of the setup delay is detection before any of the registers are actually changed?
[07:59] <daniels> sladen: not much -- that part is pretty quick, except we're now slamming /proc with about 15,000 opens
[07:59] <daniels> that's a bit of a cpu load, so i'm looking to optimise that
[07:59] <sladen> errrrrm  ?
[08:00] <sladen> why's it hitting /proc, is X not content with holding /dev/mem open?
[08:01] <daniels> sladen: probing /proc/pci
[08:01] <daniels> but instead of using readdir(), it attempts to open every possible combination of bus/device/subdevice
[08:02] <sladen> duuuuude...
[08:02] <daniels> yes, I know
[08:03] <daniels> it's in 6.8 branch
[08:03] <daniels> it fixes a problem with pci domains, to be fair
[08:03] <daniels> but yeah, I have plans to fix it
[08:03] <daniels> but not right now
[08:16] <jdub> thom: hrm, think i have libgecko-cil love with firefox
[09:35] <abelli> pitti: ding
[09:35] <pitti> Morning abelli
[09:35] <pitti> morning all
[09:35] <abelli> ciao
[09:36] <abelli> pax wont let xorg live: is it normal?
[09:37] <daniels> abelli: yes
[09:38] <abelli> ok..
[09:38] <abelli> thank you
[09:41] <Treenaks> abelli: send some money to daniels, I'm sure it'll get fixed
[09:41] <daniels> heh
[09:41] <daniels> unfortunately fixing that and using the nvidia/ati binary drivers are mutually exclusive
[09:41] <Treenaks> let's send a million threatening letters to nvidia and ati!
[09:42] <abelli> daniels: dont even mention nvidia please.
[09:42] <daniels> yeah, because that's worked in the past to get us open-source drivers :P
[09:42] <daniels> abelli: it's the main blocker with moving to a libdl-based loader (that and fglrx)
[09:43] <Treenaks> daniels: no, but it makes us feel better.. venting frustrations etc. ;)
[09:43] <daniels> heh
[09:43] <Treenaks> daniels: btw, have you seen your "transmgr" picture?
[09:43] <daniels> Treenaks: heh yes
[09:44] <Treenaks> daniels: ok, I forgot :)
[09:44] <pitti> ping daniels 
[09:44] <daniels> someone saw it and asked if I'd put on weight
[09:44] <daniels> it's not very flattering :P
[09:44] <daniels> pitti: sure, give me a URL
[09:45] <abelli> seb128: ciao
[09:46] <daniels> seb128: yo
[09:46] <daniels> seb128: do you still have the widescreen laptop?
[09:46] <seb128> morning
[09:46] <seb128> daniels: yep
[09:46] <daniels> cool
[09:46] <seb128> need some testing ?
[09:47] <daniels> yep
[09:47] <daniels> have a patch from CVS that should do away with the need for 855resolution or whatever
[09:47] <daniels> so they should all work out of the box :)
[09:47] <seb128> cool
[09:47] <abelli> daniels: what do you think about some testing with _my_ laptop, and *my* nvidia? :)
[09:47] <daniels> abelli: er?
[09:48] <abelli> i think that just because i use nvidia, having a screen that looks like leerdammer, is not so fair
[09:49] <daniels> 'leerdammer'?
[09:49] <daniels> what's the exact problem you're having?
[09:50] <Treenaks> abelli: it looks like cheese with lots of holes?
[09:50] <Treenaks> abelli: or like a human from the small town of Leerdam? :P
[09:51] <abelli> the first one
[09:51] <abelli> :)
[09:52] <daniels> abelli: ok ...
[09:53] <abelli> abelli: what does it mean sorry?
[09:54] <abelli> 1) ok ... no way i'll fix it
[09:54] <abelli> 2) ok ... please shut up
[09:54] <abelli> ?
[09:54] <daniels> abelli: i don't know what you're describing, i would need a full bug report in order to fix it
[09:55] <Treenaks> abelli: he probably wants more details :)
[09:55] <abelli> Treenaks: he has seen it in mataro...
[09:55] <seb128> abelli: I think that you need to describe the bug if you want a chance to get it fixed
[09:55] <abelli> Treenaks: ...he said: <<No idea sorry>>... :)
[09:55] <abelli> mine was just a try :)
[09:55] <seb128> abelli: is it in bugzilla ? So many guys ping with bug, not easy to remember every single bug ...
[09:56] <abelli> i don't know, i think that kinnison spotted it while using my laptop..
[10:00] <abelli> ciao
[10:00] <abelli> im off
[10:11] <daniels> abelli: oh, you had *that* laptop
[10:11] <abelli> in fact...
[10:11] <daniels> i vaguely remember it
[10:11] <daniels> i think it's a timing issue
[10:11] <abelli> i said "_my_" laptop ;)
[10:11] <daniels> well, yeah
[10:12] <daniels> i got shown a lot of laptops with a lpt of problems at matar
[10:12] <abelli> ahh..
[10:12] <Treenaks> daniels: does your client mis-transcode, or mine?
[10:12] <cartman> hmm xorg update still didn't make it to a.u.c
[10:13] <cartman> Treenaks: using a unicode charset?
[10:13] <fabbione> cartman: give the buildd the times to build it?
[10:13] <cartman> fabbione: oh I thought prebuilt packages are sent by developers
[10:13] <cartman> my bad
[10:13] <fabbione> nope
[10:13] <fabbione> it's not debian :-)
[10:13] <cartman> sorry then
[10:14] <Treenaks> cartman: I'm using UTF-8, but daniels' "" looks like he types UTF-8, that got converted to latin1, and THAT mis-converts back to UTF-8 and over the wire
[10:14] <cartman> Treenaks: daniels I don't think daniels sent last msg as unicode
[10:15] <Treenaks> cartman: I see ""
[10:15] <cartman> right
[10:15] <Treenaks> no.. 
[10:15] <cartman> funny A+sup-2
[10:16] <Treenaks> anyway, UTF-8 looks like that if you treat it as Latin1
[10:16] <Treenaks> so if you then convert your "latin1" (which is actually utf-8) to UTF-8, it breaks :)
[10:17] <cartman> U+C383 U+C2B3
[10:17] <cartman> says my hex editor ;)
[10:20] <daniels> Treenaks: mine, screen is broken
[10:20] <daniels> matar
[10:20] <daniels> much better
[10:20] <cartman> yeah
[10:20] <Treenaks> daniels: yay :)
[10:22] <seb128> jdub: http://mail.gnome.org/archives/nautilus-list/2005-January/msg00012.html <- cool
[10:42] <daniels> elmo: just the man I was looking for
[10:43] <daniels> elmo: can I please get linux-headers-2.6.10-1-* on concordia and davis (hoary chroot), and libqt3-mt-dev, libxxf86misc-dev, libxxf86vm-dev, libxtst-dev, and libxinerama-dev on concordia's hoary chroot?
[10:43] <elmo> didn't I do that already?
[10:44] <lifeless> elmo: while you're doing chroot stuff...
[10:44] <daniels> elmo: nope
[10:44] <seb128> elmo: hey. Have you seen my sync requests 2 days ago ?
[10:44] <daniels> elmo: i did get rman on halley and /dev/null unbroken though -- thanks
[10:45] <elmo> seb128: err, possibly not sorry; I managed to kill my irc client at home - can you repeat?
[10:45] <seb128> elmo: libbonobo gnome-gv gnome-pilot gnome-pilot-conduits ghfaxviewer
[10:45] <seb128> thanks :)
[10:46] <seb128> elmo: and easytag 1.99.2 from experimental too
[10:46] <Treenaks> seb128: do you have any clue on the "panel stays empty"/"nautilus doesn't start" bugs yet?
[10:47] <seb128> Treenaks: nop, gnomevfs guys are still in VAC
[10:51] <seb128> elmo: and add glib2.0 and pango1.0 from experimental too and that should be enough for now :)
[10:51] <seb128> thanks
[10:54] <cartman> and fix flac package please
[10:55] <elmo> seb128: done
[10:55] <seb128> thank you :)
[10:55] <elmo> cartman: they should be on archive.u.c by now
[10:56] <lifeless> elmo: morning :)
[10:56] <cartman> elmo hmm just updated not there. guess will take some more time.
[10:56] <elmo> lifeless: I saw you
[10:56] <lifeless> elmo: hehhe, I'll get outta your hair then.
[11:00] <ogra> fabbione: great news !
[11:00] <ogra> fabbione: anything i should do for you before rushing to the office ?
[11:01] <fabbione> ogra: try to understand why the module is loaded -> unloaded and reloaded?
[11:01] <fabbione> is there any point in the module being unloaded the first time?
[11:01] <ogra> fabbione: not to my knowing.....
[11:01] <fabbione> ok
[11:01] <fabbione> i will need to add more debugging stuff
[11:01] <ogra> fabbione: it should stay loaded...
[11:02] <fabbione> because at the first load
[11:02] <fabbione> the module automatically unloads
[11:02] <elmo> daniels: done
[11:02] <ogra> fabbione: probably its the load order
[11:02] <fabbione> it shouldn't
[11:02] <elmo> daniels: and I did do it, last time you didn't ask for linux-header-* is all, so I only installed the top level package
[11:02] <daniels> elmo: thanks dude
[11:02] <ogra> fabbione: i can experiment with that tonight and trace the module dependencys with modinfo
[11:02] <fabbione> DEBUG: AVM Fritz: pnp_unregister_driver(&fcpnp_driver);
[11:02] <fabbione> DEBUG: AVM Fritz: pci_unregister_driver(&fcpci_driver);
[11:02] <daniels> elmo: ah ok, sorry
[11:03] <fabbione> ogra: see.. it loads but later it unloads again
[11:03] <ogra> fabbione: yup...
[11:03] <fabbione> the error mostlikely is that the module does not de-register itself from mISDN core
[11:03] <fabbione> and at the second load you can see the oops when it walks the device/module lists
[11:03] <daniels> ARGH
[11:03] <fabbione> meaning that the last entry hasn't been freed properly
[11:04] <daniels> i'll be quite unhappy if the thing causing GL on original iMacs to lock up is the fix to prevent GL lockups on PC r128s
[11:04] <lifeless> daniels: hahhah
[11:05] <Treenaks> that'd suck
[11:05] <ogra> fabbione: hmm...... buggy crap, i wish we could go with i4l
[11:05] <fabbione> yeah
[11:05] <Kamion> mdz: see netcfg's base-installer script
[11:06] <fabbione> so let's build this bunch of other fixes for the kernel
[11:06] <fabbione> at lesat.. let see if they actually build
[11:08] <ogra> fabbione: i will dig the web a bit today to see if it is a workaround to run i4l instead until this really works
[11:18] <sabdfl> daniels: do we have an ATI xorg driver nowadays?
[11:28] <fabbione> sabdfl: do you mean the fglrx?
[11:29] <cartman> libflac4 is still foobared
[11:29] <cartman> trying to install /usr/lib/libFLAC.so.6.0.1
[11:29] <elmo> cartman: what version of the package?
[11:29] <daniels> sabdfl: yeah, it's in beta
[11:30] <cartman> elmo libflac4_1.1.1-1_i386.deb
[11:30] <elmo> cartman: install libflac6?
[11:30] <elmo> that's the fixed version AIUI
[11:30] <cartman> hmm
[11:32] <cartman> dpkg: error processing /var/cache/apt/archives/libflac6_1.1.1-2_i386.deb (--unpack):
[11:32] <cartman>  trying to overwrite `/usr/lib/libFLAC.so.6.0.1', which is also in package libflac4
[11:32] <cartman> still buggy
[11:33] <cartman> and still no libFLAC.so.4 installed needed by ogg123
[11:34] <elmo> ogg123 will need rebuilt with the new lib
[11:35] <cartman> what about the above error?
[11:35] <elmo> that's a bug, you can work around it for now with --force-overwrite to dpkg
[11:35] <cartman> ok
[11:45] <elmo> cartman: can you file the overwrite thing in bugzilla, by the way, please?
[11:45] <cartman> its more than that I guess
[11:46] <elmo> hmm?  no, it really is just a file overwrite for the libflac4 thing, the rebuilds are a separate issue
[11:47] <cartman> well ok
[11:47] <sabdfl> daniels: is it easy to test with the current hoary xorg?
[11:48] <daniels> sabdfl: i'm going to be doing some testing on my machine tonight -- unfortunately they're unredistributable while in beta
[11:49] <cartman> daniels: nvidia drivers?
[11:49] <cartman> or ati?
[11:49] <daniels> cartman: ati
[11:49] <cartman> okies
[11:53] <cartman> elmo https://bugzilla.ubuntu.com/show_bug.cgi?id=5276
[11:55] <elmo> cartman: thanks
[11:55] <cartman> hope it gets fixed soon. no ogg123 no sound here :/
[11:58] <cartman> daniels: when compiling kde/mplayer I got this
[11:58] <cartman> /usr/X11R6/lib/libGL.a(glxcmds.o)(.text+0x2eea): In function `glXGetMscRateOML':
[11:58] <cartman> : undefined reference to `XF86VidModeQueryVersion'
[11:58] <cartman> rm /usr/X11R6/lib/libGL.a solves it but I think somehow nvidia-glx package is responsible for this mess
[12:00] <Kamion> cartman: do you have libxxf86vm-dev installed?
[12:00] <cartman> let me check
[12:00] <cartman> nope
[12:00] <cartman> some package is missing "depends" I guess?
[12:00] <Kamion> no idea
[12:01] <daniels> cartman: you need to link with -lXxf86vm
[12:01] <daniels> nvidia-glx has a weap dep on libXxf86vm, it seems
[12:01] <daniels> which totally sucks.
[12:01] <Kamion> if kde/mplayer use XF86VidModeQueryVersion themselves, then they need to build-depend on libxxf86vm-dev
[12:01] <cartman> problem on my side then
[12:01] <daniels> Kamion: it's from libGL.a tho
[12:02] <daniels> Kamion: which would be bizzare.  because Xxf86vm was static for the longest time, and still is by default.
[12:02] <daniels> Kamion: so how it works is beyond me
[12:03] <cartman> well nvidia-glx package has far more bugs with symlinks
[12:03] <cartman> I should report them all
[12:03] <cartman> is "restricted" supported?
[12:05] <elmo> as far as possible, taking the license and lack of source into account
[12:05] <cartman> well symlink bugs can be fixed without source ;)
[12:06] <Kamion> restricted is supported, yes
[12:06] <Kamion> (oh, elmo already answered that)
[12:10] <daniels> cartman: what sort of symlink bugs?
[12:10] <cartman> daniels: you end up with /usr/lib/libGL.so being a dangling symlink after installing nvidia-glx
[12:12] <cartman> also /usr/X11R6/lib/modules/extensions/libglx.a needs to be manually symlinked to /usr/X11R6/lib/modules/extensions/libglx.so
[12:15] <cartman> well looks like you already know those issues ( http://ubuntuforums.org/showthread.php?t=7906&highlight=nvidia+glx )
[12:29] <trulux> pitti: i'm available now
[12:30] <pitti> Hi trulux
[12:30] <trulux> pitti: it would be great to have mostof things done today
[12:30] <trulux> as the next Monday school starts for me and i will have really limited time
[12:30] <pitti> sure, that'd be fine
[12:30] <trulux> pitti: the TPE engine is now finished
[12:30] <pitti> trulux: do you think you can prepare the ssp packages today?
[12:31] <trulux> pitti: i don't like what i do at school, but before i leave this for do better things i will get the secondary school graduate
[12:31] <pitti> trulux: hey, school is important
[12:31] <trulux> and move outside Spain for continue my studies in place where i can really enjoy them
[12:31] <pitti> trulux: more important than this stuff in any case
[12:32] <trulux> yes, and that's what i mean when saying limited time ;)
[12:32] <trulux> but Spain for example is not a good place for kernel hackers, here the situation is the worst of Europe, and i think i'm really enjoying low level development
[12:33] <trulux> i haven't developed any GUI application since i use computers
[12:33] <trulux> never known Glade, gtk, etc
[12:33] <trulux> last two months i've started developing with C and the kernel, and i'm learning quickly, that's the thing that matters
[12:33] <trulux> ok, back to our work
[12:33] <trulux> first
[12:34] <trulux> how's the situation of SELinux in ubuntu?
[12:34] <pitti> you asked me this already two times :-)
[12:34] <trulux> and, what about the SSP packages? we need to make a final decision on them
[12:34] <trulux> pitti: maybe :(
[12:34] <pitti> trulux: selinux: kernel support is there, no userspace support (userspace == sid)
[12:34] <pitti> trulux: ssp: we already have a decision
[12:35] <pitti> trulux: competely separate source pacakge for universe, gcc-3.4-ssp
[12:35] <elmo> pitti: hey, don't forget my question about a way to detect SSP compiled binaries, at some point pls
[12:35] <pitti> trulux: and it would be nice if it ships a binary gcc-3.4-ssp which already enables all necessary things
[12:35] <trulux> pitti: i have set a sid development chroot, if i prepare packages for it, would you prepare them for Ubuntu?
[12:36] <pitti> elmo: that's easy
[12:36] <pitti> elmo: ldd | grep -ssp
[12:36] <trulux> pitti: :)
[12:36] <pitti> elmo: second, we only make source uploads to Ubuntu, so this should not be a problem anyway, right?
[12:36] <trulux> pitti: better to call it gcc-hardened
[12:36] <elmo> pitti: every binary gets linked to a SSP lib?
[12:36] <pitti> trulux: -hardened is fine for me too
[12:36] <pitti> elmo: yes
[12:36] <mdz> morning
[12:36] <trulux> pitti: ok then
[12:36] <trulux> hey mdz
[12:36] <pitti> Hi mdz!
[12:37] <elmo> err, please don't call it hardened
[12:37] <pitti> trulux: TIA! I look forward to see the packages
[12:37] <elmo> the propaganda campaign doesn't need to extend to package names
[12:37] <trulux> mdz: i have your doc: http://wiki.debian-hardened.org/Development_layout_organization
[12:37] <elmo> please call it what it actually is
[12:37] <pitti> -ssp says what it is probabl
[12:37] <pitti> y
[12:37] <trulux> pitti: ok, today i'm a bit sleepy, i just slept 3 hours, i was testing the TPE all the night
[12:37] <pitti> mdz: we now have upstream freeze, right?
[12:37] <mdz> pitti: yes
[12:38] <trulux> elmo, what propaganda?
[12:38] <pitti> mdz: today a new hal bugfix version 0.4.4 was released which fixes some segfaults and a regression in 0.4.3
[12:38] <mdz> trulux: I don't know what that document is about
[12:38] <pitti> mdz: the changelog is relatively small
[12:38] <pitti> mdz: I can backport the patches or shall I just package the new upstream version (after auditign the diff)?
[12:38] <mdz> pitti: http://www.ubuntulinux.org/wiki/UpstreamVersionFreeze
[12:38] <mdz> Exceptions requiring confirmation:
[12:38] <mdz>  Minor fixes, if the upstream change is a micro-increment (or equivalent)
[12:38] <Kamion> trulux: "hardened" is essentially an advertising term, not a description of what it actually is :)
[12:39] <trulux> mdz: is about the development layout i commented, the infrasctructure that needs to be done
[12:39] <trulux> Kamion: hardened means a hardened toolchain, even hardened gentoo uses it and so on
[12:39] <trulux> ;)
[12:39] <pitti> mdz: exactly, point 2 seems to fit
[12:40] <pitti> mdz: so I hereby ask for permission
[12:40] <mdz> pitti: go for it
[12:40] <pitti> okay, thanks
[12:41] <trulux> pitti: so, what's your final decision? -ssp or -hardened?
[12:42] <pitti> trulux: does it contain anything else apart from ssp by now?
[12:42] <trulux> ssp would distract users of know about PIE and so on
[12:42] <trulux> PIE
[12:42] <trulux> comes by default in 3.4 but not in 3.3
[12:42] <pitti> I thought PIE was just a consequence (or arequirement) of ssp
[12:42] <trulux> it's not
[12:42] <trulux> PIE is for PaX ASLR
[12:42] <trulux> not for ssp
[12:42] <pitti> pie itself is not a security feature IIRC
[12:42] <pitti> oh right
[12:43] <pitti> but still, it is a means to support a feature, not a sec feature itself
[12:43] <trulux> PIE is used as a security feature
[12:43] <trulux> developed as it
[12:43] <pitti> trulux: since this is meant to be an experimental package only, -ssp is fine for me
[12:43] <trulux> let me try to bring here psm
[12:45] <mdz> trulux: what I asked for was a document describing what resources you needed in order to do a proof-of-concept derivative of Ubuntu using SSP, and what you are showing me is a document which describes the CVS repository layout for debian-hardened
[12:45] <mdz> I don't understand
[12:45] <mjg59> daniels: Oh, rock
[12:45] <mjg59> Can you get that into Hoary?
[12:46] <trulux> mdz: ok, let me write a section about it
[12:46] <pitti> trulux: just write a plain ASCII file, which only contains the necessary resources
[12:46] <trulux> mdz: i just have a server specs doc for a sponsorship that is going to start (with Tek, they sponsor Gentoo)
[12:46] <trulux> pitti: ok
[12:47] <pitti> trulux: i. e. separate archive, buildd support, modified toolchain in the buildd (-ssp), etc.
[12:47] <mdz> pitti is on the right track
[12:47] <pitti> trulux: also, team structure
[12:48] <pitti> trulux: who is responsible for what, future plans (eventual merge into Hoary+1 if successful, etc.)
[12:52] <psm> hello all, what are the questions about pie?
[12:52] <pitti> psm: PIE itself is no security feature right?
[12:53] <pitti> psm: as far as I understood it supports PaX memory randomization and stuff
[12:53] <psm> PIE is like a shared lib, loadable to any address
[12:53] <pitti> right
[12:53] <mdz> Kamion: did you receive my email with casper?
[12:54] <psm> if the addresses are randomized, you'll get it loaded each time at diff addresses
[12:56] <pitti> psm: this is PaX ASLR
[12:56] <psm> for ex
[12:56] <pitti> Morning carlos!
[12:57] <Kamion> mdz: no
[12:57] <mvo_> hi carlos 
[12:57] <psm> the randomization can be done in kernel (PAX does it), or ld.so could be used prob for that
[12:57] <carlos> morning
[12:57] <zul> morning pitti
[12:57] <pitti> Hi zul
[12:57] <mdz> Kamion: wtf
[12:57] <mdz> you didn't get the last one either
[12:57] <mdz> sending you a test mail
[12:57] <Kamion> mdz: where was it sent to?
[12:58] <mdz> Kamion: cjwatson@canonical
[12:58] <Kamion> bleh, it got spam-trapped?!
[12:58] <pitti> carlos: right now we agreed to the ZIP structure <LANG>/<DOMAIN>.mo, right?
[12:58] <Kamion> hold on, I have it
[12:59] <pitti> carlos: would it be any more difficult for you to change that to <LANG>/LC_MESSAGES/<DOMAIN>.mo ?
[12:59] <pitti> carlos: then it would already have the final structure
[12:59] <Kamion> opening that mail folder is a bit of a challenge, that's all ...
[12:59] <mdz> Kamion: anything else from me in there? :-P
[01:00] <Kamion> -rw-------    1 cjwatson cjwatson 1196359985 Jan  7 11:55 mail/spam
[01:00] <Kamion> I'll tell you in a bit :P
[01:01] <carlos> pitti: will do it that way
[01:01] <pitti> carlos: if it does not make the job harder for rosetta?
[01:01] <mdz> -rw-rw----  1 mdz mdz 45930357 2005-01-07 03:37 /home/mdz/mail/incoming/spam
[01:01] <mdz> you win
[01:01] <mdz> that goes back to Dec 17
[01:01] <carlos> pitti: for me it's the same one directory than two or three
[01:02] <pitti> carlos: okay, thanks
[01:02] <carlos> np
[01:02] <pitti> carlos: with this new structure I don't need to rearrange the files at all
[01:02] <trulux> mdz: done, can i dcc it to you?
[01:02] <fabbione> mdz: already awake?
[01:03] <pitti> fabbione: I'd rather call it 'still' :-)
[01:03] <Kamion> mdz: four mails from you in that folder, going back a while
[01:03] <fabbione> ehhe
[01:03] <mdz> fabbione: I'm not sure whether I'm awake already or if I haven't slept yet
[01:03] <mdz> trulux: please put it in the Ubuntu wiki
[01:03] <Kamion> to which I say, wtf?
[01:03] <fabbione> mdz: pick one :-)
[01:04] <mdz> Kamion: hmm, I have some vague recollection of you not receiving a mail from me in the past few months
[01:04] <trulux> mdz: ok
[01:05] <Kamion> Subject: ubuntu-meta
[01:05] <Kamion> mdz: apparently caused by overenthusiastic filtering of certain types of binary attachments
[01:06] <mdz> Kamion: you're not using spamassassin, are you?
[01:06] <Kamion> I am, but the binary attachment thing was manual to try to avoid being buried under Klez
[01:07] <Kamion> sorry about that
[01:08] <fabbione> daniels: still around?
[01:09] <Kamion> the kickstart stuff is vile
[01:10] <Treenaks> bile as well now 8)
[01:18] <trulux> mdz: https://www.ubuntulinux.org/wiki/HardeningNeededResources
[01:18] <trulux> btw
[01:18] <trulux> if someone wants to fall back to 2.4 for SELinux, now you have SELinux for 2.4
[01:18] <trulux> ;)
[01:18] <Treenaks> *shudder*
[01:22] <daniels> fabbione: wassup
[01:22] <daniels> mjg59: yes, it will be in hoary
[01:23] <fabbione> daniels: there is a big bunch of drm updates for 2.6.11
[01:23] <fabbione> should we pull them in?
[01:23] <daniels> fabbione: yep!
[01:23] <daniels> and i have some more drm stuff for i915
[01:23] <daniels> i'll forward it to you
[01:23] <fabbione> daniels: no need to..
[01:23] <fabbione> i will grab what is in bk
[01:24] <fabbione> if it is not upstream is no no :-)
[01:25] <thom> mdz: hrrm. there are other cases where the filesystems are unconditionally not checked
[01:26] <mdz> thom: really?
[01:26] <thom> mdz: yes
[01:26] <thom> if you have /fastboot
[01:26] <thom> as a file, then no checks are run
[01:27] <mdz> ah, right
[01:27] <mdz> thom: did you get with mako about the directory index stuff?
[01:28] <mdz> +AC_CHECK_PROGS(GAS, gas)
[01:28] <mdz> [...] 
[01:28] <mdz> +# funniest. macro. ever.
[01:28] <mdz> +AC_DEFINE(FLAC__HAS_GAS)
[01:29] <thom> mdz: um?
[01:29] <Treenaks> 8)
[01:29] <mdz> thom: for the CD image downloads
[01:29] <mdz> back about 8 hours or so
[01:29] <Kamion> mdz: wow, that's an *amazing* hack :)
[01:29] <mdz> thom: he sent you an email too
[01:29] <mdz> two of them
[01:29] <mvo_> ping doko_ 
[01:30] <thom> mdz: you can take that as a no - i have no mail from mako today
[01:30] <elmo> joii why is he sending it to thom?
[01:30] <mjg59> daniels: Rock
[01:30] <mdz> thom: hmmmm
[01:30] <Kamion> mdz: while there are obviously improvements I can think of, I'm satisfied it won't break regular d-i as it stands, so if that's all I can upload it as-is
[01:30] <mdz> never mind
[01:30] <mdz> he sent it to admins@admins
[01:31] <mdz> and mentioned it to thom on irc
[01:31] <mdz> so it's sitting in the vacuum of admins@ somewhere :-P
[01:31] <Kamion> he sent directory index stuff to me
[01:31] <mdz> CCed
[01:31] <Kamion> for releases
[01:31] <Kamion> I'm the right person to do that anyway, probably, I'll take care of it
[01:32] <mdz> yeah, I wasn't sure if you could do that without admin intervention, so I recommended he ping you as well
[01:32] <Kamion> think I can, we'll see
[01:32] <mdz> Kamion: since I'm awake anyway, shall I go ahead and seed+upload casper?
[01:32] <Kamion> go for it
[01:33] <mdz> it's a bit annoying that gnupg hassles me to update-trustdb when all I've imported are new signatures on my own key
[01:33] <mdz> I'm fairly certain that no exciting new trust paths are established by those
[01:33] <fabbione> daniels: in any case.. -5 stuff
[01:33] <thom> mdz: the case you suggest for fsck would require each individual fsck to learn how to check for being on ac, i think
[01:34] <Kamion> elmo: if I could have rescue-{check,mode}, casper-{check,udeb}, and the 2.6.10 udebs in main, I can do new d-i with all of this stuff ...
[01:34] <thom> or the fsck wrapper, certainly
[01:34] <mdz> thom: I was thinking that the fsck wrapper would pass a flag to them saying "don't do anything stupid"
[01:34] <daniels> fabbione: yeah, that's cool
[01:34] <kent> seb128, are you there?
[01:34] <daniels> fabbione: btw, the stuff in xorg is newer than bk
[01:34] <mdz> thom: I say post something to ubuntu-devel and see what folk think about the way it works now
[01:34] <mdz> thom: maybe I'm just paranoid
[01:34] <mdz> thom: on_ac_power is guaranteed not to do anything stupid on a server, right?
[01:35] <seb128> kent: yes
[01:35] <Kamion> mdz: netcfg's the only useful thing in base-installer.d AFAIK; maybe we could invent a casper.d which casper-udeb runs?
[01:35] <mdz> Kamion: the notion of having gobs of other udebs knowing about casper isn't very appealing
[01:35] <Kamion> I like that notion, actually
[01:36] <Kamion> it's a lot better than casper knowing about the internals of gobs of other udebs, which is what we have now
[01:36] <mdz> Kamion: I was thinking that prebaseconfig.d could be broken up
[01:36] <thom> mdz: yes.
[01:36] <Kamion> nah, that's casper.d :)
[01:36] <mdz> into bits which do crazy things, and bits which don't do crazy things
[01:36] <kent> seb128, well.. i was just going to ask if it was gnome-applets i should report the bug against the weather applet, but i saw that it must be that.. :) 
[01:37] <Kamion> that affects the install CD in much more invasive ways
[01:37] <Kamion> and is scary because prebaseconfig.d is dealt with by lots of udebs
[01:37] <Kamion> and it's by no means guaranteed that more stuff won't be added to prebaseconfig.d
[01:37] <seb128> kent: yep
[01:37] <mdz> Kamion: who expands the Kernel-Version in the installer seed, germinate?
[01:38] <Kamion> yep
[01:38] <Kamion> I got bored of having to substitute 2.6.8.1 with 2.6.9 a thousand times
[01:38] <mdz> Kamion: anything you noticed which ought to work differently and wasn't already marked with a scary comment?
[01:38] <kent> seb128, https://bugzilla.ubuntu.com/show_bug.cgi?id=5281   :)
[01:39] <fabbione> mdz:   [PATCH]  convert Linux to 4-level page tables
[01:39] <fabbione> interested?
[01:39] <mdz> fabbione: we're still pre-feature-freeze, if you think it's supportable
[01:39] <fabbione> no s*!t
[01:39] <Kamion> mdz: I wondered about using /dev/ram0; doesn't the installer already use that for its own ramdisk?
[01:40] <fabbione> i have not even idea of what it is after reading a few tons of documentation stuff
[01:40] <fabbione> it reorders all the VM in more layer
[01:40] <mdz> Kamion: apparently not; I didn't think the installer used a ramdisk apart from the initrd
[01:40] <mjg59> daniels: So the custom video mode stuff means we don't need 855resolution?
[01:40] <fabbione> no way i will understand that in 20 years from now ;)
[01:40] <Kamion> that's what I meant, the initrd
[01:40] <mdz> fabbione: ok, let's not backport major new features that we don't understand, ok? ;-)
[01:40] <Kamion> "newer kernels use /dev/ram0 for the initrd" <- Documentation/devices.txt
[01:41] <mdz> fascinating
[01:41] <mdz> gah, nightly backup is running
[01:42] <mdz> Kamion: I think d-i actually copies itself into a tmpfs
[01:42] <Kamion> mdz: the /dev/vc stuff is a bit nightmarish, hopefully that'll go away when we eventually switch the installer to non-devfs paths
[01:42] <Kamion> mdz: oh, so it does, good point
[01:42] <Kamion> yes, and it umounts the initrd afterwards, so you're ok
[01:42] <mdz> Kamion: we still need to find a clever way to let us unmount the d-i tmpfs
[01:42] <Kamion> mdz: other than that I think you had a sufficiency of scary comments to cover my concerns :)
[01:42] <pitti> daniels: still here?
[01:43] <Kamion> mdz: what's still open on it?
[01:43] <jdub> seb128: that sounds pretty rad :-)
[01:43] <mdz> Kamion: the new root filesystem is a device-mapper device, one of whose components is a cloop device which is attached to a file on the cdrom, which is mounted under the tmpfs :-)
[01:44] <mjg59> fabbione: The only big advantage from an end-user point of view is that 64 bit architectures get more addressible physical RAM
[01:44] <Kamion> mount --move the cdrom?
[01:44] <mdz> ooh, didn't know about that
[01:44] <mjg59> So I wouldn't worry too much
[01:44] <mdz> sounds like exactly what I need
[01:44] <fabbione> mjg59: i am not ... reallyt
[01:44] <Kamion> assuming that busybox mount implements --move
[01:45] <Kamion> doesn't look like it, but should be a small addition
[01:45] <mdz> doesn't have to
[01:45] <mdz> we have real mount by that time
[01:45] <Kamion> true
[01:47] <mdz> Kamion: what were you saying about base-installer.d?
[01:48] <daniels> pitti: yo, sup
[01:48] <daniels> mjg59: afaict, yes
[01:48] <mjg59> daniels: That makes life unbelievably easier.
[01:48] <daniels> mjg59: shit yes
[01:50] <Kamion> mdz: netcfg is the only thing that uses it, and it could easily just declare that it needs to be used by casper too
[01:51] <mdz> Kamion: will you add casper-check to your next d-i upload?
[01:51] <Kamion> yes, once it's in main
[01:52] <mjg59> daniels: How long until packages with that are available?
[01:52] <daniels> mjg59: will do it this weekend, so probably packages this weekend, hoary next week
[01:53] <mjg59> 1337
[01:53] <Kamion> http://releases.ubuntu.com/warty/ updated
[01:53] <Kamion> looks much nicer
[01:54] <crimsun> pitti: 2.6.10-hardened-1-686-smp works great :)
[01:54] <daniels> mjg59: it's because i am shit hot
[01:54] <mdz> Kamion: looks good, thanks
[01:54] <daniels> Kamion: nice :)
[01:54] <pitti> crimsun: cool
[01:55] <pitti> crimsun: did you use the linux-hardened-support package?
[01:55] <pitti> crimsun: I uploaded version 2 this morning which fixes chpax'ing
[01:55] <crimsun> pitti: and chpax, too.
[01:55] <pitti> crimsun: does framebuffer work for you?
[01:55] <crimsun> pitti: haven't tested; using X Windows atm
[01:56] <pitti> crimsun: you saw boot messages? do you boot with text console or fb?
[01:57] <elmo> Error trying to open /dev/hda exclusively (Device or resource busy)... retrying in 1 second.
[01:57] <elmo> duh
[01:57] <crimsun> pitti: text
[01:57] <pitti> elmo: is that cdrecord?
[01:57] <elmo> yeah
[01:57] <mdz> Kamion: we may want to make the ramdisks larger, too
[01:58] <elmo> nautlius isn't burning valid CDs for me :(
[01:58] <fabbione> elmo: get ready for another travel to the dc :-)))
[01:58] <elmo> fabbione: I'm AT the DC
[01:58] <elmo> (look at my IP)
[01:58] <fabbione> ok :-)
[01:59] <elmo> pitti: how do I get this stupid thing (cdrecord) to not try and gain control of the drive with my root partition on?
[01:59] <pitti> elmo: it doesn't, because it cannot exclusively open it anyway
[02:00] <pitti> elmo: but why do you try burning to /dev/hda in the first place?
[02:00] <elmo> I'm not, I'm trying to run -scanbus
[02:00] <elmo> I'm not quite that stupid; but I'm touched by your confidence in me
[02:00] <pitti> elmo: sorry
[02:00] <pitti> elmo: however, I think this -scanbus bug was fixed in Hoary
[02:00] <mdz> don't run -scanbus, then
[02:00] <pitti> elmo: it's only a cosmetic issue, though
[02:01] <pitti> elmo: older versions also touched hda during scanning, so your version is actually better
[02:01] <elmo> mdz: and figure out the archaic rune for my cdrom, how? :P
[02:01] <mdz> elmo: archaic rune?
[02:01] <mdz> elmo: dev=/dev/cdrom
[02:01] <pitti> elmo: the hda scanning should time out after 10 seconds, and hda will not be touched
[02:01] <elmo> I thought it had to be ATA:2034,3224,3841 or something
[02:01] <mdz> elmo: they fixed that in like 1990
[02:02] <mdz> it prints this obnoxious pedantic shitbag complaint about it, but then it does what you ask
[02:04] <mjg59> daniels: Does Hoary do the right thing with loading AGP and DRM modules?
[02:05] <elmo> does nautlius' burning stuff log anywhere btw?
[02:05] <daniels> mdz: UNINTENTIONAL, BE THANKFUL THIS WORKS YOU FOOL, ALL HAIL JRG
[02:05] <daniels> hmm, weird
[02:05] <daniels> JRG
[02:05] <daniels> i hate screen
[02:05] <Treenaks> daniels: Schilling?
[02:05] <daniels> mjg59: yah
[02:05] <pitti> daniels: the umlaut works fine if you meant that
[02:05] <daniels> Treenaks: who else
[02:05] <mjg59> daniels: Rocking
[02:05] <daniels> pitti: really?  it renders weird here
[02:05] <mdz> elmo: it has a debug flag in gconf which logs all the output from cdrecord/growisofs/mkisofs/whatnot
[02:05] <pitti> daniels: I have /charset UTF-8, looks fine
[02:05] <jdub> so you know that trash .desktop file i posted to u-d?
[02:05] <jdub> it's sitting on my desktop
[02:05] <pitti> daniels: something more:    
[02:06] <Treenaks> daniels: well, there are 2 other Jrgs on planet debian at least
[02:06] <jdub> and i loaded up the january calendar
[02:06] <jdub> and it's IN HIS HAND
[02:06] <mjg59> Haha
[02:07] <daniels> ahr, much better.  but mine is still rendering like crap.
[02:07] <daniels> 
[02:07] <daniels> gah.
[02:07] <lifeless> 
[02:07] <Treenaks> daniels: looks fine here
[02:08] <daniels> it renders fine in the status line, but then renders horribly in the main window
[02:08] <Treenaks> daniels: I have it the other way around
[02:08] <Treenaks> daniels: when I type it it looks f*cked, when I press ENTER it's OK
[02:08] <Kamion> urgh, badly written documentation
[02:08] <Kamion> "When posix is not true (default), the shlex instance will operate in compatibility mode."
[02:08] <mvo_> mdz: what's our policy with merges that only require a sync from debian (because debian took the changes from us)? #3518 is such a case. do we sync them? or ignore the because of upstream-version-freeze
[02:08] <Kamion> is that "not (true (default))" or "(not true) (default)"?
[02:09] <elmo> kamion the latter
[02:09] <mdz> mvo_: if the debian version doesn't contain other things that we don't want, a sync is fine
[02:09] <elmo> Kamion: I guess
[02:09] <Kamion> turns out it's the latter, but then they should say "false (default)"
[02:09] <daniels> Kamion: i'd say the latter
[02:09] <daniels> yeah
[02:10] <mvo_> mdz: it's a new upstream version that was not synced automatically
[02:12] <mdz> Kamion: where do you think I should move the CD to?
[02:12] <daniels> mdz: l-r-m 2.6.10-1 uploading now
[02:12] <mdz> Kamion: I was thinking /media/cdrom0, but there's no particular guarantee that it's cdrom0, or even a cdrom
[02:12] <daniels> well, l-r-m-2.6.10 2.6.10-1
[02:12] <mdz> daniels: thanks
[02:12] <mvo_> elmo: can you please sync "scim"? all our changes are now in the debian package (merge bug #3518)
[02:12] <mdz> lamont: ^^^
[02:13] <elmo> [NOT Updating - Modified]  scim_0.9.7-1ubuntu1 (vs 1.0.1-4)
[02:13] <elmo> mvo: ^-- that?
[02:13] <Kamion> mdz: /media/live or something?
[02:14] <mvo_> elmo: yes, all our changes are in the debian package now (only a missing build-depends)
[02:14] <daniels> mdz: i live to give
[02:14] <elmo> mvo: yeah, but look at the version numbers?
[02:15] <mdz> mvo_: that's a universe package anyway
[02:15] <mvo_> mdz: so we ignore it and leave it at 0.9.7-1ubuntu1?
[02:15] <mdz> mvo_: yes, until the MOTU decide otherwise
[02:16] <daniels> woh are the motu?
[02:16] <lifeless> masters of..
[02:16] <mvo_> mdz: what to do with the merge bug? just change it to "universe"?
[02:16] <mdz> mvo_: it should already be severity: enhancement
[02:17] <mvo_> yes. I'll just leave it alone then
[02:18] <mdz> there was a time when MOM filed bugs about universe packages, but keybuk fixed it shortly thereafter
[02:18] <mdz> the MOTU will need to get a complete list of pending universe merges
[02:19] <mvo_> how many MOTU do we have right now?
[02:19] <daniels> lifeless: yeah, but who specifically ... like, the people
[02:20] <daniels> i know what the concept of motu is :P
[02:22] <mdz> Kamion: will you take care of adding an option to isolinux which sets casper/enable=true?
[02:22] <Kamion> fabbione: in your next kernel upload, could you create an rtc-modules udeb that includes drivers/char/rtc.o?
[02:22] <Kamion> I need it for the timezone question in the first stage
[02:22] <elmo> fuck.  even burning with cdrecord didn't work.  what kind of freaks don't provide md5sums of iso's anyways
[02:22] <kent> btw, i got a broken pipe when upgrading my Hoary recently.   /usr/lib/libFLAC.so.6.0.1 from libflac6 is also in libflac4 according to synaptic.
[02:23] <jdub> http://www.livejournal.com/users/zabilcm/3490.html
[02:23] <daniels> elmo: what are you trying to burn?
[02:23] <Kamion> mdz: that would be on the live CD only, wouldn't it?
[02:23] <elmo> daniels: latest Update Xpress CD
[02:23] <elmo> IBM's "all in one" firmware/driver etc. update CD
[02:23] <mdz> Kamion: the live CD should default to it; the live+install DVD should have an option :-)
[02:24] <Kamion> the latter doesn't exist yet though ;)
[02:24] <Kamion> I'll add it commented out for the moment
[02:24] <mdz> kent: it's a bug, it's reported already
[02:24] <Kamion> and eventually make it DVD-only
[02:26] <Kamion> fabbione: (or should I file a bug?)
[02:26] <mdz> Kamion: I need something to use for testing, is all
[02:27] <mdz> easiest would be if I only had to drop /casper/ onto an install CD
[02:27] <Kamion> mdz: you can just type 'linux casper/enable=true ...
[02:27] <Kamion> '
[02:27] <mdz> Kamion: yeah, but I have to type that in qwerty :-P
[02:27] <Kamion> ah :)
[02:27] <mdz> it sucks
[02:27] <Kamion> ok, I'll add it for now
[02:27] <Kamion> won't stay for release, though
[02:27] <mdz> well, I suppose you and lamont will have automated builds going soon, no?
[02:27] <Kamion> fabbione: should I switch sparc to 2.6.10 as well?
[02:27] <mdz> if so, don't worry with it
[02:27] <Kamion> yeah, but not for the install CD, is my point :)
[02:28] <Kamion> fabbione: (d-i)
[02:28] <mdz> daniels: that's one of the topics for the next CC meeting
[02:29] <daniels> mdz: schwoit
[02:29] <mdz> daniels: motu
[02:30] <daniels> mdz: it's 'dude, where's my car?' all over again
[02:30] <daniels> mdz: (schwoit -> sweet)
[02:32] <Kamion> mdz: have you thought about doing casper over nbd or similar, incidentally?
[02:34] <mdz> Kamion: yes, in fact I was just thinking about it last night
[02:34] <mdz> er
[02:34] <mdz> tonight
[02:34] <mdz> "some hours ago"
[02:35] <jdub> casper/
[02:35] <jdub> ?
[02:35] <mdz> jdub: the new live cd/dvd/usb/whatnot system
[02:35] <jdub> oh
[02:35] <mdz> (the one I wrote on wednesday)
[02:36] <jdub> great name
[02:36] <mdz> I looked hard and couldn't find another project with that name
[02:36] <jdub> surprising
[02:36] <Kamion> mdz: right, I'm including casper-check in pkg-lists/base then, we'll just have it on all initrds
[02:36] <daniels> cartman: i'm aware of the libglx.a thing, but libGL.so shouldn't be a dangling symlink with a halfway recent version of nvidia-glx
[02:36] <mdz> Kamion: even (hypothetical) floppies?
[02:37] <cartman> daniels: I am always using latest packs
[02:37] <Kamion> yeah
[02:37] <Kamion> there are plenty of machines that have CD drives but can't boot from them
[02:37] <Kamion> booting from floppy is a common workaround
[02:38] <Kamion> of course whether any of them will run casper is a different question :)
[02:38] <mdz> I intend to make casper fairly clever about that sort of thing
[02:38] <daniels> cartman: weird.  where was it pointing?
[02:39] <cartman> libGL.so.1.2
[02:39] <mdz> it should be able to find filesystem images and COW overlays on hard disks, USB devices, etc.
[02:39] <mdz> probably do something a bit like os-prober
[02:39] <Kamion> I was thinking more about desktop memory requirements
[02:39] <daniels> cartman: bonnnnnng
[02:39] <Kamion> mdz: might want to look at iso-scan too
[02:40] <cartman> daniels: doing
[02:40] <mdz> Kamion: oh, PC that can't boot from CD -> old PC -> low memory?
[02:40] <Kamion> right
[02:40] <Kamion> might not be universally true though, c.f. laptops with pcmcia cd drives
[02:41] <Kamion> mdz: hm, need to add casper-check to the seed too, I'll do that
[02:42] <mdz> Kamion: oh, oops
[02:42] <Kamion> fixed
[02:42] <mdz> Kamion: or even USB CD drives
[02:43] <mdz> Kamion: such as loonies who buy X40s
[02:43] <Kamion> :-)
[02:44] <jdub> or the more powerful and beautiful x300 ;)
[02:45] <mdz> Kamion: how would you feel about changing the title of "loading components of the Ubuntu installer"?
[02:45] <mdz> it's rather weird-looking on a live CD :-)
[02:46] <mdz> (not nearly as weird-looking as when it says "The system is going down NOW!" and kills all the processes, but one thing at a time...)
[02:46] <stockholm> mdz: ?
[02:46] <stockholm> ah
[02:46] <daniels> mdz: if you do it through the dock, I don't think it comes up as USB
[02:46] <mdz> daniels: oh, is the dock standard equipment?
[02:46] <stockholm> mdz: do you know if there is interest in having python bindings for kerberos? there is a project started on alioth, but it needs some work and love to be usefull
[02:46] <mdz> I assume X40s can boot from USB anyway (my T42 can)
[02:47] <daniels> mdz: nope, it's $$
[02:47] <mdz> I even booted it from a CF card in a USB card reader
[02:47] <daniels> mdz: yeah, it can boot from USB in any case
[02:47] <Kamion> mdz: awkward to achieve, unfortunately. I was thinking about having a legend at the top-left corner of the screen to say that you're in rescue mode or in live CD mode or whatever ...
[02:47] <mdz> stockholm: yeah, I imagine there is, kerberos being a windows interoperability thing now
[02:48] <Kamion> mdz: unless you can think of a title for that progress bar that makes sense in all modes
[02:48] <stockholm> mdz: but there are no working python bindings yet.
[02:48] <mdz> Kamion: "loading components"
[02:48] <Kamion> bit *too* generic perhaps
[02:48] <mdz> stockholm: I imagine there is [interest] 
[02:48] <daniels> AGH VIM
[02:48] <mdz> loading runtime components? too techy
[02:48] <mdz> "loading things to do stuff"
[02:49] <mdz> I don't think "loading components" is bad
[02:49] <daniels> if there's a vim modeline at the bottom of a file, you seemingly can't change it
[02:49] <Kamion> "loading extra components"?
[02:49] <Kamion> daniels: uh?
[02:49] <Kamion> "loading additional components"
[02:49] <daniels> Kamion: debian/local/dexconf has et ts=2
[02:49] <daniels> Kamion: and despite all my efforts, the tabs are always expanded to 2 spaces
[02:49] <daniels> Kamion: having set noet, and ts=8
[02:49] <Kamion> try setting ts sts and sw
[02:50] <stockholm> mdz: and do you imagine canonical with its quest to promote python would push this?
[02:50] <Kamion> daniels: oh, if et is set there won't be any tab characters in the file
[02:50] <Kamion> daniels: you have to retab in order to change that
[02:50] <daniels> Kamion: ahr, that was it -- thanks
[02:50] <daniels> Kamion: no, this was me putting in new tabs :)
[02:51] <daniels> Kamion: what's the difference between ts and sts?
[02:51] <Kamion> softtabstop is what gets inserted when you press tab
[02:52] <daniels> elmo: please NEW l-r-m-2.6.10 as a matter of priority -- lamont and mdz's livecd is blocking on it
[02:52] <Kamion> so you can have ts=8 to make tabs in the file be eight spaces wide, but sts=4 to use four-space indent
[02:52] <elmo> daniels: I already did you talentless gypsy
[02:52] <daniels> elmo: thankyou, dear
[02:52] <jdub> catalonians are french gypsies
[02:52] <azeem> this is better than soap operas on TV
[02:53] <Kamion> hm, hw-detect/module_params is not very useful for preseeding
[02:53] <elmo> like, seriously, it'd been in NEW less than 5 minutes.. stop invoking the 'b' word with insane gratuity
[02:53] <mdz> stockholm: by "push", do you mean "fund"?
[02:53] <stockholm> mdz: not sure, i guess so.
[02:53] <daniels> elmo: BULGARIA
[02:53] <mdz> stockholm: who is developing the bindings?
[02:54] <lamont> ts should never be other than 8.  sts is a good thing.
[02:54] <stockholm> mdz: no one at the moment, they are orphaned
[02:54] <stockholm> mdz: rb@d.o started on them but he started studying now and has no time 
[02:55] <mdz> stockholm: what is rb@d.o's full name?
[02:55] <stockholm> Roland Bauerschmidt
[02:55] <stockholm> mark approached him, too
[02:55] <lamont> if we could get people to quit using ts!=8, then maybe we could get SteveA to let us have tabs back..
[02:55] <daniels> mdz: if only there was some kind of web-based utility to find information on Debian developers
[02:56] <mdz> stockholm: if you're looking for someone to continue the development, we don't have developer resources for such projects, but if you find someone who is interested in working on it, have them contact me
[02:56] <mdz> daniels: the next thing that you say to me should be "here's the command you need to run to generate a working X config for the live CD"
[02:56] <stockholm> cool!
[02:57] <daniels> mdz: i'm on it
[02:57] <mdz> BZZT
[03:02] <amu> mdz: *eg* 
[03:02] <elmo> btw, we are going to drop 2.6.9 and 2.6.8.1 eventually  right, and not let them linger on indefinitely in universe?
[03:03] <amu> elmo: imho better wait till 2.6.10 is kind of "stable"  
[03:04] <mdz> elmo: 2.6.8.1 I think we can drop today
[03:04] <elmo> yeah, sure, I do mean eventually
[03:04] <mdz> fabbione, Kamion: confirm?
[03:04] <elmo> it's just that, because we name them differently from Debian, they won't get purged, even when Debian drops support for them
[03:04] <elmo> (in 2014)
[03:06] <ogra_> mvo ?
[03:07] <mdz> elmo: please kill any kernel-*-2.6.8 stuff
[03:07] <mdz> since debian has moved onto 2.6.9
[03:07] <mdz> I don't see any reason to keep more than the most recent Debian kernel on each branch
[03:08] <Kamion> sarge hasn't moved, and 2.6.8 is still getting significant development work
[03:08] <Kamion> probably more attention than 2.6.9 at the moment
[03:08] <Kamion> I would say that 2.6.8 is still interesting for merges
[03:08] <mdz> Kamion: interesting for hoary users?
[03:08] <Kamion> developers
[03:09] <Kamion> if that doesn't matter, then TBH we might as well just kill kernel-image-* :)
[03:09] <mvo_> ogra: ?
[03:09] <mdz> we really don't need 8 versions of the kernel; we're getting Debian disease
[03:09] <ogra_> mvo: what do you think about using the original avm drivers ?
[03:10] <mvo_> ogra_: if we can distribute them we should have them 
[03:10] <ogra_> mvo: and leaving mISDN for the next release....
[03:10] <Kamion> mdz: ok, fair enough then
[03:10] <mdz> I think we can at least shed linux-source-2.6.8.1
[03:11] <mdz> probably kernel-source-2.2.25
[03:11] <mvo_> ogra_: I think doko asked for permission from avm to distribute the avm drivers
[03:11] <mdz> and hopefully one of kernel-source-2.6.x
[03:11] <pitti> ugh, we have 2.2 still?
[03:11] <mdz> pitti: in universe
[03:11] <pitti> mdz: right, but still
[03:11] <ogra_> mvo: i think it eats a reasonable amount of time from fabio and doesnt look as if it gets solved to soon
[03:11] <mdz> pitti: 2.4.27 in universe as well
[03:11] <ogra_> mvo: ah, great news
[03:12] <pitti> mdz: we should drop 2.4.27 IMHO, it has a hell of a lot of security holes
[03:12] <pitti> mdz: 2.4.28 fixed most of them
[03:12] <mvo_> ogra_: agreed
[03:12] <mdz> pitti: I don't know to what extent Debian is still patching 2.4.27
[03:12] <mdz> pitti: but if they aren't keeping it up to date with fixes, I agree, we should drop it
[03:12] <pitti> mdz: I just went though the recent vulns with elmo
[03:13] <pitti> mdz: it seems that even the recent 2.4.28 package still has issues...
[03:13] <elmo> lunch, bbiab
[03:13] <mdz> pitti: if you feel that kernel-source-2.4.27 and kernel-source-2.2.25 should be removed, I am in favour of it
[03:13] <ogra_> mvo: do you know of any probs with i4l and 2.6.10 ? anything we should test in a more detailled way ?
[03:13] <pitti> mdz: I don't know about hte security status of 2.2.25
[03:14] <pitti> mdz: but 2.6 should run fine on all of our Ubuntu arches, right?
[03:14] <mdz> pitti: 2.6?
[03:14] <mvo_> ogra_: I haven't tested i4l and 2.6.10 yet
[03:14] <pitti> mdz: I meant, that Debian still needs 2.4 and 2.2 for some architectures
[03:14] <mdz> right
[03:14] <pitti> mdz: but I guess Ubuntu doesn't
[03:15] <ogra_> mvo: ok, i will do some basic testing on the weekend then :) if i encounter probs i'll shout
[03:15] <pitti> mdz: if we have 2.4.28 in universe, I doubt that we should offer 2.4.27 still
[03:15] <mdz> the debian kernels are nice to have since they sometimes offer different features/fixes/etc., but if they are not secure, we should not include them
[03:15] <pitti> mdz: okay, it's universe, but it's so utterly useless
[03:15] <mdz> pitti: we don't have .28
[03:15] <pitti> ugh
[03:15] <mdz> pitti: Debian doesn't have .28 either
[03:15] <mvo_> ogra_: thanks
[03:15] <pitti> mdz: oh, I thought, because elmo just compiles 2.4.28 for the Debian servers
[03:16] <ogra_> :)
[03:16] <pitti> indeed, no 2.4.28 package; darn
[03:16] <pitti> mdz: I check the changelog
[03:16] <pitti> of 2.4.27
[03:18] <pitti> hmm, what's wrong with packages.d.o?
[03:19] <pitti> mdz: okay, it seems that they backported much to 2.4.27
[03:20] <mdz> pitti: right now, or in general? :-)
[03:20] <pitti> mdz: right now
[03:20] <pitti> mdz: I looked at the last two changelog entries
[03:20] <Kamion> pitti: judging from my cron mail, gluck was brought down, I'm guessing for a kernel upgrade or something
[03:21] <mdz> Kamion: I'd like to add a progress bar to casper; what's a good example to work from?
[03:21] <mdz> pitti: I meant with regard to packages.d.o ;-)
[03:21] <pitti> mdz: ah; no, right now; worked fine yesterday
[03:21] <pitti> mdz: true, that will be a consequence of elmo's kernel updates
[03:21] <Kamion> mdz: it's very easy, try yaboot-installer or something if it's just stepping through a known list of tasks
[03:22] <pitti> mdz: luckily we have mvo's changelogs at people.u.c :-)
[03:22] <mdz> Kamion: the only bit I'm uncertain about is where it runs the prebaseconfig hooks
[03:22] <mdz> Kamion: I suppose it should count them at the start and incorporate that count into the progress bar?
[03:22] <Kamion> mdz: yes, you could look at how the prebaseconfig progress bar itself works
[03:23] <Kamion> it would be best not to use run-parts then, so that you can step the progress bar properly
[03:23] <mdz> since it runs locale-gen and stuff, that is actually the longest bit I think
[03:23] <Kamion> or at least not to use the one from /target
[03:23] <mdz> that, and waiting for udev to create device nodes
[03:23] <mdz> we really should find out why that sucks so much
[03:25] <Kamion> hm, it's a shame 'apt-get -s build-dep' requires root
[03:33] <lamont> daniels: you around?
[03:34] <mdz> Kamion: there are many shameful things about apt-get build-dep
[03:34] <mdz> lamont: daniels uploaded l-r-m-2.6.10, so you should be able to use the metapackagaes again now
[03:35] <mdz> lamont: also, it would be really handy to be notified of failures in your daily desktop builds; can you arrange for those to go someplace useful?
[03:35] <Xof> ah, lamont
[03:35] <Xof> I've been told it's you I should speak to about sbcl build failures?
[03:36] <lamont> Xof: patches welcome
[03:36] <mdz> whoa, #5271 seems to trigger some bug in debzilla
[03:36] <mdz> Kamion: is it possible that some comments in debbugs have no message-ids?
[03:37] <Kamion> wouldn't surprise me
[03:38] <Xof> lamont: that attitude doesn't impress me very much
[03:38] <Kamion> mdz: which comments?
[03:38] <mdz> Kamion: https://bugzilla.ubuntu.com/show_bug.cgi?id=5271
[03:38] <mdz> Kamion: guess which :-)
[03:38] <Kamion> Xof: remember that sbcl is an unsupported package; to some extent we depend on community contributions for those
[03:39] <Xof> of course
[03:39] <Xof> and I spend my day making patches to it
[03:39] <lamont> Xof: I'm hip deep in a bunch of must-do stuff.  sbcl is ftbfs, I believe, yes?
[03:39] <Xof> and I kind of wanted to know about the environment of the buildds
[03:39] <Xof> but now I don't really care any more
[03:39] <lamont> Xof: if you have patches for it, I'd love to get them.
[03:39] <mdz> Kamion: hmm, doesn't look like a message-id problem now that I look in debbugs
[03:39] <lamont> Xof: it's sbuild in a chroot with hoary
[03:39] <mdz> Kamion: it looks like maybe the log parser is inadvertently splitting a message into two?
[03:40] <lamont> Xof: is sbcl one of those that will need to be bootstrapped from other than the binaries that are currently in hoary?
[03:40] <Xof> it shouldn't do
[03:40] <lamont> good.  those make my brain hurt./
[03:40] <lamont> what more did you need to know about the buildd environment?
[03:40] <Xof> at least, I don't know what binaries you have in hoary; it does depend on itself, I'm afraid, so for the new amd64 support you may need one bootstrap
[03:40] <Xof> but it doesn't depend on the exact same version of itself
[03:41] <Xof> lamont: the fact that it seems to be failing non-deterministically (or deterministically failing but not always in the same place) makes me suspicious
[03:41] <lamont> should be good.  http://archive.ubuntu.com/ubuntu/pool/universe/s/sbcl has the sbcl binaries for {hoary,warty}
[03:41] <Xof> is there anything like stack-guard or randomized mmap() or a movable malloc heap in your environments?
[03:42] <Kamion> mdz: looks like it's splitting at the . on a line by itself, but why would it do that?
[03:42] <Xof> any non-unlimited ulimits?
[03:42] <fabbione> mdz: sorry.. i had to run away.. what do you want me to confirm?
[03:43] <Xof> (also, knowing the difference between your buildds and debian's would be useful, because the builds seem to succeed more often over there)
[03:43] <mdz> Kamion: isn't that the delimiter you use?
[03:43] <mdz> fabbione: that we can remove linux-source-2.6.8.1
[03:43] <mdz> and corresponding l-r-m
[03:43] <fabbione> mdz: from hoary.. yes
[03:43] <Kamion> mdz: not in debbugs, but it *is* the delimiter used for communication between debbugs-log.pl and debbugs.py
[03:44] <mdz> elmo: removal of linux-source-2.6.8.1 and linux-restricted-modules-2.6.8.1 is agreed
[03:44] <mdz> Kamion: right
[03:44] <Kamion> mdz: all that code seems to dot-escape and -unescape correctly though ...
[03:45] <mdz> yeah, I thought so too
[03:46] <lamont> Xof: no ulimits that I know of 
[03:46] <Xof> lamont: having the output of /proc/`pidof emacs`/maps (when there's an emacs started) on the machines would be useful
[03:46] <Kamion> mdz: the bug's in debbugs-log.pl; I'll have a look after I get back from lunch
[03:46] <Xof> lamont: there's no terribly urgent rush from my point of view, so if you have more urgent things, go do them :-)
[03:46] <lamont> Xof: the ubuntu buildd's use ccache and a small gcc-shim (which should be having no effect on sbcl), but are otherwise currently no different from debian in any practical way
[03:46] <mdz> Kamion: meanwhile, I should probably find a workaround, since it's adding a new comment every 15 minutes...
[03:47] <fabbione> lamont: i did ping willy.. he doesn't know what is the I/O problem either
[03:47] <mdz> oh, it's been downgraded, I can just remove it
[03:47] <Xof> (fwiw, I committed amd64 support to the sbcl development tree yesterday, and it's working fine on my ubuntu desktop... so it's just the rest of the world which needs this investigation ;-)
[03:47] <fabbione> lamont: in anycase.. the kernel compiles now.. we need to allign the configurations
[03:47] <lamont> fabbione: ggg was mumbling about it last night.
[03:48] <fabbione> lamont: ok. i need to check the pa6 patch now and see if it still applies with the fixes i am backporting from bk
[03:48] <fabbione> lamont: after that i will handle you the packages to prepare the configs
[03:48] <fabbione> lamont: because i dunno some of the stuff it asks for
[03:48] <lamont> ok
[03:48] <fabbione> lamont: that are pretty specific to hppa hardware
[03:48] <lamont> right
[03:49] <Xof> lamont: I'll tell you up front that the nondeterminism in the failure point tends to lead me to suspect hardware problems (at least on x86 and powerpc); sbcl compilation is a very good way of finding those.  On the other hand, your buildds are presumably surviving the rest of the load, so...
[03:49] <Kamion> mdz: aha, this is an amusing bug :)
[03:49] <Kamion> -        $text =~ s/^\./../m;                    # escape dots
[03:49] <Kamion> +        $text =~ s/^\./../gm;                   # escape dots
[03:49] <Kamion> mdz: try that
[03:50] <Kamion> it only escaped the first dot :)
[03:50] <Kamion> (I've tested it, seems to do the right thing here)
[03:50] <lamont> buildd's are nice fat IBM boxes that have been doing quite well for some time.  The one of 10 or so that had memory issues has been repaired lo these 6 months or so.
[03:50] <lamont> Xof: and memtest was quite happy at that point.
[03:51] <Kamion> lamont: do we run exec-shield kernels on the buildds?
[03:51] <elmo> mdz: removed
[03:51] <elmo> Kamion: no
[03:51] <Kamion> ok
[03:51] <elmo> we don't run exec-shield anywhere anymore
[03:52] <mdz> Kamion: I put that in place; we'll see what happens with #5271
[03:52] <Xof> to be honest, I'm not entirely sure what to suggest
[03:52] <lamont> Kamion: so, livecd-rootfs...
[03:52] <lamont> wanna discuss it here, or take it off-channel, since it's almost entirely administrivia
[03:52] <lamont> ?
[03:52] <Xof> the same source builds fine on debian and elsewhere.  It's _possible_ that you'd see this kind of thing if the previous binaries (which you're using to build from) are bad, of course
[03:53] <Kamion> lamont: off-channel's probably better
[03:53] <Kamion> unless mdz's interested
[03:53] <Kamion> or amu
[03:54] <elmo> lamont: have you tried building without the wrapper?
[03:54] <lamont> elmo: not yet.
[03:54] <mdz> lamont: here is fine, unless there's a reason to keep it a secret
[03:54] <mdz> I would like to have a record to refer to
[03:55] <lamont> mdz: OK.
[03:55] <lamont> mdz: or ubuntu-meeting?
[03:56] <fabbione> daniels: ROCKING xserver-xorg_6.8.1-1ubuntu9_sparc.deb!
[03:56] <mdz> lamont: wherever
[03:56] <lamont> fabbione: about time, slacker. :-)
[03:56] <fabbione> lamont: i had to build twice man :-)
[03:56] <Kamion> lamont: where's easiest for you to get the blobs to, then?
[03:56] <fabbione> before to test and to do the real build
[03:56] <fabbione> ;)
[03:56] <lamont> heh
[03:56] <lamont> and on sparc.  ok.
[03:57] <fabbione> no.. on ONE sparc...
[03:57] <fabbione> you have N * 4 
[03:57] <fabbione> or * 3
[03:57] <fabbione> still...
[03:57] <fabbione> ;)
[03:57] <Kamion> mdz: d-i with 2.6.10, rescue-check, casper-check uploaded
[03:57] <lamont> Kamion: so the livecd script (a) can run in a chroot, so it will, and (b) generates ~525MB of cloopimage on i386 - prolly about the same on the others,
[03:57] <fabbione> Kamion: rocking hard!
[03:58] <lamont> since elmo doesn't want it going near the archive, and it'd be by-hand anyway, we get to figure out some other way to get the bits where they need to go.
[03:58] <mdz> Kamion: way cool
[03:58] <lamont> Kamion: me too.
[03:59] <Kamion> can I just wget it from the relevant buildd or something?
[03:59] <mdz> lamont: powerpc will end up bigger, but of course we don't need to worry about opencd stuff on powerpc I suppose
[03:59] <lamont> Kamion: certainly
[03:59] <mdz> lamont: unless we start shipping macos ports :-)
[03:59] <Kamion> lamont: assuming, of course, that it's always going to be the same one ...
[03:59] <Kamion> mdz: fink! :)
[04:00] <lamont> Kamion: so I'll get you a list of the buildd's in question, and then it's just wget http://.../~buildd/...
[04:00] <lamont> Kamion: always the same one
[04:00] <lamont> barring events
[04:00] <sivang> anybody seen pitti ?
[04:00] <Kamion> then, as I read casper-udeb, I stick that in casper/filesystem.cloop on the image
[04:00] <pitti> sivang: I think I have seen him recently :-)
[04:00] <lamont> brb
[04:01] <Kamion> now, the rest of the image should have dists/ and pool/ with d-i udebs, but no debs; correct?
[04:01] <Treenaks> pitti: prove it! ;)
[04:01] <thom> pitti: lots of mirrors in your house?
[04:01] <mdz> Kamion: what's the least ugly shell idiom for "run all this bit in a subshell, and if it fails, do this bit instead" ?
[04:01] <daniels> fabbione: :)
[04:01] <Kamion> mdz: (...) || ...?
[04:01] <mdz> ("all this bit" is many lines)
[04:01] <pitti> Treenaks: I think, therefore I am mad
[04:01] <pitti> Treenaks: or so... :-)
[04:01] <Treenaks> pitti: 8)
[04:01] <mdz> (...many many lines...) || ... seems a bit ick
[04:01] <Kamion> mdz: use a shell function for the first bit
[04:01] <Kamion> then (function) || ...
[04:02] <sivang> pitti: hehe, I tried to autocomplete you name to message you but couldnt :)
[04:02] <sivang> pitti: eh, multi network clients..
[04:02] <Kamion> mdz: do you want me to attempt to trim the list of udebs included on the live CD?
[04:02] <mdz> Kamion: yes
[04:03] <Kamion> mkay
[04:03] <fabbione> ChangeSet@1.1938.463.14, 2005-01-03 20:14:55-08:00, slpratt@austin.ibm.com
[04:03] <fabbione>   [PATCH]  Simplified readahead
[04:03] <fabbione> thoM ^
[04:03] <Kamion> ideally that would be a seed or something
[04:03] <mdz> Kamion: yeah, casper needed functionalizing anyway
[04:04] <mdz> Kamion: happy for you to create a seed out of it
[04:04] <fabbione> check it from bk9 changelog
[04:04] <Kamion> casper.seed?
[04:04] <Kamion> casper-first-stage.seed?
[04:04] <Kamion> then I'd get to figure out where the hell it lives in germinate :)
[04:04] <thom> fabbione: i don't think i care that much that it's worth backporting
[04:05] <Kamion> fabbione: you forgot to say "the first one's free"
[04:06] <Kamion> mdz: how about we call the first-stage seed 'casper' and the live-filesystem seed 'live'?
[04:07] <fabbione> thom: oh yes.. you do.. if you check the performance improvements :-)
[04:07] <fabbione> Kamion: uh?
[04:08] <thom> fabbione: that much?
[04:08] <fabbione> thom: quite a lot yes
[04:08] <Kamion> fabbione: I was reminded of a dealer passing out crack in the form of tasty kernel patches :)
[04:09] <elmo> s/one/hit/
[04:09] <mdz> Kamion: hmm, tough one
[04:09] <thom> fabbione: cool, thanks :-)
[04:09] <Kamion> elmo: do you care about the names of individual seeds, or do you just look at 'all'?
[04:09] <mdz> Kamion: whatever works for you
[04:09] <Kamion> mdz: kinda makes sense to me since you could boot into the live filesystem in ways other than casper
[04:09] <elmo> I care for generating Task: desktop entries, but other than that, no
[04:10] <fabbione> Kamion: ahahha
[04:10] <Kamion> elmo: ok, so a new seed that germinate treats as part of 'all' will automatically feed into main?
[04:10] <lamont> Kamion: things I know need to get tweaked on the livecd:  netconf (duh), /etc/postfix/main.cf, /etc/mailname (both done with the reconfig of postfix in base-installer, iirc), and /etc/papersize based on locale.  I can make the file not be there, if you can run the postinst...
[04:10] <fabbione> Kamion: that's why he will pay for the readhaed-congestion-control :-)
[04:11] <Kamion> base-config not base-installer
[04:11] <Kamion> lamont: guess that gets to be part of the weird hacks casper does :)
[04:11] <elmo> Kamion: err, mm, lemme check, but I think so
[04:12] <lamont> Kamion: yeah.  just wanted to make sure they were on the table.
[04:12] <elmo> Kamion: yes
[04:12] <Kamion> hm, I'll include that one, it's cheap
[04:12] <Kamion> elmo: ok, thanks
[04:13] <sabdfl> Kamion: can the installer framebuffer support a mouse pointer?
[04:13] <thom> holy crap! 25-100% performance improvements?
[04:13] <thom> dude, what are you waiting for
[04:14] <daniels> baaaaackport :)
[04:14] <daniels> sabdfl: not a pointer as such ... more a sort of floating block
[04:15] <sabdfl> i've seen mouse pointers of fb-text before...
[04:15] <Kamion> directfb does mouse pointers, doubt the plain fb does
[04:15] <Kamion> although I could be wrong
[04:15] <ogra_> gpm with a special charset ?
[04:16] <Kamion> (we don't have mouse drivers in the installer at the moment, so nobody's ever tried afaik :))
[04:16] <fabbione> pitti:
[04:16] <fabbione> ChangeSet@1.1938.463.17, 2005-01-03 20:15:37-08:00, Andries.Brouwer@cwi.nl
[04:16] <fabbione>   [PATCH]  mm: overcommit updates
[04:16] <fabbione> this patch is cool
[04:16] <fabbione> but really cool
[04:16] <Treenaks> fabbione: what's so cool about it?
[04:16] <fabbione> thom: i did already.. only for you :-)
[04:16] <fabbione> Treenaks: the memory allocation for root
[04:16] <thom> aw, you knew what i wanted for christmas
[04:16] <fabbione> reserver for root
[04:17] <pitti> fabbione: "mm overcommit" rings a bell
[04:17] <fabbione> Treenaks: basically a user with no ulimits cannot allocate all the RAM on the machine but only up to 97%
[04:17] <pitti> fabbione: we already have this, right?
[04:17] <fabbione> pitti: adding it now.
[04:17] <Treenaks> fabbione: coolness
[04:17] <fabbione> Treenaks: basically that ensures a 3% left for the user
[04:18] <fabbione> hem root
[04:18] <fabbione> to kill the user
[04:18] <fabbione> without having to reboot the machine
[04:18] <lamont> fabbione: what'll the hppa meta packages be?  linux-hppa32 and linux-hppa64?
[04:18] <fabbione> lamont: no idea.. 
[04:19] <lamont> what are sparc's?
[04:19] <thom> big expensive things
[04:19] <fabbione> linux-sparc64
[04:19] <thom> made by fujitsu-siemens
[04:19] <fabbione> so i guess it would be linux-hppa32 and hppa64
[04:20] <lamont>   # and the bastard stepchildren
[04:20] <lamont>   hppa)         KERNEL="linux-hppa32 linux-hppa64";;
[04:20] <lamont>   sparc)        KERNEL="linux-sparc64";;
[04:21] <elmo> thom: badoom-tisch
[04:21] <fabbione> pitti: people/~fabbione/stolen-from-head_mm-overcommit-updates.dpatch
[04:22] <thom> it was making steam rise from my brain, and the windows were misting up
[04:22] <daniels> thom: more!
[04:23] <mako> jdub: around?
[04:24] <mako> Josephus: probably not
[04:24] <mako> ergh
[04:24] <mako> jdub: probaby not
[04:24] <mako> Josephus: sorry.. borked completions
[04:24] <mako> jdub: traffic -> planet.ul.o
[04:26] <fabbione> thom: i am going to give you another 50% performance increase in the next patch:
[04:26] <fabbione> ChangeSet@1.1938.463.20, 2005-01-03 20:16:19-08:00, miquels@cistron.nl
[04:26] <fabbione>   [PATCH]  mark_page_accessed() for read()s on non-page boundaries
[04:26] <fabbione> this rocks for databases
[04:27] <fabbione> elmo: ^^you really want that on emperor
[04:31] <elmo> is anyone else seeing bizarre scrolling problems with xterm recently?
[04:31] <elmo> where the screen will like hang for a bit when you throw lots of really fast data at it, but recover 5-10 seconds later
[04:31] <thom> yay, we have infected fabio with the desire for SPEEEEEEEEEEEEEEEEEEEEEEEEEED
[04:32] <elmo> fabbione: get you and your pull-random-patches-from-bk crack behind me and my production machines ;-P
[04:33] <mdz> hmm
[04:33] <Keybuk> OSError: [Errno 2]  No such file or directory: 'sources/elilo-installer_1.3/elilo-installer_1.3/debian/changelog'
[04:33] <mdz> if a shell script is set -e, does an unsuccessful command in a function terminate the entire shell?
[04:33] <Keybuk> meh
[04:34] <mdz> or only the function?
[04:35] <mdz> eek, the whole script it seems
[04:35] <Kamion> if it's in a subshell it terminates just the subshell
[04:36] <Kamion> Keybuk: 1.3? where'd that come from? current is 0.3
[04:36] <Kamion> no it's not
[04:37] <Kamion> hah, elilo-installer_1.3.tar.gz contains the directory elilo-installer-1.3/
[04:37] <Kamion> hah, elilo-installer_1.3.tar.gz contains the directory elilo-installer-0.3/
[04:37] <Kamion> slap dannf :)
[04:37] <fabbione> elmo: tsk!
[04:37] <fabbione> ;)
[04:37] <Keybuk> it does?  heh
[04:39] <mdz> Kamion: yeah, so I need a subshell inside a function to get what I want, bleah
[04:40] <Kamion> elmo: what did you think of my gpgv-udeb patch?
[04:41] <mdz> Kamion: hmm, so my progress bar comes up, but all the text is missing
[04:42] <seb128> Keybuk: any idea on #4785 ?
[04:42] <mdz> Kamion: the templates are present in the udeb, but I don't see them in /var/cache/debconf/templates.dat
[04:43] <Kamion> there is no /var/cache/debconf/templates.dat in d-i, it's /var/lib/cdebconf/templates.dat
[04:43] <elmo> Kamion: err
[04:43] <mdz> there is on my initrd; I wonder where it came from
[04:44] <mdz> anyway I thought I did everything right, but I get no text
[04:44] <mdz> not even the text for the progress bar title
[04:44] <Kamion> mdz: it came from your mad udpkg --unpack onto initrd thing
[04:44] <mdz> is /var/lib/cdebconf/templates.dat where I should look?
[04:44] <Kamion> mdz: if you do that, udpkg calls debconf-loadtemplate, but it will call the version in the development system rather than the one in the initrd
[04:44] <Kamion> yeah
[04:44] <Kamion> but after booting
[04:45] <Kamion> the initrd should have the text in /var/lib/dpkg/info/*.templates
[04:45] <Keybuk> seb128: hmm... Libtool doesn't strip a /usr/lib rpath on AMD64 ... I can believe that; does "gcc -print-search-dirs" include /usr/lib on AMD64?
[04:45] <fabbione> ChangeSet@1.1938.463.31, 2005-01-03 20:18:48-08:00, rusty@rustcorp.com.au
[04:45] <fabbione>   [PATCH]  netfilter: Remove IPCHAINS and IPFWADM compatibility
[04:45] <fabbione> mdz: ?
[04:45] <mdz> Kamion: the initrd?
[04:45] <mdz> fabbione: yay
[04:45] <fabbione> or is it too scary?
[04:46] <mdz> sounds great to me
[04:46] <ogra_> no, do it !
[04:46] <fabbione> ok
[04:46] <mdz> less code -> less bugs
[04:46] <seb128> Keybuk: dunno ... anybody with an amd64 box around ? thom ?
[04:46] <mdz> er, less code -> fewer bugs :-P
[04:46] <thom> Keybuk: /usr/lib/, yes
[04:46] <Kamion> mdz: yes ...?
[04:46] <Keybuk> seb128: unless they made the stupid mistake of building epiphany on Fedora
[04:46] <mdz> Kamion: this is in casper-udeb
[04:46] <ogra_> seb128: next week, its ordered ;)
[04:47] <Kamion> mdz: oh
[04:47] <Keybuk> can you: grep "^    sys_lib_dl" *.m4  -- (4 spaces) in the epiphany source directory?
[04:47] <seb128> Keybuk: what's specific about fedora ?
[04:47] <Kamion> mdz: udpkg should call debconf-loadtemplate when unpacking it then, so /var/lib/cdebconf/templates.dat
[04:47] <seb128> $ grep "^    sys_lib_dl" *.m4
[04:47] <seb128>     sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
[04:47] <seb128>     sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff} $lt_ld_extra"
[04:47] <Keybuk> muahahaha
[04:48] <Keybuk> yeah, that's the fuck-arsed broken Fedora version of Libtool
[04:48] <Keybuk> SUFFER AND DIE!
[04:48] <seb128> chpe use fedora yep
[04:48] <seb128> so we just have to relibtoolize it ?
[04:48] <Keybuk> libtoolize, aclocal, autoconf, share and enjoy
[04:48] <seb128> thanks Keybuk 
[04:50] <mdz> Kamion: templates are present in cdebconf/templates.dat
[04:50] <mdz> Kamion: my god it is huge
[04:51] <Kamion> yep
[04:51] <mdz> what's the next suspect?
[04:51] <Kamion> incorrect use of the progress API probably
[04:51] <mdz> mailed you a copy of the code
[04:51] <elmo> Kamion: looks fine
[04:52] <elmo> Kamion: did you need it soonish?
[04:52] <Kamion> elmo: need it for apt authentication support in the installer, which I'd like to finish by feature freeze
[04:52] <mdz> oh
[04:52] <mdz> Kamion: I think I need to call STEP before INFO, rather than after
[04:53] <Kamion> so soonish would be nice if you could, yeah
[04:53] <Kamion> mdz: should work either way round
[04:53] <mdz> it looks correct to me, then
[04:53] <Kamion> I'm fairly sure I've written both
[04:55] <fabbione> mdz: fabbione@gordian:/usr/src/bk$ ./dpatchify 1.1938.463.31 ipchains_and_ipfwadm__must_die
[04:55] <fabbione> there you go...
[04:55] <mdz> Kamion: your debbugs-log.pl fix seems to have worked
[04:55] <Kamion> good
[04:58] <Kamion> mdz: looks ok to me too, I'd triple-check that the template names are right ...
[04:59] <mdz> Kamion: I generated the .templates file using grep|awk on the script, so I'm extremely certain that they match
[04:59] <Kamion> hm, ok
[04:59] <Kamion> can I see the templates file?
[04:59] <Kamion> wondering about po-debconf weirdness
[04:59] <mdz> sure
[04:59] <mdz> sent
[05:00] <mdz> ahhh
[05:00] <mdz> I bet that's it
[05:00] <mdz> I don't have a debian/compat file
[05:00] <mdz> hmm, maybe not
[05:00] <mdz> I thought that made a difference, but it doesn't seem to
[05:01] <mdz> mizar:[...canonical/casper/casper-0.2]  diff -u debian/casper-udeb.templates debian/casper-udeb/DEBIAN/templates
[05:01] <mdz> mizar:[...canonical/casper/casper-0.2] 
[05:02] <Kamion> that's not normal, there's usually debian/po/ and '2 utf8' in debian/po/output, which changes the format
[05:02] <mdz> I didn't create debian/po
[05:02] <mdz> should I?
[05:02] <Kamion> yes
[05:02] <mdz> ok, done
[05:02] <mdz> doesn't seem to make a difference, though
[05:02] <mdz> oh, yes it does
[05:02] <mdz> guh
[05:02] <Kamion> you'll need to do the full po-debconf gettextising routine
[05:03] <mdz> well, just creating debian/po fixed the output templates file
[05:03] <Kamion> Description: lines (at least) in .templates need to be _Description:
[05:03] <mdz> -_Description: Starting up
[05:03] <mdz> +Description: Starting up
[05:03] <Kamion> ah
[05:03] <Kamion> yes, if they were already _Description: then you'd have had a problem
[05:03] <Kamion> try debconf-updatepo as well
[05:03] <Kamion> to create templates.pot
[05:03] <mdz> File debian/po/POTFILES.in does not exist... exiting
[05:04] <Kamion> [type: gettext/rfc822deb]  casper-udeb.templates
[05:04] <mdz> did that, re-ran, works
[05:04] <mdz> doing a new test CD build now, thanks
[05:14] <elmo> mdz: dude, flac needs relibtoolized
[05:14] <fabbione> Kamion:   [PATCH]  ppc32: add uImage to default targets
[05:14] <fabbione> do we need this?
[05:15] <lamont>   ubuntu-desktop: Depends: rhythmbox but it is not going to be installed
[05:15] <lamont> GAH!
[05:15] <Kamion> fabbione: not worth backporting, it's for Amiga hardware IIRC
[05:16] <lamont> who knows, maybe rhythmbox will be installable then
[05:16] <Kamion> mdz: I've added a casper seed; you probably want to eyeball it
[05:16] <lamont> After installing, the following source dependencies are still unsatisfied:
[05:16] <lamont> python-dev(inst 2.4-0ubuntu4 ! << wanted 2.4)
[05:16] <lamont> must flee
[05:18] <fabbione> Kamion: ok
[05:19] <Keybuk> mdz: there were a handful of stuck merges, I've fixed the bug that caused them and they've been released; so there's probably a few more bugs been filed.  otherwise, that's a line drawn now
[05:27] <mdz> elmo: hmm, yeah, keybuk said the same thing, but I forgot to do it in -3
[05:28] <mdz> Keybuk: ok, thanks
[05:28] <mdz> Keybuk: can we generate a list for universe as well?
[05:28] <mdz> s/list/output/
[05:31] <elmo> SWEET
[05:31] <elmo> sensors-detect kills our dells
[05:31] <thom> kick ass
[05:33] <Keybuk> what kind of output do you want?
[05:33] <thom> elmo: i assume it was maitri you just special'ed, then
[05:37] <elmo> thom: yeah
[05:37] <elmo> I thought it be a bit harsh to trash James' arch box, even if it his devel server ;)
[05:37] <thom> heh
[05:38] <sabdfl> special'ed? that with arm effects?
[05:38] <thom> sabdfl: the arm effects are optional
[05:38] <elmo> is lm-sensors going in main for hoary?
[05:39] <Keybuk> are there many machines where lm-sensors is useful anymore?
[05:40] <Keybuk> I thought most of it was covered through ACPI and I2O in the kernel nowadays
[05:40] <mdz> Keybuk: the kernel bits are all in the kernel now
[05:40] <mdz> the userland bits are in main for hoary already, I thought
[05:40] <elmo> none of the servers in the DC have ACPI which can do what lm-sensors does
[05:40] <elmo> neither does my home machine
[05:40] <mdz> there was a discussion and agreement on it anyway
[05:41] <mdz> hmm
[05:41] <mdz> scratch that
[05:41] <mdz> anyway, I fixed it so that it doesn't build the kernel bits, and it's ready to be seeded
[05:41] <mdz> I'll seed it now
[05:42] <mdz> lamont: do you have a new image for me?
[05:43] <mdz> elmo: done
[05:44] <elmo> what about the seed proposals we discussed at mataro, are they getting done for hoary?
[05:45] <mdz> thom: ?
[05:45] <thom> ahr, i knew there was something
[05:46] <thom> shall i update the seeds direct, or the wiki and someone else will do the seeds?
[05:46] <daniels> elmo: sensors-detect kills a LOT of things
[05:47] <Kamion> thom: the wiki is totally obsolete
[05:47] <elmo> daniels: I don't see why, it's the same bloody mb as the IBM and it didn't kill that :PO
[05:47] <Kamion> if whoever's relevant (probably mdz/jdub) okays it, just update the seeds in arch
[05:47] <daniels> elmo: it takes out all my boards here
[05:47] <mdz> thom: there are no more seed lists in the wiki
[05:48] <Kamion> unless you mean the proposals pages
[05:48] <mdz> thom: the ones in baz are the one, true and authoritative seeds
[05:48] <thom> seed proposals, rather
[05:48] <thom> ok
[05:48] <mdz> this is stuff which was already discussed and approved at the conference, right?
[05:48] <trulux> mdz: did you read the doc?
[05:49] <thom> yes
[05:52] <mdz> trulux: no, not yet.  please send me an email so that I don't forget about it
[05:52] <cartman> elmo new flac packages fixed libflac6 problems but now some packs are un-installable because they depend on now removed libflac4
[05:53] <trulux> mdz: ok
[05:53] <cartman> gstreamer0.8-flac libtunepimp2 libtunepimp2-dev vorbis-tools
[05:53] <mdz> cartman: once flac is built on all architectures, we'll upload new versions of those packages
[05:54] <cartman> mdz: so I shouldn't update bugreport?
[05:54] <cartman> with the new info
[05:57] <mdz> cartman: no need; there is a list of uninstallable packages which is automatically generated
[05:57] <cartman> mdz: cool, thanks for info
[05:57] <cartman> you guys are fast bugfixers. appreciated
[06:00] <thom> what did we end up deciding for oo.o-evo/gnomevfs? that we're doing so only for x86/ppc
[06:00] <mdz> thom: dunno, but it seems a bit broken at the moment
[06:01] <thom> shall i hold off seeding them for the time being
[06:02] <thom> elmo: doesn't look good for the HP, then?
[06:04] <elmo> well.. I can helpfully see the banks of memory via lm-sensors... but for anything useful? no.. meh
[06:04] <kent> not that it matters, but how long until flac is build on the other platforms?
[06:04] <elmo> bizarrely, the IPMI stuff doesn't even work, but does with the much lower-end DL140's
[06:17] <Treenaks> mako: post 10 funny replies then :P
[06:18] <mdz> kent: it's done already
[06:18] <mako> Treenaks: i posted one funny reply :)
[06:18] <mako> Treenaks: that's my quota
[06:18] <mdz> and I just uploaded three packages
[06:19] <mdz> kent: for future reference, you can check both things for yourself at http://people.ubuntulinux.org/~lamont/buildLogs/ and http://lists.ubuntu.com/mailman/listinfo/hoary-changes
[06:19] <Treenaks> I justed picked up a copy of "Mind Hacks" (by Stafford & Webb)
[06:19] <Treenaks> great book :)
[06:20] <kent> mdz, thanks :)
[06:21] <mdz> mako: we need an equivalent of www.d.o/devel/ which points to all this stuff
[06:22] <mako> mdz: here.. lets make a wiki page for right now and then move it into the website once it's stablized
[06:22] <mdz> mako: sounds good
[06:23] <mdz> mako: once it exists, add it to the topic, and I'll add anything else to it that I think of
[06:23] <mako> http://www.ubuntulinux.org/wiki/MaintainerDocumentation
[06:23] <mako> i just found it
[06:23] <mdz> that needs to be named DeveloperResources or something instead
[06:24] <mako> i'll rename
[06:24] <mdz> lots of people who aren't maintainers can benefit from it
[06:24] <mako> chris halls did it :)
[06:24] <robtaylor> mako: hey.. out of intrest will you be going to the CDD devcamp?
[06:24] <mako> http://www.ubuntulinux.org/wiki/DeveloperResources
[06:24] <mako> robtaylor: yes.. i didn't reply onlist but i did reply
[06:25] <robtaylor> mako: groovey :)
[06:26] <robtaylor> mako: it'll be a busy summer :) FISL, CDD, then debconf.. hope i can get all the time off work :)
[06:26] <mako> robtaylor: debconf is very long this year.. i suspect many people will come for just a part
[06:26] <mako> robtaylor: i will probably take 4-5 days off to go to LSM, which happens during the middle of debconf
[06:27] <robtaylor> mako: LSM?
[06:27] <azeem> mako: are you going to hit LinuxTag as well?
[06:28] <mako> libre software meeting.. french free software meeting. one of my personal favorites
[06:28] <mako> azeem: yes, it's on the list
[06:28] <mako> azeem: is there a CFP yet? i put lt and lsm on the list of confs that i thought canonical should send people to
[06:29] <azeem> dunno, Joey would know about LT
[06:29] <azeem> I believe LSM is pretty unorganized
[06:29] <mako> this year seems better
[06:29] <mako> they have dates and a location and speakers already (!)
[06:29] <mako> that's like 6 months better than last time :)
[06:29] <azeem> whoa, you got an URL?
[06:30] <mako> i've been emailing with one of hte organizers
[06:30] <azeem> mako: Joey just said the deadline for LinuxTag is today
[06:30] <mako> damnit
[06:30] <cartman> mdz: ping
[06:31] <elmo> when is debconf?
[06:31] <azeem> mako: nah, it appears to be 15th Jan for LinuxTag
[06:31] <mako> woot!
[06:32] <robtaylor> mako: so why's LSM your fave? ;)
[06:32] <robtaylor> elmo: 1st two weeks of july i believe..
[06:33] <mako> robtaylor: it's basically just talks, TONS of them (8-10 tracks) and nothing else for 4 days
[06:33] <cartman> mdz: nm see my comments @ https://bugzilla.ubuntu.com/show_bug.cgi?id=4680
[06:33] <mako> robtaylor: lots of really great people saying lots of great things.. the facilities aren't that great, etc.. the emphasis is completely on the content and on sharing information with each other
[06:34] <mako> robtaylor: i have always learned a ton
[06:34] <robtaylor> mako: nice :)
[06:34] <thom> cartman: i know already, fix coming shortwith
[06:34] <mako> robtaylor: it helps a lot if you understand french
[06:34] <cartman> thom: alright
[06:34] <mdz> cartman: please file a separate bug about that; it is a bug in its own right
[06:34] <mdz> cartman: or, don't bother, because thom already knows
[06:34] <cartman> right
[06:34] <mdz> not used to thom being awake ;-)
[06:35] <thom> oi!
[06:35] <cartman> hehe
[06:35] <elmo> LOL
[06:35] <mdz> due to time zone differences, of course
[06:35] <bob2> haha
[06:35] <thom> cartman: your analysis is way off, by the way :-)
[06:35] <bob2> robtaylor: finnish
[06:35] <cartman> thom: speculation always works :P
[06:35] <robtaylor> bob2: i think i'd need a decade for that ;)
[06:35] <mdz> mako: oh god it's in restructuredtext
[06:36] <cartman> thom: whats the real problem?
[06:36] <bob2> haha
[06:36] <bob2> itym reStruCtuREDTeXt
[06:36] <robtaylor> bob2: oh, a freind of man was asking the other day.. has australia got anything good on its human rights records?
[06:36] <thom> cartman: on_ac_power helpfully returns 255 if it can't work out whether you're on ac power or not
[06:36] <robtaylor> s/man/mine
[06:36] <cartman> thom: I see :)
[06:36] <bob2> robtaylor: we used to not suck
[06:37] <mdz> ReST makes me want to die
[06:37] <robtaylor> bob2: heh
[06:37] <cartman> thom: I thought since it will do fsck it won't mount filesystem ;)
[06:37] <thom> that's why i check for the existence of on_ac_power before trying to use it ;-)
[06:38] <cartman> my bad
[06:38] <lamont_r> mdz:?
[06:38] <bob2> robtaylor: we used to be pretty good about pressuring other countries to shape up, but now all we do is lock up refugees and oppress indigenous people.
[06:38] <mdz> lamont?
[06:38] <lamont_r> can we pretty please have cloop-utils in main?  we're supporting it after all...
[06:38] <mdz> thom: isn't cloop-utils on your list?
[06:38] <mdz> if not, I'll add it right now
[06:39] <mdz> I thought it had already been done
[06:39] <lamont_r> then I don't have to bounce sources.list around in the chroot - it really doesn't like building a livecd rootfs with universe in there.  That or rhythmbox really was broken.
[06:39] <thom> mdz: no
[06:39] <mjg59> thom: So, how are we going to write these ACPI scripts?
[06:39] <elmo> someone needs to fix cloop not to use modules-assistant
[06:39] <elmo> then it can go into main
[06:39] <elmo> there's a bug in bugzilla
[06:39] <robtaylor> bob2: heh, thanks. I seemed to remeber it being something like that :/
[06:39] <lamont_r> elmo: ok.
[06:39] <mdz>  * cloop-utils # for LiveCD
[06:39] <mdz> lamont: it's already there
[06:40] <lamont_r> interesting... 
[06:40] <mdz> hmm
[06:40] <mdz> amu?
[06:40] <mdz> amu: I assigned that bug to you some time ago
[06:40] <amu> mdz: ?
[06:40] <mdz> amu: https://bugzilla.ubuntu.com/show_bug.cgi?id=4535
[06:41] <lamont_r> mdz: interestingly, http://archive.ubuntu.com/ubuntu/pool/main/c/cloop is 404...
[06:41] <mdz> lamont: what elmo said
[06:41] <lamont_r> mdz: so it's really just blocked on the bug
[06:41] <Kamion> lamont_r: rhythmbox really was broken, per britney
[06:41] <lamont_r> Kamion: kewl.
[06:41] <Kamion> somebody with a spare minute oughta fix that
[06:42] <lamont_r> Kamion: no ia64 love for you today - glibc still b0rked there
[06:42] <lamont_r> other 3 are chunking away now
[06:42] <mdz> Kamion: already did
[06:42] <mdz> it depends on vorbis-tools, which was broken due to flac
[06:42] <lamont_r> Kamion: it installs now...
[06:43] <mdz> I uploaded fixes for all the flac stuff in main a short while ago
[06:43] <amu> mdz: in process now 
[06:44] <Kamion> lamont_r: I'm buried in kickstart anyway :-/
[06:44] <lamont_r> Kamion: actually meant no livecd-rootfs, but the other is true to.
[06:44] <robtaylor> mdz, amu: can you point me to the current livecd work? 
[06:45] <mdz> robtaylor: www.ubuntulinux.org/wiki/LiveCD or such
[06:45] <sabdfl> lamont: is there any way to force postfix to relay through a host and use SSL?
[06:45] <sabdfl> erm, worse
[06:45] <sabdfl> use SSL *if it's offered*
[06:45] <sabdfl> sorry elmo
[06:46] <Kamion> elmo: funky
[06:46] <lamont_r> sabdfl: you can use a transport map to force it, force it.  relayhost generally does a good enough job though.
[06:46] <lamont_r> as for the TLS stuff, it's done opportunistically
[06:46] <sabdfl> so if it sees it, it uses it?
[06:47] <lamont_r> if it's configured...
[06:47] <lamont_r> we don't currently configure it
[06:47] <sabdfl> configured?
[06:47] <elmo> did we make a decision about MTA for hoary yet btw?
[06:47] <sabdfl> hmm... let's switch to #ubuntu
[06:51] <robtaylor> mdz: umm, i mean your d-i code. or can i just apt-get the hoary source for d-i + debian-cd?
[06:52] <mdz> robtaylor: the magic is spread around in many packages, but probably the most interesting one is casper
[06:53] <mdz> lamont: do you have something for me to download?
[06:53] <mdz> lamont_r: ^^^
[06:53] <fabbione> not too bad
[06:54] <fabbione> i am not even at 40
[06:54] <fabbione> 40% of bk9 changelog
[06:54] <fabbione> and we have already like 80 patches
[06:54] <fabbione> and there is bk10 out already..
[06:54] <mdz> why?
[06:54] <fabbione> mdz: all small bug fixes
[06:55] <fabbione> plenty of them
[06:55] <Kamion> hm, translating kickstart 'partition' will be interesting
[06:55] <Kamion> I think I'm going to have to write out a partman-auto recipe on the fly, or something
[06:56] <lamont_r> mdz: people.ubuntu.com/~lamont/mdz/livecd.cloop , iirc
[06:57] <lamont_r> yep.  that's it.
[06:58] <lamont_r> Kamion: setting up http for you after lunch
[07:02] <sivang> mdz: [curiosity]  what is casper?
[07:02] <mdz> sivang: the new infrastructure for the live CD
[07:03] <sivang> mdz: k, thanks, is it downloadable from anywhere yet?
[07:03] <tseng> sivang: it was accepted into hoary
[07:03] <mdz> sivang: it is a package in the Ubuntu archive
[07:03] <sivang> mdz: coooool :)
[07:05] <mdz> it will be trivial with casper
[07:05] <sivang> mdz: that's what I thought, Kamion and you are the people to thank to? :)
[07:05] <mdz> and the live DVD should support all locales
[07:06] <sivang> mdz: eh! now that's rad
[07:06] <Kamion> mostly mdz, I just checked a few things and gave advice
[07:06] <sivang> mdz: seems that localized ones are bit redundent, given the live dvd will be also distributed free by canonical? 
[07:07] <mdz> it depends on what will fit
[07:07] <Kamion> plenty of machines don't have DVD readers
[07:07] <mdz> which reminds me
[07:07] <mdz> Kamion: how are we going to work the magic to install language packs?
[07:07] <sivang> Kamion: most of the machines around my region and many people I know have been shipped with dvd reader since about 2 years ago :)
[07:07] <Kamion> mdz: for the install CD?
[07:08] <mdz> Kamion: yes
[07:08] <Kamion> mdz: hack up base-config/lib/menu/pkgsel, I figure
[07:08] <mdz> and maybe for the live CD also if we get tricky
[07:08] <ogra> sivang: i my company we have 900 PCs ... guess how many DVD readers 
[07:08] <sivang> ogra: 900? :)
[07:08] <ogra> 3
[07:08] <mdz> Kamion: e.g., ship with top N languages in the filesystem image, but if you select something else, download the language pack on the fly and install it
[07:09] <ogra> and the machines are about 2 years old
[07:09] <Kamion> mdz: (hell, just unconditionally aptitude install ...)
[07:09] <Kamion> mdz: by pkgsel I've got the language, so it's a SMOP
[07:10] <mdz> Kamion: casper doesn't talk to base-config yet, but it ought to
[07:10] <Kamion> mdz: note that kickstart has a langsupport command that lets you install multiple languages; it would be interesting to figure out how to integrate that
[07:10] <mdz> the last time I tried something like this, it didn't DTRT for noninteractive mode
[07:11] <Kamion> in fact kickstart has one command for the installation language and a totally separate command for the installed language(s)
[07:11] <sivang> Kamion: that would make preseeding a d-i question redundent? if kickstart would take care of it setting the default local/input lang per loccalized install cd.
[07:11] <Kamion> sivang: uh, don't understand
[07:12] <Kamion> sivang: the way we support kickstart is going to be by translating it into preseed files
[07:12] <thom> seed updates are now done
[07:12] <sivang> Kamion: oh ok.
[07:12] <daniels> Kamion: btw, your -devel suggestion for l-r-m is totally sick
[07:12] <daniels> Kamion: it should totally parse Packages files instead :P
[07:12] <daniels> or subscribe to hoary-changes or something
[07:13] <lamont_r> lunch time
[07:13] <Kamion> daniels: ha :)
[07:13] <lamont_r> bbiab
[07:13] <daniels> actually
[07:13] <daniels> it could parse the pipermail output
[07:14] <daniels> not too difficult
[07:14] <bob2> daniels: dude. 5am.
[07:14] <ogra> Kamion: please not before 6.8 is in and fully functional ;)
[07:15] <daniels> bob2: yeah ...
[07:15] <daniels> ogra: it's already in, dude :)
[07:15] <ogra> daniels: working ? bugfree ? 
[07:15] <bob2> daniels: you'll be happy to know I missed krust and die.
[07:15] <daniels> ogra: i wouldn't say bug-free ...
[07:15] <daniels> bob2: WHAT
[07:15] <daniels> ogra: i know how to fix your imac bug, btw
[07:15] <daniels> bob2: how?!?
[07:16] <ogra> daniels: i already tried to give V/Hsync values....
[07:17] <daniels> ogra: if you did Option "HorizSync" "12-34", don't
[07:17] <daniels> you need HorizSync 12-34
[07:17] <daniels> and VertRefresh 12-34
[07:17] <daniels> but if that fails, i really have no idea
[07:18] <ogra> mako: "Point me to the bars full of ubuntu users!" -> should have a wiki page with preferred bars ;)
[07:18] <ogra> daniels: i'll have to reinstall hoary first..... i'll answer you during the night if it works :)
[07:19] <Kamion> ogra: I think you mean 6.8.2?
[07:19] <ogra> Kamion: the hoary version..... yep.... wasnt sure about the minor num.... :)
[07:20] <mako> ogra: well.if your in nyc, it's going to be the belgian beer bar tonight :)
[07:20] <mako> ogra: we should have at least half a dozen of them
[07:22] <ogra> mako: unfortunately i have to drive about 20km to the next bar here...... but if i'm in nyc i'll ask you before ;)
[07:25] <fabbione> lamont: did pitti fix that ftbfs?
[07:26] <thom> new sysvinit uploaded, i'm net.dead for the weekend in all probably
[07:26] <thom> ciao
[07:26] <fabbione> ciao thom
[07:26] <fabbione> have fun
[07:26] <thom> and you
[07:27] <fabbione> thanks mate
[07:27] <fabbione> i am going to work in the living room this time :-)
[07:27] <fabbione> sandpapering walls.. 
[07:27] <fabbione> sandpapering more walls..
[07:27] <fabbione> put up glue and glassfiber
[07:27] <fabbione> it's an endless job
[08:03] <elmo> is there anyway with ACPI to get a description of what a thermal zone actually relates to/
[08:03] <elmo> I've got one here that claims to be 8C, which seems, err, dubious, unless it's like a thermal monitor on the right side of a fan or something
[08:06] <mdz> Kamion: I have seen that bug where udev never seems to get going in d-i
[08:06] <mdz> Kamion: it's happened to me about 3 times, in qemu and on real hardware, during live cd testing
[08:06] <mdz> running udevstart clears it up
[08:08] <mdz> lamont: /etc/apt/sources.list ends up with lines beginning with "echo" in it
[08:08] <mdz> lamont: in your cloop image
[08:13] <smurfix> mdz: a few bits in universe still want libflac4. Are you going to fix these too, or should I?
[08:16] <mdz> smurfix: I don't plan to fix them, no, feel free
[09:02] <mdz> mjg59: around?
[09:04] <mjg59> Yup
[09:04] <lamont_r> mdz: changing the sources.list to match the default install, comments, etc.  (although uncommenting hoary.. - it'll want to include hoary-security once that exists...)
[09:05] <mdz> mjg59: what data ought we collect in order to have some chance at predicting whether suspend will work properly on a given laptop?
[09:06] <mjg59> Currently, there's no good way other than doing it on a machine by machine basis
[09:06] <mjg59> But DMI information ought to be enough
[09:08] <mdz> mjg59: so we're building a hardware database, and I'd like to know what we should be sure to have in it for the sake of the laptop team
[09:08] <mjg59> Ah, ok
[09:08] <mjg59> PCI output and dmi contents ought to be fine
[09:09] <lamont_r> mdz: wondering if the image build process should remove resolv.conf and hostname, etc, or not...
[09:09] <mdz> ok, PCI is a done deal, I'll be sure to have DMI in the spec
[09:09] <mdz> what about non-x86?
[09:10] <mjg59> The only non-x86 we can deal with is Apple hardware, and that's fairly well understood
[09:13] <elmo> ITANIUM LAPTOPS!
[09:14] <lamont_r> elmo: for those who never want to have children!
[09:17] <mxpxpod> has ffmpeg been approved by ubuntu since debian approved it?
[09:19] <cartman> mxpxpod: debian approved it?
[09:19] <lamont_r> mdz: alpha2 is what I'm looking for, yes?
[09:20] <mdz> lamont_r: yes, but it's a bit disappointing
[09:20] <lamont_r> I see.
[09:20] <mdz> lamont: it uses 2.6.9 to boot, so you get no modules
[09:20] <mdz> I didn't realize that until after we takled
[09:20] <mdz> talked
[09:20] <lamont_r> I could give you a 2.6.9 kernel on the image, too.
[09:20] <mdz> I'd rather just get a 2.6.10 initrd from Kamion
[09:20] <lamont_r> 'a
[09:21] <lamont_r> 'k, even
[09:21] <mdz> it looks like today's is already 2.6.10
[09:21] <mdz> but it doesn't have casper-check :-/
[09:21] <lamont_r> hrmpf.  /me wanted to download something now though. :-)
[09:21] <mxpxpod> cartman: that's what I heard on planet.debian.org... go there and search for ffmpeg
[09:21] <cartman> hmm
[09:21] <cartman> then mplayer can be accepted too
[09:23] <cartman> http://packages.qa.debian.org/f/ffmpeg.html
[09:23] <cartman> wow they even accepted cvs version
[09:24] <lamont_r> mdz: wonder if I can get away with stubbing out ps...
[09:24] <mxpxpod> cartman: also, gst-ffmpeg will get in as well
[09:25] <cartman> mxpxpod: no need for marillat then
[09:25] <lamont_r> mdz: cupsys has issues installing in a chroot on a machine where cupsys is running.  feh
[09:25] <cartman> cool
[09:26] <lamont_r> mdz: actually, changing cupsys to just use stop-start-daemon like a good boy would do the trick, eh?
[09:27] <mdz> lamont_r: yeah, and would make it policy-compliant to boot
[09:28] <lamont_r> this is in _POSTINST_.
[09:28] <lamont_r> sheesh
[09:30] <Keybuk> gah, I forgot to cast the correct magic runes to make nautilus build
[09:30] <amu> cloop_2.01.5-2ubuntu1_source.changes ACCEPTED
[09:36] <lamont_r> amu: no crossing fingers until at least ubuntu4
[09:36] <lamont_r> :-)
[09:37] <lamont_r> sheesh.  new gnome, xorg, and kernel.  mirror's gonna take a while
[09:41] <amu> lamont_r: about 200mb :) 
[09:41] <lamont_r> ouch
[09:42] <amu> lamont_r: already tested with your script and got the image 
[09:44] <amu> lamont_r: cloop_2.01.5-2ubuntu1_20050107-2038-i386-successful ... sometimes it realy help if you're crossing fingers ;) 
[09:44] <lamont_r> yeah
[09:45] <smurfix> sivang: exactly. Nothing new unfortunately.
[09:46] <amu> lamont_r: I try the script now on ppc 
[09:46] <sivang> smurfix: but I though the polish one just stopped such from happening no?
[09:47] <sivang> smurfix: polish vote
[09:49] <smurfix> "delayed" is more correct. The fight's not over yet. Besides, most of these refer to US patents.
[09:51] <sivang> smurfix: true, I've spotted acouple of a adobeies there :)
[09:52] <sivang> smurfix: now that's not a surprise..
[09:55] <smurfix> Hmm. "Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hoary/restricted/binary-i386/Packages.gz  MD5Sum mismatch". Does anybody else see this, or do I need to dropkick my squid?
[09:58] <lamont_r> I'd vote for dropkickking
[09:58] <lamont_r> bbiab
[10:24] <mdz> elmo: if there's anything you can do to kick flac_1.1.1-1 out of the archive prematurely, that'd be swell. the fewer people upgrade to it, the better
[10:25] <Kamion> mdz: hm? today's initrd should have casper-check ...
[10:26] <Kamion> mdz: c.f. network --bootproto=static --ip=10.0.2.15 --netmask=255.255.255.0 \
[10:26] <Kamion> d'oh
[10:26] <mdz> Kamion: daily-installer-i386/current/images/cdrom/initrd.list doesn't have it
[10:26] <Kamion> mdz: c.f. http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-i386/20041227ubuntu2/images/cdrom/initrd.list
[10:26] <Kamion> mdz: use installer-i386
[10:26] <mdz> oh
[10:26] <mdz> what is daily- then?
[10:26] <Kamion> I only uploaded the changes today, the subsequent daily run hasn't happened yet
[10:27] <mdz> ah
[10:27] <mdz> so sometimes daily is newer, and sometimes not
[10:27] <Kamion> mdz: installer-* = when somebody uploads the debian-installer source package; daily-installer-* = nightly based on the last debian-installer source package
[10:27] <Kamion> exactly; I have a convenient switch on cdimage which I can flip to make it use one or the other
[10:32] <mdz> Kamion: is there anything else you need in order to add live CDs to the daily CD build process?
[10:33] <Kamion> time? :-) no, I don't think so
[10:34] <Kamion> I'm having a look at what's needed now, may be Sunday before it works though
[10:36] <Kamion> the first cut will be crude and won't use the casper seed
[10:36] <Kamion> (because it turns out that the current install CD stuff doesn't actually use the installer seed to decide what udebs to include *ahem*)
[10:36] <Kamion> (at least, not directly)
[10:39] <mdz> crude would be great
[10:39] <mdz> a crude autobuilt daily CD is a huge step forward from my crude handbuilt CDs
[10:39] <Kamion> indeed :)
[10:40] <mdz> I expect lamont will have the filesystem images available for the big three architectures this evening
[10:52] <mdz> Kamion: is linux-kernel-restricted-di-2.6 still used?
[10:53] <elmo> uh
[10:53] <elmo> what in god's name happened to the seeds
[10:53] <elmo> mono?
[10:54] <mdz> elmo: what, just today?
[10:54] <Kamion> mdz: no
[10:54] <elmo> yeah, after thom's update
[10:55] <mdz> Kamion: can it be removed from the archive?
[10:55] <Kamion> mdz: for hoary, yes
[10:55] <Kamion> obviously still needed for warty
[10:55] <mdz> elmo: please remove  linux-kernel-restricted-di-2.6 from hoary
[10:55] <elmo> is it superseded by something or just obsolete?
[10:56] <mdz> it's superseded by linux-source
[10:56] <Kamion> no, it's superseded by linux-restricted-modules-*
[10:56] <mdz> or linux-restricted-modules
[10:57] <elmo> done
[10:58] <elmo> mdz: am I insane or was the verdict on mono that the stuff wasn't ready for supported?
[10:58] <mdz> elmo: the last verdict was that we would accept and deal with it given an application that we actually wanted (which needed mono)
[10:59] <Kamion> wow, overreaction from baz
[10:59] <mdz> elmo: if it's incredibly fucked or something, we can reconsider...is it actually buildable and installable and stuff?
[10:59] <Kamion> if you ask for a delta against a patch that doesn't exist, it says "corrupt archive"
[10:59] <elmo> mdz: I've no idea, I've not looked at it.. I guess I'm just having false memory syndrome
[11:00] <mvo_> mdz: what's your feeling about the synaptic-dpkg-progress bar stuff I send a mail about to ubuntu-devel some days go? is there a chance to get the needed (small) patches into apt and dpkg? 
[11:01] <elmo> mdz: the apps they've put in are tomboy and muine
[11:01] <elmo> anyway, fuck this for a laugh, I'm sending you the list so you can take some of the blame
[11:02] <elmo> mdz: people.ubuntu.com/~james/to_sync.txt
[11:05] <seb128> elmo: gstreamer0.8 0.8.8 sync please
[11:06] <elmo> seb128: do you get super screw-the-freeze powahs for gnome stuff?
[11:06] <seb128> not afaik, I need that ?
[11:07] <seb128> elmo: BTW are the package from experimental autosynced ? ie: we have pango 1.6.0-1 from exp, 1.6.0-2 is auto-updated or I need to ask a sync ?
[11:07] <elmo> oh, we're only in Upstream Version freeze, aren't we
[11:07] <seb128> that doesn't affect GNOME
[11:08] <elmo> seb128: nope, not auto-synced, my syncing isn't clever enough to keep track of where packages came from, unfortunately
[11:08] <elmo> seb128: ah, okay --> supah powahs
[11:08] <seb128> elmo: ok, so we need pango1.0 1.6.0-2 from exp :)
[11:08] <seb128> elmo: yeah, gimme the supah powaaaahs :)
[11:09] <seb128> elmo: the new versions are blocked by a technical way, or we just count on people to not upload a new version ?
[11:10] <elmo> seb128: we rely on the iron fist of mdz
[11:10] <seb128> ah ah
[11:10] <elmo> dude, he can walk up walls; I wouldn't mess with him
[11:10] <seb128> :)
[11:11] <seb128> bah, I don't care, I've a special GNOME card which is a joker :p
[11:11] <elmo> that's a harsh, yet fair way to describe jdub
[11:11] <elmo> you mean pango 1.8.0-2, btw, right?
[11:11] <seb128> oups, yes
[11:12] <elmo> ok, both syncs done
[11:12] <seb128> thanks
[11:17] <Keybuk> seb128: I guess you know that the panel's Places menu notify-me-it-changed-fu is pooched, ya?
[11:17] <Kamion> sheesh, the CDs were still booting with devfs=mount,dall
[11:17] <seb128> Keybuk: iz inotify bug
[11:17] <seb128> or gamin
[11:18] <seb128> Keybuk: #5176
[11:18] <Keybuk> *chuckle*  Jeff's "perfect solution" in "not actually finished yet" shocker
[11:20] <Keybuk> is there an easy/quick way to turn off inotify, that you know of?
[11:24] <mvo_> I'm going to bed now
[11:24] <mdz> Kamion: I wondered that as well
[11:24] <smurfix> Kamion: Looks like a "we have a problem we don't quite understand, and this fixes the symptom" hack.
[11:24] <sivang> mvo_: night
[11:24] <mvo_> night sivang, night all
[11:25] <Kamion> mdz: I've removed it, fairly certain it's bogus
[11:25] <Kamion> smurfix: I think it's actually "this was needed somewhere in the dawn of time and nobody remembered to remove it when things changed"
[11:26] <smurfix> Kamion: Yeah -- the boundaries between these two tend to be somewhat fluid, so we may well both be right.
[11:28] <Kamion> :-)
[11:30] <mako> whiprush: you around?
[11:31] <whiprush> yeah
[11:32] <Kamion> mdz,lamont: OK, I think I've got most of the bits together to build CDs now; all I need is the exact URL.
[11:32] <mako> whiprush: cool.. i've got #16 done. do you have time to read through it? fix errors/etc?
[11:33] <whiprush> sure, just getting home, gimme 10 to settle in.
[11:33] <mdz> Kamion: http://people.ubuntu.com/~lamont/mdz/livecd.cloop is the one that he gave me
[11:33] <Kamion> lamont: (as in, the tail of the URL, I know everything up to .../~buildd/)
[11:33] <mdz> that has 2.6.10 modules on it and seems to work with my test CD
[11:34] <Kamion> mdz: yeah, that's not the per-arch buildd thing I had earlier though
[11:34] <mako> whiprush: i'm gonna run off for an hour or so.. so i'll just let you have it :)
[11:34] <Kamion> though I s'pose I can kick off a test build with that
[11:34] <mako> whiprush: email me tonight and i'll just merge back in and post when i'm done :)
[11:34] <mako> whiprush: also, add something in the intro about how you're helping out now :)
[11:35] <whiprush> k
[11:35] <Kamion> also I've only done the bootloader bits for amd64 and i386 so far
[11:35] <mdz> Kamion: I hacked up a test CD with kernel module udebs from the archive + initrd/vmlinuz from your d-i upload + lamont's filesystem image, and it worked
[11:36] <mako> whiprush: cool.. the new traffic is in my baz archive on the mirror
[11:37] <Kamion> eek, it's confused the hell out of diff-tasks
[11:37] <mako> whiprush: send me an email or an irc msg when you think it's good to go. and thanks!
[11:37] <whiprush> k
[11:37] <mdz> what's diff-tasks?
[11:38] <mako> i have a debian+ubuntu party i need get ready for for (it's at my house!)
[11:38] <Kamion> mdz: the thing that runs each cdimage cron.daily to mail me about differences in base/desktop/ship/supported since the last cron.daily
[11:39] <Kamion> hm, jigdo not such a good idea on the live image :)
[11:39] <mdz> no...it would be sweet to make rsync work, though
[11:39] <mdz> I wonder how much work it would be to graft the gzip --rsyncable bits onto create_compressed_fs
[11:41] <seb128> Keybuk: oups, better to highlight me to be sure I read a reply :p Rebuilding gamin with --disable-inotify should do it I guess
[11:51] <mdz> Kamion: while you're there, it would be nice to have a much larger ramdisk
[11:52] <Kamion> where's that set?
[11:52] <crimsun> do we know about http://isec.pl/vulnerabilities/isec-0021-uselib.txt ? (I only did a rudimentary /lastlog -regexp "isec.pl", sorry if it's a repeat)
[11:53] <mdz> Kamion: ramdisk_size on the kernel command line usually
[11:53] <Kamion> mdz: doesn't that only govern the initrd?
[11:53] <mdz> when the live CD runs out of ramdisk, everything falls apart
[11:54] <mdz> Kamion: I'm pretty sure it sets the size of all /dev/ramN
[11:54] <mdz> the current one seems to be not much more than enough to get the system going
[11:55] <mdz> we'll bring that requirement down through tuning, but for now...
[11:55] <Kamion> crimsun: pitti's aware, yeah, should be fixed soon
[11:55] <crimsun> Kamion: all right, thanks.
[11:55] <Kamion> mdz: does setting it to $HUGE impose memory requirements?
[11:55] <mdz> Kamion: it shouldn't
[11:55] <Kamion> i.e. if you set it to 64MB will it break a 32MB system?
[11:55] <Kamion> ok
[11:55] <mdz> should be virtual memory
[11:55] <mdz> I certainly don't think it allocates 20M or whatever now
[11:56] <sivang> seb128: GNOME is exempt from UFV as I heared :)
[11:57] <seb128> sivang: yep, that would be a non-sense to freeze 2.9.3 ...
[11:58] <mdz> The RAM disk dynamically grows as more space is required. It does this by using
[11:58] <mdz> RAM from the buffer cache. The driver marks the buffers it is using as dirty
[11:58] <mdz> so that the VM subsystem does not try to reclaim them later.
[11:58] <sivang> seb128: yes, if we did, we would loose all the wonderful magic of network-admin :)
[11:58] <seb128> sivang: there is something new planned ?
[11:58] <sivang> seb128: garnacho has been working hard on applet integration 
[11:58] <seb128> cool
[11:58] <sivang> seb128: for monitoring the isdn connection and others..
[11:58] <Kamion> bleh, it included all the .debs too
[11:58] <Kamion> confused
[11:58] <mdz> that'll be a big image
[11:58] <Kamion> yeah :)
[11:59] <Kamion> >1GB
[11:59] <Kamion> oh, I know
[12:00] <gsuveg> re
[12:02] <mdz> jdub: ping?