dm upload permissions

[Bart Martens]

Hello,

For your information, here are a few reports about DM upload permissions :
http://qa.debian.org/~bartm/dm-permissions/

The reports are made using these information sources :
- the old DMUA=yes flags in the debian/control files
- the new DM upload permissions in http://ftp-master.debian.org/dm.txt
- the DM keyring
- carnivore database (e-mail addresses, key fingerprints, maintainer names)
- fields Maintainer and Uploaders in Sources files

The report dd-dm-package.txt is http://ftp-master.debian.org/dm.txt reformatted
by granting DD.  No old DMUA=yes permissions here.

The report dm-dd-package.txt gives an overview of all current DM upload
permissions, either via the old DMUA=yes flag or via the new DM upload
permissions.  According to the announcement
http://lists.debian.org/debian-devel-announce/2012/09/msg8.html the
remaining permissions "only via DMUA=yes" will be revoked on 24th of November
2012.

The report dm-without-packages.txt lists DMs in the DM keyring that are
currently not maintaining any package with DM upload permissions.

The report dmua-without-dm.txt lists over 1200 source packages having the old
DMUA=yes flag but without a DM in Maintainer or Uploaders.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120928085341.gb8...@master.debian.org

Re: dm upload permissions

[Arno Töll]

Hi,

On 28.09.2012 10:53, Bart Martens wrote:
> For your information, here are a few reports about DM upload permissions :
> http://qa.debian.org/~bartm/dm-permissions/

just for the records, before people start writing more tools: I've
written one myself and asked for inclusion of it in devscripts:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688830



-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#689019: ITP: python-argh -- A simple argparse wrapper

[Marco Nenciarini]

Package: wnpp
Severity: wishlist
Owner: Marco Nenciarini 

* Package name: python-argh
  Version : 0.15.1
  Upstream Author : Andrey Mikhaylenko 
* URL : http://packages.python.org/argh/
* License : LGPL-3.0+
  Programming Lang: Python
  Description : A simple argparse wrapper

Argh provides a very simple wrapper for argparse.

Argparse is a very powerful tool; argh just makes it easy to use.

Here’s a list of features that argh adds to argparse:

 * mark a function as a CLI command and specify its arguments before the parser 
is instantiated;
 * nested commands made easy: no messing with subparsers (though they are of 
course used under the hood);
 * infer command name from function name;
 * infer agrument type from the default value;
 * infer argument action from the default value (for booleans);
 * infer arguments from function signature;
 * add an alias root command help for the --help argument;
 * enable passing unwrapped arguments to certain functions instead of a 
argparse.Namespace object.

Argh is fully compatible with argparse. You can mix argh-agnostic and
argh-aware code. Just keep in mind that dispatch() does some extra
work that a custom dispatcher may not do.



Note: I'm packaging this as a requirement for barman (http://www.pgbarman.org) 
package.

Regards,
Marco


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120928101137.ga32...@greygoo.devise-it.lan

Bug#689020: ITP: concavity -- predictor of protein ligand binding sites from 3D structure and sequence conservation

[Laszlo Kajan]

Package: wnpp
Severity: wishlist
Owner: Laszlo Kajan 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: concavity
  Version : 0.1
  Upstream Author : Thomas Funkhouser , John A. Capra 

* URL : http://compbio.cs.princeton.edu/concavity/
* License : GPL-3+
  Programming Lang: C++
  Description : predictor of protein ligand binding sites from 3D structure 
