Re: Roll call for porters of architectures in sid and testing

[Dejan Latinovic]

Hi everyone,
 
I am part of the group of MIPS porters, and we missed to officially
respond to this email. Here is for the record:
 
  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the jessie release:
 
  For MIPS,MIPSEL,MIPS64,MIPS64EL, I
  - can test all packages on this architecture on different hardware
   (I have access to different MIPS boards)
  - detect toolchain issues and bring it to the attention of toolchain
maintainers whom we already have contact to,
  - triage arch-specific bugs, see we which issues are MIPS specific
  - fix arch-related bugs
  - maintain build
 
  In the last three years, I was a MIPS porter of MIPS32 LE and BE, and
  MIPS64 LE and BE.
 
  Dejan Latinovic



On 09/01/2013 09:33 AM, Niels Thykier wrote:
> Hi,
> 
> As we announced in [LAST-BITS], we would like to get a better idea of
> that status of the ports, to make an informed decision about which
> port can be released with jessie. One of the steps is to get an
> overview of which of the porters are (still) active for each
> port. Once the results from the role-call are in, we will request
> other information about the status of the ports. In the meantime, feel
> free to update and collect info about the ports in the Debian wiki[WIKI].
> 
> If you are (or intend to become) an active porter for the lifetime of
> jessie, then please send a signed email explaining your involvement in
> the port to the Release Team  before
> 1st of October 2013. Please explain the level of your involvement in
> the port.
> 
> Feel free to use the following template as your reply:
> 
> """
>   Hi,
>   
>   I am an active porter for the following architectures and I intend
>   to continue this for the lifetime of the jessie release:
> 
>   For , I
>   - test (most|all) packages on this architecture
>   - fix toolchain issues
>   - triage arch-specific bugs
>   - fix arch-related bugs
>   - maintain buildds
>   - ...
>   
>   
>   
>   
> """
> 
> Niels, on behalf of the release team
> 
> [LAST-BITS] 
> http://lists.debian.org/debian-devel-announce/2013/08/msg6.html
> 
> [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie
> 
> 
> 

--
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/d2ee012454fb9f4a86b9302e531b435e4c90e...@badag02.ba.imgtec.org

Bug#728443: ITP: r-cran-th.data -- GNU R datasets by Torsten Hothorn

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-th.data
  Version : 1.0-2
  Upstream Author : Torsten Hothorn
* URL or Web page : http://cran.r-project.org/web/packages/TH.data/index.html
* License : GPL-3
  Description : GNU R datasets by Torsten Hothorn

This package is a new (Build-)Depends of his package multcomp (aka
r-cran-multcomp) which has been in Debian since 2004.

As it is common with R datasets, these are stored as compressed R data files,
but each datasets has a full documentation page including source references.

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


-- 
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/87y558pc4v@max.nulle.part

RE: Roll call for porters of architectures in sid and testing

[Dragoslav Sicarov]

Hi everyone,

I am part of the group of MIPS porters, and we missed to officially
respond to this email. Here is for the record:

  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the jessie release:

  For MIPS,MIPSEL,MIPS64,MIPS64EL, I
  - can test all packages on this architecture on different hardware
(I have access to different MIPS boards)
  - detect toolchain issues and bring it to the attention of toolchain
maintainers whom we already have contact to,
  - triage arch-specific bugs, see we which issues are MIPS specific
  - fix arch-related bugs
  - maintain build

  In the last three years, I was a MIPS porter of MIPS32 LE and BE, and
  MIPS64 LE and BE.

I am not a DD/DM.

Dragoslav Sicarov


From: Dejan Latinovic
Sent: Friday, November 01, 2013 11:17 AM
To: debian-rele...@lists.debian.org
Cc: debian-devel@lists.debian.org; debian-po...@lists.debian.org; 
debian-m...@lists.debian.org; Dragoslav Sicarov; Jurica Stanojkovic; Petar 
Jovanovic
Subject: Re: Roll call for porters of architectures in sid and testing

Hi everyone,

I am part of the group of MIPS porters, and we missed to officially
respond to this email. Here is for the record:

  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the jessie release:

  For MIPS,MIPSEL,MIPS64,MIPS64EL, I
  - can test all packages on this architecture on different hardware
   (I have access to different MIPS boards)
  - detect toolchain issues and bring it to the attention of toolchain
maintainers whom we already have contact to,
  - triage arch-specific bugs, see we which issues are MIPS specific
  - fix arch-related bugs
  - maintain build

  In the last three years, I was a MIPS porter of MIPS32 LE and BE, and
  MIPS64 LE and BE.

  Dejan Latinovic



On 09/01/2013 09:33 AM, Niels Thykier wrote:
> Hi,
>
> As we announced in [LAST-BITS], we would like to get a better idea of
> that status of the ports, to make an informed decision about which
> port can be released with jessie. One of the steps is to get an
> overview of which of the porters are (still) active for each
> port. Once the results from the role-call are in, we will request
> other information about the status of the ports. In the meantime, feel
> free to update and collect info about the ports in the Debian wiki[WIKI].
>
> If you are (or intend to become) an active porter for the lifetime of
> jessie, then please send a signed email explaining your involvement in
> the port to the Release Team  before
> 1st of October 2013. Please explain the level of your involvement in
> the port.
>
> Feel free to use the following template as your reply:
>
> """
>   Hi,
>
>   I am an active porter for the following architectures and I intend
>   to continue this for the lifetime of the jessie release:
>
>   For , I
>   - test (most|all) packages on this architecture
>   - fix toolchain issues
>   - triage arch-specific bugs
>   - fix arch-related bugs
>   - maintain buildds
>   - ...
>
>   
>
>   
> """
>
> Niels, on behalf of the release team
>
> [LAST-BITS] 
> http://lists.debian.org/debian-devel-announce/2013/08/msg6.html
>
> [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie
>
>
>


--
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/6015875f30b0704f993ce52e93e918686d679...@badag02.ba.imgtec.org

automatically cross-grading lib32nss-mdns to libnss-mdns:i386?

[Simon McVittie]

nss-mdns/unstable is currently available in these flavours:

libnss-mdns:any  (contains a native binary)
lib32nss-mdns:amd64  (contains an i386 binary)

My goal is that when amd64 users with both packages do a dist-upgrade to
jessie, if they have the i386 foreign architecture, they receive
libnss-mdns:amd64 and libnss-mdns:i386, plus whatever transitional
packages are needed to make that transition work. I expect that "most"
lib32nss-mdns users installed it for Wine's benefit (having libnss-mdns
but not lib32nss-mdns used to break DNS for 32-bit things, which appears
to be a long-since-fixed glibc bug), so they'll have the i386 foreign
architecture already.

In nss-mdns/experimental, I tried this:

Package: libnss-mdns
Architecture: any
Multi-Arch: same

Package: lib32nss-mdns
Architecture: i386
Depends: libnss-mdns (= ${binary:Version})
Description: ... transitional package ...

hoping that apt would automatically cross-grade lib32nss-mdns:amd64 to
lib32nss-mdns:i386, pulling in libnss-mdns:i386 as a dependency.
However, when I installed those packages in a local apt repository and
upgraded a VM that tracks that repository, it turns out that doesn't
actually work.

If cross-architecture dependencies are allowed in the archive (and don't
break dak or britney) these days, then it's easy:

Package: libnss-mdns
Architecture: any
Multi-Arch: same

Package: lib32nss-mdns
Architecture: amd64
Depends: libnss-mdns:i386 (= ${binary:Version})
Description: ... transitional package ...

I thought I remembered an announcement that cross-arch dependencies were
OK for jessie, but I couldn't find it, so that might just be wishful
thinking?

The only other option I can think of is to imitate Wine:

Package: libnss-mdns
Architecture: any
Multi-Arch: same

Package: lib32nss-mdns
Architecture: amd64
Depends: libnss-mdns-i386 (= ${binary:Version})
Description: ... transitional package ...

Package: libnss-mdns-i386
Architecture: i386
Depends: libnss-mdns (= ${binary:Version})
Description: ... transitional package ...

but that requires yet another content-free package, and a trip through
the NEW queue. So, before I upload that: is there a better way?

Thanks,
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/5273ac9b.9090...@debian.org

Re: automatically cross-grading lib32nss-mdns to libnss-mdns:i386?

[Dmitrijs Ledkovs]

On 1 November 2013 13:28, Simon McVittie  wrote:
> If cross-architecture dependencies are allowed in the archive (and don't
> break dak or britney) these days, then it's easy:
>
> Package: libnss-mdns
> Architecture: any
> Multi-Arch: same
>
> Package: lib32nss-mdns
> Architecture: amd64
> Depends: libnss-mdns:i386 (= ${binary:Version})
> Description: ... transitional package ...
>
> I thought I remembered an announcement that cross-arch dependencies were
> OK for jessie, but I couldn't find it, so that might just be wishful
> thinking?
>

This one is allowed:
   Depends: python:any

Actually spelling out the arch, is not.


> The only other option I can think of is to imitate Wine:
>
> Package: libnss-mdns
> Architecture: any
> Multi-Arch: same
>
> Package: lib32nss-mdns
> Architecture: amd64
> Depends: libnss-mdns-i386 (= ${binary:Version})
> Description: ... transitional package ...
>
> Package: libnss-mdns-i386
> Architecture: i386
> Depends: libnss-mdns (= ${binary:Version})
> Description: ... transitional package ...
>
> but that requires yet another content-free package, and a trip through
> the NEW queue. So, before I upload that: is there a better way?
>

That's the currently supported way of doing such migration.

Regards,

Dmitrijs.


-- 
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/CANBHLUiOMaGdfTEa0gNJrLmy1aAcw8w3Zc06P83acmbDmN2=n...@mail.gmail.com

RE: Roll call for porters of architectures in sid and testing

[Jurica Stanojkovic]

Hi everyone,

I am part of the group of MIPS porters, and we missed to officially
respond to this email. Here is for the record:

  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the jessie release:

  For MIPS,MIPSEL,MIPS64,MIPS64EL, I
  - can test all packages on this architecture on different hardware
(I have access to different MIPS boards)
  - detect toolchain issues and bring it to the attention of toolchain
maintainers whom we already have contact to,
  - triage arch-specific bugs, see we which issues are MIPS specific
  - fix arch-related bugs
  - maintain build

  In the last three years, I was a MIPS porter of MIPS32 LE and BE, and
  MIPS64 LE and BE.

I am not a DD/DM.


Jurica Stanojkovic


From: Dejan Latinovic
Sent: 01 November 2013 11:17
To: debian-rele...@lists.debian.org
Cc: debian-devel@lists.debian.org; debian-po...@lists.debian.org; 
debian-m...@lists.debian.org; Dragoslav Sicarov; Jurica Stanojkovic; Petar 
Jovanovic
Subject: Re: Roll call for porters of architectures in sid and testing

Hi everyone,

I am part of the group of MIPS porters, and we missed to officially
respond to this email. Here is for the record:

  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the jessie release:

  For MIPS,MIPSEL,MIPS64,MIPS64EL, I
  - can test all packages on this architecture on different hardware
   (I have access to different MIPS boards)
  - detect toolchain issues and bring it to the attention of toolchain
maintainers whom we already have contact to,
  - triage arch-specific bugs, see we which issues are MIPS specific
  - fix arch-related bugs
  - maintain build

  In the last three years, I was a MIPS porter of MIPS32 LE and BE, and
  MIPS64 LE and BE.

  Dejan Latinovic



On 09/01/2013 09:33 AM, Niels Thykier wrote:
> Hi,
>
> As we announced in [LAST-BITS], we would like to get a better idea of
> that status of the ports, to make an informed decision about which
> port can be released with jessie. One of the steps is to get an
> overview of which of the porters are (still) active for each
> port. Once the results from the role-call are in, we will request
> other information about the status of the ports. In the meantime, feel
> free to update and collect info about the ports in the Debian wiki[WIKI].
>
> If you are (or intend to become) an active porter for the lifetime of
> jessie, then please send a signed email explaining your involvement in
> the port to the Release Team  before
> 1st of October 2013. Please explain the level of your involvement in
> the port.
>
> Feel free to use the following template as your reply:
>
> """
>   Hi,
>
>   I am an active porter for the following architectures and I intend
>   to continue this for the lifetime of the jessie release:
>
>   For , I
>   - test (most|all) packages on this architecture
>   - fix toolchain issues
>   - triage arch-specific bugs
>   - fix arch-related bugs
>   - maintain buildds
>   - ...
>
>   
>
>   
> """
>
> Niels, on behalf of the release team
>
> [LAST-BITS] 
> http://lists.debian.org/debian-devel-announce/2013/08/msg6.html
>
> [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie
>
>
>

--
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/a4a4352bed09044db124e2c0d810ce956c9c3...@badag02.ba.imgtec.org

Bug#728458: ITP: libmoox-late-perl -- easily translate Moose code to Moo

[intrigeri]

Package: wnpp
Owner: intrigeri 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmoox-late-perl
  Version : 0.014
  Upstream Author : Toby Inkster 
* URL : https://metacpan.org/release/MooX-late
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : easily translate Moose code to Moo

Moo is a light-weight object oriented programming framework which
aims to be partly compatible with Moose. However, the surface syntax
of Moo differs somewhat from Moose.

MooX::late provides some assistance by enabling a slightly more
Moosey surface syntax. MooX::late makes it easier:

 - to port code that was initially written for Moose to Moo
 - to write Moo code that can later be converted to use the
   full Moose feature-set if needed.


-- 
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/85fvrgw51x@boum.org

Re: .py suffixed scripts to /usr/bin/

[Yaroslav Halchenko]

On Fri, 01 Nov 2013, Paul Wise wrote:
> > So the question is -- is there any other possible resolution I do not
> > see here besides just keeping .py suffixes and providing a lintian
> > override?

> The implementation language is irrelevant to users and thus should not
> be in the names of things in $PATH. We don't suffix binaries compiled
> from C with .c or shell scripts with .sh and python should be no
> different.

concur in general and that is why I am also suggesting such changes
upstream usually.

> The free version is command-line incompatible with the non-free version.

> This leads me to suggest you get upstream to switch to using a suffix
> like -free, -new, -fnme (free NME), -mnet (mne-tools) or prefix like f
> (free). It solves both problems and is really what upstream should
> have been doing from the beginning since .py is hardly the appropriate
> differentiator between the non-free and free versions of the commands.

yeah... upstream was already conscious enough to use a unique prefix
(mne-) and if e.g. it was a pymne project/module, it would have been
logical to just use pymne- prefix.  Since it is call mne-python, having
such a prefix would be way too ugly.

Policy's stand on removing suffixes could also be treated as "they are
irrelevant", and as such it would not matter either suffix is "-new" or
"-py" or ".py" really.

in any case -- upstream seems have liked a 'gateway script' solution:
https://github.com/mne-tools/mne-python/pull/866

-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


-- 
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/20131101150951.gz27...@onerussian.com

Re: .py suffixed scripts to /usr/bin/

[Yaroslav Halchenko]

On Fri, 01 Nov 2013, Charles Plessy wrote:
> I recommend if possible to keep the original upstream name if it has a suffix.
> Not doing so means that Debian becomes incompatible with other systems and 
> with
> the existing documentation.
> > So the question is -- is there any other possible resolution I do not
> > see here besides just keeping .py suffixes and providing a lintian
> > override?
> The solution is to the change Policy :)
> See http://bugs.debian.org/190753 for more discussion.

yeap -- for projects with sufficient legacy stripping the extensions is
hurting more than providing benefits which are pretty much
hypothetical, since extensions are pretty much unused, and in majority
of such cases would never go out of sync with underlying implementation

Well -- after all policy uses "should" and not "must", so indeed
extensionless scripts should be encouraged but do not have to be
strictly enforced.

In this case the project is young enough to not impair too many users by
switching the cmdline interface as they are keen on keeping Debian folks
happy:
https://github.com/mne-tools/mne-python/pull/866
refactor commands/scripts to expose only one named mne

-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


-- 
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/20131101151639.ga27...@onerussian.com

Bug#728465: general: Battery status indicator says "not present"

[Juan M.]

Package: general
Severity: normal

Dear Maintainer,

When I plugged the AC cable, the battery indicator starts working again. But
when I use the notebook only with the battery, it says always "not present".



-- System Information:
Debian Release: 7.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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/20131101155511.5957.94445.reportbug@debian

Bug#728466: ITP: libtypes-path-tiny-perl -- Path::Tiny types and coercions for Moose and Moo

[intrigeri]

Package: wnpp
Owner: intrigeri 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libtypes-path-tiny-perl
  Version : 0.005
  Upstream Author : David Golden 
* URL : https://metacpan.org/release/Types-Path-Tiny
* License : Apache-2.0
  Programming Lang: Perl
  Description : Path::Tiny types and coercions for Moose and Moo

Types::Path::Tiny provides types and coercions useful for dealing
with Path::Tiny objects as Moose or Moo attributes.

It handles two important types of coercion:

 - coercing objects with overloaded stringification;
 - coercing to absolute paths.

It also can check to ensure that files or directories exist.


-- 
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/85vc0cunfg@boum.org

System accounts with valid shells

[Russ Allbery]

(Apologies to Colin and Phillip for the duplicate.  It helps if I send to
the right debian-devel list.)

Hello all,

Debian currently creates most of its system users with a valid shell of
/bin/sh.  I was reminded of this problem by the recent closure of #588367,
and bug #274229 against base-passwd is still open and has been for years.
Phillip rightfully is following the precedent of base-passwd, but I think
this is globally incorrect and should be fixed everywhere.

I realize the theory is that this doesn't matter, since the accounts are
locked in /etc/shadow.  However, there are ways to configure a system
where that may or may not be honored for every possible authentication
path (such as Kerberos authentications where the existence of the account
is checked but the PAM stack is not run, or where /etc/shadow is ignored
in favor of some other data source due to nsswitch configuration).  It
increases the risk that a user may be able to log on to a system account
if there is a conflict between some other source of authentication
information (local Kerberos, LDAP, etc.) and the local /etc/passwd and
/etc/shadow files.

That being said, the *primary* reason that I would like to see this
changed is that the valid shells are an audit finding in literally every
system-level audit that we go through, and every time that happens I have
to explain again why it's probably safe (or diverge from Debian and deal
with prompts every time base-passwd is upgraded).  This is a standard
checkbox on a UNIX system audit, and this default honestly makes Debian
look bad, even if it's a trivial matter.

