Bug#522776: C.UTF-8 in squeeze
tag Roger Leigh a écrit : clone 522776 -1 reassign -1 eglibc retitle -1 eglibc: Please provide a C.UTF-8 locale by default severity -1 important thanks On Fri, Jan 07, 2011 at 09:14:47PM -0500, David Holland wrote: Can this please get done (adding a C.UTF-8 locale)? It is absolutely required for writing shell scripts that handle UTF-8 data, if you want those shell scripts to have anything like portable or reliable behavior. This is really in the hands of the glibc maintainers. I thought that a bug had been filed months ago, but I can't find it. I've done so now. Note this comment from Aurelien Jarno: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522776#342 This will only be done with the approval of the release team, who I've copied in. I know some persons already tried to work on that, so if patches are already available, they will be really appreciated. Providing a C.UTF-8 locale is quite easy, d-i is already doing that. Providing a C.UTF-8 *by default* is more complicated, as it has to be done in the GNU libc code, we can't really on the locale package generating one. This would mean this package should always be installed, and that we should trust on user to correctly regenerate the locales if they do. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d2ab8ca.5030...@aurel32.net
Bug#522776: C.UTF-8 in squeeze
On Mon, Jan 10, 2011 at 08:44:10AM +0100, Aurelien Jarno wrote: Roger Leigh a écrit : On Fri, Jan 07, 2011 at 09:14:47PM -0500, David Holland wrote: Can this please get done (adding a C.UTF-8 locale)? It is absolutely required for writing shell scripts that handle UTF-8 data, if you want those shell scripts to have anything like portable or reliable behavior. This is really in the hands of the glibc maintainers. I thought that a bug had been filed months ago, but I can't find it. I've done so now. I know some persons already tried to work on that, so if patches are already available, they will be really appreciated. Providing a C.UTF-8 locale is quite easy, d-i is already doing that. Providing a C.UTF-8 *by default* is more complicated, as it has to be done in the GNU libc code, we can't really on the locale package generating one. This would mean this package should always be installed, and that we should trust on user to correctly regenerate the locales if they do. Hi Aurelien, I think that initially, simply guaranteeing the presence of C.UTF-8 as a standard locale, generated by localedef/gen will be sufficient. This will allow packages to rely on its presence during normal system operation e.g. in maintainer scripts, for lintian and other programs requiring it. I think having it hardcoded into libc is rather more difficult and having it prior to /usr being mounted is not that important--all of the known use cases do not require this. So at least initially, I think simply providing it outside libc will be more than sufficient. I would like to see it in libc itself eventually, but I am concerned about the UTF-8 codeset table being duplicated for every locale. I'd like to see it shared so that users using it don't have to pay a large penalty for the needless duplication. Possibly best looked at upstream; I did already mention it a year or so back, but I didn't get too far--it was more of a casual enquiry about the possibilities. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#522776: C.UTF-8 in squeeze
Roger Leigh a écrit : On Mon, Jan 10, 2011 at 08:44:10AM +0100, Aurelien Jarno wrote: Roger Leigh a écrit : On Fri, Jan 07, 2011 at 09:14:47PM -0500, David Holland wrote: Can this please get done (adding a C.UTF-8 locale)? It is absolutely required for writing shell scripts that handle UTF-8 data, if you want those shell scripts to have anything like portable or reliable behavior. This is really in the hands of the glibc maintainers. I thought that a bug had been filed months ago, but I can't find it. I've done so now. I know some persons already tried to work on that, so if patches are already available, they will be really appreciated. Providing a C.UTF-8 locale is quite easy, d-i is already doing that. Providing a C.UTF-8 *by default* is more complicated, as it has to be done in the GNU libc code, we can't really on the locale package generating one. This would mean this package should always be installed, and that we should trust on user to correctly regenerate the locales if they do. Hi Aurelien, I think that initially, simply guaranteeing the presence of C.UTF-8 as a standard locale, generated by localedef/gen will be sufficient. This will allow packages to rely on its presence during normal system operation e.g. in maintainer scripts, for lintian and other programs requiring it. Doing so means that the locales or locales-all package will be installed by default. People are going to shout... Or we should create a locales-cutf8 packages, but then the integration with the two other packages will become quite complex. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d2ae542.2030...@aurel32.net
Bug#522776: C.UTF-8 in squeeze
Aurelien Jarno dixit: Doing so means that the locales or locales-all package will be installed Hm, localedef is in libc-bin – can C.UTF-8 not be generated by its postinst (with some logic in locales-all to restore C.UTF-8 in its postrm)? bye, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” -- Edward Burr -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1101101307410.11...@herc.mirbsd.org
Bug#522776: C.UTF-8 in squeeze
On Mon, Jan 10, 2011 at 01:09:10PM +, Thorsten Glaser wrote: Aurelien Jarno dixit: Doing so means that the locales or locales-all package will be installed Hm, localedef is in libc-bin – can C.UTF-8 not be generated by its postinst (with some logic in locales-all to restore C.UTF-8 in its postrm)? I was thinking the same thing, but I think it needs things like /usr/share/i18n/charmaps/UTF-8.gz which are in the locales package. Could we pre-generate it using --no-archive so we don't use the locale archive; would this be sufficient to providing it in a package separate from the locales package or are there other issues? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
On Sun, Jan 09, 2011 at 08:10:04PM -0600, Steve Langasek wrote:
Also, it's possible that some of the bits I've marked as upstart-specific
will also be applicable to systemd and should be moved up a section. I'm
not familiar enough with the mechanics of systemd to say whether this is the
case; eyeballs/wording tweaks welcome.
Next to upstart and systemd we currently also have file-rc and runit
as alternatives to sysvinit. But runit-run doesn't seem to exist
anymore?
+ method guaranteed to be supported by all init implementations. An
+ exception to this rule is scripts or jobs provided by the init
+ implementation itself; such jobs may be required for an
+ implementation-specific equivalent of the file/etc/rcS.d//file
+ scripts and may not have a one-to-one correspondence with the init
+ scripts.
+/p
A lot of the scripts currently in /etc/rcS.d/ come from the
initscripts package. Is the alternative supposed to implement
all the functionality by those scripts? Or do we expect them
to run the scripts from /etc/rcS.d/ as 9.3.4. seems to suggest?
What should packages do that want to have their script run
at that time? For sysvinit scripts this is calling update-rc.d
with S as the runlevel. I don't know if the alternatives
support something like a runlevel, and which they support.
+sect1 id=upstart
+ headingEvent-based boot with upstart/heading
+
+ p
+Packages may integrate with the prgnupstart/prgn event-based
+boot system by installing job files in the
+file/etc/init/file directory.
/etc/init seems to be a very general directory name for an upstart job.
Can the alternatives use the same job files as upstart?
SysV init scripts for which
+an equivalent upstart job is available must query the output of
+the command prgntelinit --version/prgn for the string
+ttupstart/tt and avoid running in favor of the native
+upstart job.
telinit --version with sysvinit now returns:
telinit: invalid option -- '-'
Usage: telinit {-e VAR[=VAL] | [-t SECONDS]
{0|1|2|3|4|5|6|S|s|Q|q|A|a|B|b|C|c|U|u}}
What kind of output would you expect from it?
If I understand you right, if the package supports something
other than sysvinit, the file in /etc/init.d/ should check that
any of those is currently used? And it should just return 0?
I wonder if it would be useful to call invoke-rc.d instead
in that case if it's run by a user.
+ /p
+ p
+Because packages shipping upstart jobs may be installed on
+systems that are not using upstart, maintainer scripts must
+still use the common prgnupdate-rc.d/prgn and
+prgninvoke-rc.d/prgn interfaces for configuring runlevels
+and for starting and stopping services. These maintainer
+scripts must not call the prgnstart/prgn,
+prgnrestart/prgn, prgnreload/prgn, or prgnstop/prgn
+commands directly.
That's already covered by 9.3.3.2? (But could use rewording.)
What I miss in policy is a description of update-rc.d. We
currently seem to have 2 implementations (each with it's
manpage) of it while I was expecting each alternative to
implement this. And I guess the same goes for invoke-rc.d.
9.3.3.1. could use a re-write as it also seems to be sysvinit
specific.
Kurt
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110110201733.ga2...@roeckx.be
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
On Mon, Jan 10, 2011 at 8:17 PM, Kurt Roeckx k...@roeckx.be wrote: + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the file/etc/rcS.d//file + scripts and may not have a one-to-one correspondence with the init + scripts. + /p A lot of the scripts currently in /etc/rcS.d/ come from the initscripts package. Is the alternative supposed to implement all the functionality by those scripts? Or do we expect them to run the scripts from /etc/rcS.d/ as 9.3.4. seems to suggest? Well, in the systemd case, all the things those scripts used to do are built in and hardcoded in systemd itself. And in the Upstart case, there is a separate implementation of those as well. So yes, I think an init system should deal with core boot by itself, as sysvinit does with the initscripts package. I guess this means policy needs to specify what needs to be done ;-) (otherwise people may find they get a shock if systemd's hardcoded mounting doesn't match what they expected) Scott -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinrow2gp8og01bbxgripgb0rhyn4cphs6pcs...@mail.gmail.com
Vai sekss tev jau ir bijis?
Esu latviete. Esmu porno aktrise. Ja velies, tad izmanto to, ka tagad atverta man veltita majas lapa latvju meelee. Ienaac un paskaties pirmaas 3 filmas no manas kolekcijas. Profesionalju darbs - seksigi, atklati, erotiski. Spied she: HTTP://WWW.MEITENE-NO-OLAINES.INFO -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110111011728.c276713a4...@liszt.debian.org