and sequence conservation

 ConCavity predicts protein ligand binding sites by combining evolutionary
 sequence conservation and 3D structure.
 .
 ConCavity takes as input a PDB format protein structure and (optionally)
 files that characterize the evolutionary sequence conservation of the chains
 in the structure file.
 .
 The following result files are produced (by default):
  * residue ligand binding predictions for each chain (*.scores)
  * residue ligand binding predictions in a PDB format file (residue
scores placed in the temp. factor field, *_residue.pdb
  * pocket prediction locations in a DX format file (*.dx)
  * PyMOL script to visualize the predictions (*.pml)
 .
 ConCavity has many features.  The default run of concavity is equivalent to
 ConCavity^L in the paper:
 'Capra JA, Laskowski RA, Thornton JM, Singh M, and Funkhouser TA(2009)
 Predicting Protein Ligand Binding Sites by Combining Evolutionary Sequence
 Conservation and 3D Structure. PLoS Comput Biol, 5(12).'.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQZX4/AAoJEJvS1kCaDFL6WSwP/0JAWgVwepTLSRFGON9RQmZ7
r6vUpQs3GmZxPYPa+vqY961HPkG4FKXu2hywRN/dojoz+FVL9R1MHmLuU+trJJ8p
tbknGUdTOYLvygrBSzAUYY1O3Vqgk9zO6ht0je5WdNSiFJiaUk/z+LezAzwvfdzd
zo0wfB9CVqT72tBE3Y0fLjudBDG3HlTyiL5JnSHIvFk9E9alsYU1r04GYOIwmi38
/txTH6QspTPlOmL3Ky1IvM3oQNR+LUL/QHO1vCJ1EmrErNju4A2jWFkoe8bvGZYw
tyPEr8ygzNel0+/vD1MDGF3seRJZAz10SKduxEMsT6xC8myHoXbOkKeGKceUc2wm
8rgJUZhBUGuq5jtt2g44al5ArWo82bS+qbAqJ8AYhVjF9rm8wUjGQxtObb53Si2J
aW1lEYlWI+VDeUPBfpQNIa9MuwnbBGsgbp8+015g7ci7W1PO3pVx6T13an6Xl83u
naw55C0flsE63W78bt0a8qKmCyFLBO485J7CdHKolR/2x8i1SGGeSoOnJRO1o1rO
g0vKrcCX7Vv/2/9N88E03dGjQJLCRFb3JBOpzkYZnwyVNfqSdLmVSFSGh+Hloo2M
QzmXnVpmGMnWy6aUN2zgTWUmKg39yXvajICTnBBEcsQLKvOCwvTv7ODaU9/dbHF+
kM8AxpsQLVn3kBabB4r+
=5PF/
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120928103900.24805.55055.reportbug@debian-unstable.rostclust

Re: ${HOME} vs. g_get_home_dir ()

[Simon McVittie]

On 27/09/12 22:53, Josselin Mouette wrote:
> Le jeudi 27 septembre 2012 à 14:39 -0700, Josh Triplett a écrit : 
>> "sudo foo" leaves $HOME set to the user's
>> home directory rather than root
> 
> This is a bug in sudo. There can be very dangerous things in $HOME

It's configurable, because each of you can be right in different
situations. I think the Debian default is to clear the environment
(except for a few whitelisted variables like LANG).

If only root-equivalent ("admin") users are allowed to sudo (as seen in
an out-of-the-box Ubuntu installation, or Debian when a user is in the
sudo group), then escalating privileges is a non-issue. In this case,
Josh's version is OK: passing environment variables through doesn't let
the user do anything they couldn't do already.

If certain users are granted sudo access to certain commands but are not
otherwise root-equivalent, then Josselin is right that it's not
generally safe to pass environment variables through: it's likely that
they can subvert those commands by careful choice of environment variables.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/506582d2.90...@debian.org

Re: ${HOME} vs. g_get_home_dir () [and 1 more messages]

[Ian Jackson]

(Resending due to a problem with mail headers.)

Josselin Mouette writes ("Re: ${HOME} vs. g_get_home_dir () [and 1 more 
messages]"):
> I expect programs to use my real home, regardless of whatever crap could
> have been put in the environment (and there are really too many things
> that fiddle with $HOME incorrectly).

What things fiddle with $HOME incorrectly ?

> Le jeudi 27 septembre 2012 à 10:06 +0200, Bjørn Mork a écrit : 
> > I believe changing XAUTHORITY from default is part of the same upstream
> > problem.
> 
> To me this looks like a classical change management problem.  Just
> because we did things in a certain way for 30 years doesn’t mean this
> way is best.

On the other hand it would be a good idea to try to understand why
things were done a particular way, and what situations would break if
it were to be done a different way.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20581.35921.429021.810...@chiark.greenend.org.uk

Bug#689029: ITP: orthanc -- A lightweight, RESTful DICOM server for healthcare and medical research

[Sebastien Jodogne]

Package: wnpp
Severity: wishlist
Owner: Sebastien Jodogne 


* Package name: orthanc
  Version : 0.2.1
  Upstream Author : Sebastien Jodogne 
* URL : https://code.google.com/p/orthanc/
* License : GPL
  Programming Lang: C++
  Description : A lightweight, RESTful DICOM server for healthcare and 
medical research


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120928134141.19306.55678.reportbug@main.localdomain

Re: Re: Processor microcode update packages (was: Towards d-i wheezybeta 3)

[Eric Valette]

  
  
Reading the thread about microcode, I wonder why
  there is no more any /etc/init.d/microcode.ctl equivalent for
  people like building their own kernel without initrd.
  
  -- eric
  

  



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5065a9c4.2070...@free.fr

FTWCA irker (another CIA.vc alternative)

[Daniel Baumann]

for those who care about irker, another CIA.vc alternative, to rely 
commit noticies into an irc channel, see:


  * #689011
  * http://people.debian.org/~daniel/irker/

--
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5065abb8.7090...@progress-technologies.net

Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Arno Töll]

