[12:10] <crimsun> ah, that would explain why this firmware is loaded in Dapper whereas I have to wait a tick before hotplugging the sound device in Edgy
[12:10] <crimsun> I'll just have to fix the loader then
[01:04] <zul> Keybuk: is it possible to remove xen-3.0.2+hg9697-1 from the archive?
[02:45] <Keybuk> zul: the particular version?
[02:46] <Keybuk> when a package is removed ... it can't come back
[02:47] <zul> Keybuk: yes that version, i have a new one to be uploaded that works for edgy
[02:47] <Keybuk> just upload the new version then
[02:48] <Keybuk> it'll supersede the old one
[02:48] <zul> im keeping getting rejects sayint that new version is older than the one in the archive
[02:49] <Keybuk> right, what version are you uploading?
[02:49] <zul> gimme a sec
[02:49] <Keybuk> I only see xen 2.0.6-1 in the archive
[02:49] <zul> trxen-3.0_3.0.2+20060724_source.upload
[02:50] <zul> sorry...
[02:50] <zul> xen-3.0_3.0.2+20060724_source.upload
[02:50] <Keybuk> right
[02:50] <Keybuk> that version is older than the one in the archive
[02:50] <zul> hmm...ok
[02:50] <Keybuk> 3.0.2+20060724 < 3.0.2+hg9697-1
[02:50] <Keybuk> because "+" < "+hg"
[02:51] <Keybuk> why the change in version number?  why not use the +hgNNNN format again?
[02:51] <zul> ah ok...so should it be 3.0.2-20060724?
[02:51] <Keybuk> no
[02:51] <Keybuk> it should be 3.0.2+hg(number bigger than 9697)-1
[02:52] <zul> so 3.0.2+hg11127-1
[02:52] <Keybuk> right
[02:52] <zul> ok ill do that
[02:52] <zul> thanks
[02:52] <Keybuk> 11127 > 9697 ... so you win
[02:52] <Keybuk> unless you have a very good reason, stick to the version numbering in the archive
[02:52] <Keybuk> even if you disagree with it
[02:52] <zul> ok
[03:03] <lifeless> Keybuk: around ?
[03:10] <Keybuk> lifeless: yup
[03:13] <lifeless> can you eyeball this quickly -
[03:13] <lifeless> https://launchpad.net/products/launchpad/+bug/53698
[03:14] <lifeless> its a discussion about a change to dyson, it tried to register a cvs snapshot of grass
[03:14] <lifeless> which failed the upstream version number format check. But more interestingly, cvs snapshots are not that interesting, so we're considering how to get it to not register that
[03:15] <Keybuk> lifeless: it's more of a single e-mail than a discussion
[03:15] <lifeless> I'd just like your thoughts on it
[03:15] <Keybuk> don't really have any
[03:15] <lifeless> ok, fair enough.
[03:15] <Keybuk> I agree that it doesn't make sense to import cvs snapshots
[02:43] <zul> hi
[09:59] <crimsun> Keybuk: RE: the mount-by-UUID conversion: Does it handle [read-only]  NTFS mounts?
[09:59] <Keybuk> why wouldn't it?
[10:00] <crimsun> well, it appears to have correctly converted it, but I'm uncertain about the actual writing of the UUID
[10:01] <crimsun> for reference:
[10:01] <crimsun> # /dev/sda1 -- converted during upgrade to edgy
[10:01] <crimsun> UUID=58E475CEE475AEBE /media/sda1 ntfs umask=022,nls=utf8,users 0 0
[10:01] <crimsun> but /media/sda1 is empty after a reboot
[10:02] <Kamion> doesn't look like a proper UUID
[10:02] <crimsun> hmm, true, the others are of the form '11f6ccb2-f5bd-4d3b-87cc-c6fe260023fd'
[10:03] <crimsun> so that incorrect UUID is from ``/sbin/vol_id -u /dev/sda1''
[10:07] <Keybuk> Kamion: that's what NTFS uuids seem to look like
[10:08] <Keybuk> quest scott% ls /dev/disk/by-uuid
[10:08] <Keybuk> 2b4dde85-714c-42fa-b43f-02af9c64dc4b@  7d074f9a-80e7-4f0c-89aa-8efa8366766a@
[10:08] <Keybuk> 43DB-3ADE@                             C84C0C3A4C0C25B2@
[10:08] <Keybuk> of course, vol_id could be on the cock, but it shouldn't matter given things just convert to /dev/disk/by-uuid anyway
[10:08] <Keybuk> crimsun: does "mount" claim it's mounted?
[10:08] <crimsun> Keybuk: no
[10:09] <Keybuk> of course, the interesting thing is whether mount can support those uuids :)
[10:12] <Keybuk>  * For now, only ext2, ext3, xfs, ocfs, ocfs2, reiserfs, swap are supported
[10:12] <Keybuk> "no"
[10:12] <crimsun> right, "no such partition found"
[10:12] <Keybuk> http://lists.opensuse.org/archive/opensuse-commit/2006-Jun/0412.html
[10:13] <Keybuk> lamont: how much would you hurt me?
[10:13] <mjg59> No jfs?
[10:13] <lamont> Keybuk: what is that adding?
[10:14] <Keybuk> lamont: it replaces mount's current "find the uuid" code with calls to libvolume_id
[10:14] <Keybuk> (well it's got the code to do that in it, anyway)
[10:15] <lamont> if the patch is reasonably clean, and libvolume_id is reasonable sane (rather than full of festering security vuls), I'd be happy to include it in debian, too.  Then again, I need to corner you sometime and figure out what the right answer is for my debian-issue that you were able to just smash through when you last branched util-linux for dapper....
[10:15] <lamont> of course, assuming that it works with the existing stuff as well, rather than forcing user changes.... :-)
[10:15] <Keybuk> what's the debian issue?
[10:15] <lamont> hwclock.sh
[10:16] <Keybuk> oh, which one?
[10:16] <Keybuk> hwclock.sh is a zillion issues all to itself
[10:16] <lamont> we need to set the clock before we load the modules so that we can mount /usr so that we can get the TZ to set the clock.
[10:16] <Keybuk> that's not entirely true
[10:16] <Keybuk> you need to set the clock before you run depmod
[10:17] <Keybuk> not "load the modules"
[10:17] <lamont> right
[10:17] <lamont> and actually, modules startup doesn't run depmod anymore
[10:17] <lamont> (the bug in question is the front of the #debian-devel topic...)
[10:17] <lamont> 342887\
[10:18] <Keybuk> yeah. it's amazing how Debian stop arguing once Ubuntu has gone ahead and changed it anyway
[10:18] <lamont> yep
[10:18] <Keybuk> so hwclock.sh is an annoying case:
[10:18] <Keybuk> it DOES need to run before dhclient
[10:18] <lamont> it helped that someone else was doing bootchart type stuff and discoverd that depmod takes _FOREVER_
[10:18] <Keybuk> yet needs /dev/rtc, which udev creates
[10:19] <Keybuk> heh, we noticed that 6 months ago!
[10:19] <lamont> yep
[10:19] <lamont> I think debian noticed that it took much longer to boot debian than ubuntu....
[10:19] <Keybuk> it takes less time to boot a clean debian than ubuntu
[10:19] <Keybuk> because they support less crazy fabbione shit
[10:19] <Keybuk> (yay, edgy's dropped it all)
[10:19] <lamont> yeah fabbione! :-0)
[10:21] <lamont> the simple solution to the /dev/rtc thing is to quit compiling it as a module... if the hardware is there, you want it.
[10:22] <Keybuk> yes
[10:22] <fabbione> Keybuk: we can do that too.. install lvm and raid stuff only on demand.. we just never did it :)
[10:22] <lamont> fabbione: fix that. kthxbye
[10:22] <lamont> (CONFIG_RTC that is)
[10:22] <fabbione> lamont: what arch?
[10:22] <lamont> arch: any
[10:23] <fabbione> how do you want it? M or Y or just fix the driver?
[10:23] <fabbione> the latter i accept patches :)
[10:23] <lamont> it's an architecture independant fact that I need the RTC available before we do stuff.
[10:23] <lamont> =Y
[10:23] <lamont> it's very tiny, you see....
[10:23] <fabbione> lamont: ok i will talk to Ben and Kamion
[10:23] <fabbione> yup
[10:24] <fabbione> but CONFIG_RTC is not available on all arches as it is iirc
[10:24] <lamont> oh, well, just on the architectures where there is something that (uniquely) provides /dev/rtc
[10:25] <fabbione> i will look at it
[10:25] <lamont> better yet - just change Kconfig to force it on when it can. :-)
[10:25] <fabbione> ehehe
[10:25] <lamont> oh, that'll probably be an ABI bump, of course...
[10:25] <fabbione> no big deal on edgy
[10:26] <lamont> of course, I want it in etch
[10:26] <lamont> and edgy. :-)
[10:26] <fabbione> etch i can't do nothing.. file  a bug on those kernel guys
[10:26] <fabbione> but there will be people objecting to it for another 398398439 reasons
[10:26] <Kamion> there are some arches where there are multiple possible providers of /dev/rtc, aren't there?
[10:27] <Kamion> so you might have to deal with the problem anyway :(
[10:27] <fabbione> Kamion: i am not sure..
[10:28] <Kamion> hmm, there's a whole drivers/rtc/ tree now with rtc-dev.ko and stuff, so maybe that's been fixed
[10:28] <fabbione> i think Al Viro was working on a generic rtc implementation across all arches
[10:28] <fabbione> or there was at least
[10:28] <fabbione> no idea if it's fixed in .17
[10:29] <fabbione> we can always do it the old good way
[10:38] <lamont> Keybuk: if the volume_id patch looks sane, pls file a bug against the debian util-linux package with a pointer, and I'll merge it in
[10:43] <Keybuk> lamont: hmm, looking through the code, mount is using libblkid
[10:43] <lamont> yes
[10:43] <lamont> and before that, it used it's own random guessing techniques
[10:53] <fabbione> except the code in libblkid is a copy or almost of the one in util-linux :)
[11:36] <lamont> fabbione: not my problem :-)
[11:42] <mjg59> Keybuk: http://lkml.org/lkml/2006/7/25/280 ?
[11:49] <Keybuk> mjg59: interesting