Bug#679739: RFS: ia32-libs/20120701 [RC]

2012-07-01 Thread Goswin von Brederlow 
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "ia32-libs":

 Package name: ia32-libs
 Version : 20120701
 Upstream Author : Goswin von Brederlow 
 URL : NA
 License : GPL
 Section : oldlibs

It builds those binary packages:

  ia32-libs  - Transitional package to migrate ia32-libs to multiarch
  ia32-libs-i386 - Transitional package to migrate ia32-libs to multiarch

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/ia32-libs


Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/i/ia32-libs/ia32-libs_20120701.dsc

More information about hello can be obtained from http://bugs.debian.org/679671

Changes since the last upload:

  * Drop dependency on removed libdb4.8 [ROM] (Closes: #679671)

Regards,
Goswin

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120701091227.20738.73917.reportbug@frosties.localnet

Moving /home of a package account, and to where?

2012-07-01 Thread Marc Haber 
Hi,

Debian QA decided recently that it is bad to have a system/package
account created with its home directory in /home/package, as it is
adduser --system's default btw. I am therefore faced with having to
change /home to some non-/home place. Unfortunately, policy does not
give any hint about how to do it right.

Where do I put my user's home directory? In this case, the user's home
directory contains a .ssh with known_hosts, authorized_keys and actual
keys and it might additionally accumulate some regular dotfiles.

(1)
Which is the correct place for a user's home dir?

/etc/ or /etc//home
  - surprise for a seasoned admin
  - might create QA bugs regarding "package does not properly clean up
after itself"
  - might create dpkg-conffile hassle for files that are bound to
automatically change during operation, such as known_hosts

/var/lib/
  - impossible to use ("users must never need to modify files in
/var/lib to configure a package's operation", FHS)

/var/cache/ / /var/spool
  - inapprorpiate via FHS

/var/run
  - inappropriate as /var/run is cleared during boot


So, /etc looks like the only feasible way for a package that needs
configuration files in its users' home directory. Is that the case or
am I missing things?


For a package that has never been part of a Debian stable release, it
is ok to just change the home directory in the maintainer script,
causing existing installations (5, regarding to popcon) to still use
the old, "inappropriate" location (with a NEWS.Debian suggesting a
manual change), or do I _really_ need to prompt the user whether he
wants his old data to be moved, forcing me to handle gazillions of
translation and debconf-related bugs?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701104448.ge25...@torres.zugschlus.de

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Roger Leigh 
On Sun, Jul 01, 2012 at 12:44:48PM +0200, Marc Haber wrote:
> Hi,
> 
> Debian QA decided recently that it is bad to have a system/package
> account created with its home directory in /home/package, as it is
> adduser --system's default btw. I am therefore faced with having to
> change /home to some non-/home place. Unfortunately, policy does not
> give any hint about how to do it right.
> 
> Where do I put my user's home directory? In this case, the user's home
> directory contains a .ssh with known_hosts, authorized_keys and actual
> keys and it might additionally accumulate some regular dotfiles.

I'd go with /var/lib, which is what most packages do.  I don't count
the user-specific stuff to be package configuration, in general.

% getent passwd | grep /var/lib
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
statd:x:102:65534::/var/lib/nfs:/bin/false
dictd:x:107:114:Dictd Server,,,:/var/lib/dictd:/bin/false
postgres:x:111:121:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
sbuild:x:115:124:Debian source builder,,,:/var/lib/sbuild:/bin/bash
buildd:x:116:125:Debian build daemon,,,:/var/lib/buildd:/bin/bash
ntop:x:118:128::/var/lib/ntop:/bin/false
Debian-gdm:x:120:132:Gnome Display Manager:/var/lib/gdm3:/bin/false
colord:x:123:135:colord colour management daemon,,,:/var/lib/colord:/bin/false


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701120417.gp9...@codelibre.net

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Goswin von Brederlow 
Marc Haber  writes:

> Hi,
>
> Debian QA decided recently that it is bad to have a system/package
> account created with its home directory in /home/package, as it is
> adduser --system's default btw. I am therefore faced with having to
> change /home to some non-/home place. Unfortunately, policy does not
> give any hint about how to do it right.
>
> Where do I put my user's home directory? In this case, the user's home
> directory contains a .ssh with known_hosts, authorized_keys and actual
> keys and it might additionally accumulate some regular dotfiles.
>
> (1)
> Which is the correct place for a user's home dir?
>
> /etc/ or /etc//home
>   - surprise for a seasoned admin
>   - might create QA bugs regarding "package does not properly clean up
> after itself"
>   - might create dpkg-conffile hassle for files that are bound to
> automatically change during operation, such as known_hosts

That would be not only confusing but also problematic since /etc is
(potentially) read-only. No automatically changing files allowed there.

> /var/lib/
>   - impossible to use ("users must never need to modify files in
> /var/lib to configure a package's operation", FHS)
>
> /var/cache/ / /var/spool
>   - inapprorpiate via FHS

Iirc /var/cache might be cleared by the admin and what you talk about
certainly isn't spool material.

> /var/run
>   - inappropriate as /var/run is cleared during boot

As you say. :)

> So, /etc looks like the only feasible way for a package that needs
> configuration files in its users' home directory. Is that the case or
> am I missing things?

If you need configuration files (which the user is supposed to edit as
supposed to calling some config tool) in the users home directory and
also automatically changing files then I'm afraid you will need to use
both /etc and /var/lib and symlinks.

Maybe think about patching the source so that it reads a system wide
file as well as a users file. Then you can have the conffiles in /etc
(for debian packages) or in ~/ (for upstream or local installs). Just
like there is /etc/bash.bashrc and ~/.bashrc.

> For a package that has never been part of a Debian stable release, it
> is ok to just change the home directory in the maintainer script,
> causing existing installations (5, regarding to popcon) to still use
> the old, "inappropriate" location (with a NEWS.Debian suggesting a
> manual change), or do I _really_ need to prompt the user whether he
> wants his old data to be moved, forcing me to handle gazillions of
> translation and debconf-related bugs?
>
> Greetings
> Marc

MfG Goswin


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3ynbq2n.fsf@frosties.localnet

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Marc Haber 
On Sun, Jul 01, 2012 at 01:04:17PM +0100, Roger Leigh wrote:
> On Sun, Jul 01, 2012 at 12:44:48PM +0200, Marc Haber wrote:
> > Debian QA decided recently that it is bad to have a system/package
> > account created with its home directory in /home/package, as it is
> > adduser --system's default btw. I am therefore faced with having to
> > change /home to some non-/home place. Unfortunately, policy does not
> > give any hint about how to do it right.
> > 
> > Where do I put my user's home directory? In this case, the user's home
> > directory contains a .ssh with known_hosts, authorized_keys and actual
> > keys and it might additionally accumulate some regular dotfiles.
> 
> I'd go with /var/lib, which is what most packages do.  I don't count
> the user-specific stuff to be package configuration, in general.

.ssh is used to log in to another system running my package, it holds
manually created authorized_keys and keys. I'd call that configuration.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701125613.gf25...@torres.zugschlus.de

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Marc Haber 
On Sun, Jul 01, 2012 at 02:53:20PM +0200, Goswin von Brederlow wrote:
> If you need configuration files (which the user is supposed to edit as
> supposed to calling some config tool) in the users home directory and
> also automatically changing files then I'm afraid you will need to use
> both /etc and /var/lib and symlinks.

sshd won't honor a symlinked authorized_keys, would it?

> Maybe think about patching the source so that it reads a system wide
> file as well as a users file.

sshd???

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701125752.gg25...@torres.zugschlus.de

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Roger Leigh 
On Sun, Jul 01, 2012 at 02:56:13PM +0200, Marc Haber wrote:
> On Sun, Jul 01, 2012 at 01:04:17PM +0100, Roger Leigh wrote:
> > On Sun, Jul 01, 2012 at 12:44:48PM +0200, Marc Haber wrote:
> > > Debian QA decided recently that it is bad to have a system/package
> > > account created with its home directory in /home/package, as it is
> > > adduser --system's default btw. I am therefore faced with having to
> > > change /home to some non-/home place. Unfortunately, policy does not
> > > give any hint about how to do it right.
> > > 
> > > Where do I put my user's home directory? In this case, the user's home
> > > directory contains a .ssh with known_hosts, authorized_keys and actual
> > > keys and it might additionally accumulate some regular dotfiles.
> > 
> > I'd go with /var/lib, which is what most packages do.  I don't count
> > the user-specific stuff to be package configuration, in general.
> 
> .ssh is used to log in to another system running my package, it holds
> manually created authorized_keys and keys. I'd call that configuration.

Yes, but it's user configuration not system configuration.
If you do want to have that as configuration in /etc, I'd
suggest symlinking it from /var/lib/foo to /etc/foo/authorized_keys
(or vice versa), like e.g. postgresql handles cluster configuration.

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701132905.gq9...@codelibre.net

Proper upgrade path for lib32v4l-{0,dev}?

2012-07-01 Thread Gregor Jasny 

Hello,

currently my source package v4l-utils builds lib32v4l-0 and lib32v4l-dev 
packages on amd64. I'd like to get rid of them sooner than later and 
provide a proper upgrade path to multiarch packages. What's the best way 
to achieve this?


As far as I can see this always involves manual action due to the 
required addition of the foreign i386 architecture.


So should I simply drop the lib32 packages? The only dependent users of 
these packages are Skype and Google talk plugin users. They usually 
preload the libs via LD_PRELOAD. Due to the changed library paths when 
migrating from lib32 packages to multiarch they need to perform manual 
actions anyway.


Or should I change the packages from:

Package: lib32v4l-0
Section: libs
Architecture: amd64
Depends: libv4l-0 (= ${binary:Version}),
 ${shlibs:Depends},
 ${misc:Depends}

to virtual transition packages:

Package: lib32v4l-0
Section: libs
Architecture: i386
Pre-Depends: multiarch-support
Depends: libv4l-0 (= ${binary:Version}),
 ${misc:Depends}

Thanks for your help,
Gregor


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff05907.3090...@googlemail.com

Bug#679785: RFS: vorbisgain/0.37-2 -- add Replay Gain volume tags to Ogg Vorbis files

2012-07-01 Thread Daniel Martí 
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "vorbisgain"

 * Package name: vorbisgain
   Version : 0.37-2
   Upstream Author : Gian-Carlo Pascutto 
 * URL : http://sjeng.org/vorbisgain.html
 * License : LGPL-2+
   Section : sound

It builds those binary packages:

  vorbisgain - add Replay Gain volume tags to Ogg Vorbis files

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/vorbisgain

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/v/vorbisgain/vorbisgain_0.37-2.dsc

Changes since the last upload:

  * Updated maintainer's info
  * debian/patches
- 0001-temp_files.patch re-adds X's in mktemp() (Closes: #676926)
- 0009-hardening.patch added to solve an issue with debian's build flags.
  + Bumped debhelper compat level to 9
  + Solved lintian complaints on hardening
- 0010-fclose.patch added (Closes: #488126). Thanks to Marcel Rehberg for
  the patch.
  * debian/rules
- Fixed lintian hardening complaints by adding the Debian build flags.

Regards,
-- 
Daniel Martí - mv...@mvdan.cc - GPG 0x58BF72C3


pgpo53gpW3Dai.pgp
Description: PGP signature

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Marc Haber 
On Sun, Jul 01, 2012 at 02:29:05PM +0100, Roger Leigh wrote:
> On Sun, Jul 01, 2012 at 02:56:13PM +0200, Marc Haber wrote:
> > On Sun, Jul 01, 2012 at 01:04:17PM +0100, Roger Leigh wrote:
> > > On Sun, Jul 01, 2012 at 12:44:48PM +0200, Marc Haber wrote:
> > > > Debian QA decided recently that it is bad to have a system/package
> > > > account created with its home directory in /home/package, as it is
> > > > adduser --system's default btw. I am therefore faced with having to
> > > > change /home to some non-/home place. Unfortunately, policy does not
> > > > give any hint about how to do it right.
> > > > 
> > > > Where do I put my user's home directory? In this case, the user's home
> > > > directory contains a .ssh with known_hosts, authorized_keys and actual
> > > > keys and it might additionally accumulate some regular dotfiles.
> > > 
> > > I'd go with /var/lib, which is what most packages do.  I don't count
> > > the user-specific stuff to be package configuration, in general.
> > 
> > .ssh is used to log in to another system running my package, it holds
> > manually created authorized_keys and keys. I'd call that configuration.
> 
> Yes, but it's user configuration not system configuration.

A system user's .ssh is user configuration?

> If you do want to have that as configuration in /etc, I'd
> suggest symlinking it from /var/lib/foo to /etc/foo/authorized_keys
> (or vice versa), like e.g. postgresql handles cluster configuration.

Can you give a more visible example? Should /etc/foo/authorized_keys
be a symlink to /var/lib/foo/home/.ssh/authorized_keys? I don't think
that circumvents the FHS forbidding configuration in /var/lib just by
making it accessible through /etc.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701151308.gj25...@torres.zugschlus.de

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Henrique de Moraes Holschuh 
On Sun, 01 Jul 2012, Marc Haber wrote:
> > Yes, but it's user configuration not system configuration.
> 
> A system user's .ssh is user configuration?

If it is intended to be manipulated by the local admin, yes, and it would
belong in /etc somewhere.

> > If you do want to have that as configuration in /etc, I'd
> > suggest symlinking it from /var/lib/foo to /etc/foo/authorized_keys
> > (or vice versa), like e.g. postgresql handles cluster configuration.
> 
> Can you give a more visible example? Should /etc/foo/authorized_keys
> be a symlink to /var/lib/foo/home/.ssh/authorized_keys? I don't think
> that circumvents the FHS forbidding configuration in /var/lib just by
> making it accessible through /etc.

No.  The real file goes in /etc, the symlink goes in /var/lib.  But you may
need very tight permissions in the directory that hosts these to have sshd
tolerate it, if it will work at all.

-- 
  "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-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701153641.gg2...@khazad-dum.debian.net

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Marc Haber 
On Sun, Jul 01, 2012 at 12:36:41PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 01 Jul 2012, Marc Haber wrote:
> > > Yes, but it's user configuration not system configuration.
> > 
> > A system user's .ssh is user configuration?
> 
> If it is intended to be manipulated by the local admin, yes, and it would
> belong in /etc somewhere.

I would call that system configuration.

> > > If you do want to have that as configuration in /etc, I'd
> > > suggest symlinking it from /var/lib/foo to /etc/foo/authorized_keys
> > > (or vice versa), like e.g. postgresql handles cluster configuration.
> > 
> > Can you give a more visible example? Should /etc/foo/authorized_keys
> > be a symlink to /var/lib/foo/home/.ssh/authorized_keys? I don't think
> > that circumvents the FHS forbidding configuration in /var/lib just by
> > making it accessible through /etc.
> 
> No.  The real file goes in /etc, the symlink goes in /var/lib.  But you may
> need very tight permissions in the directory that hosts these to have sshd
> tolerate it, if it will work at all.

Does sshd honor symlinks when looking for authorized_keys? I am really
really astonished about with which ease we hurl RC bugs at packages
without having thought-out alternatives.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701160358.gk25...@torres.zugschlus.de

Bug#678836: Package qpdfview

2012-07-01 Thread Benjamin Eltzner 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

after the issue has been resolved with upstream, I uploaded a package
of the most recent version of qpdfview to mentors. As usual it is
available at

http://mentors.debian.net/package/qpdfview

I hope this resolves the issues and I would be glad if the package
could be uploaded into unstable.

Regards,

Benjamin Eltzner

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP8HpqAAoJEK27BRz67lmpNasP/2mQ55K8r/MEgD5XQumUlIlf
iS3nlLbx5vtz6cGDIieXZNMc18O9stYyZVwFeWF6vPSSgifLsHup/uDz1/bDiwhv
QOoO9w8dp6KprTlcgWwUrdLHI94lcLlqrhHSBWj6H+A4XMAdD8wyFSJ2sbGPNnaV
6DrQYqWLXUdllPTFIusArkw5oBB9fJZl0lHCbZQs4OJAQEluim0z8LfZCW/VP5at
1pxMNplYwQ2fY3bJDqMCDz9mK3+4fvykv/ZaaJ8rZVvqV+5Y8u4xgLC7Ilcqebbn
8tAW3pZSVjTtsLyxiE4qqKEYTYum10DJXzD91aM/jsdY07kDcPWr6joLrXDfcIX5
3ce5zDP6Mcqfp5BNr6XPGfCVlxNjULgrZ7s2pMIe+ZHgytF59g93J5lDHd0QiZaZ
2FzNm1Pcv624dYlzTlgfU5nG0PDJbhCpvdc9oyRorvbJMezIcWgfBJzA1OGNGvx7
PV5qkHxwE+SGY2Z1naq7VP4muKT/iR1AKMOEjQKgxsuzpD/9+oixEd8F3S5h7AvH
h3JgUEFsBPx01ydc9qV45FWFOQBgPr0Gyb6SoZgF1xznljAuCHt9azczyBNEvtaC
ZdUwgU2dPnvUHak87GODy7+FQSpiiqZdpwa61mN2aQzcDIRlFx6Yv1g+3f/pis+z
PAnrfCM8XIU/SribyTQg
=kKCw
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff07a6b.4070...@gmx.de

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Henrique de Moraes Holschuh 
On Sun, 01 Jul 2012, Marc Haber wrote:
> On Sun, Jul 01, 2012 at 12:36:41PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 01 Jul 2012, Marc Haber wrote:
> > > > Yes, but it's user configuration not system configuration.
> > > 
> > > A system user's .ssh is user configuration?
> > 
> > If it is intended to be manipulated by the local admin, yes, and it would
> > belong in /etc somewhere.
> 
> I would call that system configuration.

I suppose, since it is system-wide.

> > No.  The real file goes in /etc, the symlink goes in /var/lib.  But you may
> > need very tight permissions in the directory that hosts these to have sshd
> > tolerate it, if it will work at all.
> 
> Does sshd honor symlinks when looking for authorized_keys? I am really

Test it.

> really astonished about with which ease we hurl RC bugs at packages
> without having thought-out alternatives.

Sometimes you *really* have to do some heavy work to get something to
actually work sanely.  I've had to actually enhance upstream C code to
get it to be able to do things in a way that makes it easier to properly
package it.  Had to do it for fetchmail, Cyrus IMAPd, amavisd-new...

This is the Debian added-value.  We do what it takes to make it sane.

-- 
  "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-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701171023.gh2...@khazad-dum.debian.net

Bug#676722: RFS: ruby-kyotocabinet/1.32-1 [ITP] -- DBM-Ruby bindings

2012-07-01 Thread Bart Martens 
Hello Shawn,

I don't see ruby-kyotocabinet at mentors.  What happened ?

Regards,

Bart Martens



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

Bug#676722: RFS: ruby-kyotocabinet/1.32-1 [ITP] -- DBM-Ruby bindings

2012-07-01 Thread shawn 
On Sun, 2012-07-01 at 18:40 +, Bart Martens wrote: 
> Hello Shawn,
> 
> I don't see ruby-kyotocabinet at mentors.  What happened ?
> 
> Regards,
> 
> Bart Martens

After kyotocabinet got uploaded to unstable with an out-of-date version
I was worried that old versions (of same version number) are
downloadable even after reuploading them with dput -f, so I removed the
package before reuploading. However it seems that it also didn't post
the upload that I did make after deleting the package (!). I just
uploaded it yet again (and it required a -f) so hopefully that will
fix it.

Ruby-kyotocabinet is also available in pkg-ruby-extras on alioth now
http://git.debian.org/?p=pkg-ruby-extras/ruby-kyotocabinet.git;a=summary

(which is in the control file)


also, make note that because #679683 this package will not build against
libkyotocabinet-dev 1.2.76-1 (but it will against the -2 I have uploaded
to mentors)

-- 
-Shawn Landden




-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1341168658.3130.269.camel@shawn-ssd

Bug#676722: RFS: ruby-kyotocabinet/1.32-1 [ITP] -- DBM-Ruby bindings

2012-07-01 Thread shawn 
On Sun, 2012-07-01 at 18:40 +, Bart Martens wrote: 
> Hello Shawn,
> 
> I don't see ruby-kyotocabinet at mentors.  What happened ?
> 
> Regards,
> 
> Bart Martens

Yeah I must have forgot to re-upload

http://mentors.debian.net/package/ruby-kyotocabinet

-- 
-Shawn Landden




-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1341168747.3130.270.camel@shawn-ssd

Bug#676722: RFS: ruby-kyotocabinet/1.32-1 [ITP] -- DBM-Ruby bindings

2012-07-01 Thread Bart Martens 
On Sun, Jul 01, 2012 at 11:50:58AM -0700, shawn wrote:
> After kyotocabinet got uploaded to unstable with an out-of-date version
> I was worried that old versions (of same version number) are
> downloadable even after reuploading them with dput -f, so I removed the
> package before reuploading. However it seems that it also didn't post
> the upload that I did make after deleting the package (!). I just
> uploaded it yet again (and it required a -f) so hopefully that will
> fix it.
> 
> Ruby-kyotocabinet is also available in pkg-ruby-extras on alioth now
> http://git.debian.org/?p=pkg-ruby-extras/ruby-kyotocabinet.git;a=summary
> 
> (which is in the control file)
> 
> 
> also, make note that because #679683 this package will not build against
> libkyotocabinet-dev 1.2.76-1 (but it will against the -2 I have uploaded
> to mentors)

Do you mean that kyotocabinet must be sponsored before ruby-kyotocabinet ?
http://mentors.debian.net/package/kyotocabinet
http://mentors.debian.net/package/ruby-kyotocabinet

Regards,

Bart Martens



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

Bug#676722: RFS: ruby-kyotocabinet/1.32-1 [ITP] -- DBM-Ruby bindings

2012-07-01 Thread shawn 
On Sun, 2012-07-01 at 19:09 +, Bart Martens wrote: 
> On Sun, Jul 01, 2012 at 11:50:58AM -0700, shawn wrote:
> > also, make note that because #679683 this package will not build against
> > libkyotocabinet-dev 1.2.76-1 (but it will against the -2 I have uploaded
> > to mentors)
> 
> Do you mean that kyotocabinet must be sponsored before ruby-kyotocabinet ?
> http://mentors.debian.net/package/kyotocabinet
> http://mentors.debian.net/package/ruby-kyotocabinet

Well, ruby-kyotocabinet will not build until the -2 version of
kyotocabinet gets sponsored, but I don't think that should hold back
ruby-kyotocabinet getting sponsored. Its a bug in kyotocabinet, not
ruby-kyotocabinet, and the bug will presumably be fixed, or otherwise
kyotocabinet would have to be removed from the archive (which I would
certainly hope is unlikely) 
> 
> Regards,
> 
> Bart Martens


-- 
-Shawn Landden




-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1341170125.3130.273.camel@shawn-ssd

Bug#676722: RFS: ruby-kyotocabinet/1.32-1 [ITP] -- DBM-Ruby bindings

2012-07-01 Thread shawn 
On Sun, 2012-07-01 at 19:09 +, Bart Martens wrote: 
> On Sun, Jul 01, 2012 at 11:50:58AM -0700, shawn wrote:
> > also, make note that because #679683 this package will not build against
> > libkyotocabinet-dev 1.2.76-1 (but it will against the -2 I have uploaded
> > to mentors)
> 
> Do you mean that kyotocabinet must be sponsored before ruby-kyotocabinet ?
> http://mentors.debian.net/package/kyotocabinet
> http://mentors.debian.net/package/ruby-kyotocabinet

Note also, that I am the maintainer of kyotocabinet. I am just not a
Debian developer so am using the mentorship process. Sylvestre Ledru
 sponsored 1.2.76-1, and I initially had -2 set
"sponsor needed: no", but then set it to "yes", after realizing that the
-1 version of the package is not in a very good state. If I should keep
it at "no" and expect Slyvestre to stay my mentor, I can do that.

-- 
-Shawn Landden




-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1341170367.3130.277.camel@shawn-ssd

Processed: retitle to RFS: qpdfview/0.3.1-1

2012-07-01 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> retitle 678836 RFS: qpdfview/0.3.1-1
Bug #678836 [sponsorship-requests] RFS: qpdfview/0.3-1
Changed Bug title to 'RFS: qpdfview/0.3.1-1' from 'RFS: qpdfview/0.3-1'
> stop
Stopping processing here.

Please contact me if you need assistance.
-- 
678836: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678836
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.134117047012858.transcr...@bugs.debian.org

Bug#679820: RFS: rubybook [ITA] -- "Programming Ruby" book

2012-07-01 Thread Γεώργιος Μ . Ζαρκάδας 
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "rubybook":

dget -x
http://mentors.debian.net/debian/pool/non-free/r/rubybook/rubybook_0.2.1-2.dsc

It builds these binary packages:

  rubybook - "Programming Ruby" book

Changes since the last upload:

rubybook (0.2.1-2) unstable; urgency=low

  * New maintainer (Closes: #677789).
  * Fix typo in debian/copyright (Closes: #421069).
  * Update the book's url in README.Debian (Closes: #475491).
  * Change source format to 3.0 (quilt) and update debian/rules 
and debian/compat accordingly.
  * Update debian/copyright.
  * Update description to fix a lintian warning.
  * Fix all other lintian warnings.

 -- Georgios M. Zarkadas   Sat, 30 Jun 2012 11:26:30 +0300

regards
George Zarkadas



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701192936.ga10...@freedom.lan

Re: Proper upgrade path for lib32v4l-{0,dev}?

2012-07-01 Thread Sven Joachim 
[ CC'ing ia32-libs maintainers for their opinion. ]

On 2012-07-01 16:04 +0200, Gregor Jasny wrote:

> Hello,
>
> currently my source package v4l-utils builds lib32v4l-0 and
> lib32v4l-dev packages on amd64. I'd like to get rid of them sooner
> than later and provide a proper upgrade path to multiarch
> packages. What's the best way to achieve this?

Getting rid of reverse dependencies so these packages can be removed as
unused, I think.

> As far as I can see this always involves manual action due to the
> required addition of the foreign i386 architecture.

Correct, but the same is true for ia32-libs which is usually the reason
why people install lib32v4l-0.

> So should I simply drop the lib32 packages? The only dependent users
> of these packages are Skype and Google talk plugin users. They usually
> preload the libs via LD_PRELOAD. Due to the changed library paths when
> migrating from lib32 packages to multiarch they need to perform manual
> actions anyway.
>
> Or should I change the packages from:
>
> Package: lib32v4l-0
> Section: libs
> Architecture: amd64
> Depends: libv4l-0 (= ${binary:Version}),
>  ${shlibs:Depends},
>  ${misc:Depends}
>
> to virtual transition packages:
>
> Package: lib32v4l-0
> Section: libs
> Architecture: i386
> Pre-Depends: multiarch-support
> Depends: libv4l-0 (= ${binary:Version}),
>  ${misc:Depends}

The Pre-Depends: multiarch-support is not necessary, but you would need
to mark lib32v4l-0 as "Multi-Arch: foreign".

However, since lib32v4l-0 is usually installed because ia32-libs depends
on it, and the skype-debian_4.0.0.7-1_amd64.deb package I downloaded
from Skype's website depends on ia32-libs but not lib32v4l-0: maybe a
better upgrade path would be given by letting ia32-libs-i386 depend on
libv4l-0?

The ia32-libs-i386 package depends on all libraries formerly included in
ia32-libs (well, as far as they are still available), but not on the
i386 counterparts of the various lib32* packages ia32-libs depended
upon.  This seems like a bug to me.

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874npri73b@turtle.gmx.de

Re: Proper upgrade path for lib32v4l-{0,dev}?

2012-07-01 Thread Gregor Jasny 

Hello,

On 7/1/12 10:01 PM, Sven Joachim wrote:
> [ CC'ing ia32-libs maintainers for their opinion. ]

Is the 20120616 or 20120701 version of ia32-libs supposed to go into Wheezy?


On 2012-07-01 16:04 +0200, Gregor Jasny wrote:

currently my source package v4l-utils builds lib32v4l-0 and
lib32v4l-dev packages on amd64. I'd like to get rid of them sooner
than later and provide a proper upgrade path to multiarch
packages. What's the best way to achieve this?


Getting rid of reverse dependencies so these packages can be removed as
unused, I think.


The 'fat' ia32-libs was the last dependency. According to apt-cache 
rdepends nothing depends on lib32v4l* anymore.



Or should I change the packages from:

Package: lib32v4l-0
Section: libs
Architecture: amd64
Depends: libv4l-0 (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}

to virtual transition packages:

Package: lib32v4l-0
Section: oldlibs
Architecture: i386
Pre-Depends: multiarch-support
Depends: libv4l-0 (= ${binary:Version}),
  ${misc:Depends}


The Pre-Depends: multiarch-support is not necessary, but you would need
to mark lib32v4l-0 as "Multi-Arch: foreign".


So it would read:

Package: lib32v4l-0
Section: oldlibs
Architecture: i386
Multi-Arch: foreign
Depends: libv4l-0 (= ${binary:Version}),
 ${misc:Depends}


However, since lib32v4l-0 is usually installed because ia32-libs depends
on it, and the skype-debian_4.0.0.7-1_amd64.deb package I downloaded
from Skype's website depends on ia32-libs but not lib32v4l-0: maybe a
better upgrade path would be given by letting ia32-libs-i386 depend on
libv4l-0?

The ia32-libs-i386 package depends on all libraries formerly included in
ia32-libs (well, as far as they are still available), but not on the
i386 counterparts of the various lib32* packages ia32-libs depended
upon.  This seems like a bug to me.


I suppose lib32v4l was only pulled into ia32-libs due to being a 
gstreamer dependency. And libv4l isn't necessary to run Skype on most 
systems. You'd only need it if our camera supports just non-YUV/RGB 
output formats or is built in upside down like on most ASUS notebooks.
In both cases one has to do the LD_PRELOAD trick (with changed preload 
paths for multiarch).


So to me the most appealing solution would be to drop the lib32v4l 
packages altogether and let those users that need the conversion install 
and configure these packages by hand.


Thanks,
Gregor


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff0b2b6.2040...@googlemail.com

Processed: RFS: rubybook/0.2.1-2 [ITA] -- "Programming Ruby" book

2012-07-01 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> retitle 679820 RFS: rubybook/0.2.1-2 [ITA] -- "Programming Ruby" book
Bug #679820 [sponsorship-requests] RFS: rubybook [ITA] -- "Programming Ruby" 
book
Changed Bug title to 'RFS: rubybook/0.2.1-2 [ITA] -- "Programming Ruby" book' 
from 'RFS: rubybook [ITA] -- "Programming Ruby" book'
> stop
Stopping processing here.

Please contact me if you need assistance.
-- 
679820: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679820
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.134117795614346.transcr...@bugs.debian.org

Processed: RFS: rubybook/0.2.1-2 [ITA] -- "Programming Ruby" book

2012-07-01 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> block 677789 by 679820
Bug #677789 [wnpp] ITA: rubybook -- the "Programming Ruby" book
677789 was not blocked by any bugs.
677789 was not blocking any bugs.
Added blocking bug(s) of 677789: 679820
> stop
Stopping processing here.

Please contact me if you need assistance.
-- 
677789: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677789
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.134117894218962.transcr...@bugs.debian.org

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Sven Dowideit 

On 02/07/12 02:03, Marc Haber wrote:
I am really really astonished about with which ease we hurl RC bugs at 
packages without having thought-out alternatives.
Would it not be better to reject the Debian QA 'suggestion' until such 
time as its documented thoroughly in the Packaging manual?


I'm a non-DD that gave up maintaining a package in debian (and in the 
process decided not to be a DD).


The main reason was the constant barrage of opposing and incomplete 
directions given (and each that I implemented lead to more bugs and yet 
more opposing suggestions), and not enough well finished and detailed 
documentation.


2 cents more
Sven


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff18dfc.7040...@home.org.au

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Russ Allbery 
Sven Dowideit  writes:
> On 02/07/12 02:03, Marc Haber wrote:

>> I am really really astonished about with which ease we hurl RC bugs at
>> packages without having thought-out alternatives.

> Would it not be better to reject the Debian QA 'suggestion' until such
> time as its documented thoroughly in the Packaging manual?

Not using /home is already documented in Debian Policy.  Marc quoted the
relevant excerpt in his original message.

It would indeed be best if everything possible was documented, but very
few people volunteer to do the work to drive changes to the documentation
through to completion.

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


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obny27sf@windlord.stanford.edu

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Sven Dowideit 

On 02/07/12 12:53, Russ Allbery wrote:

Sven Dowideit  writes:

On 02/07/12 02:03, Marc Haber wrote:

I am really really astonished about with which ease we hurl RC bugs at
packages without having thought-out alternatives.

Would it not be better to reject the Debian QA 'suggestion' until such
time as its documented thoroughly in the Packaging manual?

Not using /home is already documented in Debian Policy.  Marc quoted the
relevant excerpt in his original message.

It would indeed be best if everything possible was documented, but very
few people volunteer to do the work to drive changes to the documentation
through to completion.

y, instead they all volunteer to pontificate on details that come due to 
the lack of detail - like where to put the ssh keys.


ie, having the doc say 'don't use /home' without addressing common 
reasons for wanting to use /home in that doc is the problem. (And I'd 
consider them a blocker for putting such a statement in the doc.


but as i said, I declined to do more because dealing with the details 
meant that every year someone would demand that I undo something i was 
demanded to do the year before. (The policy on complicated 
self-modifying web apps is pretty much non-existant)


Sven


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff1a41d.7060...@home.org.au

Re: Moving /home of a package account, and to where?

2012-07-01 Thread Sven Dowideit 

Sorry, I wanted to be constructive:

IMO, if a maintainer of a package isn't sure how to address a policy 
request, I believe the best response is to reject/park the issue, 
pending a separate discussion and adding of the needed details to policy 
(or appendices etc).


The reason I feel this way, is that when an implementation detail isn't 
pushed into policy, the debate happens more than once, and often with 
differing loud results (based on opinions of those awake at the time).


if policy isn't clear enough, make the process require fixing the 
documentation, rather than allowing having debian-mentors etc re-debate 
in an adhoc and lossy way.



Sven



On 02/07/12 23:37, Sven Dowideit wrote:

On 02/07/12 12:53, Russ Allbery wrote:

Sven Dowideit  writes:

On 02/07/12 02:03, Marc Haber wrote:

I am really really astonished about with which ease we hurl RC bugs at
packages without having thought-out alternatives.

Would it not be better to reject the Debian QA 'suggestion' until such
time as its documented thoroughly in the Packaging manual?

Not using /home is already documented in Debian Policy.  Marc quoted the
relevant excerpt in his original message.

It would indeed be best if everything possible was documented, but very
few people volunteer to do the work to drive changes to the 
documentation

through to completion.

y, instead they all volunteer to pontificate on details that come due 
to the lack of detail - like where to put the ssh keys.


ie, having the doc say 'don't use /home' without addressing common 
reasons for wanting to use /home in that doc is the problem. (And I'd 
consider them a blocker for putting such a statement in the doc.


but as i said, I declined to do more because dealing with the details 
meant that every year someone would demand that I undo something i was 
demanded to do the year before. (The policy on complicated 
self-modifying web apps is pretty much non-existant)


Sven





--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff1a658.7020...@home.org.au

freeze policy - open requests for sponsorship

2012-07-01 Thread Bart Martens 
Hello,

Now that the freeze period has started, some of the open requests for
sponsorship are now invalid because the packages don't conform to the freeze
policy.
http://release.debian.org/wheezy/freeze_policy.html

With "open requests for sponsorship" I mean not only the RFS bugs but also the
packages at mentors marked "needs a sponsor = yes".
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=sponsorship-requests
http://mentors.debian.net/packages/index

Here are some numbers of open requests for sponsorship, and the part "in
Debian" means "in unstable or in experimental" in this context :
total : 236
for package in Debian : 79
for package in Debian with RFS bug : 45

I see no problem for the 236-79=157 requests for packages not yet in Debian.
The current freeze policy allows these packages to be uploaded to unstable, at
least how I read the current freeze policy.

For the 45 requests "for package in Debian with RFS bug" we currently use the
severity of the RFS bug to indicate whether the package fixes RC bugs.  I
suggest to change that now.  I suggest to use the severity of the RFS bugs to
group the requests into "for wheezy" with severity "important" and "not for
wheezy" with severity "normal".

For the 79-45=34 requests "for package in Debian without RFS bug" I suggest to
open RFS bugs for the packages meant for wheezy.

I suggest that the person requesting sponsorship indicates whether the package
is meant for wheezy, and that reviewers comment on the RFS bugs and on the
pages at mentors on whether the package conforms to the freeze policy.

Comments on these suggestions ?

Regards,

Bart Martens


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