Hello,

we may all agree that the maintenance of some (many?) packages in Debian
is in a unclear situation. There is a transient state, where people are
interested to bring a package in shape but the strong role of a package
maintainer in Debian effectively blocks any commitment beyond fixing
important issues in minimally invasive non-maintainer uploads.

I realize this is going to be controversial (a bit?), but eventually I'm
hoping to allow people to make Debian better. Truth is, as a good
citizen of Debian Town, there few possibilities for unapproved changes
someone else's packages.

Therefore, this is not an approach to take packages away from people.
Instead, I'm trying to find a procedure where people don't need to be
afraid of the good work they are interested to deliver, while there is a
good chance, the original maintainer is unavailable and unresponsive for
a substantial time. Our goal ought to be to make Debian better - if
people are interested to make a package better, why should we refuse
their work?

Prior discussion on that matter was on this year's DebConf [6][7]. While
I didn't base my work directly on the argumentation from that DebConf
BoF, many ideas I am proposing are being derived from it. I tried to
address concerns, but also problems mentioned there.

Some more work was approached by Michael Gilbert in #681833 [8],
introducing "liberal NMUs", a concept to weaken the NMU requirements in
case of a maintainer missing in action. Note, my proposal (somewhat) is
in conflict with this proposal.

The actual proposal follows below, but first let me address some questions:

Q: Why do you call it a salvage, not hijack? You DO eventually hijack a
package

Well, that's right. As for me, I do not mind continue to call my salvage
process a hijack, if people prefer. However, the term hijacking has a
negative connotation, implying a rude and hostile action. My "weak
hijack", however, tries to be as nice to (previous) maintainers as
possible. Also, I'm trying to work out explicitly what I mean by
"salvaging" and what I still consider to be a "hijack".

Having that said, I am not interested to debate later on whether a
package was salvaged or whether it was hijacked ("You waited 23 seconds
too little - you hijacked it!"). So, please, let's concentrate on facts,
not wording.

Q: What? You only want to wait X weeks before considering a package
unmaintained? or, alternatively: What? Why do you want me to wait so
long, until the package is finally considered orphaned?

Truth is, we won't ever agree on that. I tried to find a compromise
being longer than any usual or typical vacation or "work has caught me"
period, but shorter than a typical Debian release cycle letting people
time to actually work on a package.

Having that said, I'm entirely open to any other waiting times, people
may find more appropriate.


While I am taking the blame for piping this proposal to a larger
audience, I'd like to thank gregor herrmann, Laurent Bigonville, David
Prévot, Stuart Prescott and Steve McIntyre, Jakub Wilk for commenting
previously and working out this proposal together with me.

Actual proposal follows:

Adopting an unmaintained package
===

Packages being marked as orphaned, or those being up for adoption can be
immediately taken over. This is currently the status quo. The wnpp
pseudo-package [1][2] holds packages being up for adoption ("RFA" bugs),
or being orphaned ("O" bugs). Moreover, packages maintained by the QA
Team [3] can be taken over without further discussion.

Salvaging a package
=

Salvaging is the process by which, one attempts to save a package from a
state where it is poorly maintained or appears not maintained at all,
without being officially orphaned. This is a weaker and faster procedure
than orphaning a package officially through powers of the MIA team [4].
Salvaging a package is not meant to replace MIA handling, and in
contrast to it, it does not comment about the overall activity of a
maintainer. Instead, it handles a package maintainer transition for a
single package only, leaving any other package or Debian membership or
upload rights (when applicable) untouched. However, during the salvage
process, the MIA team will be informed (see below). This might be
considered by them as a kick-off to start the MIA procedure as well.
That's a desired side effect when found beneficial by MIA team members.


Reasons to salvage a package

The package is in clear need of some love and care, i.e. there are open
bugs,  missing upstream releases, or there is work needed from a
quality-assurance perspective; AND there is the need to upload the
package to deal with these  issues; AND at least one of these criterias
applies:

* There is no visible activity regarding the package [5] for /six months/.

* There is no visible activity regarding the package [5], and the
maintainer of the package in question is tracked in the MIA data

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Bart Martens]

