| 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 | 12:10 |
| === johanbr [n=j@jupiter.physics.ubc.ca] has joined #ubuntu-kernel | ||
| zul | Keybuk: is it possible to remove xen-3.0.2+hg9697-1 from the archive? | 01:04 |
| === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel | ||
| Keybuk | zul: the particular version? | 02:45 |
| Keybuk | when a package is removed ... it can't come back | 02:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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 | 02:52 |
| lifeless | Keybuk: around ? | 03:03 |
| Keybuk | lifeless: yup | 03:10 |
| lifeless | can you eyeball this quickly - | 03:13 |
| lifeless | https://launchpad.net/products/launchpad/+bug/53698 | 03:13 |
| 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:14 |
| 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 | 03:15 |
| === 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 | ||
| zul | hi | 02:43 |
| === 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 | ||
| crimsun | Keybuk: RE: the mount-by-UUID conversion: Does it handle [read-only] NTFS mounts? | 09:59 |
| Keybuk | why wouldn't it? | 09:59 |
| crimsun | well, it appears to have correctly converted it, but I'm uncertain about the actual writing of the UUID | 10:00 |
| 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:01 |
| 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:02 |
| crimsun | so that incorrect UUID is from ``/sbin/vol_id -u /dev/sda1'' | 10:03 |
| Keybuk | Kamion: that's what NTFS uuids seem to look like | 10:07 |
| 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:08 |
| Keybuk | of course, the interesting thing is whether mount can support those uuids :) | 10:09 |
| 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:12 |
| === Keybuk looks at that patch | ||
| Keybuk | lamont: how much would you hurt me? | 10:13 |
| mjg59 | No jfs? | 10:13 |
| lamont | Keybuk: what is that adding? | 10:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| Kamion | so you might have to deal with the problem anyway :( | 10:27 |
| fabbione | Kamion: i am not sure.. | 10:27 |
| 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:28 |
| fabbione | we can always do it the old good way | 10:29 |
| 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:38 |
| 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:43 |
| fabbione | except the code in libblkid is a copy or almost of the one in util-linux :) | 10:53 |
| === jbailey [n=jbailey@209.217.74.66] has joined #ubuntu-kernel | ||
| lamont | fabbione: not my problem :-) | 11:36 |
| mjg59 | Keybuk: http://lkml.org/lkml/2006/7/25/280 ? | 11:42 |
| Keybuk | mjg59: interesting | 11:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!