is not legal advice, and it's worth what you paid for it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
uild
chroot is on a remote NFS server with root-squash enabled, one might see
this. I'm not sure if using user namespaces may do something similar.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Sure, no problem. I'll file a bug against dash.
#1007263 had already been filed and was on a very similar topic, so I have
added some supplemental information to that bug report.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
f files in the data.tar of a .deb. All of the protective
> diversions that we ever installed for DEP17 are managed in maintainer
> scripts and dh_movetousr does not touch maintainer scripts at all.
Ah! Thank you.
> Your reasoning makes sense to me. I do not intend to work on this
> matter, b
il dpkg can gain full understanding of the path aliasing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
int to bash directly.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ere are two occasions where this could be seen as having been vetted.
> One is elaborate discussions on d-devel with consensus summaries that
> have not been objected to. The other is a transition bug that has been
> acknowledged by the release team. In any case, I do not think w
at needs to be
analyzed and appropriately addressed, but in the typical case, no, the
files in the packages should move so that we get to the more predictable
and easier-to-reason-about end state that was the goal of the migration
fix adopted by the CTTE.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
x27;m guessing that you're anticipating some problem related to
diversions, but I can't put the pieces together without some more details.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
you're using any
mechanism other than the simple password ones. See Authen::SASL::Perl:
As for server support, only *PLAIN*, *LOGIN* and *DIGEST-MD5* are
supported at the time of this writing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
should really be doing from Perl and the rest of it remains
somewhat useful, but given that upstream has archived the project, I would
go ahead and remove it.
Maybe someday I'll dust off and finish a proper Kerberos Perl module that
uses the modern C API. In my copius free time. :
gregor herrmann writes:
> On Wed, 06 Sep 2023 08:21:24 -0700, Russ Allbery wrote:
>> gregor herrmann writes:
>>> According to https://github.com/rra/docknot/issues/6 fixed upstream
>>> (in git, not released yet).
>> Yeah, I'm sorry about the delay here.
also explicitly says that it's non-breaking (I believe that's
the case, although please tell me if I got that wrong) and is more
(perhaps excessively) explicit about distinguishing it from "-" because of
all the confusion about this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
aphy (the hyphen-minus is one of 25 dashes in Unicode), you may want
to say that explicitly in addition to saying that it's the character used
in UNIX command-line options (and, arguably as importantly, in UNIX
command names).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
at have been turned
into \-. People will have to rewrite them using proper Unicode hyphens to
get proper formatting.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ng long lines with
lots-of-words-that-are-all-conncted-by-hyphens, although that's somewhat
rare.
My opinion is that the world of documents that are handled by man do not
encode meaningful distinctions between - and \-, and man should therefore
unify those characters.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
7;t immediately obvious
to me. Sorry about the noise.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ture for them.
That said, this is an architectural stab in the dark and I obviously don't
work on file system development, so maybe this isn't viable for some
reason that I'm not seeing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
arget distribution before using it to
build the file system the actual installation is going into.
I suspect this won't be Ted's favorite option because this isn't a natural
way to think about the option space from a file system developer
perspective, but maybe we could find som
only going to care when stable is released; people doing
production work on unstable or testing already know that they're signing
up for occasional breakage. So the proximity-to-release argument to me
feels most relevant if this change is specifically a problem for the
release process and
Package: tripwire
Version: 2.4.3.7-4+b3
Severity: grave
X-Debbugs-Cc: r...@debian.org
Looks like tripwire needs another rebuild against the latest libc6.
tripwire --check and tripwire --init both segfault once they start
analyzing the file system. Rebuilding the package with no changes
causes it
the wrong ownership and upgraded again
with USER and LOGNAME set to root, and now everything works fine. (Well,
my laptop gets extremely hot the first time I start the new Emacs, but I
assume that's expected for the new compilation system.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
yone else on Debian isn't seeing this.
I would have assumed it must be something in my startup files that is
incompatible with the latest release of Emacs, except I thought -q
--no-site-file should completely disable loading anything from my local
configuration.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: emacs-lucid
Version: 1:28.1+1-1
Severity: grave
X-Debbugs-Cc: r...@debian.org
The 28.1 version of emacs-lucid fails on startup with a cryptic error
message:
% emacs
Cannot find suitable directory for output in ‘comp-native-load-path’.
Running emacs -q allows it to start, but it still re
ither bump the SONAME for the dropped symbol,
or add an rk_closefrom wrapper around the glibc closefrom to keep the same
ABI. (Or break the ABI without changing the SONAME on the grounds that
only a few packages use it, but I'm pretty hesitant to recommend doing
that since who knows what outside of
; The whole perl + shell + makefile has also lot of duct tape included.
> I’ll either fix this directly in dh-php or provide the affected packages
> with a patch.
> 1. I don’t think missing dependency on PHP is a serious bug, it doesn’t
> prevent usage of the extension, it just doesn’
doing anything
as a package maintainer, or is this expected? Should it be a serious bug?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
pologies for the delay in fixing this! There
was a test suite change that requires an additional file from the source
tree be available and I need to fix the test configuration. Will fix this
shortly.
Thank you so much for generating these bug reports. They're incredibly
helpful!
--
Package: tripwire
Version: 2.4.3.7-3+b3
Followup-For: Bug #994910
Reproduced here following a libc6 upgrade. I suspect this is because
tripwire is statically linked and there has been a new release of libc6,
so I suspect the nsswitch interface has broken (which is a standard
problem with statical
Adrian Bunk writes:
> Source: docknot
> Version: 4.00-1
> Severity: serious
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/docknot/10221864/log.gz
Thank you for relaying those results! I forgot to go explicitly check.
Will fix shortly.
--
Russ Allbery (r..
#x27;t. I admit I have no idea on how
> to report a bug outside reportbug.
To add additional information to a bug, you can just send mail directly to
976...@bugs.debian.org with a regular mail client if you want. (reportbug
is very useful for getting all the right bits in place to open a ne
Russ Allbery writes:
> Adrian Bunk writes:
>> ...
>> lib/network/server..MISSED 34-42 (killed by signal 14)
>> ...
>> Failed Set Fail/Total (%) Skip Stat Failing Tests
>> -- -- -
provide two sockets ran fairly
deep.
I think the problem only affects the test suite.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Thanks, this is probably because that's one of the buildds with only IPv6
addresses. Working on a fix, will try to get it uploaded soon since I
know a Python transition is coming.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
gt; /etc/facter/facts.d
> /etc/puppetlabs/facter/facts.d
> /opt/puppetlabs/facter/facts.d
Yup, confirmed that works. Thank you!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: facter
Version: 3.11.0-4.1
Severity: grave
facter no longer works at all on amd64. When invoked, it dies with
an invalid pointer error:
% facter
free(): invalid pointer
Aborted (core dumped)
gdb backtrace:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0
e-only upload to DELAYED/15, closing this
> bug. Please let me know if I should delay or cancel that upload.
Oh, whoops, sorry. Thank you for letting me know! I'll do the source
upload myself, since that way it's easy for me to keep the Git history
consistent. I can do that this eve
Marco d'Itri writes:
> On Jan 20, Russ Allbery wrote:
>> This also implies that there is arguably an SONAME issue with this library
>> given that two versions of the library with the same SONAME don't provide
>> the same symbols, but I suspect there were really
e for me (but now I wonder if I have other
> leftover files like this…).
This also implies that there is arguably an SONAME issue with this library
given that two versions of the library with the same SONAME don't provide
the same symbols, but I suspect there were really, really good reasons
Andreas Beckmann writes:
> Followup-For: Bug #932351
> Control: tag -1 pending
> buster-pu request: https://bugs.debian.org/948796
Oh, thank you! I was going to get to that and then didn't. Much
appreciated and let me know if I can help in any way.
--
Russ Allbery (r
Now fixed, although I got the changelog message wrong because I still
didn't understand properly. Ugh. I could have sworn that Debian buildds
didn't allow network access. I'll fix the changelog message in a future
upload.
Thank you!
--
Russ Allbery (r...@debian.org)
Now fixed, although I got the changelog message wrong because I still
didn't understand properly. Ugh. I could have sworn that Debian buildds
didn't allow network access. I'll fix the changelog message in a future
upload.
Thank you!
--
Russ Allbery (r...@debian.org)
s smarter than apparently it actually
is (I thought it would know that an unversioned dependency on typing was
already satisfied by Python 3 stdlib). Will fix tonight.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
thought setuptools was much smarter than apparently it
actually is. I'll look at this tonight; I may fix this upstream instead
of only in the Debian package if it doesn't take too long to do.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
I'll fix this for unstable and will see about getting a targeted fix into
stable as well, although it won't go out, at best, until the next point
release.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
nated
> I got the same result on two different machines, over Wayland and X11.
I can't reproduce this.
Can you enable core dumps (ulimit -c unlimited) and then run gdb on the
corresponding core dump (gdb /usr/games/gnubg core) and then run backtrace
and show the backtrace for this?
--
Rus
e with kernel
errors like:
[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo
underrun on pipe B
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO
underrun
and then lots and lots of:
[drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle
patt
ed yet.
> https://lwn.net/Articles/664800/
The work is actively underway in both the kernel and in glibc, but I don't
think it's fully working in buster. I would expect it to be there by the
next Debian release, though.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: rssh
Version: 2.3.4-8
Severity: grave
Tags: security upstream
https://sourceforge.net/p/rssh/mailman/message/36519118/ is the upstream
report. The reporter indicated they asked for a CVE but didn't include it
in the message.
scp allows remote code execution inside the server environment
nfinite loop during byte-compilation does make it feel like there may
be some underlying but in Emacs as well, since that doesn't feel like
something that should be possible, but it may not be detectable or
avoidable depending on what the cause was.)
--
Russ Allbery (r...@debian.org)
rome_gnome_shell.json
Splitting that single config file into a separate contrib package feels
like overkill here. It shouldn't hurt anything on a system without Chrome
and it doesn't create any sort of dependency on Chrome, which is the
normal case for contrib.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Vincent Lefevre writes:
> On 2018-09-11 15:29:02 -0700, Russ Allbery wrote:
>> Vincent Lefevre writes:
>>> This would mean that a breakage is possible after any patch (in
>>> particular with those "Update to SVN..." in the changelog). Thus this
>>
one used to build the kernel. For
> sid, GCC is often not in sync with the one used to build the
> kernel. This is a really big problem.
I don't think it's an NVIDIA-specific problem, though, right? Doesn't
this happen with any kernel module build? Or am I confused and
te an unsatisfiable dependency since the compiler packages aren't
broken apart that way.)
> If the minor version really matters, why Debian doesn't ship different
> packages, such as gcc-6.3 and gcc-6.4?
I suspect that usually only the kernel is affected.
--
Russ Allbery (r
It is the obligation of
> the one doing the change to ensure proper availability of modules and
> support files.
There were literally zero packages in Debian that did this that Lintian
could find. Did we miss something?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
' failed
> make[2]: *** [policy.pdf] Error 127
> Since Sphinx 1.6, latexmk is required to build the LaTeX documentation [1].
> Adding a build-dependency on latexmk should help.
Thanks, fixed in Git. We'll need to make a new upload shortly.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ng for the
employer who had that problem). If someone runs into a need for it, they
can always circle back and look at the package again. It seemed pretty
seriously unmaintained.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
esponding base-files change has been uploaded.
(It will probably actually be 3.10.0.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
se of action).
Yeah, this is a good argument. Works for me! It's also good to use a
more robust mechanism for doing this so that we don't get accidental
problems in the future when the locking stuff changes again.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e init script and this ended up being better, but I forget the
history.
I think restoring the disable logic may be all that's required.
Thank you for looking at this!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
n start and try to use the server
named "puppet" as a Puppet master on package installation is pretty bad.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ror message you give
doesn't even have anything to do with this module?
Lots of people are using this package in jessie, so the chances are
extremely low that it's actually broken for everyone.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ll the pieces are happy. (The OpenSSL work is
done in a separate daemon, shibd, that the Apache module talks to.)
(Not that this solves all the problems, but just FYI.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
debian-devel?
This seems like something we're going to have to figure out project-wide,
since the way the transition is currently set up doesn't seem likely to
work.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
'm not sure there's any other alternative.
Whatever dependencies that were pushing open-vm-tools to 1.1 may have to
be reverted back to 1.0.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
losely) than
letting it use its normal upgrade semantics. (Also, a general upgrade is
safer in that you'll always get security updates.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
against this by also checking for a
string containing $(hostname), but if you happen to know what the reverse
DNS is for 127.0.0.1 in the test environment, I'll make sure this is
caught.
Downgrading since this shouldn't be a problem for Debian proper; this
seems to work fine on all the b
hem back to the default value, both lbcd and remctl build
> fine.
Ah, thank you! I'll see if I can adjust the test to be less fragile.
Usually some minor tuning will resolve issues like this. (It's
irritatingly difficult to properly test network code because the OS loves
hiding things like
l FTBFS for anyone building it.
Thanks for the report! I won't get a chance to get to this until this
weekend, but I'll definitely take a look and try to get it fixed then.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ferenc Wagner writes:
> Russ Allbery writes:
>> I think I was just confused and everything is fine, since the
>> transition already happened after the previous NMU. There's still a
>> transition for opensaml2 and shibboleth-sp2, I think, but that's tiny
>&g
ib propagates everywhere just in case.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
I forgot about that until just
after I uploaded it.
I'll open a bug against release.debian.org for the mini-transition.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ferenc Wagner writes:
> Please wait a little, I'm packaging the new upstream anyway and will
> introduce this change soon (I'll need a sponsor, though).
I should be able to help with sponsorship.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
> __len@entry= detected (257).>) at /usr/include/x86_64-linux-gnu/bits/string3.h:53
> 53
Hrm. Okay, so the compiler is doing something weird, and this isn't a
problem with libtasn1. Thanks for the additional information! I'm going
to reassign this to gcc-5, and mi
nstable and running gnubg. To get the above backtrace, I just
grabbed the source package, did apt-get build-dep gnubg, debian/rules
build, and installed the debugging packages for libgnutls and libtasn1.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
the
version I uploaded wasn't built with PIE.
I can reproduce this, trying to figure out what's going on right now.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
CE_DATE_EPOCH support from podlators-4.00
> doesn't itself survive being build with SOURCE_DATE_EPOCH (or
> POD_MAN_DATE, for that matter) set. Patch attached.
podlators 4.03 released with this fix.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Niko Tyni writes:
> Turns out the backported SOURCE_DATE_EPOCH support from podlators-4.00
> doesn't itself survive being build with SOURCE_DATE_EPOCH (or
> POD_MAN_DATE, for that matter) set. Patch attached.
Doh. Thanks. :) I'll kick out a new version, probably this
Package: golang-golang-x-tools
Version: 1:0.0~git20150716.0.87156cb+dfsg1-4
Severity: serious
Unpacking golang-golang-x-tools (1:0.0~git20150716.0.87156cb+dfsg1-4) ...
dpkg: error processing archive
/var/cache/apt/archives/golang-golang-x-tools_1%3a0.0~git20150716.0.87156cb+dfsg1-4_amd64.deb
(--
, just don't be too concerned about the fate of
> the current versions in unstable, expect new upstream versions after a
> couple of weeks.
If you're changing the SONAME anyway, you don't have to do the renaming
described here. That's actually an even cleaner solution.
Just one more data point:
I just upgraded another system using assword, with a separate private key
that was generated on 2014-08-20, and everything worked fine with it. And
I don't get the legacy keys errors on that system either.
--
Russ Allbery (r...@debian.org)
ond command actually
imported the secret key as well (in that I saw "1 key imported" in the
resulting message). For some reason, all my other secret keys were
successfully imported. Just not that one.
> do you know if there were more "legacy key" messages for the seco
mmand works:
mithrandir:~$ gpg2 -kv D15D313882004173
gpg: using classic trust model
pub rsa4096/D15D313882004173 2009-05-29 [expires: 2017-09-17]
uid [ultimate] Russ Allbery
uid [ultimate] Russ Allbery
uid [ultimate] Russ Allbery
uid
09-05-29 [expires: 2017-09-17]
uid [ultimate] Russ Allbery
uid [ultimate] Russ Allbery
uid [ultimate] Russ Allbery
uid [ revoked] Russ Allbery
uid [ultimate] Russ Allbery
sub 4096R/7CE29A76E9769486 2009-05-29 [expires: 20
ale/en/LC_MESSAGES/libgpg-error.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
close(3)= 0
munmap(0x7f988d24e000, 4096)= 0
write(2, "Assword database error: Decrypti"..., 59Assword database error:
Decryption error: Decryption failed) = 59
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: assword
Version: 0.8-2
Severity: grave
assword can no longer decrypt any of my password stores. It fails with
the error:
mithrandir:~$ assword dump foo
Assword database error: Decryption error: Decryption failed
The data store is not corrupt; running GnuPG on it manually works fine.
Th
critical. (Meaning that I don't think we should remove this
package from the release if no one gets to this.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject
Vincent Lefevre writes:
> On 2015-03-21 13:14:08 -0700, Russ Allbery wrote:
>> Correct. The Policy statement is about preserving user changes, not
>> about never touching any file that a user has modified in any way. The
>> package is free to modify unchanged portions of t
er
the benefit of the change is worth the disruption of changed behavior on
upgrades.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
e unusual. I
> don't think it makes sense to regard that as a particularly `strict'.
There are certainly other packages in the archive with Perl maintainer
scripts, although the ones I'm aware of I don't think use modules that
have moved.
--
Russ Allbery (r...@debian.or
tart/reload/status, and update-rc.d for enable/disable.
That should do the right thing in all three init systems.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ders are
"supposed" to interact, and a tiny bit more welcoming.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
tch that I think is a bit cleaner should a later backport be done, but I
think your change will work fine.
Sorry about that oversight!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
w
try to take a look, but I no longer use Shibboleth and handed the
package maintenance off. Copying the general mailing list.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of
nd presumably a process crash. But to create
this situation, the attacker has to nearly exhaust all process memory, and
could just go a step farther and exhaust all memory, which would almost
certainly result in a process crash anyway, or an OOM kill.
Am I overlooking something?
--
Russ A
said, this is also partly
pkgconfig's fault for not separating CFLAGS and CPPFLAGS.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
I would hope is a very small change, and it's one
that upstream should accept fairly readily.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
upgraded Network Manager a while
back, so this explains that as well. Sorry about the incorrect diagnosis!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
anges, but for the
record, there's no need to have the discussion again after a library
SONAME change. Pre-Depends on libraries should be assumed to track SONAME
changes in that library.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE
vide that.
There's no reason to switch away from inittab for sysvinit. For systemd,
a unit file can easily do everything that you would get from inittab.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@l
1 - 100 of 509 matches
Mail list logo
