Roger Leigh wrote:
I wasn't aware that this level of checking was performed, though
it does make sense. But, does it not reject non 7-bit input in the C
locale for completeness?
Should tools doing raw I/O not be using lower level interfaces
such as fread() and fwrite() rather than the
Andrew McMillan wrote:
On Tue, 2009-04-07 at 22:32 +0200, Adeodato Simó wrote:
It is my impression that more packages than mksh could use an UTF-8
locale at build time (I’m afraid I don’t have pointers, but I’m sure
I’ve come across at least a couple).
Wouldn’t it be just better to change
On Tue, Apr 07, 2009 at 10:47:00PM +, Thorsten Glaser wrote:
Roger Leigh dixit:
Are you sure?
Not entirely, but I recall fgetc (or was it fgetwc?)
being affected.
Ah, fgetc/fputc are specified in the standard as byte oriented
rather than character-oriented, so are probably
Roger Leigh wrote:
On Tue, Apr 07, 2009 at 09:24:38PM +0200, Adeodato Simó wrote:
+ Thorsten Glaser (Tue, 07 Apr 2009 18:54:59 +):
Except the ton which sets LC_ALL=C to get sane (parsable,
dependable, historically compatible) output.
These would then unset all other LC_* and LANG and
On Wed, 2009-04-08 at 02:30 +0200, Holger Levsen wrote:
Or is RC too much? Or fine now?
Anything normal would be too much IMO.
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Roger Leigh wrote:
On Tue, Apr 07, 2009 at 10:36:20AM +0200, Giacomo A. Catenazzi wrote:
Roger Leigh wrote:
I can't help but feel that your reply completely missed the
purpose of what I want to do, and why. I hope the following
response clears things up.
I know that I missed the original
On Wed, Apr 08, 2009 at 02:30:23AM +0200, Holger Levsen wrote:
Hi,
On Dienstag, 7. April 2009, Paul Wise wrote:
A single rmdir in every game using /var/games isn't that hard,
especially since they have to remove the files from there.
I agree and plan to file RC bugs on this.
(There
On Wed, 2009-04-08 at 10:15 +0200, Giacomo A. Catenazzi wrote:
So I've a question: what does UTF-8 mean in this context (C.UTF-8) ?
It is not a stupid question, and the answer is not the UTF-8 algorithm
to code/decode unicode.
I'm still thinking that you are confusing the various meanings.
Hi,
On Mittwoch, 8. April 2009, Paul Wise wrote:
How about this:
Game a gets installed and ships /var/games
Game b gets installed and ships /var/games
Game a gets purged and removes /var/games
User starts game b and gets a high score
Game b tries to save the high score but fails because
On Wed, Apr 8, 2009 at 7:51 PM, Holger Levsen hol...@layer-acht.org wrote:
On Mittwoch, 8. April 2009, Bill Allombert wrote:
Unless policy is changed to make clear that /var/games can be removed
at any time, and thus that package cannot just ship /var/games in the
deb and expect it to be
On Wed, 2009-04-08 at 14:17 +0200, Holger Levsen wrote:
Hi,
On Mittwoch, 8. April 2009, Paul Wise wrote:
How about this:
Game a gets installed and ships /var/games
Game b gets installed and ships /var/games
Game a gets purged and removes /var/games
User starts game b and gets a
Hi,
On Mittwoch, 8. April 2009, Adeodato Simó wrote:
Additionally, what happens if package A and B both ship an empty
/var/games (they both write their score files directly there, rather
than a subdirectory), get both installed, then B gets purged and its
postinst removes /var/games, and then
+ Russ Allbery (Mon, 06 Apr 2009 11:33:41 -0700):
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).
Hi Bill,
On Mittwoch, 8. April 2009, Bill Allombert wrote:
Unless policy is changed to make clear that /var/games can be removed
at any time, and thus that package cannot just ship /var/games in the
deb and expect it to be available when running the postinst, or at any
latter time, I have to
On Wed, Apr 08, 2009 at 01:51:25PM +0200, Holger Levsen wrote:
Hi Bill,
On Mittwoch, 8. April 2009, Bill Allombert wrote:
Unless policy is changed to make clear that /var/games can be removed
at any time, and thus that package cannot just ship /var/games in the
deb and expect it to be
On Wed, Apr 08, 2009 at 10:22:15AM +0200, Giacomo A. Catenazzi wrote:
Roger Leigh wrote:
On Tue, Apr 07, 2009 at 09:24:38PM +0200, Adeodato Simó wrote:
+ Thorsten Glaser (Tue, 07 Apr 2009 18:54:59 +):
Except the ton which sets LC_ALL=C to get sane (parsable,
dependable, historically
On Wed, Apr 08, 2009 at 02:04:13PM +0200, Adeodato Simó wrote:
+ Russ Allbery (Mon, 06 Apr 2009 11:33:41 -0700):
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
On Wed, Apr 08, 2009 at 09:41:18AM +0200, Giacomo A. Catenazzi wrote:
Roger Leigh wrote:
I wasn't aware that this level of checking was performed, though
it does make sense. But, does it not reject non 7-bit input in the C
locale for completeness?
Should tools doing raw I/O not be using
On Wed, 2009-04-08 at 14:17 +0200, Holger Levsen wrote:
Hi,
On Mittwoch, 8. April 2009, Paul Wise wrote:
How about this:
Game a gets installed and ships /var/games
Game b gets installed and ships /var/games
Game a gets purged and removes /var/games
User starts game b and gets a
On Wed, 2009-04-08 at 14:04 +0200, Adeodato Simó wrote:
+ Russ Allbery (Mon, 06 Apr 2009 11:33:41 -0700):
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
Ok, maybe I found the problem.
Giacomo A. Catenazzi wrote:
No ;-) Ok, it take me some modifications of your program and
looking to POSIX to discover the reason.
You forget to check error codes. In this case we have
Invalid or incomplete multibyte or wide character in the
non UTF-8 locale.
Andrew McMillan wrote:
On Wed, 2009-04-08 at 10:15 +0200, Giacomo A. Catenazzi wrote:
So I've a question: what does UTF-8 mean in this context (C.UTF-8) ?
It is not a stupid question, and the answer is not the UTF-8 algorithm
to code/decode unicode.
I'm still thinking that you are confusing
Giacomo A. Catenazzi dixit:
The locale C is already a UTF-8 compatible locale.
It is UTF-8 transparent but that's its pro and con.
It does not tell the system that UTF-8 encoding is to be used.
It basically says the encoding is none/unknown.
Why build need to depend to a locale?
[...]
For
On Wed, 2009-04-08 at 15:31 +0200, Giacomo A. Catenazzi wrote:
We have the same objective, but two different ways.
Indeed, but it seems to me that you are pushing for a much bigger change
than I am.
So the smallest step which is in the same direction both of us want to
go, is for *a* UTF-8
Package: debian-policy
Severity: minor
In chapter 1.1 of Debian Python Policy
http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html,
second paragraph, it says The default Debian Python version should
alway be... should say always.
-- System Information:
Debian Release:
25 matches
Mail list logo