Even if the risk is low, I see absolutely no reason why these accounts
should have valid shells, and therefore don't understand why we wouldn't
want to just change them to /usr/sbin/nologin.  The local administrator
has other ways of getting a shell with that account by overriding the
shell with su, etc., if they really want to interactively be that user.

Colin, this bug has been dormant for a very long time, and I've previously
pinged it with no response.  Is that just due to lack of time, or were you
not sure whether this should change?  Is this something for which you want
the broader advice of the project or the technical committee?

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87eh70jdg8@windlord.stanford.edu

Bug#728465: general: Battery status indicator says "not present"

[Thomas Goirand]

On 11/01/2013 11:55 PM, Juan M. wrote:
> Package: general
> Severity: normal
> 
> Dear Maintainer,
> 
> When I plugged the AC cable, the battery indicator starts working again. But
> when I use the notebook only with the battery, it says always "not present".

Hi Juan,

You are not giving enough information on this bug report. Where do you
see this? What desktop environment do you use (gnome?)?

Assigning this bug to "general" isn't very helpful.

What is the model of your laptop?

Cheers,

Thomas


-- 
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/5273dbe9.4010...@debian.org

Re: System accounts with valid shells

[Colin Watson]

severity 184979 important
block 274229 by 184979
thanks

On Fri, Nov 01, 2013 at 09:26:15AM -0700, Russ Allbery wrote:
> Even if the risk is low, I see absolutely no reason why these accounts
> should have valid shells, and therefore don't understand why we wouldn't
> want to just change them to /usr/sbin/nologin.  The local administrator
> has other ways of getting a shell with that account by overriding the
> shell with su, etc., if they really want to interactively be that user.
> 
> Colin, this bug has been dormant for a very long time, and I've previously
> pinged it with no response.  Is that just due to lack of time, or were you
> not sure whether this should change?  Is this something for which you want
> the broader advice of the project or the technical committee?

