[05:49] <akio> hello
[03:18] <Keybuk> BenC: ping?
[04:25] <BenC> Keybuk: pong
[04:27] <fabbione> hey BenC 
[04:27] <BenC> hey
[04:28] <Keybuk> BenC: what would be the estimated timeline for getting http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d9aca22cf443f5ed77d15a320abbab055ae4a976 into our kernels?
[04:29] <fabbione> BenC: i will pretty soon need 2 things from you.... pull from gfs2-nmw tree and export the 3 symbols i need for gfs1.
[04:29] <fabbione> BenC: but i will give you a ping when it's time. I need 2 more fixes to hit gfs2-nmw
[04:29] <BenC> fabbione: why isn't gfs2-nmw in 2.6.22?
[04:30] <BenC> I really wanted to avoid pulling in other trees, especially when there's time to push things upstream still
[04:30] <fabbione> BenC: not all of it yet. but i need it before otherwise new userland doesn't build/work
[04:30] <BenC> Keybuk: Should be next upload, hopefully on or before Friday
[04:31] <fabbione> BenC: i understand, but there is a change on dlm headers and gfs2 headers that i need to propagated to build the new userland.. otherwise i am blocked.
[04:31] <fabbione> BenC: i still want these 2 extra fixes in before you pull
[04:31] <BenC> Keybuk: We need to talk about bug #115616
[04:31] <fabbione> BenC: also.. i saw kernel.u.c
[04:32] <BenC> fabbione: any assurance that those changes will be pushed upstream for 2.6.22 or are we stuck with the divergence in gutsy?
[04:32] <BenC> fabbione: you might have an account on kernel.u.c, try ssh to zinc.u.c
[04:32] <fabbione> BenC: they will be pushed upstream for sure.. when it's something i can't say right now, but i can ask
[04:32] <BenC> you can clone, and put whatever changes you want to push to me there
[04:32] <fabbione> BenC: i already have an account there
[04:32] <fabbione> how do i setup a tree that shows up in gitweb?
[04:33] <BenC> fabbione: are you in kernel_team group?
[04:33] <fabbione> i was planning to put gfs2/ocfs2 and gfs1 team
[04:33] <fabbione> i guess so... checking
[04:33] <BenC> if so, mkdir /srv/kernel.ubuntu.com/git/fabbione/
[04:33] <BenC> then clone a tree, mv newtree/.git /srv/kernel.ubuntu.com/git/fabbione/fabbione-gutsy.git
[04:33] <fabbione> yes i am
[04:34] <Keybuk> BenC: ok :)
[04:34] <BenC> fabbione: you might want to look at 115616 too, since it involves evms, and I could use some feedback
[04:35] <fabbione> BenC: i saw that bug. i will need to look at whatchanges
[04:35] <BenC> The basic issue is described here: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/115616/comments/3
[04:35] <fabbione> BenC: not sure i can get there by today
[04:35] <BenC> Mainly that I want to ditch the horrible bd_claim patch, but we need a way for users not to have broken systems that were based on the work around
[04:36] <Keybuk> BenC: ah, ok, it was a patch we dropped?
[04:36] <BenC> Keybuk: yeah, we've been carrying it around for a few releases, and it really is evil, and in actuality creates more room for breakage than it fixes
[04:37] <Keybuk> agree
[04:37] <Keybuk> the evms FAQ doesn't offer a better solution though
[04:37] <BenC> Actually, it does, which is to convert to evms totally, or ignore devices that evms isn't using
[04:37] <Mithrandir> fixing it is easy.  Move partition discovery out of the kernel and just use devmapper devices.
[04:37] <Mithrandir> fsvo easy, that is.
[04:38] <Keybuk> Mithrandir: actually, that doesn't help, since evms would still fight over the devmapper devices
[04:38] <Keybuk> claim applies to the devmapper ones too
[04:38] <BenC> it still tries to lock the physical block dev, which is the problem
[04:38] <fabbione> BenC: ok.. i have the tree cloned as you say... now?
[04:38] <Keybuk> evms for all => well, if you're using evms, you're doomed anyway
[04:39] <BenC> fabbione: "mv newtree/.git /srv/kernel.ubuntu.com/git/fabbione/fabbione-gutsy.git"
[04:39] <Keybuk> we actually have udev set to prefer to *not* use the evms-supplied devices right now
[04:39] <fabbione> BenC: done that
[04:39] <Keybuk> evms to exclude => it doesn't seem easy to do that either, since we don't know what to exclude or not?
[04:39] <BenC> fabbione: the main gitweb page is hourly generated...let me run the script
[04:40] <fabbione> BenC: ok
[04:40] <BenC> fabbione: shows up now
[04:40] <fabbione> oh neay
[04:40] <fabbione> neat
[04:40] <Mithrandir> Keybuk: make it not lock the whole device unless it contains an evms volume, and if so, see if it can just claim a partition?
[04:40] <fabbione> how do i setup the repo description?
[04:40] <BenC> fabbione: vi ubuntu-gutsy-gfs2.git/description
[04:40] <Keybuk> Mithrandir: do you know how to do that?
[04:41] <Mithrandir> Keybuk: a) get drunk, b) dive into the evms source code.
[04:41] <Mithrandir> it's a big and scary chunk of code.
[04:41] <Mithrandir> talking to upstream might be a good start, though
[04:41] <Keybuk> given that upstream haven't felt inclined to fix it yet, I doubt they'll be responsive
[04:42] <BenC> yeah, their FAQ is sort of "eh, deal with it"
[04:42] <Mithrandir> depends.. I've found them very good in the past when I've managed to catch their attention.
[04:42] <fabbione> BenC: ok.. all done.. can you regenerate the page?
[04:42] <fabbione> BenC: coolness it works
[04:43] <BenC> fabbione: weez cookin' now
[04:47] <Keybuk> I think we have two choices:
[04:47] <Keybuk> - apply the bd-claim patch
[04:47] <Keybuk> - stop supporting evms
[04:54] <BenC> Keybuk: what's the fallout from option 2?
[04:55] <Keybuk> upsetting some users
[05:03] <BenC> is there any way we can make option 2 work without asking users to hack a config file?
[05:07] <fabbione> BenC: let see if the git-send-pack works :)
[05:07] <fabbione> yeps
[05:07] <fabbione> gfs1 tree updated...
[05:09] <fabbione> BenC: the gfs2 author is in vacation this week. there are a set of patches in there that will be pushed to Linus (like the 2 i am waiting for), others will make .23 for sure
[05:10] <fabbione> BenC: if you really really feel unconfortable with that, i can start diverging userland, but it's just shifting one problem from one place to another
[05:10] <fabbione> BenC: also note that gfs2 tree touches "only" dlm and gfs2.. meaning none of the core kernel functionalities
[05:11] <fabbione> and not stuff people will use regularly
[05:11] <BenC> fabbione: that's good
[05:11] <fabbione> anyway. i will let you take a breath on it and ping you once the other fixes are in
[05:23] <Keybuk> BenC: how do you mean?
[05:24] <BenC> Keybuk: I mean our work arounds include: 1) uninstall evms, 2) edit evms.conf to ignore the disks, 3) switch to evms completely
[05:25] <BenC> none of which seem easy to do with update-manager or something
[05:25] <Keybuk> the problem with 2) is that it's not obvious to me why evms doesn't just do that by default
[05:26] <Keybuk> (ignore volumes without evms metadata)
[05:26] <BenC> yeah, that does seem pretty broken
[05:26] <BenC> the people having the problem so far are not even using evms at all
[05:26] <BenC> it's just being stupid
[05:26] <Keybuk> yeah
[05:26] <Keybuk> we installed it by default once
[05:26] <Keybuk> yay us
[05:26] <BenC> which release was that, dapper?
[05:32] <Keybuk> warty
[05:32] <Keybuk> +/**
[05:32] <Keybuk> + * activate_on_kernel_partition
[05:32] <Keybuk> + * The normal activation failed. If we're running on a 2.6 kernel, this could
[05:32] <Keybuk> + * be due to bd_claim, meaning the user may have a kernel partition mounted on
[05:32] <Keybuk> + * the same disk that we're trying to activate on. In this case, lets try to
[05:32] <Keybuk> + * activate the segment on top of the kernel partition instead of the disk.
[05:32] <Keybuk> + * The only things that change are the minor number for the target device and
[05:32] <Keybuk> + * the starting offset.
[05:32] <Keybuk> + *
[05:32] <Keybuk> + * If this succeeds, we must indicate that this segment is active on top of a
[05:32] <Keybuk> + * kernel partition, since it means certain other functionality cannot be used.
[05:32] <Keybuk> + **/
[05:33] <BenC> sounds like it's supposed to work around things
[05:34] <Keybuk> yeah, trying to work out exactly how
[07:21] <bdmurray> what is the ti multimedia card reader bug number?
[07:23] <rtg> bdmurray: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/53923
[07:25] <bdmurray> rtg: thanks
[07:56] <johanbr> I've never been bitten by the above bug, but I noticed SD cards no longer automount with the Gutsy kernel. They work fine after manually mounting, though.
[08:38] <bdmurray> rtg: is dmidecode helpful with bugs like 116185?
[08:41] <BenC> bdmurray: /proc/acpi/dsdt is more helpful, but in reality, most bugs like that are BIOS bugs
[08:41] <BenC> dsdt will help find out
[08:43] <bdmurray> BenC: okay, thanks