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