aking the
changes necessary to satisfy the Devuan developers that a separate distro is
no longer needed.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
ing, etc) and I also absolutely 100% did
NOT want NetworkManager managing my ethernet port and had it configured via
netplan instead.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
U
n both Debian and Ubuntu - to my consternation as a member of
the Ubuntu Release Team, since that increases the number of flavor images
we have to manage releases of ;)
- Canonical has not discontinued its development of lxd. I think the larger
Free Software community pol
ng on? The mass-NMUs included a
lintian override to suppress this warning.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://w
port for other armhf devices for both Ubuntu and Ubuntu Core to come soon
in 24.04.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
ved.
>
> "Kinda or not"
>
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com
of the maintainers at this
point, it's very much dependent on folks rebootstrapping armel and armhf
against the new library names. Should these bugs be downgraded again to
important severity?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
those should still
be coordinated with the Release Team.
> Am 27. Februar 2024 08:19:21 MEZ schrieb Steve Langasek :
> >Hi Simon,
> >
> >On Mon, Feb 26, 2024 at 11:40:56AM +, Simon McVittie wrote:
> >> > glib2.0 # already in experimental
> &
one in Ubuntu is:
- unpack cargo and libstd-rust debs to the root via dpkg-deb -x
- use equivs to mock up packages by these names with no dependencies and
install those
- bootstrap
- enjoy
--
Steve Langasek Give me a lever long enough and a Free OS
Debian De
n unstable for 2 days?
I'm also not sure why it hasn't expired out of unstable given that it is
superseded.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
Similarly, libcom-err2 and libss2 don't use time_t, so
> the rename to ...t64 was completely unnecessary.
Yes, apologies, we can't assume any particular mapping from -dev packages to
runtime lib packages in packages that have multiple -dev packages, so
libcom-err2 and libss2 were
all the libextutils-cbuilder-perl package anymore.
(which, btw, was an arch: all package, so in any case it wouldn't be
affected by the ABI transition.)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move t
On Thu, Mar 07, 2024 at 01:43:11AM +0500, Andrey Rahmatullin wrote:
> On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote:
> > > > Are there instructions on how to progress an unstable system through
> > > > this, or is the repo currently in a known
t is done (later today?), if apt dist-upgrade is
NOT working, I think we should want to see some apt output showing what's
not working.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
https://paste.debian.net/1309262/
curl, nordugrid-arc, poppler, qtbase-opensource-src, and xmlrpc-c have been
uploaded with the fix. petsc will take a little bit, as there are other
bugs that need fixing at the same time.
--
Steve Langasek Give me a lever long enough and a Free
me troubles. Thanks for the information,
> let's see if this is a real issue or not.
Furthermore, this is a downgrade from a replacing package to a replaced
package. Unless you also --reinstall the package at the end, missing files
are quite to be expected.
--
Steve Langasek
ansition through, we aren't going to vary it by
much. So maintainer name reverts in unstable that happen after this are not
guaranteed to be picked up, and whatever package names we have on the Ubuntu
side are going to be locked in for a 10-year LTS cycle. So I think any
maintai
gate these substvars, *IFF* there is
not already a reference to the substvar in question in the package stanza in
debian/control? This would provide adequate flexibility for any other
exceptions that might be out there, beyond the Pre-Depends case.
Cheers,
--
Steve Langasek
On Fri, Feb 23, 2024 at 04:36:43PM +0100, Guillem Jover wrote:
> Hi!
> On Mon, 2024-02-19 at 19:48:38 -0800, Steve Langasek wrote:
> > I have coordinated with the gcc maintainer so that we can have the default
> > flags in gcc-13 changed this week.
> > We are therefore
failed
# no sane ABI info, no revdeps
sipxtapi: failed
# no sane ABI info; https://bugs.debian.org/1064328
snort: failed
# obsolete, skip it
python3.10: failed
# soon to be obsolete skip it
python3.11: failed
# has to be handled manually, mark failed temporarily
python3.12: failed
Thanks,
--
Steve Lang
_compat_time() {
> +fixup(pam_misc_conv_warn_time64, pam_misc_conv_warn_time);
> +fixup(pam_misc_conv_die_time64, pam_misc_conv_die_time);
> +}
> +static void reset_warn_time() {
> + pam_misc_conv_warn_time = 0;
> + pam_misc_conv_warn_time64 = 0;
> +}
> +
are being staged in experimental where
possible, but we will not be pulling experimental versions into unstable as
part of this.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and
On Tue, Feb 06, 2024 at 05:33:22PM +, Alberto Garcia wrote:
> On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote:
> > In fact, none of the t64 binaries currently being uploaded
> > to experimental have the final ABI either, we're just using
> > experi
this be made the default in gcc or glibc ?
On Thu, Feb 08, 2024 at 08:07:19PM +0100, Ansgar wrote:
> On Fri, 2024-02-02 at 08:21 -0800, Steve Langasek wrote:
> > Once all of these packages have built in experimental and we have identified
> > and addressed all adverse interactions w
the package rename without so rename and then in forky
> we'll have to clean up all those diversions, and in forky+1 we'll have
> to delete the cleanup code, so while investing more now may seem more
> expensive, it saves later.
I think the cost of chasing upstreams about soname bum
in unstable and breaking the world has affected the
timeline, yes.
I now have a tested patch that I've raised as an MP in salsa:
https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/9
I welcome review from the Debian libselinux maintainers prior to opening a
discussion with upst
txt
Much better that there be a library transition only for the lesser-used
library!
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://w
On Mon, Feb 05, 2024 at 08:57:50AM +0200, Andrius Merkys wrote:
> On 2024-02-02 19:46, Steve Langasek wrote:
> > If there is no new version in experimental, or there is a new version BUT
> > the patch against unstable applies cleanly to the version in experimental
> > (n
There may be build failures if there are interdependencies between some of
these packages because of unsatisfiable build dependencies, but those will
be resolved semi-automatically in cooperation with the buildd maintainers
and only one round of builds will actually be required.
--
Steve Langasek
aded to unstable,
we will rebase all patches on whatever version of the library is in unstable
at that time. You don't need to hold off on an upload to unstable for fear
of conflicts.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Sat, Feb 03, 2024 at 10:16:48AM +0100, julien.pu...@gmail.com wrote:
> Le vendredi 02 février 2024 à 08:21 -0800, Steve Langasek a écrit :
> > The packages previously not reported are:
> > flint
> > flint-arb
> About flint: if you need anything done, don't
On Fri, Feb 02, 2024 at 07:34:46PM +0100, Bill Allombert wrote:
> On Fri, Feb 02, 2024 at 08:21:57AM -0800, Steve Langasek wrote:
> > Dear developers,
> > As mentioned previously on debian-devel[6], we know that there are a number
> > of library packages being included in thi
in experimental can ignore this transition and just use the new
soname once it finally lands (is superseded by the next LTS version?)
On Fri, Feb 02, 2024 at 09:46:10AM -0800, Steve Langasek wrote:
> On Fri, Feb 02, 2024 at 05:27:02PM +, Scott Kitterman wrote:
> > On February 2, 2024 4
On Fri, Feb 02, 2024 at 05:27:02PM +, Scott Kitterman wrote:
> On February 2, 2024 4:43:52 PM UTC, Steve Langasek wrote:
> >Hello,
> >debian-devel-announce wouldn't let me attach the file, but for those on
> >debian-devel at least, you can find the dd-list of to-b
On Thu, Feb 01, 2024 at 07:45:57AM +0100, Carsten Schoenert wrote:
> Hello Steve,
> Am 31.01.24 um 21:59 schrieb Steve Langasek:
> ...
> > Please find the patch for this NMU attached.
> > If you have any concerns about this patch,
libdmtx0b and libvibrant6b at least have explanations in the changelog. So
I guess I'll work on fleshing out a rename map for these.
On Sun, Jan 21, 2024 at 12:57:17AM -0800, Steve Langasek wrote:
> Hello,
>
> Here is an updated analysis of the transition. This is based on a
library does not have an
> > > > ABI
> > > > breakage, especially in the long tail of libraries with few
> > > > reverse-dependencies whose involvement in the transition is unlikely to
> > > > substantially slow down Debian development.
On Sun, Jan 07, 2024 at 09:30:37AM +0100, Rene Engelhard wrote:
> Am 07.01.24 um 02:01 schrieb Steve Langasek:
> > If you say you are going to fix eventual breakage (and not ignoring the
> > test results!) and if that means fixing asm on all affected archs, then
> > it&#
Hi again,
On Sun, Jan 07, 2024 at 01:09:48PM +0100, Rene Engelhard wrote:
> Am 07.01.24 um 04:38 schrieb Steve Langasek:
> > The ordering here would be:
> > - dpkg will be uploaded to experimental with 64-bit time_t in the default
> >flags
> > - the source packag
On Wed, Jan 17, 2024 at 09:33:12PM -0800, Steve Langasek wrote:
> And my proposal for checking that set, since we're only talking about
> runtime library packages, is to check whether any of the contents of these
> packages in bookworm match ^/lib - as a runtime library package NOT m
Hi Colin,
On Tue, Jan 09, 2024 at 01:32:11PM +, Colin Watson wrote:
> On Mon, Jan 08, 2024 at 03:01:11PM -0800, Steve Langasek wrote:
> > On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote:
> > > On 05-01-2024 17:36, Rene Engelhard wrote:
> > > > Also
experimental? It seems to me there's ample
opportunity to catch such mistakes if they happen.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
cause it will take time to get all the binary
uploads done (longer than it will take to get the sourceful uploads to
unstable done), so it's better to stage in experimental to minimize the
window in unstable when uploads can be broken.
--
Steve Langasek Give me a lever l
On Sat, Jan 06, 2024 at 09:25:52AM +0100, Rene Engelhard wrote:
> Hi,
> Am 06.01.24 um 06:51 schrieb Steve Langasek:
> > > > - dpkg will be uploaded to experimental with 64-bit time_t in the
> > > > default
> > > > flags
> > [...]
>
On Sat, Jan 06, 2024 at 09:07:15AM +0100, Rene Engelhard wrote:
> Am 06.01.24 um 06:51 schrieb Steve Langasek:
> > > > - dpkg will be uploaded to experimental with 64-bit time_t in the
> > > > default
> > > > flags
> > > I think at that point
On Sat, Jan 06, 2024 at 10:01:30AM -0700, Sam Hartman wrote:
> >>>>> "Steve" == Steve Langasek writes:
> >> At one level, krb5-multidev only has an rdep of 5, but I suspect
> >> the rdep count for libkrb5-dev is somewhat larger:-) I don'
On Fri, Jan 05, 2024 at 02:23:59PM -0700, Sam Hartman wrote:
> >>>>> "Steve" == Steve Langasek writes:
> Steve> - In multi-library packages, there is no reliable way to map
> Steve> from a set of headers in a dev package to specific shared
>
LFS and is a
false-positive, I've removed this as well.
Reduces the count of revdeps to be rebuilt from 5450+169 to 5450+168 (not
much improvement :).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set i
ld address your concern. It's not as
if there is going to be any time that it's ok to tell maintainers they can't
use experimental at all because we're doing this transition.
> >experimental with the new binary package names in order to clear binary
> >NEW, in c
On Fri, Jan 05, 2024 at 09:32:28PM +0100, Sebastian Ramacher wrote:
> On 2024-01-05 11:06:09 -0800, Steve Langasek wrote:
> > On Fri, Jan 05, 2024 at 06:53:50PM +0100, Sebastian Ramacher wrote:
> > > Hi Steve
> > > > - perl will also get a sourceful uploa
which do not?
Sorry for the confusion. The two lists requiring binary package name
changes are the attachments named 'source-packages' and
'lfs-and-depends-time_t'. This is what I fed into dd-list, and encompass
1248 source packages (1195 + 53).
--
Steve Lang
g defaults
will be uploaded to unstable
- the sourceful NMUs of the libraries will be reuploaded to unstable
(without binaries, so that they can be promoted to testing without
additional uploads).
- perl will also get a sourceful upload, to manually handle 'perlapi'
Provi
uire a change of the binary
> package name.
There are other reverse-dependencies of libvlccore9 in the archive that are
not VLC plugins (phonon4qt5-backend-vlc etc). Are these packages simply
mis-linked against that library?
Thanks,
--
Steve Langasek
On Fri, Jan 05, 2024 at 12:05:57PM +, Simon McVittie wrote:
> On Fri, 05 Jan 2024 at 00:17:04 -0800, Steve Langasek wrote:
> > - In multi-library packages, there is no reliable way to map from a set of
> > headers in a dev package to specific shared libraries in a
Hi Sebastian,
On Fri, Jan 05, 2024 at 06:34:38PM +0100, Sebastian Ramacher wrote:
> On 2024-01-05 00:23:00 -0800, Steve Langasek wrote:
> > On Fri, Jan 05, 2024 at 12:17:04AM -0800, Steve Langasek wrote:
> > > == Results ==
> > > The overall findings of this analys
On Fri, Sep 22, 2023 at 12:58:10PM +0200, Stephan Lachnit wrote:
> On Fri, Sep 22, 2023 at 11:11 AM Steve Langasek wrote:
> > SPDX defines an xml format only. They lost before they'd even started.
> > debian/copyright is supposed to be human-readable first and foremost. XM
> gain traction and people centered on desktop files.
> We failed to gain traction on the structure of the copyright file, and
> spdx is the one who has won here.
SPDX defines an xml format only. They lost before they'd even started.
debian/copyright is supposed to be h
he project.
> I appreciate the value of doing work and having people who are willing
> to do the work have a larger share of power in the decision making.
I would like to see that discussion happen. I don't think this thread is
that discussion, and I'm not stepping forward to
o pam, it's integration
with the OS that has been done in /etc.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http
ession-noninteractive} which are
constructed at package install time and therefore are inappropriate to ship
in /usr.
Shipping the same file in both /usr and /etc from application packages seems
like it would be a reasonable workaround as far as it goes, but doesn't let
us empty /etc/pam.d
On Fri, Sep 15, 2023 at 10:15:53PM +0200, Paul Gevers wrote:
> Hi Steve,
> On 15-09-2023 21:54, Steve Langasek wrote:
> > armel != armhf
> Of course
> > and nobody should be running armel on a NEON-capable CPU...
> Not sure why you say it like that, I guess you don
the list of
> features of that machine.)
armel != armhf and nobody should be running armel on a NEON-capable CPU...
or chromium on an armel-only system.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I
s expressed, in
all of the packages in the archive. An audit of that sort would certainly
be unrealistic.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
s of religious texts would presumably be the first things
> tossed onto the pyre.
Don't you think it's a bit hyperbolic to equate "not distributing a text in
our archive" to "book burning"?
--
Steve Langasek Give me a lever long enough and a Free
als
> who have themselves engaged in terrorism or other violence toward
> individuals and groups, supported those who have engaged in such
> activities, or been otherwise complicit in such.
Lol bothsidesing anarchism and fascism
--
Steve Langasek Give me a lever long en
has
> bothered me. It just hasn't bothered me enough to investigate what the proper
> way to solve it is. It hasn't bothered me enough to bother other people with
> this issue.
Agreed.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
So while it's best practice when replying to make sure you're sending to the
right address, the fact that it winds up in your announce imap folder is a
local configuration issue, not a question of where it was sent.
--
Steve Langasek Give me a lever long enough and a Fr
and get human-editable
netplan files out), it's certainly close. And I can say that I am a happy
user of netplan across multiple systems, with no need to manage networkd
configuration directly.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Thu, Jul 20, 2023 at 12:30:50AM +0100, Simon McVittie wrote:
> On Wed, 19 Jul 2023 at 14:27:21 -0700, Steve Langasek wrote:
> > to understand the impact that a change to the size of
> > time_t will have on a library's ABI, it must be possible to compile the
> > he
in having some of these
library packages excluded from the transition is welcome to contribute
fixes up to that deadline that will let us analyze them and show that the
ABI has not changed.
Your thoughts?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Develop
1038482
1039564
Also closing WNPP bug(s):
=====
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote:
> On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote:
> > The difference in my view is that the changes to handle Provides: are
> > something that should persist in the packaging (until the next soname
>
a decision if we find that there isn't
consensus. If we need more assurance that the project supports the
decision, I think it's better to go straight for a GR.
I wouldn't like this to drag on too long into the trixie release cycle.
--
Steve Langasek Give me a
Hi Helmut,
On Tue, Jun 06, 2023 at 09:33:22AM +0200, Helmut Grohne wrote:
> On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote:
> > * … but NOT on i386. Because i386 as an architecture is primarily of
> > interest for running legacy binaries which cannot be rebuil
ons of old computers,
refurbishes them, installs Linux, and both sells them and provides them free
to people in need.
They receive x86-64 systems that they determine are *too old to be worth
refurbishing* and they e-cycle them.
Hanging on to systems using power-hungry chips from 20 years ago in
On Mon, May 22, 2023 at 06:24:53PM -0700, Steve Langasek wrote:
> > We don't need to enable/fix it for everything though. A rebuild check of
> > affected libraries to see how much work this adds would be a good idea.
> Isn't it a problem not just for library ABIs but al
ABIs but also for any other packages
rebuild with -D_TIME_BITS=64, because the code will be consuming the 64-bit
prototype from the headers but using the 32-bit symbol at runtime?
(Which is a better answer in terms of automation, because then we can just
put it in dpkg-buildflags)
--
Steve Langasek
ver, I fail to see any way
that we can effectively mitigate this in advance - either now or by delaying
the time_t transition. I don't see any way to avoid this via automated
source analysis, so the only option (given that we can't avoid the time_t
transition forever) is
On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote:
> Based on the analysis to date, we can say there is a lower bound of ~4900
> source packages which will need to be rebuilt for the transition, and an
> upper bound of ~6200. I believe this is a manageable transition, and
reason to
care about test results for it because it has no end-user application!)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
ot;authentic" Unix *roff behavior.
Dustin Kirkland once did a demo where he booted every 6-monthly Ubuntu
release since the dawn of time in a VM (15+ at the time, I think). That's
much more useful for software archaeology of this sort than providing i386
host support in *future* Debian releases.
programs is a
compelling reason to keep binary-compatibility on i386. But I counter that
unless you care about this, there's no reason to keep i386 as an
architecture *at all*.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to se
same handling for mipsel as for other 32-bit archs wrt
compatibility provides; do you agree?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
On Thu, May 18, 2023 at 03:04:30AM +0200, Guillem Jover wrote:
> On Tue, 2023-05-16 at 21:04:10 -0700, Steve Langasek wrote:
> > === Technical details ===
> > The proposed implementation of this transition is as follows:
> > * Update dpkg-buildflags to emit -D_FI
feature=+time64 should also emit
-Wno-implicit-function-declaration; cc:ing the bug on dpkg regarding
implementation of that interface.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Dev
86?
> * Do time64 changes affect downstream packages?
>+ Which?
> I understand that answering these questions on a per-package basis is
> far from trivial. That much is evident from your analysis. I think this
> is ok. Even if such a service says "unknown" 10% of t
On Tue, May 16, 2023 at 09:31:05PM -0700, Russ Allbery wrote:
> Steve Langasek writes:
> > * Largely via NMU, add a “t64” suffix to the name of runtime library
> > packages whose ABI changes on rebuild with the above flags. If an
> > affected library already has a diffe
Hi Craig,
On Wed, May 17, 2023 at 10:14:17PM +1000, Craig Small wrote:
> On Wed, 17 May 2023 at 14:10, Steve Langasek wrote:
> > Over on debian-arm@lists, there has been discussion on and off for several
> > months now about the impending 32-bit timepocalypse. As many of you ar
packages under
the old name on upgrade.
* In the future when the upstream SONAME changes, the t64 suffix should be
dropped.
Your thoughts?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the
Package: wnpp
Severity: wishlist
Owner: Steve Langasek
* Package name: pam-session-timelimit
Version : 0.5
Upstream Author : Steve Langasek
* URL : https://github.com/vorlonofportland/pam_session_timelimit
* License : LGPLv3
Programming Lang: C
Description
nd to be able to
effectively analyze build results to identify Werror-related failures with
high signal would require two parallel builds, one with and without the
flag, built against the same baseline. So since this is infeasible, if
Debian decides to pass -Wno-error by default from dpkg-buildfl
On Mon, Feb 27, 2023 at 03:06:25PM -0700, Sam Hartman wrote:
> >>>>> "Steve" == Steve Langasek writes:
> Steve> If this is for people doing out-of-archive builds who don't
> Steve> want to deal with failures from -Werror, I can see how havin
ument, then I
think the logical desired policy outcome would be for dpkg-buildflags to be
changed to emit -Wno-error *by default*, with an option flag along the lines
of DEB_BUILD_OPTIONS=Werror that lets you turn it on instead.
--
Steve Langasek Give me a lever long enough and
nd the one-time work of removing it.
> > > ...
> > > The point of going 64-bit only is to clean up data structures and remove
> > > technical debt: Hence 5.x will start a cleanup and removal of 32-bit code.
> > >
> > > The next point release may work
shipping common sysctl settings among
different distributions would be in the Linux kernel, instead of diverging
from the kernel defaults in userspace and representing this as "common".
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
ither base-files
(which I don't think the base-files maintainer would like) or apt.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https
On Mon, May 16, 2022 at 08:46:04PM +0200, Ben Hutchings wrote:
> On Sun, 2022-05-08 at 22:07 +0200, Steve Langasek wrote:
> [...]
> > Ubuntu no longer uses isc-dhcp by default, because it no longer uses
> > ifupdown; NetworkManager and networkd both have their own implement
based rootfs, it appears to still be the only game in
town. It would be a good idea to make sure as part of the deprecation of
isc-dhcp-client that we get initramfs integration of whatever is the
preferred replacement.
--
Steve Langasek Give me a lever long enough and a
d:
> passwordrequisite pam_cracklib.so retry=3
> difok=3 minlen=14
> Yes, I surely would miss the NIS support.
If your users are using yppasswd on the NIS master for changing passwords,
then evidently you are not relying on support for NIS in PAM. (yppasswd
doesn't e
I
wasn't going to offer it up as a solution without some evidence of demand
(which I would say this thread hasn't yet established), since it would
require additional work on the package.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
1 - 100 of 2915 matches
Mail list logo