Sorry for not responding to this before (and CCing the bug now so that
this response is recorded properly).  I would like to fix this.  Of
course it needs due care and attention, but I don't think it especially
needs more discussion or broader advice.

However, there's an awkward problem blocking the change, namely #184979.
The last time I made any change to passwd.master or group.master that
caused update-passwd to prompt everyone to accept it was in December
2004.  Since then, the policy manual has been updated to say that all
packages must use debconf for prompting (albeit with an exception for
Essential and transitively-Essential packages, but only in that they may
have a fallback mechanism).  base-passwd is not in compliance with this
policy and it will require an extensive rewrite of update-passwd.c to
make it so.

This is absolutely an important problem and one I regard it as my
responsibility to solve; but, as long as I leave passwd.master and
group.master untouched, it is dormant.  If I change those files before
fixing that bug, however, then I know that I will unnecessarily
introduce problems for at least some of the package management tools
that have been developed on the reasonable Policy-derived assumption
that packages aren't going to do non-debconf-based prompting on upgrade.
For a less critical package, this might be an acceptable trade-off, but
base-passwd is pretty much certain to affect everyone and I don't think
I can justify knowingly introducing this kind of breakage.

I've been promising to fix #184979 for rather a long time now and have
been conspicuously failing to get round to it; from my local tree it
looks like all I ever managed to do was put together some template text.
Partially-working patches stand a good chance of getting me to debug
them into a more complete state, so I'd be glad of even incomplete
patches towards this.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
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/20131101180411.gc16...@riva.ucam.org

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Kevin Chadwick]

