Russ Allbery wrote: > I'm in the same spot. I'll get to it at some point, but I don't think it > needs to hold up the upload.
Ok > Raphael Geissert writes: >> * switch to use i18n/SUPPORTED instead of local copy of locale codes >> built from ISO 639-1..3 -- probably for a future release since it >> requires some work on the eglibc side. > > Agreed. Just to make it clear: we would need to ship a copy of i18n/SUPPORTED since it may vary. > I think we're good for an upload if you want to make one, or I can try to > get to one (but probably not today). I probably won't have time to make one before Friday (school projects...) so if you have time please go ahead. I ran the testsuite and it passed[1]. [1] As a matter of fact, the huge-usr-share test fails on my machine for some time now. I haven't been able to determine what's causing this behaviour. I briefly talked about it with Adam once but he was unable to reproduce the failure. See: -I: huge-usr-share-percent: arch-dep-package-has-big-usr-share 2076kB 99% +I: huge-usr-share-percent: arch-dep-package-has-big-usr-share 2064kB 100% But: $ debc debian/tests/*changes | grep \\./usr/share drwxr-xr-x root/root 0 2010-04-14 16:26 ./usr/share/ drwxr-xr-x root/root 0 2010-04-14 16:26 ./usr/share/doc/ drwxr-xr-x root/root 0 2010-04-14 16:26 ./usr/share/doc/huge-usr- share-percent/ -rw-r--r-- root/root 1017 2010-02-19 23:00 ./usr/share/doc/huge-usr- share-percent/copyright -rw-r--r-- root/root 215 2010-04-14 16:26 ./usr/share/doc/huge-usr- share-percent/changelog.gz drwxr-xr-x root/root 0 2010-04-14 16:26 ./usr/share/a/ -rw-r--r-- root/root 2097152 2010-04-14 16:26 ./usr/share/a/zero 2097152 + 2017 + 215 = 2098384 bytes checks/huge-usr-share uses -k which means block-size=1K, then we have 2098kB So: a) size of usr/share is reported as 2064kB but tar says they are 2098kB. b) Modifying the check to use --apparent-size[2] (which, correct me if I'm wrong, is what we should be using) reports it as 2050kB -- still not matching the size reported by tar. c) I believe the result I'm getting even though it doesn't match the size reported by tar, is "more correct." Reason being that it reports a 100% of the consumed space being under usr/share, which is true (there's no single file or directory outside /usr/share in the test case.) What do you think? I'm using an i686, FWIW. [2] "print apparent sizes, rather than disk usage; although the apparent size is usually smaller, it may be larger due to holes in (`sparse') files, internal fragmentation, indirect blocks, and the like." -- du(1) Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
