Em Seg, 2004-04-19 às 16:03, Ryan Murray escreveu:
> No patch that involves doing anything with the PAM login-time configuratio
n
> file /etc/environment is going to be applied by me.

Ok, you mean I must do a NMU? or this mean I must go to the next step,
that would be the tech-ctte?

Just to make clear... I don't want to create problems, but this bug is
really annoying for non-english speakers, and as there is a patch that
fixes the bug (at least before init i18n be cleared), I don't see a
reason for not fixing it. If you do have a better way to fix it, please
do it, but if not, let this 2-years old be fixed.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Wed, Apr 21, 2004 at 12:31:28PM +0200, Andreas Metzler wrote:
> internals but a place to set *arbitrary* environment variables for
> all sessions using pam_env, including ssh, login, xdm, ...

in fact is used to be used even before pam, thats why it inherits its shell 
like structure in most places. If an application is not pam enabled it stall
 can be expected to observe this property list.

Greetings
Bernd
--
(OO)      -- Bernd_Eckenfels@Mörscher_Strasse_8.76185Karlsruhe.de --
( .. )      ecki@{inka.de,linux.de,debian.org}  http://www.eckes.org/
o--o     1024D/E383CD7E  eckes@IRCNet  v:+497211603874  f:+497211603875
(O____O)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Wed, Apr 21, 2004 at 12:31:28PM +0200, Andreas Metzler wrote:
> /etc/environment is not some configuration file for mysthical PAM
> internals but a place to set *arbitrary* environment variables for
> all sessions using pam_env, including ssh, login, xdm, ...
>                cu andreas

which brings me to wonder, why hasn't someone fixed this problem for
gdm via pam_env?


sean

[ Post a follow-up to this message ]

On Wed, Apr 21, 2004 at 12:31:28PM +0200, Andreas Metzler wrote:
> Calum Mackay <calum.mackay@cdmnet.org> wrote: 
[vbcol=seagreen] 
[vbcol=seagreen] 
[vbcol=seagreen] 
> [...]

> Neither of which need to be.

> /etc/environment is not some configuration file for mysthical PAM
> internals but a place to set *arbitrary* environment variables for
> all sessions using pam_env, including ssh, login, xdm, ...

And this is precisely why it shouldn't be used for pushing values into
the environment of gdm -- its purpose (as documented and implemented
by the system) is to set environment variables for *user sessions* once
the user has authenticated, not to set env vars for arbitrary processes
that are not related to user sessions (such as the gdm greeter).

-- 
Steve Langasek
postmodern programmer

[ Post a follow-up to this message ]

This fixes the bug after user logs in, but not before. The gdm message
will be without locale definition.

Em Qua, 2004-04-21 às 14:36, sean finney escreveu:
> On Wed, Apr 21, 2004 at 12:31:28PM +0200, Andreas Metzler wrote: 
>
> which brings me to wonder, why hasn't someone fixed this problem for
> gdm via pam_env?
>
>
> 	sean


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Thu, Apr 22, 2004 at 02:39:33PM -0300, Daniel Ruoso wrote:
> Em Qui, 2004-04-22 às 06:33, Mathieu Roy escreveu: 
>
> This is exactly what I'm asking. The question is... I made the same
> question almost a year ago, and nothing happened. What should I do now?
> should I NMU? should i go to tech-ctte?

There is a disagreement among developers. Seems an obvious tech-ctte
thing to me if you're really interested.

6. Technical committee

6.1. Powers

The Technical Committee may:
[...]
2. Decide any technical matter where Developers' jurisdictions
overlap.
In cases where Developers need to implement compatible technical
policies or stances (for example, if they disagree about the
priorities of conflicting packages, or about ownership of a
command name, or about which package is responsible for a bug that
both maintainers agree is a bug, or about who should be the
maintainer for a package) the technical committee may decide the
matter.
[...]
4. Overrule a Developer (requires a 3:1 majority).
The Technical Committee may ask a Developer to take a particular
technical course of action even if the Developer does not wish to;
this requires a 3:1 majority. For example, the Committee may
determine that a complaint made by the submitter of a bug is
justified and that the submitter's proposed solution should be
implemented.

[...]

6.3. Procedure

[...]
5. No detailed design work.
The Technical Committee does not engage in design of new proposals
and policies. Such design work should be carried out by
individuals privately or together and discussed in ordinary
technical policy and design forums.
The Technical Committee restricts itself to choosing from or
adopting compromises between solutions and decisions which have
been proposed and reasonably thoroughly discussed elsewhere.
Individual members of the technical committee may of course
participate on their own behalf in any aspect of design and policy
work.
6. Technical Committee makes decisions only as last resort.
The Technical Committee does not make a technical decision until
efforts to resolve it via consensus have been tried and failed,
unless it has been asked to make a decision by the person or body
who would normally be responsible for it.

