Jérémy Lal writes:
> About sparing time, having to maintain
> debian/compat
> Build-Depends debhelper
> Standards-Version
> is overkill. Sure, i suppose there are times it's useful to be decoupled,
> but wouldn't it be simpler to couple debhelper dependency to
> Standards-Version ?
They're not v
Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov
* Package name: libmail-message-perl
Version : 3.005
Upstream Author : Mark Overmeer
* URL : https://metacpan.org/release/Mail-Message
* License : Artistic or GPL-1+
Programming Lang: Perl
Description
On Mon, Jan 01, 2018 at 07:43:06PM +0100, Vincent Bernat wrote:
> ❦ 1 janvier 2018 17:47 +0100, Jonas Smedegaard :
>
> >> I have very little time for Debian. Each time I update a package, I have
> >> to bump Standards-Version and fix new Lintian warnings. I would
> >> appreciate if we would ass
]] Simon Richter
> A daemon must be capable of running standalone and dealing with the
> fallout of depended-on services shutting down, restarting, crashing or
> being generally unavailable. All of these are significantly harder to
> get right than startup in a SysV environment.
A lot of the tim
2018-01-01 20:33 GMT+01:00 Tollef Fog Heen :
> ]] Vincent Bernat
>
> > ❦ 1 janvier 2018 17:47 +0100, Jonas Smedegaard :
> >
> > > Purpose of the Standards-Version field is *not* to keep you busy
> > > silencing corresponding lintian warning, but to state which version of
> > > Debian Policy the
Package: wnpp
Severity: wishlist
Owner: Daniel Ring
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-knockout-transformations
Version : 2.1.0
Upstream Author : One.com
* URL : https://github.com/One-com/knockout-transformations
* License : Apach
Josh Triplett writes:
> It seems far harder to do so for a service that provides no
> daemonization support at all, expects socket or D-Bus activation,
> integrates with containerization, or otherwise makes use of the
> variety of mechanisms that make it far easier to write more capable
> and sec
Package: wnpp
Severity: wishlist
Owner: Daniel Ring
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-progressjs
Version : 0.1.0
Upstream Author : Afshin Mehrabani
* URL : https://github.com/usablica/progress.js
* License : Expat
Programming L
On Mon, Jan 01, 2018 at 08:40:38PM +0100, Jérémy Lal wrote:
> wouldn't it be simpler to couple debhelper dependency to
> Standards-Version ?
There are packages which may break with newer debhelper, but can be easily
updated to the current policy.
--
WBR, wRAR
signature.asc
Description: PGP sign
On Mon, Jan 01, 2018 at 05:26:35PM +, Sean Whitton wrote:
> IMO the point of the field is to ensure that you /don't/ have to upgrade
> to the latest version of Policy right away. It allows you to keep track
> of the version of Policy you are up-to-date with, so you can do it
> later/someone mo
Package: wnpp
Severity: wishlist
Owner: Daniel Ring
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-knockout-sortable
Version : 1.1.0
Upstream Author : Ryan Niemeyer
* URL : https://github.com/rniemeyer/knockout-sortable
* License : Expat
Pro
Paul Wise wrote:
> > W: python3-pysnmp4:
> > python-package-depends-on-package-from-other-python-variant (Suggests:
> > python-pysnmp4-doc)
> >
> > My solution? Removing the Sugggests and pray someone doesn't open a bug
> > to request suggesting the documentation.
I'm finding it difficult to re
Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher
* Package name: libplacebo
Version : 0.2.0
Upstream Author : Niklas Haas
* URL : https://github.com/haasn/libplacebo
* License : LGPL-2.1+
Programming Lang: C
Description : GPU-accelerated video
❦ 1 janvier 2018 14:28 GMT, Chris Lamb :
> > W: python3-pysnmp4:
> > python-package-depends-on-package-from-other-python-variant (Suggests:
> > python-pysnmp4-doc)
> >
> > My solution? Removing the Sugggests and pray someone doesn't open a bug
> > to request suggesting the documentation.
>
>
Quoting Vincent Bernat (2018-01-01 17:19:36)
> ❦ 1 janvier 2018 14:28 GMT, Chris Lamb :
>
>>> W: python3-pysnmp4:
>>> python-package-depends-on-package-from-other-python-variant (Suggests:
>>> python-pysnmp4-doc)
>>>
>>> My solution? Removing the Sugggests and pray someone doesn't open a bug
Russ Allbery wrote:
> Josh Triplett writes:
> > Russ Allbery wrote:
>
>>> It does, however, mean that it's a good idea for us to continue to
>>> support sysvinit.
>
>> Not quite. It means we should maintain support for sysvinit *scripts*
>> for the foreseeable future; there's no good reason for us
Hello,
On Mon, Jan 01 2018, Vincent Bernat wrote:
> I have very little time for Debian. Each time I update a package, I
> have to bump Standards-Version and fix new Lintian warnings. I would
> appreciate if we would assess the time developers will take to update
> packages because of a change.
O
On Mon, Jan 01, 2018 at 08:42:52AM -0800, Josh Triplett wrote:
It seems easy
enough to just write a "missing" init script, or accept a patch for one.
It seems far harder to do so for a service that provides no
daemonization support at all, expects socket or D-Bus activation,
integrates with conta
Josh Triplett writes:
> This thread started with the question of "is it a bug to not have
> sysvinit support". And I think the answer, at this point, is "yes, but
> depending on the level of additional code and maintenance required, it
> might potentially be a wishlist bug". And there's a limit t
❦ 1 janvier 2018 17:47 +0100, Jonas Smedegaard :
>> I have very little time for Debian. Each time I update a package, I have
>> to bump Standards-Version and fix new Lintian warnings. I would
>> appreciate if we would assess the time developers will take to update
>> packages because of a chang
Vincent Bernat writes:
> ❦ 1 janvier 2018 17:47 +0100, Jonas Smedegaard :
>> Purpose of the Standards-Version field is *not* to keep you busy
>> silencing corresponding lintian warning, but to state which version of
>> Debian Policy the package is verified to comply with.
> And why is it us
❦ 1 janvier 2018 19:45 GMT, "Dr. Bas Wijnen" :
>> If we don't comply with the latest policy, this is considered a serious bug.
>
> Yes. But a package complying with the previous policy, but not the current
> one
> is unlikely, because policy changes are normally written down once most
> packa
Hi,
On 01.01.2018 17:42, Josh Triplett wrote:
> There's a difference between "dropping support" and "not mandating
> support".
Ideally, yes, but in practice the difference isn't very large. The main
reasons I see for people to use sysvinit are:
- reliability: there have been a few interesting
❦ 1 janvier 2018 11:31 -0800, Russ Allbery :
>>> Purpose of the Standards-Version field is *not* to keep you busy
>>> silencing corresponding lintian warning, but to state which version of
>>> Debian Policy the package is verified to comply with.
>
>> And why is it useful to know something li
Hi!
2018-01-01 22:51 Theodore Ts'o:
This probably doesn't help much, but for people who are doing things
by hand, you can skip the dependency on fuse by unpacking the
e2fsprogs source packaging, adding the file debian/rules.custom which
contains the single line, "SKIP_FUSE2FS=yes", and building
Vincent Bernat writes:
> ❦ 1 janvier 2018 11:31 -0800, Russ Allbery :
>> So that when someone does have a chance to update the package, they
>> know where to start from when reading the upgrading checklist.
> I never do that and I don't intend to do that in the future. Packaging
> is already
On Mon, Nov 13, 2017 at 08:35:10PM +0100, Helmut Grohne wrote:
> > To to be clear, the key metric for your specific goal is the reduction
> > of the _source_ package count since the goal is to reduce the number
> > of packages which have to be built by "hand" (or by script), before
> > you can crea
]] Vincent Bernat
> ❦ 1 janvier 2018 17:47 +0100, Jonas Smedegaard :
>
> > Purpose of the Standards-Version field is *not* to keep you busy
> > silencing corresponding lintian warning, but to state which version of
> > Debian Policy the package is verified to comply with.
>
> And why is it
On Tue, Jan 02, 2018 at 12:38:55AM +0100, Manuel A. Fernandez Montecelo wrote:
> Lately architectures tend to use automatic bootstrapping at least for
> some of the initial dependencies. Adding support for build profiles
> (would be something like pkg.e2fsprogs.nofuse in this case) can help to
> b
On Mon, 01 Jan 2018 at 16:51:45 -0500, Theodore Ts'o wrote:
> This probably doesn't help much, but for people who are doing things
> by hand, you can skip the dependency on fuse by unpacking the
> e2fsprogs source packaging, adding the file debian/rules.custom which
> contains the single line, "SKI
30 matches
Mail list logo