previously on this list Ben Hutchings contributed:

> > > In other words, Canonical gets the right to take a free software
> > > contribution and make it proprietary. The contributors gets to own the
> > > software, and can continue releasing it as free software, but can't
> > > prevent Canonical from making non-free versions of it. I don't find
> > > that an acceptable situation.  
> > 
> > But I saw today that this paragraph goes on with:
> > 
> > As a condition on the exercise of this right, We agree to also
> > license the Contribution under the terms of the license or
> > licenses which We are using for the Material on the Submission
> > Date.
> > 
> > My understanding (as a non-expert on legalese en_*) is, that Canonical
> > would only be allowed to re-license the Contribution under a
> > dual-license scheme, with (a) the original license, and (b)
> > $whatever-they-want.  
> [...]
> 
> Yes, but that says nothing about the rest of the program that it's a
> part of, nor that they will continue to distribute the Contribution.
> Since the contributor, retaining copyright, can give that license to
> anyone anyway, this condition doesn't appear to have any meaningful
> effect.
> 
> Ben.

I don't see why this should affect the decision at all personally
especially far less than less co-operative upstreams though perhaps a
pure BSD license could be seen as a free-er plus point.

It basically means they have reserved the right that they may never
use but put in jut in case likely for other projects to stop
contributing or publishing the source of their work to the project but
continue to use the communities past work.