I've already made my views on this bug fairly clear, I think; but going
to the Technical Committee is *definitely* superior to getting into an
NMU-fight with the maintainer.

> But I just want to see this bug fixed. I repeat, this bug has a patch
> for more than a year.

The maintainer has repeated that he thinks the patch is wrong; therefore
I don't think it's particularly worthwhile to continue repeating that it
has had a patch. Developers are not obliged to apply any patch they
receive.

--
Colin Watson                                  [cjwatson@flatline.org.uk]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

Em Qui, 2004-04-22 às 15:57, Colin Watson escreveu:
> There is a disagreement among developers. Seems an obvious tech-ctte
> thing to me if you're really interested.

Yes, as this bug is *really* annoying for non-english speakers, I am
interested.

Following the recommendations on how to proceed to take a question to
tech-ctte, I'll try to make a summary of the disagreement, please
correct me if I'm wrong.

Disagreement Point: Apply or not patch in /etc/init.d/gdm to parse
/etc/environment and get the LANG variable setted by locales package.
This patch would close bug #133578.

Daniel Ruoso's Point of View:

The file /etc/environment is the one that the package locales change in
postinst to save the "Default System Locale". This file seems to be a
generic configuration file, that is readed by pam_env module, and that
could be read by an init script. And even if this is not the case, the
patch could be a workaround for a long-standing bug, until a better
solution be made. Note that there is a wait for this "better" solution
for more than one year.

Ryan Murray's Point of View (I'm trying to catch the things up, if I'm
wrong please correct me):

The file /etc/environment is a user-session PAM related file that *must
not* be readed by init scripts. In this way, the patch should not be
applied and a better solution must be found. This solution is already in
discussion with the glibc package maintainers.

Once we agree about the disagreement, we can move on.

daniel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

Scripsit Daniel Ruoso <daniel@ruoso.com>

> Disagreement Point: Apply or not patch in /etc/init.d/gdm to parse
> /etc/environment and get the LANG variable setted by locales package.
> This patch would close bug #133578.

Wouldn't it be better to disagree about the *behavior*? Ask tech-ctte
to decide

Should or should not the default configuration of gdm honor
a language setting in /etc/environment?

If the decision is "yes it should", then it still ought to be the
maintainer's decision how to achieve that behavior - either by
applying the existing patch or by himself writing code that he is more
happy with.

It might be a good idea also to ask tech-ctte to rule explicitly on
the (apparently) underlying disagreement:

Is /etc/environment intended to configure environment variables
only for processes that run in the context of an authenticated
session, or is it also appropriate for other programs that interact
with users in non-authenticated contexts to adhere to locale
settings (et cetera) in /etc/environment?

In the latter case, is it appropriate for other programs to parse
/etc/environment themselves, or should such parsing be done through
an API controlled by whatever (source?) package is deemed to "own"
/etc/environment?

--
Henning Makholm               "The Board views the endemic use of PowerPoint
briefing slides instead of technical papers as an
illustration of the problematic methods of technical communicaion at NASA."


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

Agreed. But even if decided /etc/environment must not be parsed, I think
this must be done as a workaround until a better way to fix it is found.

Em Qui, 2004-04-22 às 20:14, Henning Makholm escreveu:[vbcol=seagreen]
> Scripsit Daniel Ruoso <daniel@ruoso.com>
> 
>
> Wouldn't it be better to disagree about the *behavior*? Ask tech-ctte
> to decide
>
>     Should or should not the default configuration of gdm honor
>     a language setting in /etc/environment?
>
> If the decision is "yes it should", then it still ought to be the
> maintainer's decision how to achieve that behavior - either by
> applying the existing patch or by himself writing code that he is more
> happy with.
>
> It might be a good idea also to ask tech-ctte to rule explicitly on
> the (apparently) underlying disagreement:
>
>    Is /etc/environment intended to configure environment variables
>    only for processes that run in the context of an authenticated
>    session, or is it also appropriate for other programs that interact
>    with users in non-authenticated contexts to adhere to locale
>    settings (et cetera) in /etc/environment?
>
>    In the latter case, is it appropriate for other programs to parse
>    /etc/environment themselves, or should such parsing be done through
>    an API controlled by whatever (source?) package is deemed to "own"
>    /etc/environment?
>
> --
> Henning Makholm               "The Board views the endemic use of PowerPoi
nt
>                            briefing slides instead of technical papers as 
an
>  illustration of the problematic methods of technical communicaion at NASA."[/vbco
l]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Thu, Apr 22, 2004 at 10:16:46PM -0300, Daniel Ruoso wrote:
> Agreed. But even if decided /etc/environment must not be parsed, I think
> this must be done as a workaround until a better way to fix it is found.

There hardly seems much point referring it to the technical committee if
you're not going to take it seriously ... this is part of the general
problem and if you're referring the whole thing to the TC then they
should be adjudicating this too.

--
Colin Watson                                  [cjwatson@flatline.org.uk]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]