Hi Arno,

On Fri, Sep 28, 2012 at 06:48:22PM +0200, Arno Töll wrote:
> Actual proposal follows:

The proposal adds a new procedure that overlaps/bypasses existing procedures.

We have discussed that before in this thread :
http://lists.debian.org/debian-devel/2012/07/msg00540.html

What we essentially need, is a lightweight procedure to orphan individual
packages.  I propose this :

  |  Anyone can mark a package as orphaned after the following steps have been
  |  completed : Someone submits an "intent to orphan" in the bts with an
  |  explanation of why he/she thinks that the package needs a new maintainer.
  |  Anyone can submit this "intent to orphan".  At least three DD's second the
  |  "intent to orphan" on the same bug report with a cc to the maintainer.  
And the
  |  maintainer does not respond within one month after the the third second.

After the package is orphaned, the rest of the "salvaging" fits in the existing
procedures.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120928175223.ga2...@master.debian.org

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Ricardo Mones]

  Hi,

On Fri, 28 Sep 2012 18:48:22 +0200
Arno Töll  wrote:

> Salvaging a package
> =
> 
> Salvaging is the process by which, one attempts to save a package from a
> state where it is poorly maintained or appears not maintained at all,
> without being officially orphaned. This is a weaker and faster procedure
> than orphaning a package officially through powers of the MIA team [4].
> Salvaging a package is not meant to replace MIA handling, and in
> contrast to it, it does not comment about the overall activity of a
> maintainer. Instead, it handles a package maintainer transition for a
> single package only, leaving any other package or Debian membership or
> upload rights (when applicable) untouched. However, during the salvage
> process, the MIA team will be informed (see below). This might be
> considered by them as a kick-off to start the MIA procedure as well.
> That's a desired side effect when found beneficial by MIA team members.
> 
> 
> Reasons to salvage a package
> 
> The package is in clear need of some love and care, i.e. there are open
> bugs,  missing upstream releases, or there is work needed from a
> quality-assurance perspective; AND there is the need to upload the
> package to deal with these  issues; AND at least one of these criterias
> applies:
> 
> * There is no visible activity regarding the package [5] for /six months/.
> 
> * There is no visible activity regarding the package [5], and the
> maintainer of the package in question is tracked in the MIA database
> already, and there was no recorded activity in the MIA tracker for
> /three months/.
> 
> * A previous NMU was not acknowledged, and at least another issue
> justifying another NMU is pending for /one month/ [5].
> 
> * The last upload was an NMU and there was no maintainer upload within
> /one year/.
> 
> * The package blocks a sourceful transition or the implementation of a
> release goal for /six months/ after a transition or release goal bug was
> filed against the package in question.
> 
> 
> Procedure to salvage a package
> -
> If any of the criteria denoted above are fulfilled, anyone interested
> can start the salvage procedure.  For Debian Developers, it should be
> checked whether they are on vacation.
> 
> 1) A bug with severity "serious" against the package in question must be
> filed, expressing the intent to take over maintainership of the package.
> The reporter may also offer co-maintenance of the package.
> 
> 2) The maintainer, or any current uploader of the package in question
> may object publicly in response to the bug filed within 14 days. Of
> course, current maintainers may also agree to the intent to salvage a
> package by filing a (signed) public response to the bug. In such a case,
> a new package can be uploaded immediately thereafter by the new
> maintainer(s).
> 
> 3) After waiting at least the required 14 days, another warning must be
> sent to the bug report, this time also the MIA team shall be informed
> and all maintainers or uploaders of the package shall be contacted
> explicitly as well.

  If the above criteria only apply to one package but the rest of
  maintainer's packages is being maintained, informing the MIA team should
  be bypassed: maintainer is just neglecting a single package but not MIA.
  And in fact there's little the MIA team can do with those maintainers, so
  this procedure could be a nicer alternative.

  Otherwise the MIA team should be Cc-ed first, when reporting the bug: the
  maintainer may be very likely MIA, I don't see a reason to wait more. And
  if MIA team achieves a response quicker, the salvage procedure bug can be
  fixed faster.

  regards,

P.S.: please keep Cc to debian-qa, I'm not subscribed to debian-devel.
-- 
 Ricardo Mones, on behalf of Debian QA/MIA team
 http://people.debian.org/~mones
 «Tomorrow will be cancelled due to lack of interest.»