The community could even then decide that just canonical was not
allowed to use any of their changes from then on whilst still
benefiting from Canonical's past work.

At the end of the day whatever increases the chance of code being done
for good reasons and the good of the community is what is important
and forcing publication may?? help twist the arms of the less important
contributors but also hinders that likelihood in reduced initial
take up anyway possibly including partial release.

Apache's BSD based and Googles BSD based licenses and many others would
all allow this, what has been and is going to be contributed in a
constructive and forth coming way for the good of all is what is
important.


-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
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/304170.20633...@smtp139.mail.ir2.yahoo.com

Re: System accounts with valid shells

[Russ Allbery]

Colin Watson  writes:

> However, there's an awkward problem blocking the change, namely #184979.
> The last time I made any change to passwd.master or group.master that
> caused update-passwd to prompt everyone to accept it was in December
> 2004.  Since then, the policy manual has been updated to say that all
> packages must use debconf for prompting (albeit with an exception for
> Essential and transitively-Essential packages, but only in that they may
> have a fallback mechanism).  base-passwd is not in compliance with this
> policy and it will require an extensive rewrite of update-passwd.c to
> make it so.

Ah!  Thank you.  I hadn't realized this was the issue.

I assume that would mean that update-passwd would need to become a client
of the libdebconfclient0 library?

