Re: OpenLiteSpeed Build Script Violating Debian Upstream Guide

2020-03-07 Thread Nicholas D Steeves
Hi Bagas, Andrey Rahmatullin writes: > On Sat, Mar 07, 2020 at 03:47:56PM +0700, Bagas Sanjaya wrote: >> > Packages must be self-contained, using only their contents and the Debian >> > repo during the build process. There are multiple technical and >> > non-technical reasons for this requiremen

Re: not starting a daemon upon installation

2020-03-07 Thread Marco d'Itri
On Mar 07, Tomas Pospisek wrote: > tldr: why is not having a daemon started on install so involved? Can't > there be a better way? There is: # systemctl mask $DAEMON.service # apt install $DAEMON That's it. If the package fails to install then file a bug. > When I duckduckgo "dpkg do not start

Re: not starting a daemon upon installation

2020-03-07 Thread Jonas Smedegaard
Quoting Tomas Pospisek (2020-03-07 21:30:33) > tldr: why is not having a daemon started on install so involved? Can't > there be a better way? > It /seems/ that the "official" way to achieve "not starting a daemon > upon installation" is to use `dpkg-divert` to overwrite `policy-rc.d` > with a

apt 2.0 release notes

2020-03-07 Thread Julian Andres Klode
# APT 2.0 After brewing in experimental for a while, and getting a first outing in the Ubuntu 19.10 release; both as 1.9, APT 2.0 is now landing in unstable. 1.10 would be a boring, weird number, eh? Compared to the 1.8 series, the APT 2.0 series features several new features, as well as improvem

not starting a daemon upon installation

2020-03-07 Thread Tomas Pospisek
Hi all, tldr: why is not having a daemon started on install so involved? Can't there be a better way? I'm hacking around an ansible playbook that needs to configure an etcd cluster. The problem is that installing the package will automatically start the daemon cluster in a "default" configuratio

Bug#953324: ITP: golang-github-grpc-ecosystem-grpc-opentracing -- consistent, expressive, vendor-neutral APIs for distributed tracing and context propagation

2020-03-07 Thread Tong Sun
Package: wnpp Severity: wishlist Owner: Tong Sun * Package name: golang-github-grpc-ecosystem-grpc-opentracing Version : 0.0~git20180507.8e809c8-1 Upstream Author : gRPC Ecosystem * URL : https://github.com/grpc-ecosystem/grpc-opentracing * License : BSD-3-clau

Processed: Re: Bug#953302: general: GNU Image Manipulation Program version 2.10.12

2020-03-07 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org: > reassign 953302 gimp Bug #953302 [general] general: GNU Image Manipulation Program version 2.10.12 Bug reassigned from package 'general' to 'gimp'. Ignoring request to alter found versions of bug #953302 to the same values previously set Ignoring

Bug#953302: general: GNU Image Manipulation Program version 2.10.12

2020-03-07 Thread ighrdm
Package: general Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action?

Re: Re: Re: OpenLiteSpeed Build Script Violating Debian Upstream Guide

2020-03-07 Thread Andrey Rahmatullin
On Sat, Mar 07, 2020 at 03:47:56PM +0700, Bagas Sanjaya wrote: > > Packages must be self-contained, using only their contents and the Debian > > repo during the build process. There are multiple technical and > > non-technical reasons for this requirement, including knowing that the > > package is

Re: Re: Re: OpenLiteSpeed Build Script Violating Debian Upstream Guide

2020-03-07 Thread Bagas Sanjaya
Packages must be self-contained, using only their contents and the Debian repo during the build process. There are multiple technical and non-technical reasons for this requirement, including knowing that the package is DFSG-compliant and being able to always rebuild the package. But I found that