signature.asc
Description: PGP signature

Bug#689080: ITP: ktouchpadenabler -- kded daemon to enable/disable touchpad

[Daniel Skinner]

Package: wnpp
Severity: wishlist
Owner: Daniel Skinner 

* Package name: ktouchpadenabler
  Version : 0.1.0
  Upstream Author : Unknown
* URL : http://download.kde.org/stable/extragear/
* License : GPL
  Programming Lang: C++
  Description : kded daemon to enable/disable touchpad

ktouchpadenabler is a kded daemon to enable and disable the system's touchpad.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120928233255.4094.94314.reportbug@zombix

Bug#689087: ITP: sweethome3d-furnitures -- Interior 2D design application with 3D preview (additional furnitures)

[Gabriele Giacone]

Package: wnpp
Severity: wishlist
Owner: Gabriele Giacone <1o5g4...@gmail.com>

* Package name: sweethome3d-furnitures
  Version : 1.2
  Upstream Author : Various SweetHome3D contributors
* URL : http://www.sweethome3d.com/importModels.jsp
* License : CC-BY-3.0 Unported, CC-BY-3.0 USA, Free Art License 1.3
  Programming Lang: no code, zip archives containing OBJ + MTL (Wavefront) 
format files.
  Description : Interior 2D design application with 3D preview (additional 
furnitures)

Furnitures released under CC-BY-3.0 in sweethome3d-furnitures package in main.
Free Art License ones in sweethome3d-furnitures-nonfree in non-free.

 Sweet Home 3D is an interior design Java application for quickly choosing and 
 placing furniture on a house 2D plan drawn by the end-user, with a 3D preview.
 .
 This package contains additional furniture libraries created by SweetHome3D
 contributors.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120929003646.GA14652@phenomenon

Re: Processor microcode update packages (was: Towards d-i wheezybeta 3)

[Henrique de Moraes Holschuh]

On Fri, 28 Sep 2012, Eric Valette wrote:
> 
>   
> 
> 
>   
>   
> Reading the thread about microcode, I wonder why
>   there is no more any /etc/init.d/microcode.ctl equivalent for
>   people like building their own kernel without initrd.
>   
>   -- eric
>   
> 
>   
> 

1. No html, please.

non-initrd is supported.  Read the package documentation for the details.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120929014648.gb31...@khazad-dum.debian.net

Re: Processor microcode update packages

[Ivan Shmakov]

> Henrique de Moraes Holschuh  writes:
> On Fri, 28 Sep 2012, Eric Valette wrote:

 >> 
 >>   
  
 >> 
 >>   
 >>   
 >> Reading the thread about microcode, I wonder why

[…]

 > 1. No html, please.

And, especially, no /invalid/ HTML, please.

[…]

-- 
Advocating the
judicious use of XML applications at the Internet at large.
Stop the use of proprietary formats on the Web and e-mail!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86vcexsdsv@gray.siamics.net

Re: ${HOME} vs. g_get_home_dir ()

[Ivan Shmakov]

> Simon McVittie  writes:
> On 26/09/12 18:15, Ivan Shmakov wrote:
> Simon McVittie  writes:

 >>> Please research previous discussion to check that you're not
 >>> missing arguments that have happened in the past,

 >> Any particular pointers?

 > Following the git history points to
 > , which raises
 > interesting issues regarding running GUI applications from under
 > su/sudo (which is generally a bad idea, but back then there was
 > little alternative).

There's also the analysis at [1].

Unfortunately, it seems that the possibility of the user
/intentionally/ changing his or her own HOME was never
considered (and neither such concerns are reflected in the
documentation.)  E. g.:

--cut--
It turns out that most of this time, this is irrelevant.  login sets
$HOME and until you switch users, it will be left unchanged.  The case
where it becomes an issue is with some "execute a program as another
user" commands.  There is some difference in behavior here.
--cut--

Should the target user be a non-privileged one, my suggestion
(to only use HOME if it points to a directory which is both
accessible and owned by the “now-current” user) should relieve
the concerns listed.  On the other hand, when the target user is
‘root’ (UID 0), either of these behaviors may be valid
(depending on the exact circumstances, as was noted elsewhere in
this thread), so this check shouldn't be done (should we follow
the general principle of “root knows what it wants.”)

[1] http://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00066.html

-- 
FSF associate member #7257


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86r4pls8w9@gray.siamics.net