Thanks
On Wed, Jan 15, 2025 at 06:03:42PM -0600, G. Branden Robinson wrote:
> I've saved the worst for last.
>
> That is of course docbook-to-man. Ingo and I both find the quality of
> its output to be execrable. It has been unmaintained for many years and
> consistently seems to burn out and drive fro
Quoting Simon McVittie (2025-01-17 10:19:47)
> Many libraries have their API reference as HTML or even PDF, generated
> via something like Doxygen, gtk-doc or Pandoc,
Those packages currently using pandoc are recommended to check if either
of the much lighter cmark or cmark-gfm is sufficient.
-
On Fri, 17 Jan 2025 at 10:56:39 +0900, Simon Richter wrote:
> basically we'd have to give every -dev package containing
> manual pages a -doc package
In many cases I think this is best-practice anyway, because it takes
the documentation generation toolchain out of the critical path for
bootstrappi
Hi,
On 1/17/25 05:14, Sam Hartman wrote:
With the exception of Simon Richter, we appear to be agreed that
avoiding man pages in m-a: same packages is good.
I mean, this is specifically about the manpages included in
libpam-modules, which are at the intersection of
- likely to be useful
>>>>> "Simon" == Simon McVittie writes:
Simon> On Thu, 16 Jan 2025 at 09:41:51 -0700, Sam Hartman wrote:
>> (We'd also need to do something about libpam0g-dev man pages).
Simon> Moving user-facing documentation from libpam0g into either
> "Simon" == Simon Richter writes:
Simon> Hi,
Simon> On 1/16/25 01:43, Sam Hartman wrote:
>> For a while we just built the man pages but if any of the docbook
>> tools changed between one arch build and another, we'd end up
>> with m-a uninstallable packages.
Simon>
tice requirement that the man pages be in
the same binary package, only that they be installed when the package is
installed, so putting them in a dependency has always been fine. I think
the concern here may just be that the effective dependency on libpam-doc
is Suggests and people would rather
On Thu, 16 Jan 2025 at 09:41:51 -0700, Sam Hartman wrote:
> (We'd also need to do something about libpam0g-dev man pages).
Moving user-facing documentation from libpam0g into either
libpam-modules-bin or libpam-doc (depending how often you expect users to
need it), and developer docum
>>>>> "Guillem" == Guillem Jover writes:
Guillem> Hi!
Guillem> On Wed, 2025-01-15 at 09:43:36 -0700, Sam Hartman wrote:
>> My proposal is to move the man pages into libpam-doc. I'm not
>> actually convinced that normal Debian use
On Wed, Jan 15, 2025 at 06:24:39PM -0500, Gioele Barabucci wrote:
> On 15/01/25 17:43, Sam Hartman wrote:
> > My proposal is to move the man pages into libpam-doc.
> > I'm not actually convinced that normal Debian users need man pages for
> > all the pam modules on
[Please don't CC me]
* Sam Hartman [250115 14:45]:
> Do you actually have a system on which you want these man pages and on
> which the extra space of libpam-doc would be a problem?
No.
> Unless there's a compelling need, my answer is that I don't understand
> why m
Hi!
On Wed, 2025-01-15 at 09:43:36 -0700, Sam Hartman wrote:
> My proposal is to move the man pages into libpam-doc.
> I'm not actually convinced that normal Debian users need man pages for
> all the pam modules on all Debian systems, and a suggests relationship
> should be
Hi,
On 2025. Jan 16., Thu at 8:17, Simon Richter wrote:
> Hi,
>
> On 1/16/25 13:22, Russ Allbery wrote:
>
> > There are various things one can do to try to make the output of a man
> > page generator like that more consistent, but they don't fix the problem,
> > just reduce its frequency, unless
Hi Sam,
On Wed, Jan 15, 2025 at 09:43:36AM -0700, Sam Hartman wrote:
> My proposal is to move the man pages into libpam-doc.
> I'm not actually convinced that normal Debian users need man pages for
> all the pam modules on all Debian systems, and a suggests relationship
> sho
Hi,
On 1/16/25 13:22, Russ Allbery wrote:
There are various things one can do to try to make the output of a man
page generator like that more consistent, but they don't fix the problem,
just reduce its frequency, unless Debian sets up to do a fully
reproducible build with pinned versions of ev
Simon Richter writes:
> On 1/16/25 01:43, Sam Hartman wrote:
>> For a while we just built the man pages but if any of the docbook tools
>> changed between one arch build and another, we'd end up with m-a
>> uninstallable packages.
> Can this be fixed by removing the "Generator:" comment in the g
Hi,
On 1/16/25 01:43, Sam Hartman wrote:
For a while we just built the man pages but if any of the docbook tools
changed between one arch build and another, we'd end up with m-a
uninstallable packages.
Can this be fixed by removing the "Generator:" comment in the generated
manpage, and possi
"G. Branden Robinson" writes:
> 1. podlators/Pod::Man -- a proud exception to some of the
> generalizations above. First, it's been around probably longer than
> any of these others, maybe by a margin of decades. Second, it was
> initially developed by people who seemed to have a g
Hi Jonathan,
At 2025-01-15T22:01:28+, Jonathan Dowland wrote:
> On Wed Jan 15, 2025 at 9:42 PM GMT, G. Branden Robinson wrote:
> > As someone who has a bit of a preoccupation with man pages
>
> You've reminded me that you presented 'Write the Fine Manual' in 2005,
> (possibly at DebConf?).
I
On Wed Jan 15, 2025 at 9:42 PM GMT, G. Branden Robinson wrote:
As someone who has a bit of a preoccupation with man pages
You've reminded me that you presented 'Write the Fine Manual' in 2005,
(possibly at DebConf?). I thought it was a really good slide-deck, but
it's either unavailable or at
er
bootstrapping of new architectures (or just ABIs) are a couple that
spring to mind.
> Were it not for multi-arch, I could see an argument that dpkg filters
> were sufficient and the man pages could stay in libpam-modules.
As someone who has a bit of a preoccupation with man pages, I feel
strongly
Sam Hartman writes:
> My proposal is to move the man pages into libpam-doc. I'm not actually
> convinced that normal Debian users need man pages for all the pam
> modules on all Debian systems, and a suggests relationship should be
> sufficient. If people really want to mai
e the man pages installed without the additional
Marvin> documentation in libpam-doc. Why not (other than a trip
Marvin> through NEW) put them in a new binary package
Marvin> libpam-manpages (arch:all)? I would prefer recommends
Marvin> rather than suggests.
>>
vin> documentation in libpam-doc. Why not (other than a trip
> Marvin> through NEW) put them in a new binary package
> Marvin> libpam-manpages (arch:all)? I would prefer recommends
> Marvin> rather than suggests.
>
> Do you actually have a system on which you wan
>>>>> "Marvin" == Marvin Renich writes:
Marvin> I have on a number of occasions used these man pages, and
Marvin> having them installed locally is very helpful. I would
Marvin> rather have the man pages installed without the additional
Marvin&
* Sam Hartman [250115 11:44]:
>
> TL;DR: I propose move man pages out of a multi-arch: same package into a
> arch all package. Asking for any downsides and usrmerge review.
>
> My proposal is to move the man pages into libpam-doc.
> I'm not actually convinced that norma
On 15/01/25 17:43, Sam Hartman wrote:
My proposal is to move the man pages into libpam-doc.
I'm not actually convinced that normal Debian users need man pages for
all the pam modules on all Debian systems, and a suggests relationship
should be sufficient.
Unrelated to the question at hand
e all or almost all build artifacts such as generated
man pages.
Today, we include man pages for all the pam modules in libpam-modules.
Libpam-modules is multi-arch: Same, so all these man pages need to be
bit-for-bit identical across all architectures.
Originally that was easy: we just inc
* Marvin Renich [221115 12:57]:
> TEMPDIR, on the other hand, is for _specific_ cases, and can have
^ et al
Of course, that should be TMPDIR, not TEMPDIR. Apologies.
...Marvin
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will rep
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will rep
from? Obviously for users of
> > Where is the expectation that $TMPDIR is writable by any user but the
> > current one?
> > I do not believe that it is expected that if a user creates a directory
> > and points $TMPDIR to it then they also have to make it sticky, so this
&
> "Otto" == Otto Kekäläinen writes:
Otto> Instead of manually trying to manage TMPDIR env variable in
Otto> various places, we should have a standardized way to run
Otto> maintainer scripts in clean shell sessions that have all env
Otto> variables set automatically correctly.
Robie Basak writes:
> This seems inconsistent to me. Where is the expectation that TMPDIR must
> be unset if dropping privileges coming from? Obviously for users of
> libpam-tmpdir that's a problem. But in the default case, it's something
> that would be entirely reasonabl
n that $TMPDIR is writable by any user but the
> current one?
> I do not believe that it is expected that if a user creates a directory
> and points $TMPDIR to it then they also have to make it sticky, so this
> has nothing to do with libpam-tmpdir.
I understand the traditional sema
pected that if a user creates a directory
and points $TMPDIR to it then they also have to make it sticky, so this
has nothing to do with libpam-tmpdir.
--
ciao,
Marco
signature.asc
Description: PGP signature
e not dropping
> privileges).
This seems inconsistent to me. Where is the expectation that TMPDIR must
be unset if dropping privileges coming from? Obviously for users of
libpam-tmpdir that's a problem. But in the default case, it's something
that would be entirely reasonable to inherit throug
t various other things, I don't think it's at all
clear whether TMPDIR is one of the things that the maintainer script
should be expected to unset in this case.
For libpam-tmpdir's use of setting TMPDIR, it's obviously the required
behaviour.
But what about in general? Wha
]] Sunil Mohan Adapa
> During today's FreedomBox meet, we have discussed that systemd'd
> PrivateTmp= is a better solution than libpam-tmpdir for FreedomBox at
> least as systemd makes a cleaner mount isolation between processes
> instead of managing directories and perm
]] Daniel Black
> How User= systemd directives work with lbpam-tmpdir I'm not sure,
> however without a setuid there shouldn't be an invalid TMPDIR env
> variable there.
systemd doesn't start a new PAM session for services, so there's no
interaction there.
--
Tollef Fog Heen
UNIX is user frien
erent privileges as to what is
> appropriate to reset.
I don't think we're disagreeing here.
> > I'm not sure this is libpam-tmpdir specific, but rather a bit more
> > general: what are the expectations that maintainer scripts can have
> > about the envi
x27;s consider an environment in which:
- there is no relevant elevation of privileges, so discussions about
what should libpam-something, sudo, etc... do are not applicable
- the root environmente legitimately has TMPDIR=/tmp/root-only/ mode 700
- a maintainer script does something as an unp
On Sun, 13 Nov 2022 at 11:38:08 +, Robie Basak wrote:
> On Sun, Nov 13, 2022 at 02:21:58AM +0100, Marco d'Itri wrote:
> > On Nov 12, Otto Kekäläinen wrote:
> > > Instead of manually trying to manage TMPDIR env variable in various
> > > places, we should have a standardized way to run maintaine
On Sun, Nov 13, 2022 at 02:21:58AM +0100, Marco d'Itri wrote:
> On Nov 12, Otto Kekäläinen wrote:
>
> > Instead of manually trying to manage TMPDIR env variable in various
> > places, we should have a standardized way to run maintainer scripts in
> > clean shell sessions that have all env variabl
On Thu, Nov 10, 2022 at 10:46:55PM +, brian m. carlson wrote:
> > I think it's more wide than that: If you change UID, you need to
> > sanitise the environment. Your HOME is likely to be wrong. PATH might
> > very well be pointing at directories which are not appropriate for the
> > user you'
> user you're changing the UID to, etc.
I don't think that this is necessarily obviously the case in general.
For example, I often use "sudo -s" and *don't* want HOME reset. It
depends on the purpose of taking different privileges as to what is
appropriate to reset.
> I&#
On Thu, Nov 10, 2022 at 12:08:55PM +0100, Marco d'Itri wrote:
> > But are you in essence saying that libpam-tmpdir requires that *every
> > maintainer script* that runs things as non-root, or starts processes
> > that do that, unset TMPDIR first?
> This would not be ri
On Nov 12, Otto Kekäläinen wrote:
> Instead of manually trying to manage TMPDIR env variable in various
> places, we should have a standardized way to run maintainer scripts in
> clean shell sessions that have all env variables set automatically
> correctly.
This is not about maintainer scripts,
r solution than libpam-tmpdir for FreedomBox at
least as systemd makes a cleaner mount isolation between processes
instead of managing directories and permissions.
For this reason, we believe that we can stop using libpam-tmpdir if most
of the daemons on the system use PrivateTmp=yes.
variable there.
Also not perfect, but maybe viable.
On Sun, Nov 13, 2022 at 8:14 AM Otto Kekäläinen wrote:
>
> > > I think the answer to this should probably be established by the
> > > libpam-tmpdir maintainer and documented first, for fear of someone else
> >
> > I think the answer to this should probably be established by the
> > libpam-tmpdir maintainer and documented first, for fear of someone else
> > later coming along and saying that the maintainer script incorrectly
> > ignores TMPDIR because we started ignoring it t
On 2022-11-10 at 16:37:53, Tollef Fog Heen wrote:
> ]] Robie Basak
>
> > But are you in essence saying that libpam-tmpdir requires that *every
> > maintainer script* that runs things as non-root, or starts processes
> > that do that, unset TMPDIR first?
>
> I thin
]] Robie Basak
> But are you in essence saying that libpam-tmpdir requires that *every
> maintainer script* that runs things as non-root, or starts processes
> that do that, unset TMPDIR first?
I think it's more wide than that: If you change UID, you need to
sanitise the environme
On Nov 10, Robie Basak wrote:
> Thank you for the report. Adding debian-devel@ and the libpam-tmpdir
> maintainer for wider discussion.
>
> On Thu, Nov 10, 2022 at 12:54:34AM +, brian m. carlson wrote:
> > On my systems, I use libpam-tmpdir, which provides each user
Thank you for the report. Adding debian-devel@ and the libpam-tmpdir
maintainer for wider discussion.
On Thu, Nov 10, 2022 at 12:54:34AM +, brian m. carlson wrote:
> On my systems, I use libpam-tmpdir, which provides each user with a
> private temporary directory owned and accessible o
This won't be an easy task (rather impossible) since libfprint is
written in C and libpam-fingerprint is written in Python.
Regards,
Philipp
Am 26.02.19 um 02:35 schrieb Paul Wise:
> On Mon, Feb 25, 2019 at 7:14 PM Philipp Meisberger wrote:
>
>> Poorly libpam-fprintd i
On Mon, Feb 25, 2019 at 7:14 PM Philipp Meisberger wrote:
> Poorly libpam-fprintd is not suitable as libfprint0 seems to support
> ZhianTec fingerprint sensors. libpam-fingerprint is especially for those
> sensors. I see it would be more precise to use "Pluggable Authenticatio
Poorly libpam-fprintd is not suitable as libfprint0 seems to support
ZhianTec fingerprint sensors. libpam-fingerprint is especially for those
sensors. I see it would be more precise to use "Pluggable Authentication
Module for ZhianTec fingerprint sensors" as description and name t
On 2019-02-25 08:20, Philipp Meisberger wrote:
Package: wnpp
Severity: wishlist
Owner: Philipp Meisberger
* Package name: libpam-fingerprint
Version : 1.5
Upstream Author : Philipp Meisberger
* URL :
https://github.com/philippmeisberger/pam-fingerprint
* License
Package: wnpp
Severity: wishlist
Owner: Philipp Meisberger
* Package name: libpam-rfid
Version : 1.4
Upstream Author : Philipp Meisberger
* URL : https://github.com/philippmeisberger/pam-rfid
* License : D-FSL
Programming Lang: Python
Description
Package: wnpp
Severity: wishlist
Owner: Philipp Meisberger
* Package name: libpam-fingerprint
Version : 1.5
Upstream Author : Philipp Meisberger
* URL : https://github.com/philippmeisberger/pam-fingerprint
* License : D-FSL
Programming Lang: Python
ing
> this now
>
> The proposed virtual packages are:
>
> logind: a org.freedesktop.login1 D-Bus API implementation
> default-logind: should be provided by the distributions default logind
> provider (currently pam-systemd)
>
> Background: currently libpam-systemd provid
]] Felipe Sateler
Two minor typos.
> The proposed virtual packages are:
>
> logind: a org.freedesktop.login1 D-Bus API implementation
«an org…»
> default-logind: should be provided by the distributions default logind
> provider (currently pam-systemd)
distribution's.
Otherwise, this looks
;
> Sorry for the radio silence. Let's try to remedy that.
Thank you for moving this forward!
> > opt-in for every depender on libpam-systemd
>
> This is a good feature of the proposal: it requires explicit opt-in by
> reverse dependencies.
> > Thus: if package X a
ince January.
>
> I admit that my own testing was extremely uneven -- mostly restricted to
> environments I personally use -- but as the idea is opt-in for every
> depender on libpam-systemd, packages no one claims to have tested simply
> won't be usable without systemd. Just
to make some suppositions, which may well be wrong.
>
> So I'd appreciate a review of the draft summary/conclusions below.
>
>
> Clear recommendations from the thread:
>
> Don't provide libpam-systemd.
> Do provide a separate pam module, rather than pam_systemd.so.
> F
On Tue, 06 Nov 2018 12:29:10 +, Ian Jackson wrote:
> Simon McVittie writes ("Re: Should libpam-elogind Provide libpam-systemd
> ?"):
>> Similarly, I think pulseaudio's Recommends is because pulseaudio is
>> frequently a systemd user service (one per uid
Simon McVittie writes ("Re: Should libpam-elogind Provide libpam-systemd ?"):
> I don't want this to turn into "us vs. them", and I'm trying not to get
> drawn into a debate about the merits of these approaches because I can
> already see how much time and
Simon McVittie writes ("Re: Should libpam-elogind Provide libpam-systemd ?"):
> On Mon, 05 Nov 2018 at 13:32:40 +, Ian Jackson wrote:
> > pinentry-gnome3 and pulseaudio seem wrong to me. PINs should not be
> > shared between login sessions and sound control should be
On Mon, 05 Nov 2018 at 13:32:40 +, Ian Jackson wrote:
> When a package does not want, specifically, this sharing, the
> dependency should be on
>default-dbus-session-bus | dbus-session-bus
This is right for packages that don't particularly care whether the
session bus is per-uid or per-log
eview of the draft summary/conclusions below.
Clear recommendations from the thread:
Don't provide libpam-systemd.
Do provide a separate pam module, rather than pam_systemd.so.
File bugs against packages whose dependencies must be updated.
On Conflicts and/or switchability:
There was a
On Mon, 05 Nov 2018 at 08:44:45 +0100, Philipp Kern wrote:
> Do you know if any idea was
> already floated somewhere on how to make this work? I.e. have multiple
> systemd user instances per user?
This is specifically not supported. `systemd --user` always has the
same semantics as the $XDG_RUNTIM
On Mon, Nov 5, 2018 at 4:00 PM Philipp Kern wrote:
> I.e. have multiple systemd user instances per user?
That sounds strange, something like systemd session instances and
services seems more logical to me. systemd already has session scopes
so it isn't too much of a stretch to add session instanc
Hi Simon,
On 03.11.2018 12:11, Simon McVittie wrote:
> However, note that if you want multiple parallel dbus-daemons per uid,
> in particular one per X11 display, then dbus-user-session is not for you,
> and you should continue to use dbus-x11 or some third party implementation
> of the dbus-sessi
On Sat, 03 Nov 2018 at 00:08:50 +0100, Adam Borowski wrote:
> On Fri, Nov 02, 2018 at 10:22:58PM +, Simon McVittie wrote:
> > libpam-elogind is very unlikely to be enough to satisfy
> > dbus-user-session's dependency, for instance, unless elogind has taken
> > an e
On Fri, Nov 02, 2018 at 10:22:58PM +, Simon McVittie wrote:
> On Fri, 02 Nov 2018 at 12:20:55 -0700, Josh Triplett wrote:
> > please work with packages
> > that depend on libpam-systemd to add appropriate alternatives like
> > libpam-systemd | libpam-elogind if and *on
On Fri, 02 Nov 2018 at 12:20:55 -0700, Josh Triplett wrote:
> please work with packages
> that depend on libpam-systemd to add appropriate alternatives like
> libpam-systemd | libpam-elogind if and *only* if they work with both.
Yes, this. libpam-elogind is very unlikely to be enough t
Adam Borowski writes:
> Conflicts would greatly simplify packaging, but I'm afraid we need
> coinstallability at least for upgrades. With d-i installing systemd,
> the user needs to be able to switch to sysvinit -- and, horrors, some
> might want to go the other way.
> It'd be damage to allow t
On Fri, Nov 02, 2018 at 03:39:10PM -0400, Michael Stone wrote:
> On Fri, Nov 02, 2018 at 05:41:10PM +, Ian Jackson wrote:
> > Should it also Conflict libpam-systemd ?
>
> Does it somehow prevent the admin from configuring one or the other in pam?
Conflicts would greatly sim
On Fri, Nov 02, 2018 at 05:41:10PM +, Ian Jackson wrote:
> tl/dr: would this be wrong
>Package: libpam-elogind
>Provides: libpam-systemd
> and should there be a Conflicts too ?
This has been briefly discussed before: it's a quite bad idea to have
provides with sa
On Fri, Nov 02, 2018 at 05:41:10PM +, Ian Jackson wrote:
Should it also Conflict libpam-systemd ?
Does it somehow prevent the admin from configuring one or the other in
pam?
(Our draft package ships libpam_elogind.so, but there are some
difficulties with pam configuration ending up
Ian Jackson wrote:
> tl/dr: would this be wrong
>Package: libpam-elogind
>Provides: libpam-systemd
> and should there be a Conflicts too ?
Please don't, no, for multiple reasons.
First, various packages followed the widely offered advice of using
libpam-systemd as the c
Hi.
tl/dr: would this be wrong
Package: libpam-elogind
Provides: libpam-systemd
and should there be a Conflicts too ?
(emailing the systemd maintainers since that's Providing their package
name, and also d-devel since I'm not sure what input others may have)
There's an ac
Package: wnpp
Severity: wishlist
Owner: Daniel Gröber
* Package name: libpam-net
Version : 0.1
Upstream Author : Renzo Davoli, Eduard Caizer University of Bologna
* URL : https://github.com/rd235/libpam-net
* License : GPL2
Programming Lang: C
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel
* Package name: libpam-freerdp2
Version : 2.0.0
Upstream Author : Mike Gabriel
* URL : https://github.com/ArcticaProject/libpam-freerdp2.git
* License : GPL-3
Programming Lang: C
Description : PAM
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel
* Package name: libpam-x2go
Version : 0.1.1
Upstream Author : Mike Gabriel
* URL : https://github.com/ArcticaProject/libpam-x2go
* License : GPL-3
Programming Lang: C
Description : PAM Module to
Package: wnpp
Followup-For: Bug #699116
Owner: Lucas Castro
Hi,
On Wed, Nov 19, 2014 at 12:40:00AM -0800, Keith Packard wrote:
>
> I'd like to apologize to the systemd maintainer team, and to Tollef in
> particular for my TC vote on the libpam-systemd bug.
>
> The discussion on this issue was an excellent model of the Debian
> co
I'd like to apologize to the systemd maintainer team, and to Tollef in
particular for my TC vote on the libpam-systemd bug.
The discussion on this issue was an excellent model of the Debian
community at work:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578
Josh Triplett
On Mon, 17 Nov 2014, Anthony Towns wrote:
> the systemd maintainers may have wanted to protect systemd users
> tracking unstable from systemd-shim breakage.
This dependency change doesn't install systemd-shim if someone is
already using systemd-sysv. It only installs systemd-shim if someone has
al
On Sun, Nov 16, 2014 at 03:52:39PM -0800, Don Armstrong wrote:
> On Sun, 16 Nov 2014, Anthony Towns wrote:
> > I assume that RC bug was one blocker from the systemd maintainers'
> > POV, but that bug doesn't seem to have been considered by the
> > technical committee in its deliberations at all (at
On Sun, 16 Nov 2014, Anthony Towns wrote:
> I assume that RC bug was one blocker from the systemd maintainers'
> POV, but that bug doesn't seem to have been considered by the
> technical committee in its deliberations at all (at least in so far as
> Steve as systemd-shim maintainer is distinct from
Hi,
I need some help/advice with bug 759559 [0] . Im not sure if the suggested
patch is the right one for fixing this problem.
Any advice/patches are welcome.
Thanks.
Regards,
Martijn van Brummelen
Debian maintainer libpam-script
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759559
Hi folks,
So with wheezy out, libaudit is now multiarch-capable, which means for
jessie I would like to enable the tty_audit PAM module. This brings
libaudit into the transitively essential set of libraries, so should be
discussed here. (I forgot to raise this thread before actually uploading
th
private key on a removable media one can get a
poor-man's version smart card, similar with libpam-rsa, but you get the
added benefit of having the key automatically added to the ssh-agent.
Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.
On 08/16/2012 11:42 PM, Antti-Juhani Kaijanaho wrote:
> On Thu, Aug 16, 2012 at 05:39:50PM +0200, Jerome BENOIT wrote:
>
>> According to its PTS ( http://packages.qa.debian.org/libp/libpam-ssh.html ):
>> [2011-12-03] libpam-ssh REMOVED from testing (Britney)
>> [2011-12-
On Thu, Aug 16, 2012 at 05:41:08PM +0200, Alexander Wirt wrote:
> What let you think this?
Carelessness in investigating (looked at
http://packages.qa.debian.org/libp/libpam-ssh.html, noticed that the last news
entry was removal from testing and did not read closely enough to notice the
unsta
lease engineering action that doesn't imply any change in a package's
> maintainership.)
What let you think this?
rmadison libpam-ssh
libpam-ssh | 1.92-14 | squeeze | source, amd64, armel, i386, ia64,
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
W: Archive maintena
esting"
> -
> a release engineering action that doesn't imply any change in a package's
> maintainership.)
$ ssh release.debian.org dak ls libpam-ssh
libpam-ssh |1.92-14 |stable | source, amd64, armel, i386, ia64,
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc
1 - 100 of 180 matches
Mail list logo
