Hi,
On 21/06/2022 01:31, Sean Whitton wrote:
Hello,
I hereby call for votes on the following resolution:
BEGIN BALLOT
Using its powers under constitution 6.1.5, the Technical Committee
issues the following advice:
1. It is not a bug of any severity for a package with a non-native
On 07/06/2022 07:08, Sean Whitton wrote:
I agree, it's not about the benefits of the source format, we do indeed
understand all the trade-offs by now. It's that certain ideas and
workflows *which are not really about source packages* are made
inconvenient or impossible if we remove this
Hi,
Would you like me to prepare an upload for these, or are you working on
this?
[sorry, it's not clear from the bug report]
Thanks,
Matthew
Hi,
I thought it might be useful to try and summarize where we are with this
bug, which hasn't see much recent activity (not least as there's a TC
meeting later...).
* Questions asked of the TC
The Committee was invited to issue advice on a number of points:
I - continued use of 1.0 native
On 20/04/2022 15:31, Matthew Vernon wrote:
I hereby call for a vote on the following ballot. Unless a TC member
objects to calling for a vote, voting lasts for a week, or until the
result is no longer in doubt.
The voting period is over.
===Rationale
There are two "rename"
Hi,
I hereby call for a vote on the following ballot. Unless a TC member
objects to calling for a vote, voting lasts for a week, or until the
result is no longer in doubt.
===Rationale
There are two "rename" programs - the perl rename, and the util-linux
rename. Debian and its derivatives
Hi,
Thanks for this.
1. While the former "should" is guarded by "requires", I think the
latter can be read as a recommendation. I therefore propose replacing
it with "must" to make the override more obvious.
2. While option B reads fine to me, option A is a little confusing to
me
Hi,
Thanks for the feedback on my previous draft; here's a revised ballot.
I propose a ballot as follows - if no-one suggests further options in
the mean time, I will call for a vote on this ballot on Tuesday, after
the weekend of public holidays.
From a procedural point of view, I am
On 15/04/2022 07:36, Gunnar Wolf wrote:
Matthew Vernon dijo [Thu, Apr 14, 2022 at 04:47:17PM +0100]:
Backwards-compatibility (and the lack of a compelling argument that
util-linux's rename is significantly superior to the perl rename) means that
/usr/bin/rename in Debian should remain the perl
Hi,
Thanks to everyone for your contributions to this discussion. I think
we're at the point where voting is appropriate.
I propose a ballot as follows - if no-one suggests further options in
the mean time, I will call for a vote on this ballot on Tuesday, after
the weekend of public
Hi,
Upstream already have a Hurd build fix (
https://github.com/PhilipHazel/pcre2/commit/adf76faace83d2b926b9136821daa02a78266b95
), which I've applied to my tree, and uploaded as 10.39-4.
Regards,
Matthew
Tags 1009066 +upstream
quit
On 06/04/2022 20:33, Yavor Doganov wrote:
This packages fails to build on hurd-i386 as of version 10.39-1;
from the last build log for 10.39-3 [1]:
Thanks; the patch looks reasonable to me (and my local tree works OK
with it applied); I've sent it upstream for
Hi,
On 09/04/2022 14:59, Chris Hofstaedtler wrote:
I was not planning on doing that: stable already does not have
/usr/bin/rename.ul.
People were asking for it to be restored before the stable release,
though, I think? #966468 was opened against version 2.36-1 back in July
2020.
Given
Hi,
On 29/03/2022 00:55, Sean Whitton wrote:
On Mon 28 Mar 2022 at 10:35PM +02, Christoph Berg wrote:
The problem here is that if ul-extra contains things besides rename,
and it conflicts with the perl rename, people will rightfully complain
that they can't install
On 25/03/2022 16:25, Russ Allbery wrote:
Luca Boccassi writes:
But anyway, it turns out it's all moot because - drum roll - there is a
patch:
https://0x0.st/oNFG.diff
This was shared just now on #debian-devel IRC by user 'uau', linked
here with explicit permission.
This is fantastic,
On 17/03/2022 17:52, Russ Allbery wrote:
Helmut Grohne writes:
Do you think it would be impossible to move forward on this matter in a
consensus-based way?
I don't know. I have some reasons to be dubious, but it's possible that
I'm being excessively pessimistic.
I'm inclined to agree
Hi,
I have uploaded bible-kjv 4.34+deb11u1 for bullseye in the light of the
announced forthcoming stable point release. I hope this is in order :)
Regards,
Matthew
On 16/02/2022 10:18, Jon Daley wrote:
On Wed, 16 Feb 2022, Matthew Vernon wrote:
[Debian policy is usually that bugs need to be "Important" priority or
higher for fixes to be considered for a stable point release. I'm
assuming you don't think that applies here]
Ok, thanks. J
+bible-kjv (4.34+deb11u1) bullseye; urgency=medium
+
+ * Fix off-by-one-error in search (Closes: #1005856)
+
+ -- Matthew Vernon Wed, 16 Feb 2022 11:15:11 +
+
bible-kjv (4.34) unstable; urgency=medium
* Check for error return value
diff -Nru bible-kjv-4.34/makeconc.pl bible-kjv-4.
Package: python3
Version: 3.9.2-3
Severity: normal
Tags: upstream
Hi,
sys.excepthook is called to handle any uncaught exception, other than
SystemExit.
This behaviour is described correctly in help(sys).
help(sys.excepthook) and the web documentation[0] both lack the IMO
important fact that
Hi,
Having joined the committee, I thought it best to try and get up to
speed on this issue. Is my summary correct?
--begin
There are two "rename" programs, one part of upstream util-linux
"rename.ul" and one provided by the rename package "rename.pl"[0]
For a long time, Debian's
===BEGIN
A: Christoph Berg
B: Helmut Grohne
C: Elana Hashman
D: Simon McVittie
E: Niko Tyni
F: Matthew Vernon
G: Sean Whitton
H: Gunnar Wolf
===END
G > A = C = D = E = H > B = F
[rationale: being new I don't really have much of an opinion, other than
the new chair pr
On 05/12/2021 12:58, Jonas Smedegaard wrote:
Sounds sensible to me - I'll make sure to add the Conflicts: to iwd.
Cool; I've just uploaded orphan-sysvinit-scripts 0.11 to unstable.
Thanks,
Matthew
On 01/12/2021 08:51, Jonas Smedegaard wrote:
Quoting Job Bautista (2021-12-01 04:11:38)
Matthew Vernon wrote:
On 30/11/2021 15:50, Job Bautista wrote:
Package: orphan-sysvinit-scripts
Version: 0.10
Severity: normal
X-Debbugs-Cc: jobbautis...@protonmail.com
Please remove iwd's init script
Hi,
On 24/11/2021 15:42, Stéphane Glondu wrote:
Le 18/11/2021 à 12:49, Matthew Vernon a écrit :
Your package still depends on the old, obsolete PCRE3[0] libraries
(i.e. libpcre3-dev). This has been end of life for a while now, and
upstream do not intend to fix any further bugs
Hi,
On 22/11/2021 09:16, Ondřej Surý wrote:
I analysed the problem in:
https://github.com/PhilipHazel/pcre2/issues/56
Thanks! I've had a read of that, and AIUI it's a behaviour change
(matching that of perl) rather than an ABI change?
I guess bumping the version in the symbols file
Hi,
On 30/11/2021 15:50, Job Bautista wrote:
Package: orphan-sysvinit-scripts
Version: 0.10
Severity: normal
X-Debbugs-Cc: jobbautis...@protonmail.com
Please remove iwd's init script, as it's added now in iwd 1.20-2.
This will need some co-ordination, I think; orphan-sysvinit-scripts uses
On 21/11/2021 22:48, Thorsten Glaser wrote:
On Sun, 21 Nov 2021, tito wrote:
couldn't renaming the scripts in the orphan-sysvinit-scripts package
be a solution to solve this?
I think that breaks user expectations and should only be a
very last resort.
I agree.
I think both the “cp”,
Hi,
On 21/11/2021 01:09, Axel Beckert wrote:
Seems to have worked for me, but now I get the same error for
/etc/init.d/nftables:
Setting up orphan-sysvinit-scripts (0.10) ...
/usr/bin/which: this version of `which' is deprecated; use `command -v' in
scripts instead.
/usr/bin/which: this
Hi,
On 18/11/2021 14:10, Simon McVittie wrote:
On Thu, 18 Nov 2021 at 11:49:04 +, Matthew Vernon wrote:
Your package still depends on the old, obsolete PCRE3[0] libraries
(i.e. libpcre3-dev).
As I'm sure you're already aware, in the case of GLib this is something
that needs
On 18/11/2021 15:11, Mattia Rizzolo wrote:
On Thu, Nov 18, 2021 at 11:49:07AM +, Matthew Vernon wrote:
The newer PCRE2 library was first released in 2015, and has been in
Debian since stretch. Upstream's documentation for PCRE2 is available
here: https://pcre.org/current/doc/html/
Sigil's
On 18/11/2021 12:28, Barak A. Pearlmutter wrote:
It looks to me like the pcre3 dependency in the terminus package is
entirely due to its use of valac and other build support. There
doesn't appear to be any direct use, except in a build dependency.
If I remove that build dependency, libpcre3-dev
Hi,
On 18/11/2021 12:44, Christoph Berg wrote:
Re: Matthew Vernon
Many large projects that use PCRE have made the switch now (e.g. git,
php); it does involve some work,
is there some migration guide? The upstream homepage doesn't seem to
have anything.
Regrettably not; the PHP folk did
On 18/11/2021 12:06, Marco d'Itri wrote:
On Nov 18, Matthew Vernon wrote:
Many large projects that use PCRE have made the switch now (e.g. git,
php); it does involve some work, but we are now at the stage where
PCRE3 should not be used, particularly if it might ever be exposed to
untrusted
Hi,
On 15/11/2021 14:34, Ondřej Surý wrote:
This appears when built with 10.39, but the runtime version is less than that.
My guess is that this needs manual debian/libpcre2-8.shlibs override. (Or just
mangle the symbols file, so it always generates correct versioned dependency.)
I've had
Hi,
On 15/11/2021 14:03, Ondřej Surý wrote:
It’s still a bug, but I think it might be a bug in pcre2. The other
Matthew (in CC) might need to bump the shlibs on the shared lib to >= 10.39
I'm slightly confused - this appears to be an issue in a php function
that went away after an upgrade?
On 10/11/2021 16:51, Adam Borowski wrote:
On Wed, Nov 10, 2021 at 12:21:09PM +, Debian Bug Tracking System wrote:
#998893: orphan-sysvinit-scripts: fails to configure: "not replacing deleted config
file /etc/init.d/rsyslog"
It has been closed by Debian FTP Masters (reply t
Hi,
On 10/11/2021 09:37, Matthew Vernon wrote:
On 09/11/2021 15:17, Adam Borowski wrote:
Not replacing deleted config file /etc/init.d/rsyslog
This is the problem - ucf thinks that it knew about /etc/init.d/rsyslog
before it got deleted (and so it thinks you deliberately removed
Hi,
On 10/11/2021 07:35, Dirk Griesbach wrote:
While rsyslog doesn't ship its init script anymore, ucf is still having
a reference to that script after the rsyslog upgrade.
,
| # ls -l /var/lib/ucf/cache/*rsyslog*
| -rwxr-xr-x 1 root root 2864 5. Nov 01:24
Hi,
On 09/11/2021 15:17, Adam Borowski wrote:
Not replacing deleted config file /etc/init.d/rsyslog
This is the problem - ucf thinks that it knew about /etc/init.d/rsyslog
before it got deleted (and so it thinks you deliberately removed it).
AFAICT:
This should happen if and only iff
On 09/11/2021 15:45, gregor herrmann wrote:
On Tue, 09 Nov 2021 16:17:31 +0100, Adam Borowski wrote:
On two different setups, I get:
Not replacing deleted config file /etc/init.d/rsyslog
update-rc.d: error: initscript does not exist: /etc/init.d/rsyslog
dpkg: error processing package
Hi,
On 07/11/2021 15:52, Diederik de Haas wrote:
On Sunday, 7 November 2021 13:08:38 CET Matthew Vernon wrote:
On 24/12/2020 11:56, Diederik de Haas wrote:
The short answer is because you installed something that depends on the
8-bit runtime version.
I actually knew that, but I should've
Hi,
On 24/12/2020 11:56, Diederik de Haas wrote:
On my system I have the 8/16/32 bit versions of the pcre2 library
installed.
The discription only tells me that this is the 8-bit runtime version.
But I have no idea why I/anyone would want a 8-bit runtime on my 64-bit
machine, where I'd
Hi,
On 04/11/2021 17:18, Michael Biebl wrote:
I haven't made up my mind on this one yet. There are pros and cons.
If we continue to install rsyslog alongside journald by default, then
using imjournal is imho the more logical choice.
That said, I actually think we should no longer do that to
Hi,
On 02/11/2021 16:41, Michael Biebl wrote:
I intend to remove the SysV init script from the rsyslog package with the
next upload.
Maybe you are interested in taking maintainership for the file.
Thanks for letting me know; I've taken the version from debian/master on
salsa, and it'll be
Hi,
On 25/10/2021 17:21, Mathieu ROY wrote:
powerdns packaged removed then working init script. You might consider
including them in your package.
I was about to send you a working version but the debian developer in
charge of powerdns, apparently tied to powerdns development, made me
Hi,
On 20/10/2021 15:29, Jesse Smith wrote:
Is there a reason for wanting to revert this behaviour instead of using
the "-z" flag on the command line? If you use pidof a lot and expect to
see processes that are in the uninterruptable sleep state then making an
alias of pidof='pidof -z' seems
On 26/08/2021 21:45, Holger Wansing wrote:
Hi,
Am 26. August 2021 09:24:58 MESZ schrieb Matthew Vernon :
Hi,
Could someone merge
https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/15
please?
It's the smaller change that folk asked for :)
I wonder if "the ea
Hi,
Could someone merge
https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/15
please?
It's the smaller change that folk asked for :)
Thanks,
Matthew
rom 6e6b681d094294b2bd0eaf5c1f55da591935b91e Mon Sep 17 00:00:00 2001
From: Matthew Vernon
Date: Sun, 15 Aug 2021 16:49:36 +0100
Subject: [PATCH] Short note on installing alternative inits (Closes: #992034)
Discussion on the BTS apropos this bug / !14 suggests that a shorter
note with a link to more detailed discussion on the wiki wo
Hi,
On 14/08/2021 08:42, Paul Gevers wrote:
On 09-08-2021 22:53, Matthew Vernon wrote:
Not currently (I imagine something like it will end up there
eventually); I think it warrants being in the release notes because it's
quite a significant change from Buster (where non-systemd inits were
On 09/08/2021 20:01, Holger Wansing wrote:
I tend to see it this way:
The installation-guide documents the functionality of
debian-installer.
That change-init-system-during-install thing is not a function
of d-i (means: there is no question asking the user what init
system shall be used, or
On 09/08/2021 21:34, Paul Gevers wrote:
Short question (I'm low on time for this tonight): don't we have this
documented on the Wiki somewhere? It feels a bit long for the release notes.
Not currently (I imagine something like it will end up there
eventually); I think it warrants being in
Hi,
Sorry, correct patch this time :-/
Regards,
Matthew
>From a44e86218574309a747279d2cef3255772c0c632 Mon Sep 17 00:00:00 2001
From: Matthew Vernon
Date: Mon, 9 Aug 2021 11:37:12 +0100
Subject: [PATCH] Add a subsection on changing init system
It's slightly fiddly to switch init system a
rom: Matthew Vernon
Date: Mon, 9 Aug 2021 11:37:12 +0100
Subject: [PATCH] Add a subsection on changing init system
It's slightly fiddly to switch init system away from systemd, so
include a short note on doing so; and a pointer to the init-diversity
list for help.
---
en/issues.dbk |
On 09/08/2021 16:35, Samuel Thibault wrote:
Matthew Vernon, le lun. 09 août 2021 16:19:03 +0100, a ecrit:
I don't think adding a subsection at the bottom of "Using Individual
Components" is really burdening the casual systemd user! We wouldn't say
that a subsection on serial braill
On 09/08/2021 16:12, Cyril Brulebois wrote:
Holger Wansing (2021-08-09):
Am 9. August 2021 16:36:33 MESZ schrieb Matthew Vernon :
Source: installation-guide
Severity: normal
Tags: patch
Hi,
I've drafted a note on how to switch init system during the
installation process; it's easiest to do
On 09/08/2021 15:57, Holger Wansing wrote:
Am 9. August 2021 16:36:33 MESZ schrieb Matthew Vernon :
Source: installation-guide
Severity: normal
Tags: patch
Hi,
I've drafted a note on how to switch init system during the
installation process; it's easiest to do it at this point rather than
=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From 8a1342942cedd48a4a5655e9efc07e6bbd23bff5 Mon Sep 17 00:00:00 2001
From: Matthew Vernon
Date: Mon, 9 Aug 2021 15:32:27 +0100
Subject: [PATCH] Notes on install
Hi,
Thanks for your comments; I'll try and make a revised patch.
On 09/08/2021 12:56, Justin B Rye wrote:
Matthew Vernon wrote:
+ init systems, you install the new init system and reboot. The
+ exception is switching away from systemd - systemd's packages
(We don't seem
: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From 8b723915627d2546d4266d360cc41fbf3f7c6ebf Mon Sep 17 00:00:00 2001
From: Matthew Vernon
Date: Mon, 9 Aug 2021 11:37:12 +0100
Subject: [PATCH] Add a subsection on changing init system
It's slightly fiddly to switch init system a
Package: installation-reports
Severity: normal
Tags: d-i
Boot method: USB
Image version:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/bullseye_di_rc2+nonfree/amd64/iso-cd/firmware-bullseye-DI-rc2-amd64-netinst.iso
Date: 2021-07-20
Machine: Lenovo Thinkpad X1
00
@@ -1,3 +1,16 @@
+bible-kjv (4.34) unstable; urgency=medium
+
+ * Check for error return value
+
+ -- Matthew Vernon Mon, 19 Jul 2021 12:36:43 +0100
+
+bible-kjv (4.33) unstable; urgency=medium
+
+ * Make the build not run in parallel
+ * Use bible.rawtext to build concordance (Closes: #991133)
+
Hi,
The other bug was that makeconc.pl tries to run "bible -f
gen1:1-rev99:99" to generate the text it builds the raw concordance
from; obviously this doesn't work on chroots / buildds.
It's also unnecessary, since we have the rawtext file in the source
tree, so use that instead.
This now
tags 991133 +pending -help
quit
Hi,
Right, the issue is that the Makefile isn't parallel-build safe (see
e.g. the re-entrant calls of Make for building the concordance);
Helmut's cross-building patch replaced $(MAKE) all (not parallel) with
some dh_auto_build calls (parallel), and that's
On 19/07/2021 09:56, Matthew Vernon wrote:
Hi,
More on this; a nostrip build works. If I take the unstripped executible
and strip it as I did in 4.31 (install -s), then the resulting stripped
executible also works.
So dh_strip (version in bullseye) is stripping too much out
severity 991133 important
tags 991133 +help
quit
bible(KJV) [Gen1:1]> ??hath
Searching for 'hath'... not found.
Huh. Thanks for reporting this.
If I build 4.32 on my (old-)stable system, this works.
Similarly, if I build 4.30 on my bullseye system, this works.
4.31 building on bullseye
Hi,
More on this; a nostrip build works. If I take the unstripped executible
and strip it as I did in 4.31 (install -s), then the resulting stripped
executible also works.
So dh_strip (version in bullseye) is stripping too much out of the
executible and that's breaking the search. dh_strip
On 04/03/2021 14:20, Matthew Vernon wrote:
On 04/03/2021 14:01, Matteo Croce wrote:
On Thu, Mar 4, 2021 at 2:53 PM Matthew Vernon wrote:
On 04/03/2021 13:36, Matteo Croce wrote:
I'm seeing it multiple times now during an upgrade:
Which version of insserv have you got? 1.21.0-1.1 (which we
Hi,
I just got orphan-sysvinit-scripts pulled in on a few boxes where I
happen to have nftables installed but rules are still defined and
loaded by iptables, called by a locally-defined init script.
I'm slightly confused by your report, sorry. Historically nftables did
have a sysvinit script
On 04/03/2021 14:01, Matteo Croce wrote:
On Thu, Mar 4, 2021 at 2:53 PM Matthew Vernon wrote:
On 04/03/2021 13:36, Matteo Croce wrote:
I'm seeing it multiple times now during an upgrade:
Which version of insserv have you got? 1.21.0-1.1 (which we expect to
fix this) isn't yet in testing
Hi,
On 04/03/2021 13:36, Matteo Croce wrote:
I'm seeing it multiple times now during an upgrade:
Which version of insserv have you got? 1.21.0-1.1 (which we expect to
fix this) isn't yet in testing.
Regards,
Matthew
On 21/02/2021 22:30, Vincent Lefevre wrote:
On 2021-02-21 14:06:20 -0400, Jesse Smith wrote:
A new version of SysV init and innserv have been published today. The
new version of insserv (1.23.0) fixes the above issue. It can be
downloaded from here:
Default-{Start,Stop} more clearly
+(Closes: #971713)
+
+ -- Matthew Vernon Sun, 21 Feb 2021 17:13:07 +
+
insserv (1.21.0-1) unstable; urgency=medium
* New upstream release
diff --git a/debian/patches/patches-from-trek-closes-971713.patch b/debian/patches/patches-from-trek-closes-971713
On 15/12/2020 21:34, Jesse Smith wrote:
On 2020-12-15 5:04 p.m., Trek wrote:
On Tue, 15 Dec 2020 12:45:40 -0400
Jesse Smith wrote:
I gave the patch a test run and, while I like what it does in theory,
in practise I'm running into trouble with it. When I use the attached
patch and then run
Hi,
If you install the "orphan-sysvinit-scripts" package, that contains an
init script for (among other things) network-manager.
HTH,
Matthew
package: sysvinit-core
version: 2.96-5
severity: important
Hi,
Prompted by the filing of #981747 (another person falling foul of
network-manager no longer shipping an init script), I think
sysvinit-core should Recommends: orphan-sysvinit-scripts ?
That will make it a bit easier for folk to
Hi,
[Please keep the BTS copied in on mails about this]
On 31/01/2021 14:16, Hamid Alaei V. wrote:
I think php is built with pcre 10.35 not 10.36.
Right, but that's nothing to do with Debian - if you got a PHP package
from Debian (or built on a Debian bullseye system), then it would be
tags +moreinfo
quit
On 31/01/2021 08:28, hamid wrote:
Version: 10.35-5+ubuntu18.04.1+deb.sury.org+1
This isn't a Debian version number, rather an Ubuntu one.
I had a conversation in php bugs
(https://bugs.php.net/bug.php?id=79363=2). According to the maintainer,
Ubuntu (I guess in that
Hi,
This bug got mentioned in a TC thread; it occurs to me that
orphan-sysvinit-scripts might provide a home for these scripts (and has
much of the ucf machinery available to DTRT with the conf-files).
Unless anyone feels very strongly, though, I'd suggest looking at this
after the bullseye
On 17/01/2021 10:29, Andreas Henriksson wrote:
Possibly getting off topic here, but I happened to read a bit of this
discussion and while seeing your comment I thought it might be a good
time to remind you about #934463.
I agree it's off-topic here, so I've sent a message to that bug
On 16/01/2021 01:39, Gunnar Wolf wrote:
Matthew Vernon dijo [Mon, Jan 11, 2021 at 09:07:03PM +]:
Please overrule the maintainer in #923387 so that it is can be used on
systems with elogind; it has been tested and shown to work thus as well as
being supported by upstream[1
Hi,
On 10/01/2021 20:03, Simon McVittie wrote:
If you intend the scope of this bug to involve overruling maintainers'
decisions in packages other than NM, what other packages/bugs did you
have in mind? Is it just udisks2/#923387, or are there more?
I understand (but I don't think it has been
Hi,
I see that network-manager 1.28.0-2 has been uploaded, with (inter alia)
the following changelog entry:
* Demote libpam-systemd to Recommends.
This allows users to use and experiment with other init systems. Such a
setup is neither tested nor fully supported and users need to be aware
On 19/12/2020 21:00, Bastian Germann wrote:
Am 19.12.20 um 20:28 schrieb Matthew Vernon:
On 19/12/2020 13:28, Bastian Germann wrote:
On Fri, 18 Dec 2020 00:01:10 +0100 Bastian Germann
wrote:> bible-kjv package claims to be
GPLv2 licensed. One file has an "or
later" clause but so
Hi,
On 21/12/2020 23:36, Elana Hashman wrote:
The maintainer, Michael Biebl, reached out to the tech-ctte privately. I
have summarized his reasoning for why he dropped support for elogind and
the init script that prompted this bug:
Thanks. There's little point trying to have this discussion
On 19/12/2020 13:28, Bastian Germann wrote:
On Fri, 18 Dec 2020 00:01:10 +0100 Bastian Germann
wrote:> bible-kjv package claims to be
GPLv2 licensed. One file has an "or
later" clause but some files seem to GPLv2-only. However, with the
switch to readline6 (#553733), it uses a GPLv3 library.
On 14/12/2020 21:56, Philip Hands wrote:
Could I just check if there's a point of common acceptability which both
sides of this discussion could live with?
[...]
My suggestion for a mutually bearable solution would be that the
network-manager package could have its dependency on
On 15/12/2020 22:07, Sam Hartman wrote:
However, Debian remains an environment where developers and users can
explore and develop alternate init systems and alternatives to systemd
features. Those interested in exploring such alternatives need to
provide the necessary development and packaging
at 17:33:26 +, Matthew Vernon wrote:
I invite the technical committee to rule that:
* The network-manager init script should be restored
* Network-manager should Depend: on default-logind | logind rather than
libpam-systemd
This looks like a request to use the technical committee's power
[I don't need a CC, thanks]
Hi,
I know it was mentioned back in the day, but trying to re-ask it now:
Wouldn't it be possible to ship init scripts for compatibility purposes
from a sysvinit (or maybe a sysvinit-support) package? This would be the
inverse of what happened back when systemd was
Package: tech-ctte
Control: block 921012 by -1
Control: block 964139 by -1
X-Debbugs-CC: debian-init-divers...@chiark.greenend.org.uk
Dear Technical Committee,
This bug report relates specifically to bugs in the network-manager
package (#921012, #964139) but has broader implications,
On 16/09/2020 18:33, Ansgar wrote:
Matthew Vernon wrote:
On 15/09/2020 19:26, Michael Biebl wrote:
I don't agree with this NMU. Please cancel it.
I did so.
Huh; I thought that was the uploader's (i.e. my) responsibility. Doing
so was on my TODO.
Could you please explain what
Dear Michael,
On 15/09/2020 20:37, Michael Biebl wrote:
The removal of the SysV init script was not a mistake that needs to be
corrected.
You appreciate that both the restoration of the init script and use of
the logind virtual package are both essential for network-manager to be
Dear Michael,
On 15/09/2020 19:53, Michael Biebl wrote:
Am 15.09.20 um 20:45 schrieb Matthew Vernon:
Hi,
On 15/09/2020 19:26, Michael Biebl wrote:
Am 15.09.20 um 19:44 schrieb Matthew Vernon:
Hi,
These two related init compatibility issues haven't seen any activity
recently, so I've
Hi,
On 15/09/2020 19:26, Michael Biebl wrote:
Am 15.09.20 um 19:44 schrieb Matthew Vernon:
Hi,
These two related init compatibility issues haven't seen any activity
recently, so I've uploaded an NMU (delayed/14) to fix them in line with
the patches already posted; in the case of the init
be sending you an MR on salsa.
HTH,
Matthew
>From f6cb26bcc9b54d75f6e343019714cd905afe1cc1 Mon Sep 17 00:00:00 2001
From: Matthew Vernon
Date: Sun, 13 Sep 2020 12:42:23 +0100
Subject: [PATCH 1/3] Revert "Remove SysV init script" (closes: #964139)
This r
Package: dovecot-imapd
Version: 1:2.2.27-3+deb9u6
Severity: important
Hi,
One of my IMAP users reports failures when trying to do full-text
searches of a large (3G) mailbox; subject-only searches are OK.
The backtrace in syslog is:
Sep 15 11:51:37 aragorn dovecot: imap(atreic): Panic: file
Hi,
We encountered this issue, too - many of our systems are setup in the
smarthost config, with /etc/mailname set to sanger.ac.uk. This mostly
works - central LDAP means that user fred will reliably by fred at
sanger.ac.uk, and so on.
The downside is that we can't then e.g. alias 'root' so
On 16/06/2020 20:21, Helge Kreutzmann wrote:
Hello Matthew,
thanks for your reply.
On Tue, Jun 16, 2020 at 07:24:29PM +0100, Matthew Vernon wrote:
On 13/06/2020 20:44, Helge Kreutzmann wrote:
gcc -g -O2 -fdebug-prefix-map=/tmp/testfoo2/linuxinfo-3.1.2=.
-fstack-protector-strong -Wformat
101 - 200 of 589 matches
Mail list logo