Phillip, given the above background, would you be willing to modify the
libuuid package to use /bin/false or /usr/sbin/nologin instead of /bin/sh
for the shell for the libuuid user?  That package doesn't have the same
issues that base-passwd has.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87mwlnhpsp@windlord.stanford.edu

Re: Bug#274229: System accounts with valid shells

[Colin Watson]

On Fri, Nov 01, 2013 at 12:42:30PM -0700, Russ Allbery wrote:
> Colin Watson  writes:
> > However, there's an awkward problem blocking the change, namely #184979.
> > The last time I made any change to passwd.master or group.master that
> > caused update-passwd to prompt everyone to accept it was in December
> > 2004.  Since then, the policy manual has been updated to say that all
> > packages must use debconf for prompting (albeit with an exception for
> > Essential and transitively-Essential packages, but only in that they may
> > have a fallback mechanism).  base-passwd is not in compliance with this
> > policy and it will require an extensive rewrite of update-passwd.c to
> > make it so.
> 
> Ah!  Thank you.  I hadn't realized this was the issue.

I've been terrible at communicating it, so no wonder :-)

> I assume that would mean that update-passwd would need to become a client
> of the libdebconfclient0 library?

That was my thought, yes.  There are probably other ways to do it, but I
think pulling libdebconfclient0 into transitively-Essential is
reasonable at this point (given that it aligns with the long-term plans
for debconf), and is likely to be the simplest change.

