lintian.debian.org update plan?
Hi :), Just a question, how's about update lintian.d.o plan? Now it complains 3.8.1 is newer policy or so... ;) -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lintian.debian.org update plan?
On Thu, 2009-04-09 at 15:10 +0900, Hideki Yamane wrote: Just a question, how's about update lintian.d.o plan? Now it complains 3.8.1 is newer policy or so... ;) There's an update run currently in progress. We were hoping it might have finished by now, but it isn't quite there yet. Hopefully it won't be too much longer - it's currently at package 36,842 of 38,093 (source and binary packages) and processing binary packages with names starting x. Regards, Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Thorsten Glaser wrote: Giacomo A. Catenazzi dixit: I think you misunderstand the mksh part of the problem. mksh has two modi: a legacy mode, in which it does not make any assumptions about charsets or encodings and is 8-bit clean and mostly 8-bit transparent, safe a few mostly past bugs and imple- mentation shortcomings, and a unicode mode, in which it assumes its input is UTF-8 (although, with ^V, you can still enter non- UTF-8 sequences, and tabcomplete filenames in legacy encodings as well). The unicode mode is enabled with mksh -U or set -U. However, mksh has a feature which automatically enables the uni- code mode if - the current CODESET is UTF-8 (or the locale ends in .utf8 or .UTF-8 or something similar, in some cases), or - the input begins with a UTF-8 BOM. This is good way to do things! The regression test suite merely checks for this feature. To do so, it needs a way to set the checked mksh process' CODESET to UTF-8, which is only possible by setting a non-C/POSIX locale. This means that we make few automatic regression tests ;-) But so, the UTF-8 requirement are a lot narrow than the rest of discussion. I think that we should provide some package that give pbuilder environment a UTF-8 environment. Or a debhelper (or like) utility that construct it for build needs. In this case us_EN.UTF-8 is a sensible locale (we want to test a real locale), but in this case I would also test some UTF-16 or Asian locale (mksh should not assume UTF-8 in these cases). You had already a solution (but embedding in a standard utility is IMHO better, which hide the complexity, and show direct what you need). BTW the locale could be also a pathname, so no root power needs (i.e. for other tests in user gleba). Andrew McMillan dixit: The proposal, at this stage is only that the C.UTF-8 locale is *installed* and *available* by default. Not that it *be* the default, but that it *be there* as a default. This is about what I was to propose, indeed. I agree that we must provide by default also a UTF-8, but I don't like C.UTF-8. A solution: force all locales to have also the UTF-8 brother, and force installation of such locale when user choose (at installation time) a non UTF-8 locale. C is not offered at installation time (but IIRC KDE offered at first run, some versions ago). For building env I prefer a us_EN.UTF-8 (we need English to read logs) or build when needed (better because probably we need other locales to test, and probably some packages needs some Asian locale for building/testing) Andrew McMillan dixit: Once this minimum step is made, and we've all calmed down, we can think further on radical and dramatic changes over coming years where more significant shifts are made, like: * The default locale at installation is C.UTF-8 rather than C. That would be nice. C is not the default locale. en_US.UTF-8 is the default (d-i of lenny, pressing only ENTERs). Andrew McMillan dixit: [...] and indeed Steve Langasek has already suggested a seemingly reasonable workaround for the immediate problem which was, funnily enough, that mksh wants to have a UTF-8 locale *available* in order for it to *test the build*... Yes, his suggestion and searching for someone to actually use it (Daniel Jacobowitz does) helped that part of the problem. However, the mksh regression test suite is only one of the manifestations. Even as a mere user, I'd like to have, see above, a UTF-8 locale available and, if possible, default. Well, maybe not a UTF-8 locale, just UTF-8 encoding (especially when I ssh from a MirBSD system to a Debian system, since on MirBSD there is *only* UTF-8¹), but glibc defines encodings exclusively via locales, which is why I'm in fa- vour of C.UTF-8 for myself, but setting LC_CTYPE only has the same effect (and I often set LC_MESSAGES to en_GB.UTF-8 for gcc's bene- fit). But your case is very specific (to building package). And in these case we want a minimal build environment. Additionally it is for testing purpose, so you test UTF-8, other package maybe needs other locales. Anyway I agree that a UTF-8 locale could be installed by default (also on pbuilder), but I we need also a locale utility for debian/rules, and that user has the right UTF-8 locale (so for a generic user, not C.UTF-8, but xz_YW.UTF-8, if is normally using xz_YW) ciao cate -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Giacomo A. Catenazzi dixit: This is good way to do things! Thanks. Or a debhelper (or like) utility that construct it for build needs. That’s already done, as I said – vorlon gave me an idea, I implemented it, it works, I uploaded a new mksh package… and then I saw someone’s added it to the D-D-R since I last looked into it… In this case us_EN.UTF-8 is a sensible locale (we want to test It’s “en_US.UTF-8” by the way. a real locale), but in this case I would also test some UTF-16 or Asian locale (mksh should not assume UTF-8 in these cases). It doesn’t. This test is already run for the C locale. Besides, there are no UTF-16 or somesuch locales on UNIX® or compatible systems. //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: does /var/games have to be deleted on purge? (if it's empty..)
Hi, On Montag, 6. April 2009, Russ Allbery wrote: I don't see much real benefit in going out of our way to remove /var/games and it looks like it would be a bit annoying (at the least, require adding purge code to all games that put files in /var/games that would usually never be triggered). My inclination would be to say that this behavior is fine and perhaps we should officially bless it somewhere. I've come to agree with this. :-) Now, where to bless it? regards, Holger signature.asc Description: This is a digitally signed message part.
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
Thorsten Glaser wrote: Giacomo A. Catenazzi dixit: a real locale), but in this case I would also test some UTF-16 or Asian locale (mksh should not assume UTF-8 in these cases). It doesn’t. This test is already run for the C locale. Besides, there are no UTF-16 or somesuch locales on UNIX® or compatible systems. Yes, right. ASCII-7 characters need to be encoded as a single char (octet), with values between 1 and 127, but not necessarily with ASCII values. With a quick look, it seems that all locales implement are ASCII compatible charsets, which is also very nice for filename portability (also between users and system). Recently there was a short discussion in POSIX about locales which code / in a non stanrdard place, thus creating a lot of problems (also security related), but this is an other story. ciao cate -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lintian.debian.org update plan?
Hi, On Thu, 09 Apr 2009 07:33:59 +0100 Adam D. Barratt a...@adam-barratt.org.uk wrote: There's an update run currently in progress. We were hoping it might have finished by now, but it isn't quite there yet. Hopefully it won't be too much longer - it's currently at package 36,842 of 38,093 (source and binary packages) and processing binary packages with names starting x. Great, and thanks for your reply, Adam :-) And question, is it so huge process? It means that the machine has enough resource? If not, I'll ask some guys to help it (if that is the thing I can do). -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523348: debian-policy: upgrading-checklist states policy 3.8.1.0 as unreleased
Package: debian-policy Version: 3.8.1.0 Severity: normal Hi, /usr/share/doc/debian-policy/upgrading-checklist.txt.gz still states policy 3.8.1.0 as unreleased, which is confusing to read while lintian already complains that 3.8.0 is outdated. Please correct. Regards, Philipp -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (700, 'experimental'), (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: pn doc-base none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#523348: debian-policy: upgrading-checklist states policy 3.8.1.0 as unreleased
Processing commands for cont...@bugs.debian.org: package debian-policy Ignoring bugs not assigned to: debian-policy forcemerge 519706 523348 Bug#519706: debian-policy: Checklist specified 3.8.1.0 unreleased Bug#523348: debian-policy: upgrading-checklist states policy 3.8.1.0 as unreleased Forcibly Merged 519706 523348. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523348: debian-policy: upgrading-checklist states policy 3.8.1.0 as unreleased
package debian-policy forcemerge 519706 523348 thanks Hi, Philipp Huebner wrote: /usr/share/doc/debian-policy/upgrading-checklist.txt.gz still states policy 3.8.1.0 as unreleased, which is confusing to read while lintian already complains that 3.8.0 is outdated. This has already been reported (as #519706) and will be fixed in the next Policy release. Regards, Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lintian.debian.org update plan?
Hideki Yamane henr...@debian.or.jp writes: On Thu, 09 Apr 2009 07:33:59 +0100 Adam D. Barratt a...@adam-barratt.org.uk wrote: There's an update run currently in progress. We were hoping it might have finished by now, but it isn't quite there yet. Hopefully it won't be too much longer - it's currently at package 36,842 of 38,093 (source and binary packages) and processing binary packages with names starting x. It's now done. Great, and thanks for your reply, Adam :-) And question, is it so huge process? It means that the machine has enough resource? If not, I'll ask some guys to help it (if that is the thing I can do). There are a couple of reasons why it takes so long. One of them is that Lintian somewhere has either a memory leak or is accumulating data across all packages that it shouldn't. As a result, the process grows to about 1GB of resident memory over the course of doing the whole archive run, which slows it down a lot due to overflowing caches and probably other bad effects. We've spent a fair bit of time looking for this memory leak and have plugged a few contributing causes, but much of it is still there. My current suspicion is that part of it is the version comparison cache (plus the slowness from forking dpkg --compare-versions). My intention in a release relatively soon is to replace that code with something that uses libapt-pkg-perl to do the version comparisons internally, which will eliminate the need for the cache. The other reason is that Lintian is extremely disk-I/O-intensive, and several new checks have been added recently that make it even more so (checks that require running strings on ELF binaries and file on all source package files, for instance). It's hard to do very much about this, since that disk I/O is part of finding problems. (strings on ELF binaries is used to find embedded copies of zlib, for instance.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lintian.debian.org update plan?
Hideki Yamane henr...@debian.or.jp writes: So, there are 2 points. one is lintian program itself, now you're trying to improve. And the other is its purpose and design, it needs powerful machine, right? Well, more faster storage. I'm not sure how fast gluck already is, though, and whether it's realistic to make it that much faster. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lintian.debian.org update plan?
On Thu, 09 Apr 2009 10:46:24 -0700 Russ Allbery r...@debian.org wrote: It's now done. Wow, now it says new warnings! :) Thanks for your effort! There are a couple of reasons why it takes so long. So, there are 2 points. one is lintian program itself, now you're trying to improve. And the other is its purpose and design, it needs powerful machine, right? -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lintian.debian.org update plan?
Hideki Yamane henr...@debian.or.jp writes: Russ Allbery r...@debian.org wrote: Well, more faster storage. I'm not sure how fast gluck already is, though, and whether it's realistic to make it that much faster. Or maybe lintian should be like buildd network. How's that? Well, incremental updates are not a problem -- it's only the archive-wide run that takes forever. If we could hand out pieces of it to multiple machines and then reassemble the results, that would definitely help complete the whole run more quickly. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lintian.debian.org update plan?
On Thu, 09 Apr 2009 13:48:57 -0700 Russ Allbery r...@debian.org wrote: So, there are 2 points. one is lintian program itself, now you're trying to improve. And the other is its purpose and design, it needs powerful machine, right? Well, more faster storage. I'm not sure how fast gluck already is, though, and whether it's realistic to make it that much faster. Or maybe lintian should be like buildd network. How's that? -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lintian.debian.org update plan?
On Thu, 09 Apr 2009 14:22:33 -0700 Russ Allbery r...@debian.org wrote: Well, incremental updates are not a problem -- it's only the archive-wide run that takes forever. If we could hand out pieces of it to multiple machines and then reassemble the results, that would definitely help complete the whole run more quickly. But it needs big changes for lintian, right? # well, maybe we propose it at NEXT Google Summer of Code program ;) -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: does /var/games have to be deleted on purge? (if it's empty..)
Holger Levsen hol...@layer-acht.org writes: Hi, while testing the archive with piuparts I found a failure reported by piuparts, that after purge /var/games existed on the system while it wasnt there before installing+purging the package. See http://piuparts.debian.org/squeeze/fail/slashem-common_0.0.7E7F3-1.3.log (at the end..) http://www.pathname.com/fhs/pub/fhs-2.3.html#VARGAMESVARIABLEGAMEDATA says that /var/games is an optional directory, which must be present if the corresponding subsystem (here: a game) is present. Thus I would conclude that it has to be removed on purge if there are no other games installed. Right? Or should I make piuparts ignore the /var/games directory if present after purge? regards, Holger http://piuparts.debian.org/squeeze/fail/armagetronad-dedicated_0.2.8.2.1-10.log is definitly buggy, as it not only leaves /var/games on the system but also /var/games/armagetronad :-) And I think there is your problem. If the package had removed all files then dpkg would have removed the dir automatically. MfG Goswin -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
