On 6/28/23 21:49, Helmut Grohne wrote:
Debian GIS Project
postgis
qgis
Why is postgis on this list?
$ grep -c Replaces debian/control*
debian/control:0
debian/control.in:0
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F
Package: wnpp
Severity: wishlist
Owner: Michael Fladischer
X-Debbugs-Cc: debian-devel@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: python-ocspbuilder
Version : 0.10.2
Upstream Contact: Will Bond
* URL : https://github.com/wbond/ocs
On Wed, Jun 28, 2023 at 08:59:18PM +, Holger Levsen wrote:
> however it's author also said on #-devel just now:
[...]
< josch> | h01ger: i'm not multistraps author though
(josch AFAICS is the last maintainer of it, maintaining it from 2016
to 2018.)
my point is: it's more than two tools
On Wed, Jun 28, 2023 at 08:28:28PM +, Holger Levsen wrote:
> On Wed, Jun 28, 2023 at 09:15:30PM +0100, Luca Boccassi wrote:
> > > to how you see things moving forward?
> > Changing the bootstrap tools seems much safer. It is just two tools,
> three: debootstrap, mmdebstrap and cdebootstrap.
fo
> "Helmut" == Helmut Grohne writes:
I believe I'm up on this discussion to at least comment on the consensus
calls you discuss in the mail.
Except where noted below, I support your reading of consensus.
Helmut> Consensus proposal #1:
Helmut> This updated DEP17 is a complete rep
Hi,
On Wed, 2023-06-28 at 21:37 +0200, Helmut Grohne wrote:
> Among these options, the first has a working prototype (debootstrap),
> but it is unclear how that extends to use of snapshot.d.o and how to
> make it work with debootsnap and debbisect as those tend to use a
> suite name rather than a
On Wed, Jun 28, 2023 at 09:15:30PM +0100, Luca Boccassi wrote:
> > to how you see things moving forward?
> Changing the bootstrap tools seems much safer. It is just two tools,
three: debootstrap, mmdebstrap and cdebootstrap.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproduci
On Wed, 28 Jun 2023 at 20:38, Helmut Grohne wrote:
>
> Hi,
>
> thanks for all the valuable feedback on the huge DEP17 thread. As
> promised, I looked into condensing that discussion into something
> shorter. That shorter thing still has more than 3000 words and is
> available as source at
After s
Hi,
thanks for all the valuable feedback on the huge DEP17 thread. As
promised, I looked into condensing that discussion into something
shorter. That shorter thing still has more than 3000 words and is
available as source at
https://salsa.debian.org/dep-team/deps/-/merge_requests/5
and I als
Michael Biebl writes:
> While I find this discussion really interesting, is this really relevant
> for orphan-sysvinit-scripts? After all, it doesn't ship any conffiles in
> /etc, i.e. it doesn't take over any (conf)files from packages that
> dropped their initscript.
> Have you actually looked
> "Simon" == Simon Richter writes:
>> It also seems a bit strange to require more from the maintainer
>> when they are dropping an init script than we would if a
>> maintainer started depending on a feature like socket activation
>> such that their packkage simply would not wo
Hi,
On 6/29/23 01:56, Sam Hartman wrote:
Russ> This feels like exactly the kind of problem that normally
Russ> Debian goes to some lengths to avoid creating, but it sounds
Russ> like several commenters here don't think the effort is worth
Russ> it?
Normally, Debian spends
On Wed, 28 Jun 2023 at 17:20, Ansgar wrote:
>
> Hi Simon,
>
> On Thu, 2023-06-29 at 00:32 +0900, Simon Richter wrote:
> > According to Policy as currently published, systemd units are
> > encouraged, and init scripts are mandatory.
>
> Please stop lying:
>
> +---
> | Packages that include system s
Hi Russ,
On 6/29/23 01:58, Russ Allbery wrote:
According to Policy as currently published, systemd units are
encouraged, and init scripts are mandatory.
I thought I found and fixed all of the places init scripts were said to be
mandatory, but apparently I missed one. Could you file a bug an
Simon Richter writes:
> According to Policy as currently published, systemd units are
> encouraged, and init scripts are mandatory.
I thought I found and fixed all of the places init scripts were said to be
mandatory, but apparently I missed one. Could you file a bug and point it
out? That obv
> "Russ" == Russ Allbery writes:
Russ> I think the open question is whether we're happy to just break
Russ> init scripts in unstable, since that migration path means
Russ> there will always be a window where a fully-upgraded unstable
Russ> system has no init script for a packa
Hi Simon,
On Thu, 2023-06-29 at 00:32 +0900, Simon Richter wrote:
> According to Policy as currently published, systemd units are
> encouraged, and init scripts are mandatory.
Please stop lying:
+---
| Packages that include system services should include systemd service
| units to start or stop
Hi,
On 6/28/23 22:42, Holger Levsen wrote:
I'm not sure Debian Policy is the best place to document this, because Debian
Policy
documents what packages *must* comply with, while legacy initscripts are a thing
of the past which still are permitted (and liked & prefered by some), so *maybe*
src:
Package: wnpp
Severity: wishlist
Owner: Nilesh Patra
* Package name: golang-maunium-go-maulogger
Version : 2.4.1-1
Upstream Author : 2016-2023 Tulir Asokan
* URL : https://github.com/tulir/maulogger.git
* License : MPL-2
Programming Lang: Go
Description
On Sun, Jun 25, 2023 at 03:15:24PM +0100, Mark Hindley wrote:
> Debian Policy no longer requires that packages which provide a systemd
> .service
> file also provide an initscript. This permits maintainers who so wish to
> remove
> initscripts from their packages. However, initscripts remain used
Am 27.06.23 um 19:31 schrieb Russ Allbery:
Simon Richter writes:
The only thing we actually need is a versioned Replaces that allows
orphan-sysvinit-scripts to take over ownership of the conffile.
Conflicts is unneeded here, and the daemon package does not need to
declare any relationship.
Hello Thomas Goirand,
On Wed, Jun 28, 2023 at 10:01:13AM +0200, Thomas Goirand wrote:
> On 6/27/23 17:45, Andreas Henriksson wrote:
> > Dropping things and letting people pick them up if they
> > think they are still useful seems to be the only practical way forward.
>
> It's not. As written by R
On Wed, Jun 28, 2023 at 10:01:13AM +0200, Thomas Goirand wrote:
> It's not. As written by Russ in this thread, filling a bug against
> orphan-sysvinit-scripts so it takes over the abandoned script is. I wouldn't
> mind seeing this mandatory, and written in the policy.
I do. This also does not hav
On Wed, 28 Jun 2023, 06:31 Paul Wise, wrote:
> On Tue, 2023-06-27 at 09:36 +0100, Luca Boccassi wrote:
>
> > That has been implemented a long time ago, services can set
> > ProtectProc= so that processes run with hidepid:
> >
> >
> https://freedesktop.org/software/systemd/man/systemd.exec.html#Pr
On 6/27/23 17:45, Andreas Henriksson wrote:
Dropping things and letting people pick them up if they
think they are still useful seems to be the only practical way forward.
It's not. As written by Russ in this thread, filling a bug against
orphan-sysvinit-scripts so it takes over the abandoned
On Tue, 2023-06-27 at 21:05:57 -0700, Russ Allbery wrote:
> Simon Richter writes:
> > On 6/28/23 02:31, Russ Allbery wrote:
> >> Normally Conflicts is always added with Replaces because otherwise you can
> >> have the following situation:
>
> >> * Package A version 1.0-1 is installed providing fi
* Russ Allbery , 2023-06-27 23:19:
for some reason I thought we normally always combine Replaces with
Breaks or Conflicts even for other cases.
There is a good reason.
Consider the following scenario:
* Package A 1.0-1 is installed providing file F.
* File F is moved to package B as of packag
27 matches
Mail list logo
