Bug#689854: pmount needs some loving care

[Axel Beckert]

Hi again,

Barak A. Pearlmutter wrote:
> > https://pmount.alioth.debian.org/ seems more suitable than
> > https://alioth.debian.org/projects/pmount/ to me for the Homepage
> > header.
> 
> The reason I changed it is that, the former refers to
> git://git.debian.org which you're not supposed to do anymore, and also
> has the image https://alioth.debian.org/themes/gforge/images/logo.png
> on the upper left hang corner which is not found so renders with a
> broken image.

Actually, I'd use https://pmount.alioth.debian.org/ and just update
the web page accordingly. Or is that not wanted for some reason? I'd
expect that all group members should have write access to the web
page, too.

> Sound I change it back?

You never changed it forward. There was no Homepage header before. So
the addition is definitely an improvement, with either value. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#689854: pmount needs some loving care

[Simon McVittie]

On 15/10/15 21:04, Vincent Fourmond wrote:
>   I'm OK to give input, and do few things from time to time...

It seems I'm still in the Cc list because I said something about the
adoption a while ago. To clarify, I do not intend to get involved in
this package's maintenance, and anything I say about it is only a
suggestion.

I do have one comment, which is that the package Description could
perhaps benefit from updating: it describes pmount's original
motivation, which was as a backend for GNOME and other GUI stuff.
However, GNOME and other "large" desktop environments have stopped using
it in favour of the more featureful (but correspondingly heavier-weight)
udisks2, leaving pmount as a potentially useful tool in its own right,
but no longer directly used by GNOME.

(No value-judgement intended here - pmount is simple and small; udisks2
is more complex and larger; and either could be more suitable than the
other, depending on your requirements.)

The major differences:

* udisks2 is a privileged D-Bus system service (daemon), controlled
  via D-Bus messages by an accompanying (unprivileged) CLI tool or by
  other unprivileged processes like the various GNOME GUIs that use it.
  pmount is a setuid CLI tool (a privilege boundary) with no daemon,
  which can be executed directly or by an unprivileged frontend;
  less complexity, but more need to cope with the security implications
  of being setuid.

* udisks2 has a broader scope, and also handles non-mount operations
  on disk devices, such as partitioning and SMART. pmount has a
  narrower scope, and only (un)mounts disks.

* udisks2 uses PolicyKit for access control, with a relatively subtle
  default policy designed to "do what I mean" (locally-logged-in users
  can mount removable disks on the same "seat" where they are currently
  logged-in), but configurable to have other policies (e.g.
  a group-based override) if that's what a sysadmin wants. pmount's
  policy is simpler, using group-ownership to allow any user in the
  plugdev group to mount removable disks, whether they are logged-in
  locally or remotely; this is simple and easy to understand if you
  know how Unix groups work, but can lead to unexpected results if the
  system is multi-seat or has remote access (users taking control of
  each other's USB drives).

Hopefully that's enough information for a Description that indicates to
a potential user whether pmount is suitable for their needs. In
particular, it seems worthwhile to mention "users in the plugdev group"
in the Description.

S

Bug#689854: pmount needs some loving care

[Barak A. Pearlmutter]

> I request an adopter for the pmount package.

I can adopt it, although I'd much prefer to team/co-maintain.

I've done a bit of work, which I just took the liberty of pushing to
branch barak-tweaks in
 git://anonscm.debian.org/git/pmount/pmount-debian.git
This supports btrfs and has some other misc fixes like updated packaging
scripts and rm freeze-my-shell bash completion file.

Barring objections, I'll dput it as better-than-nothing.

Cheers,

--Barak.
--
Barak A. Pearlmutter 
 Dept Comp Sci, Maynooth University, Co. Kildare, Ireland
 http://barak.pearlmutter.net

Bug#689854: pmount needs some loving care

[Axel Beckert]

Hi Barak,

Barak A. Pearlmutter wrote:
> > I request an adopter for the pmount package.
> 
> I can adopt it, although I'd much prefer to team/co-maintain.

As mentioned before, I could help with package maintenance, but not
with the upstream code.

> I've done a bit of work, which I just took the liberty of pushing to
> branch barak-tweaks in
>  git://anonscm.debian.org/git/pmount/pmount-debian.git
>
> This supports btrfs and has some other misc fixes like updated packaging
> scripts and rm freeze-my-shell bash completion file.

Thanks!

Vincent wrote:
> > I'm the current upstream maintainer too, so the
> > adopter will have to take care of upstream too.

So wouldn't it be better to make a new upstream release instead of
adding patches to debian/patches/?

> Barring objections, I'll dput it as better-than-nothing.

For my taste, the changelog item "Update debian packaging scripts"
should be more verbose. (But then again some people think, my
changelog entries are slightly too verbose. ;-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#689854: pmount needs some loving care

[Barak A. Pearlmutter]

> So wouldn't it be better to make a new upstream release instead of
> adding patches to debian/patches/?

I actually did also push them to the maintain-0.9.23 branch of
 git://anonscm.debian.org/pmount/pmount.git
But maybe it would be best if people test it a bit before making an
"upstream" release...

Bug#689854: pmount needs some loving care

[Barak A. Pearlmutter]

> https://pmount.alioth.debian.org/ seems more suitable than
> https://alioth.debian.org/projects/pmount/ to me for the Homepage
> header.

The reason I changed it is that, the former refers to
git://git.debian.org which you're not supposed to do anymore, and also
has the image https://alioth.debian.org/themes/gforge/images/logo.png
on the upper left hang corner which is not found so renders with a
broken image.

Sound I change it back?

Bug#689854: pmount needs some loving care

[Axel Beckert]

Hi Barak,

Barak A. Pearlmutter wrote:
> I've done a bit of work, which I just took the liberty of pushing to
> branch barak-tweaks in
>  git://anonscm.debian.org/git/pmount/pmount-debian.git
> This supports btrfs and has some other misc fixes like updated packaging
> scripts and rm freeze-my-shell bash completion file.
> 
> Barring objections, I'll dput it as better-than-nothing.

One more thing I noticed in
http://anonscm.debian.org/cgit/pmount/pmount-debian.git/commit/?h=barak-tweaks=6123946b37c6d98118ea413be623acca50d90118:

https://pmount.alioth.debian.org/ seems more suitable than
https://alioth.debian.org/projects/pmount/ to me for the Homepage
header.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#689854: pmount needs some loving care

[Vincent Fourmond]

  Hi all,

On Thu, Oct 15, 2015 at 2:11 PM, Barak A. Pearlmutter
 wrote:
>> I request an adopter for the pmount package.
>
> I can adopt it, although I'd much prefer to team/co-maintain.

  I'm OK to give input, and do few things from time to time...

> I've done a bit of work, which I just took the liberty of pushing to
> branch barak-tweaks in
>  git://anonscm.debian.org/git/pmount/pmount-debian.git
> This supports btrfs and has some other misc fixes like updated packaging
> scripts and rm freeze-my-shell bash completion file.

  Thanks a lot !

> Barring objections, I'll dput it as better-than-nothing.

  That looks good to me, please go ahead.

  To respond to Axel about upstream vs debian: I find using patches
simpler for small patches, that saves the trouble of preparing and
announcing a full upstream release. So long as the patches find their
into the next upstream release.

  Cheers,

  Vincent