[12:23] <BenC> mdz: Wont be back till Saturday, but I'm available
[12:39] <zul> hey
[12:43] <mdz> BenC: ok, I'll talk to you then
[12:44] <mdz> or monday rather
[12:44] <zul> hey mdz
[12:44] <mdz> zul: good day
[01:13] <fabbione> Keybuk: do you happen to know if udev in edgy is broken? It seems i have lost some devices with one of the last updates...
[01:14] <Keybuk> it's not broken
[01:14] <Keybuk> the kernel might be, of course
[01:14] <Keybuk> but there's no reason why udev would be dropping kernel events
[01:14] <fabbione> hmm weird
[01:15] <fabbione> yeah i see no reason except it started happening all of a sudden
[01:15] <Keybuk> *shrug*
[01:15] <Keybuk> udev is almost never to blame
[01:16] <zul> heh..
[01:20] <makx> Keybuk i've a questions for dapper initramfs-tools
[01:20] <Keybuk> makx: dapper?
[01:20] <makx> yes i'm facing same sort of upgrade somehow
[01:21] <Keybuk> hmm?
[01:21] <makx> Keybuk: mkinitramfs is adding vgchange and mdrun, but i see no boot script
[01:21] <Keybuk> it's in mdadm or lvm2 ?
[01:21] <makx> (conditional addition)
[01:22] <Keybuk> you'll have to be more verbose
[01:22] <makx> well mkinitramfs add mdrun if there is no md hook around from mdadm, but mdrun and mdadm is installed
[01:23] <makx> but i see no boot script calling this mdrun
[01:23] <makx> some story for vgchange
[01:23] <Keybuk> BE MORE VERBOSE :)
[01:23] <Keybuk> /usr/share/initramfs-tools/hooks/lvm
[01:23] <Keybuk> /usr/share/initramfs-tools/scripts/local-top/lvm
[01:23] <Keybuk> /usr/share/initramfs-tools/hooks/evms
[01:23] <Keybuk> /usr/share/initramfs-tools/scripts/local-top/evms
[01:23] <Keybuk> *shrug*
[01:23] <Keybuk> it's all there
[01:24] <makx> # FIXME: Remove this LVM block after Dapper releases
[01:24] <makx> if [ -x /sbin/vgchange -a -d /lib/lvm-200 -a ! -f /usr/share/initramfs-tools/hoo
[01:24] <makx> ks/lvm ] ; then
[01:24] <makx> copy_exec /lib/lvm-200/vgchange /sbin
[01:24] <makx> and so on..
[01:24] <makx> but i don't see the usage inside of 0.40ubuntu32
[01:24] <Keybuk> why would it be in initramfs-tools ?
[01:25] <Keybuk> it's in our lvm packages
[01:25] <makx> also the breezy lvm had no hooks yet
[01:25] <Keybuk> I don't understand what you're going on about
[01:25] <Keybuk> could you please be more verbose
[01:25] <makx> i think it was done for partial upgrades
[01:25] <makx>   * Conditionalise the use of lvm and md in mkinitramfs so it's a no-op if
[01:25] <makx>     you don't have those packages installed, but allows for smooth upgrades
[01:25] <makx>     if you have older versions that don't ship their own hooks yet.
[01:25] <Keybuk> *shrug* no idea
[01:25] <Keybuk> ask whoever did that change
[01:26] <makx> the strange thing is that it is not accompagnied by an lvm or md script in scripts/local-top
[01:26] <Keybuk> no, it wouldn't be
[01:26] <Keybuk> the lvm and md script are in lvm2 and mdadm
[01:27] <Keybuk> it's likely that code was supposed to be removed from mkinitramfs and never was
[01:27] <makx> no it was added shortly before dapper release
[01:27] <makx> so it was on purpose
[01:27] <Keybuk> then it's likely to be a bug fix for something
[01:27] <Keybuk> no idea what
[01:27] <Keybuk> dependency ordering, maybe?
[01:27] <makx> yes partial upgrade where you still have old lvm2 from breezy around
[01:28] <Keybuk> right
[01:28] <Keybuk> there you go then
[01:28] <makx> still i miss the boot scripts of that idea, so it was only half done
[01:28] <Keybuk> no
[01:28] <Keybuk> the boot scripts are in lvm2
[01:28] <Keybuk> I keep saying this
[01:28] <Keybuk> but you keep ignoring me
[01:28] <Keybuk> quest scott% dpkg -L lvm-common | grep initramfs
[01:28] <Keybuk> /usr/share/initramfs-tools
[01:28] <Keybuk> /usr/share/initramfs-tools/scripts
[01:28] <Keybuk> /usr/share/initramfs-tools/scripts/local-top
[01:28] <Keybuk> /usr/share/initramfs-tools/scripts/local-top/lvm
[01:28] <Keybuk> /usr/share/initramfs-tools/hooks
[01:28] <Keybuk> /usr/share/initramfs-tools/hooks/lvm
[01:29] <makx> no i don't ignore you but lvm2 versioned dep is pulled in by?
[01:29] <Keybuk> ubuntu-desktop
[01:29] <makx> i see
[01:29] <Keybuk> or probably ubuntu-standard or something
[01:29] <makx> ok that explains why you didn't to care about the boot scripts
[01:30] <Keybuk> in edgy, we don't install either lvm2 or mdadm by default
[01:30] <makx> have no such dep on the Debian side
[01:30] <Keybuk> and we made an effort in dapper to remove all the specific stuff out of initramfs-tools
[01:30] <Keybuk> so it's just a "kit for making initramfses"
[01:30] <makx> Keybuk: sure but you upgrade from a package that has already initramfs hooks
[01:31] <makx> much easier, thanks Keybuk
[02:04] <rodarvus> infinity, ping
[02:08] <infinity> rodarvus: pong
[02:09] <rodarvus> infinity, I'd like to blacklist build of a bunch of X.Org packages on some architectures - sometime ago I was informed I should talk to you to do this :)
[02:10] <rodarvus> (sorry for asking in #ubuntu-kernel, btw - I didn't noticed before actually asking here)
[02:11] <infinity> rodarvus: We don't actually have that capacity correctly in place right now.  I have an outstanding soyuz bug about it.
[02:11] <rodarvus> oh, no problem, then
[02:11] <infinity> rodarvus: Is it too much trouble to set the arch: line in the source? (I assume this is for the suncg drivers and such)
[02:11] <rodarvus> it is set
[02:12] <infinity> Right, so no big deal.  They'll fail, which is what we want.
[02:12] <infinity> It wastes a few buildd cycles to get there, but not the end of the world.
[02:12] <rodarvus> the "bug" is only cosmetic, actually - packages are showing as "build failed" on Soyuz, even with Arch: set on debian/control
[02:12] <infinity> Yeah, no big deal.  Some day, soyuz will be fixed to do P-a-s stuff properly, like Debian, and you won't have to see that.
[02:13] <rodarvus> *nods*
[02:13] <rodarvus> infinity, thanks!
[02:18] <mdz> one day, we'll make the Architecture line in the .dsc work correctly
[02:19] <infinity> mdz: Well, it does, but that only works well for inclusive arch lines, not exclusive.
[02:20] <infinity> So, in the case of a sparc-only driver (like this), Arch: sparc is fine.  In the case of sometihng that you DON'T want built on a single arch (or a few), it gets... Ugly.
[02:20] <mdz> exactly
[02:20] <rodarvus> infinity, apparently its failing for inclusive arch lines too
[02:20] <infinity> And changing those sorts of semantics across the board in dpkg, sbuild, etc, etc gets... Interesting.
[02:20] <rodarvus> (see latest build of xserver-xorg-video-i810)
[02:21] <mdz> it should contain enough information for the buildds to determine whether they need to bother
[02:21] <infinity> rodarvus: No, it works fine.  sbuild bombs out when it sees it.
[02:21] <infinity> rodarvus: soyuz isn't looking at it, but the buildds do.
[02:21] <rodarvus> infinity, oh, right - sorry
[02:21] <rodarvus> I thought you were mentioning soyuz
[02:22] <infinity> No, not especially.  The soyuz problem is purely cosmetic, really.  Having the buildds DTRT is what really matters.
[02:22] <infinity> Catching it in soyuz first saves a bit of time, but it's not really a big deal.
[03:25] <thom> uh, is http://www.kernel.org/git not actually showing any projects for anyone else?
[03:26] <zul> thom: no problems here
[03:26] <rodarvus> no problems here either
[03:28] <thom> great, thanks. 
[05:55] <freeflying|away> use edgy-alternate-amd64(today's iso), it can not install on an AMD64 Turion 64x2's notebook, after boot kernel, it hangs, and give a message like this " kernel dicrect mapping tables up to 10000000 @ 8000-8000" at the bottom of the screen
[05:56] <freeflying|away> I've tried with noapic and nolapic 
[08:01] <zul> well that was unpleasant
[09:36] <crimsun> Fjodor: are you referring to a specific source file or the config{,s} themselves?
[09:38] <Fjodor> crimsun: I assume that /usr/src/linux-source-2.6.17/include/linux/config.h (or autoconf.h, as it is) is generated on kernel build. There, I find a #undef CONFIG_D80211 (not unset, sorry)
[09:39] <Fjodor> crimsun: This prevents building of rt2x00 cvs sources
[09:39] <Fjodor> crimsun: as their rt2x00_compat.h #include <linux/config.h>
[09:40] <crimsun> Fjodor: but CONFIG_D80211=m appears in all the i386-class configs.
[09:40] <crimsun> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=blob;h=0da4742d94127974c29d20325fd47e6933e40da8;hb=b6e0a65ea85c03dc1512b4b13d1f24bc837a6481;f=debian/config/i386/config
[09:41] <crimsun> what do the cvs snaps offer in addition?
[09:42] <Fjodor> crimsun: cvs sources has their own config file, where it must be set to y
[09:43] <crimsun> and other distros' kernel headers have it set?
[09:43] <Fjodor> crimsun: Wouldn't know. I'm not sure other kernel trees have it at all
[09:44] <Fjodor> crimsun: It is hardly stable now, and thus even less so at the time the sources where put in the kernel
[09:52] <Fjodor> crimsun: All in all, any config for rt2x00 and dscape 80211 in the kernel autoconf.h will override values from rt2x00 cvs config. I am in the process of reporting this to their fora, but a specific #undef seems unnecessary, and is atm. counterproductive
[09:52] <crimsun> Fjodor: I can't speak for a policy decision, sorry
[09:53] <Fjodor> crimsun: inasmuch as the #undef is the result of completely unselecting rt2x00 from the kernel with cvs build in mind
[09:53] <Fjodor> crimsun: Ok. You said BenC?
[09:55] <crimsun> yes.
[09:55] <crimsun> (he's off at a tourney atm)
[09:58] <Fjodor> crimsun: Ok. I'll get back sometime then
[10:00] <Fjodor> crimsun: For now, though, I'm off to bed. Thanks so far
[11:26] <wesj> hi