> Phillip, given the above background, would you be willing to modify the
> libuuid package to use /bin/false or /usr/sbin/nologin instead of /bin/sh
> for the shell for the libuuid user?  That package doesn't have the same
> issues that base-passwd has.

Right, no reason to couple these.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
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/20131101202040.gd16...@riva.ucam.org

Re: System accounts with valid shells

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

reopen 274229
thanks

On 11/1/2013 3:42 PM, Russ Allbery wrote:
> Phillip, given the above background, would you be willing to modify
> the libuuid package to use /bin/false or /usr/sbin/nologin instead
> of /bin/sh for the shell for the libuuid user?  That package
> doesn't have the same issues that base-passwd has.

Sure.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSdBAkAAoJEJrBOlT6nu75z8QIAIIusuDVCuNqIL5CcS3T83kU
O8sUGe9i4Xqgah4SiKxqjIRA7Km7ZjUGIJsE/YP/aSxXKXBUMJ5olq0xiHHdh7n8
hrqfvF9rrxrGL1LKFjdFp2esIOz2gQATbN/D4WpCh4JDlgYcTmysB2yGGIvjFsWV
aNcFFpHJUAdT5SyPL3ApznzksyedXfF44bsuAx9mif1EF0bhRgB/b3NwBGQoenAq
R6QXBuf0XLSAFrt33xUjClAIev9P5bXSRAjGjrj8lRLzarG/2KZFvQMGXTEG6Imc
GleqNgGJ/OGirL8i/o3fF9UutHpGsNhR3V3Z4eX2admycWrX6IIlA6PzoEvhcXU=
=Vhfh
-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/52741024.9050...@ubuntu.com

Re: automatically cross-grading lib32nss-mdns to libnss-mdns:i386?

[Paul Wise]

On Fri, Nov 1, 2013 at 9:28 PM, Simon McVittie wrote:

> I thought I remembered an announcement that cross-arch dependencies were
> OK for jessie, but I couldn't find it, so that might just be wishful
> thinking?

The cross-compilers built by [1] need them so I guess we need them
before [2] can be implemented.

1. https://wiki.debian.org/MultiarchCrossToolchainBuild
2. https://wiki.debian.org/ReleaseGoals/CrossToolchains

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6g-nizikj34p6gdq0f+brisdeox48c+uhmtb44c6ds...@mail.gmail.com

Re: .py suffixed scripts to /usr/bin/

[Paul Wise]

On Fri, Nov 1, 2013 at 11:09 PM, Yaroslav Halchenko wrote:

> in any case -- upstream seems have liked a 'gateway script' solution:
> https://github.com/mne-tools/mne-python/pull/866

Sounds like a better solution anyway, thanks.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6ggsojeox1h6y63v7m2ctchyor8yctdfrefrvnkswt...@mail.gmail.com