Re: Why do we list individual copyright holders?

[Andrey Rahmatullin]

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 more interested in the changes can do it.
> 
> I think that Lintian shouldn't warn about not using the latest
> Standards-Version; perhaps it should warn when you're using a really old
> one.
If S-V is declaring that the package conforms to some older version of the
policy then all the tools should check that package against that policy
and not against the latest one.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Why do we list individual copyright holders?

[Andrey Rahmatullin]

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 signature

Bug#886097: ITP: node-progressjs -- JavaScript progress bar library

[Daniel Ring]

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 Lang: JavaScript
  Description : JavaScript progress bar library

 ProgressJs is a JavaScript and CSS3 library that helps developers create and
 manage progress bars for every object on the page.
 .
 Node.js is an event-based server-side JavaScript engine.

Re: Is missing SysV-init support a bug?

[Benda Xu]

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 secure services these days.

If that is the case, shouldn't the package "Depends:" on systemd?

Benda

Bug#886092: ITP: node-knockout-transformations -- Live transform methods for Knockout observable arrays

[Daniel Ring]

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 : Apache-2.0
  Programming Lang: JavaScript
  Description : Live transform methods for Knockout observable arrays

 This plugin adds observable map, filter, indexBy and sortBy features to
 Knockout.js observable arrays, so you can transform collections in arbitrary
 ways and have the results automatically update whenever the underlying source
 data changes.
 .
 Node.js is an event-based server-side JavaScript engine.

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

[Theodore Ts'o]

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
> build just by using env variables when invoking dpkg-buildpackage or
> other build tools.
> 
> Would you accept patches to achieve this in e2fsprogs?  It would
> probably be quite clean, not complicating/obfuscating the packaging
> files too much, usually only 2~10 lines (but I didn't look specifically
> into this package yet).

Sure.  The debian/rules.custom support that I put in predates the
Debian build profiles spec, but it's basically the same idea.  So it
should be pretty simple to migrate things to use the build profile
concept; it's just a matter of wiring up things slightly differently
in debian/rules.

I haven't looked at build profiles spec super-closely yet, but since
it looks like there is core infrastructural support for it in dpkg,
debhelpers, and friends, it's no longer necessary to run
debian/control.in through m4 to generate debian/control (which is how
I did things sans dpkg support).

Send me a patch, either sent to linux-e...@vger.kernel.org, or as
Debian bug, and I'll happily take it.

My only real concern is whether this might complicate building the
latest version of e2fsprogs for stable and old-stable for
debian-backports.

Cheers,

- Ted

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

[Simon McVittie]

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, "SKIP_FUSE2FS=yes", and building by hand.

Perhaps you could convert this into a pkg.e2fsprogs.nofuse build profile?

This would look something like the attached (untested!) patches.

The intention seems to be that build profiles are how this is done
automatically or near-automatically in future. dbus and glib2.0 are
examples of packages where I've made use of build profiles to cut off
non-essential functionality for bootstrapping (they're significantly
further up the stack than e2fsprogs, but were involved in a cycle in
the past).

Having nodoc and noudeb build profiles (assuming the package has
documentation and udebs) also makes local test-builds a lot faster for
many packages, which is very convenient when testing functional changes.

> It currently doesn't automatically fix up the control file

You can skip binary packages on a per-build-profile basis without having
to generate debian/control from debian/control.in. After doing that,
it's often convenient to write build profile checks in debian/rules as
a check for "are we building package foo?" rather than "are we using
build profile foo?", like this in dbus:

binaries := $(shell dh_listpackages)

[...]

ifneq ($(filter dbus-udeb,$(binaries)),)
# udeb build
make -C debian/build-udeb install-exec 
DESTDIR=$(CURDIR)/debian/tmp-udeb
endif

> (The rules.custom infrastructure in e2fsprogs's debian/rules file was
> something I had put in a while ago to support building subsets of
> e2fsprogs for certain specialized use cases at $WORK.  It was also
> used way back when to support building new versions of e2fsprogs on
> extremely ancient old-old-old-old-stable.)

These sound like excellent use-cases for build profiles.

> Yeah, it's horribly manual, but when you need to bootstrap a newn
> architecture, it's all manual *anyway*.

Less so these days - I believe there are tools being developed that can
automatically break cycles by building cut-down packages (no documentation,
no FUSE, etc.) and later replacing them with a fully-featured version.

Regards,
smcv
>From 1d50ce0d72d3c4d9397b7e8e13f52bbb19bb5b61 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 1 Jan 2018 23:23:36 +
Subject: [PATCH 1/2] [UNTESTED] Add a build profile to skip the FUSE
 dependency

This is a non-standard build profile, but could be used during
bootstrapping.
---
 debian/control | 3 ++-
 debian/rules   | 4 
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 779f107..6ab004f 100644
--- a/debian/control
+++ b/debian/control
@@ -2,11 +2,12 @@ Source: e2fsprogs
 Section: admin
 Priority: required
 Maintainer: Theodore Y. Ts'o 
-Build-Depends: gettext, texinfo, pkg-config, libfuse-dev [linux-any kfreebsd-any], libattr1-dev, debhelper (>= 9.0), libblkid-dev, uuid-dev, m4
+Build-Depends: gettext, texinfo, pkg-config, libfuse-dev [linux-any kfreebsd-any] , libattr1-dev, debhelper (>= 9.0), libblkid-dev, uuid-dev, m4
 Standards-Version: 4.1.1
 Homepage: http://e2fsprogs.sourceforge.net
 
 Package: fuse2fs
+Build-Profiles: 
 Priority: optional
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Architecture: linux-any kfreebsd-any
diff --git a/debian/rules b/debian/rules
index 841715d..a6592dc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -31,6 +31,10 @@ ifeq ($(DEB_HOST_ARCH_OS), hurd)
 SKIP_FUSE2FS=yes
 endif
 
+ifneq ($(filter pkg.e2fsprogs.nofuse,$(DEB_BUILD_PROFILES)),)
+SKIP_FUSE2FS=yes
+endif
+
 DH_VERSION := $(shell dpkg-query -W -f '$${Version}' debhelper)
 
 # USE_DBGSYM :=
-- 
2.15.1

>From 9be2f6e9e61efa603e970fcd9167320068b9fb6c Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 1 Jan 2018 23:24:03 +
Subject: [PATCH 2/2] [UNTESTED] Add a build profile to skip the udeb

This is a standard build profile. Not building udebs speeds up test
builds if only the full-fat version is going to be tested anyway.
---
 debian/control | 1 +
 debian/rules   | 4 
 2 files changed, 5 insertions(+)

diff --git a/debian/control b/debian/control
index 6ab004f..c55bfa2 100644
--- a/debian/control
+++ b/debian/control
@@ -103,6 +103,7 @@ Description: command-line interface parsing library - headers and static librari
 
 
 Package: e2fsprogs-udeb
+Build-Profiles: 
 Package-Type: udeb
 Section: debian-installer
 Priority: optional
diff --git a/debian/rules b/debian/rules
index a6592dc..3eb65f1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -35,6 +35,10 @@ ifneq ($(filter pkg.e2fsprogs.nofuse,$(DEB_BUILD_PROFILES)),)
 SKIP_FUSE2FS=yes
 endif
 
+ifneq ($(filter noudeb,$(DEB_BUILD_PROFILES)),)
+SKIP_UDEB=yes
+endif
+
 DH_VERSION := $(sh

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

[Manuel A. Fernandez Montecelo]

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 by hand.

It currently doesn't automatically fix up the control file, but I can
set things up so that adding the rules.custom file with
SKIP_FUSE2FS=yes, and running "./debian/rules debian-files" will
automatically rewrite the control file dropping the fuse2fs
dependencies and the "fuse2fs" package from the control.in file.

Which might not matter that much, since when bootstrapping a new
architecture, it's all done manually anyway, so having a properly
update debian/control file might not matter that much.


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
build just by using env variables when invoking dpkg-buildpackage or
other build tools.

Would you accept patches to achieve this in e2fsprogs?  It would
probably be quite clean, not complicating/obfuscating the packaging
files too much, usually only 2~10 lines (but I didn't look specifically
into this package yet).

(We can continue off-list, I thought that it's useful for other people
if they are not away of the above).



Yeah, it's horribly manual, but when you need to bootstrap a newn
architecture, it's all manual *anyway*.  And yes, it's a workaround
compared to dropping e2fsprogs from the essential set (for which I
still support), but it's a workaround that works today.  I suppose the
real problem is that a random developer who is trying to bootstrap
Debian on a new architecture won't know about this trick, but in case
it's helpful, I thought I would mention it.


Thanks, it's useful to know :)



(Waving to the RISC-V folks.)


o/


--
Manuel A. Fernandez Montecelo 

Re: Why do we list individual copyright holders?

[Russ Allbery]

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 too much time-consuming. My assumption is that I know the
> policy good enough to just follow the latest version. When packaging for
> the first time, I won't re-read all the policy either.

> Other answers agree with you, but I believe people not reviewing the
> checklist won't just tell it here since they may not like being shamed
> or doctored (not my case, don't worry).

Others may feel differently, but I'd prefer if you just didn't update
standards version at all for your packages in that case.  I think that
would be fine -- you're indicating that you're not reviewing all changes
to Policy in a systematic way.  Should you have (or later get)
co-maintainers for your package, they'll see that this is something they
could do if they wished and enjoyed that work more than you do.

-- 
Russ Allbery (r...@debian.org)   

Re: Why do we list individual copyright holders?

[Vincent Bernat]

 ❦  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
> packages in the archive have been following the rule.  Such changes are placed
> in policy as a SHOULD initially, which is upgraded to a MUST (much) later.
> There is usually a mass bug filing which informs you of the change and gives
> you enough time to fix the issue.  And if you're lucky, an NMU is already
> prepared to fix the issue for you.
>
> In other words, the problem you describe ("my package followed policy, but 
> with
> the new version it suddenly doesn't anymore") is extremely rare.  Violating a
> SHOULD in Policy is not a serious bug.
>
>> We would spare a lot of developer time by not using this field anymore.
>
> I am surprised by this statement; it makes me think you do not mean what I
> understand from your email.  So I'll explain what the result of removing the
> field would be, please let me know if I misunderstand you:
>
> If you remove the field, every package must always conform to the newest
> version, which means that whenever a change that affects a package happens, a
> new upload must be made immediately.  This is exactly what you don't want, and
> the Standards-Version field is what you need to prevent it.
>
> What am I missing?

I don't see how you can say in the first a package complying with the
previous policy will likely comply with the current one and at the same
time saying that always complying with the latest policy is too much
work.

Moreover, if a package violates a MUST of the policy, just having an outdated
Standards-Version doesn't exempt it from getting a serious bug.
-- 
Remark of Dr. Baldwin's concerning upstarts: We don't care to eat toadstools
that think they are truffles.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

[Theodore Ts'o]

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 create a sbuild/pbuild build chroot, correct?
> 
> Correct. Unless I am mistaken, removing e2fsprogs from the build set
> also removes fuse.

Apologies for the thread necromancy, but I was going through old bugs
and old todo items for e2fsprogs debian package, and I was rereading
this thread as part of that.

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 by hand.

It currently doesn't automatically fix up the control file, but I can
set things up so that adding the rules.custom file with
SKIP_FUSE2FS=yes, and running "./debian/rules debian-files" will
automatically rewrite the control file dropping the fuse2fs
dependencies and the "fuse2fs" package from the control.in file.

Which might not matter that much, since when bootstrapping a new
architecture, it's all done manually anyway, so having a properly
update debian/control file might not matter that much.

(The rules.custom infrastructure in e2fsprogs's debian/rules file was
something I had put in a while ago to support building subsets of
e2fsprogs for certain specialized use cases at $WORK.  It was also
used way back when to support building new versions of e2fsprogs on
extremely ancient old-old-old-old-stable.)

Yeah, it's horribly manual, but when you need to bootstrap a newn
architecture, it's all manual *anyway*.  And yes, it's a workaround
compared to dropping e2fsprogs from the essential set (for which I
still support), but it's a workaround that works today.  I suppose the
real problem is that a random developer who is trying to bootstrap
Debian on a new architecture won't know about this trick, but in case
it's helpful, I thought I would mention it.  (Waving to the RISC-V
folks.)

Cheers,

- Ted

Re: Why do we list individual copyright holders?

[Vincent Bernat]

 ❦  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 like that?
>
> 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 too much time-consuming. My assumption is that I know the
policy good enough to just follow the latest version. When packaging for
the first time, I won't re-read all the policy either.

Other answers agree with you, but I believe people not reviewing the
checklist won't just tell it here since they may not like being shamed
or doctored (not my case, don't worry).

>> If we don't comply with the latest policy, this is considered a serious
>> bug. We would spare a lot of developer time by not using this field
>> anymore.
>
> Most changes to Policy are not serious bugs.  We try to avoid that sort of
> disruption.  Most of the changes are incremental, and can be batched for
> when you have time.  It doesn't particularly matter when you switch URLs
> to https or add upstream signing keys for verification.
>
> If you don't have a lot of time for Debian and are trying to keep packages
> updated with new upstream releases, I think there's some merit to doing
> regular uploads of new upstream packages while only checking Lintian
> errors, and then once per release cycle do a standards version update and
> deeper Lintian run with warnings and even info tags.  That keeps the
> package decrufted, while batching the work a little rather than feeling
> obligated to do it on every upload.

Doing it at each new upstream version gives me a little motivation to do
it on the spot since I get a new upstream version packaged in the
process. No way I'll get the motivation to do batch of dozens of
package. But since I understand this is acceptable to just ignore
Lintian warnings and to keep the policy version untouched, I am also
fine with this solution.
-- 
The lunatic, the lover, and the poet,
Are of imagination all compact...
-- Wm. Shakespeare, "A Midsummer Night's Dream"


signature.asc
Description: PGP signature

Re: Why do we list individual copyright holders?

[Russ Allbery]

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 very linked -- the debhelper compatibility level has a few
things related to Policy compliance, but it's mostly about the interface
to debhelper itself and changes in that.  (What add-ons are run by
default, for instance.)  The type of changes the package requires are
different in my experience.

Now, debian/compat and the versioned build dependency on debhelper are
indeed duplicates in almost all cases.  It's hard to generate the build
dependency from debian/compat (templating control at the source package
level is fraught with peril), but I do wonder if it would make sense for
debhelper to read debian/control and assume a compat level matching the
lower bound on the debhelper dependency if no debian/compat exists.  (But
maybe this would be too magical?)

-- 
Russ Allbery (r...@debian.org)   

Bug#886027: ITP: libmail-message-perl -- generic class representing mail messages (perl library)

[Damyan Ivanov]

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 : generic class representing mail messages (perl library)

A Mail::Message object is a container for MIME-encoded message information,
as defined by RFC2822.  Everything what is not specificly related to storing
the messages in mailboxes (folders) is implemented in this class.  Methods
which are related to folders is implemented in the Mail::Box::Message
extension (included in the libmail-box-perl package).



This is a split off libmail-box-perl, which got split upstream at version 3.

The package will be maintained under the umbrella of the Debian Perl Group.

Re: Why do we list individual copyright holders?

[Dr. Bas Wijnen]

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 assess the time developers will take to update
> >> packages because of a change.
> >
> > Only if you additionally have time to read the updated Debian Policy and 
> > ensure that the package complies with that newer version, should you 
> > bump Standards-Version.
> >
> > (possibly that's what you meant)
> 
> I read d-d-a@ where the policy changes are announced. Most of the time, I
> feel unconcerned as I don't remember anything particular.

If a policy change doesn't affect your package (which is most of the time),
there is no hurry to upload a new version.  Just bumping the standards version
isn't urgent.  In fact, I don't believe it's worth an upload at all.

> > 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 like that?

A package may not have been updated for a while, because changes in policy
didn't affect it, but perhaps also because the maintainer was too busy.  Once
you find out that there is a reason for an update, you should check if it
follows the new version of policy.  You don't want to recheck all of policy, so
instead you would use the upgrading-checklist from the debian-policy package.
In order to use that, you need to read all changes between the version that it
complied with and the current version.  For that, you need to know what version
it complied with.  This is recorded in the Standards-Version field.

> 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
packages in the archive have been following the rule.  Such changes are placed
in policy as a SHOULD initially, which is upgraded to a MUST (much) later.
There is usually a mass bug filing which informs you of the change and gives
you enough time to fix the issue.  And if you're lucky, an NMU is already
prepared to fix the issue for you.

In other words, the problem you describe ("my package followed policy, but with
the new version it suddenly doesn't anymore") is extremely rare.  Violating a
SHOULD in Policy is not a serious bug.

> We would spare a lot of developer time by not using this field anymore.

I am surprised by this statement; it makes me think you do not mean what I
understand from your email.  So I'll explain what the result of removing the
field would be, please let me know if I misunderstand you:

If you remove the field, every package must always conform to the newest
version, which means that whenever a change that affects a package happens, a
new upload must be made immediately.  This is exactly what you don't want, and
the Standards-Version field is what you need to prevent it.

What am I missing?

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Why do we list individual copyright holders?

[Jérémy Lal]

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 is verified to comply with.
> >
> > And why is it useful to know something like that?
>
> Because you can then you can focus on the particular changes from
> when-last-synced-with-Policy rather than checking the entirety of the
> package against all of Policy.
>
> > If we don't comply with the latest policy, this is considered a
> > serious bug.
>
> No, it's not.  Not complying with policy is anything from wishlist to
> critical all depending.
>
> > We would spare a lot of developer time by not using this field
> > anymore.
>
> I don't think so, I think we save quite a bit of effort by having it due
> to the aforementioned reasons.
>

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 ?

Jérémy

Re: Is missing SysV-init support a bug?

[Tollef Fog Heen]

]] 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 time, you can just detect it, exit and leave restarting to
the init system, assuming your init system supports this.  «Don't ever
die» is only the rule if the init system lacks that support.

(Yes, there are cases where you need to handle errors more gracefully,
but having the option of «on error: exit» is useful, especially for
simplistic control loops.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Why do we list individual copyright holders?

[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 is verified to comply with.
> 
> And why is it useful to know something like that?

Because you can then you can focus on the particular changes from
when-last-synced-with-Policy rather than checking the entirety of the
package against all of Policy.

> If we don't comply with the latest policy, this is considered a
> serious bug.

No, it's not.  Not complying with policy is anything from wishlist to
critical all depending.

> We would spare a lot of developer time by not using this field
> anymore.

I don't think so, I think we save quite a bit of effort by having it due
to the aforementioned reasons.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Why do we list individual copyright holders?

[Russ Allbery]

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 useful to know something like that?

So that when someone does have a chance to update the package, they know
where to start from when reading the upgrading checklist.

> If we don't comply with the latest policy, this is considered a serious
> bug. We would spare a lot of developer time by not using this field
> anymore.

Most changes to Policy are not serious bugs.  We try to avoid that sort of
disruption.  Most of the changes are incremental, and can be batched for
when you have time.  It doesn't particularly matter when you switch URLs
to https or add upstream signing keys for verification.

If you don't have a lot of time for Debian and are trying to keep packages
updated with new upstream releases, I think there's some merit to doing
regular uploads of new upstream packages while only checking Lintian
errors, and then once per release cycle do a standards version update and
deeper Lintian run with warnings and even info tags.  That keeps the
package decrufted, while batching the work a little rather than feeling
obligated to do it on every upload.

-- 
Russ Allbery (r...@debian.org)   

Re: Is missing SysV-init support a bug?

[Simon Richter]

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 surprises when systemd
internal functionality changed.

 - standards compliance: you can use a common management framework for
various SysV-compatible systems in a heterogeneous environment.

 - small footprint: starting a few daemons on an embedded system doesn't
require anything more complex than a script to invoke all of them, so
there is no point in keeping a complex program around to resolve
dependencies.

The first two go out of the window if init scripts become optional, and
these are precisely the main reasons for me to run sysvinit.

> 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 secure
> services these days.)

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.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Why do we list individual copyright holders?

[Vincent Bernat]

 ❦  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 change.
>
> Only if you additionally have time to read the updated Debian Policy and 
> ensure that the package complies with that newer version, should you 
> bump Standards-Version.
>
> (possibly that's what you meant)

I read d-d-a@ where the policy changes are announced. Most of the time, I
feel unconcerned as I don't remember anything particular.

> 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 like that? If we don't comply
with the latest policy, this is considered a serious bug. We would spare
a lot of developer time by not using this field anymore.
-- 
Replace repetitive expressions by calls to a common function.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Is missing SysV-init support a bug?

[Russ Allbery]

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 to how much
> maintainers are expected to deal with every wishlist bug, versus passing
> them upstream or seeking volunteers to help.

Yes, I agree with this.  The only additional point that I would add is
that while offering sysvinit support may not provide much according to
objective measures of number of users or technical features, it provides a
*lot* in terms of social cohesion of the project, making fellow developers
feel valued, and continuing to help the project heal from some deep
wounds.

So yes, I agree that it's a wishlist bug, but if people have the time, I
think it's work that's worth doing, assuming it's not ridiculously
complicated for a particular package.

-- 
Russ Allbery (r...@debian.org)   

Re: Is missing SysV-init support a bug?

[Michael Stone]

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 containerization, or otherwise makes use of the variety
of mechanisms that make it far easier to write more capable and secure
services these days.


I think the level of complexity is an important factor as well. For a 
simple "start this daemon" script, it's not a big deal. If the script 
needs to have a bunch of complex logic to support different use cases it 
doesn't make sense at this point to write both a systemd target and an 
init script--the init script isn't going to get much testing, and it's 
likely that there will be more bugs in the complicated logic than 
there'd be for someone who just hard codes their own requirements into 
rc.local (or whatever). As an example think of something like 
openvpn--if the init script didn't already exist, it would be a lot 
easier for someone to just kick off a single openvpn process than to 
make sure that all the logic that sets up multiple processes with 
different configurations was working properly on both systemd & sysvinit 
systems. As the number of sysvinit users continues to decline, I think 
simpler is better to minimize bugs in seldom-used code paths.


Mike Stone

Re: Why do we list individual copyright holders?

[Sean Whitton]

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.

Our current culture under which many of us feel obligated to ensure our
package uses the latest Standards-Version is problematic.

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 more interested in the changes can do it.

I think that Lintian shouldn't warn about not using the latest
Standards-Version; perhaps it should warn when you're using a really old
one.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Is missing SysV-init support a bug?

[Josh Triplett]

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 to break
>> support for /etc/init.d/* any time soon.
>
> There are other reasons to continue to support sysvinit: developers who
> want to continue to use it, ports that want to continue to use it, and so
> forth.
>
> I don't see any reason to drop support.

There's a difference between "dropping support" and "not mandating
support". I'm entirely in favor of maintaining support for sysvinit for
as long as people continue to be willing to spend their time on it. But
we already, de-facto, let packages decide to not support it and only
support systemd, if nobody cares enough to provide the additional code
and support that would be required to do otherwise. (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 containerization, or otherwise makes use of the variety
of mechanisms that make it far easier to write more capable and secure
services these days.)

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 to how much
maintainers are expected to deal with every wishlist bug, versus passing
them upstream or seeking volunteers to help.

Re: Why do we list individual copyright holders?

[Jonas Smedegaard]

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
>>> to request suggesting the documentation.
>>
>> I'm finding it difficult to relate or understand where you are coming
>> from that you would believe this is the best way forward... Can you
>> help? :)
>>
> > To me, it's clearly just a bug in Lintian (fixed a few days ago in
> > Git, pending upload..)
> 
> I admit this example is unfair since it's just a bug for a check that
> would totally be worth it.
> 
> 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.

Only if you additionally have time to read the updated Debian Policy and 
ensure that the package complies with that newer version, should you 
bump Standards-Version.

(possibly that's what you meant)

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.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Why do we list individual copyright holders?

[Vincent Bernat]

 ❦  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.
>
> I'm finding it difficult to relate or understand where you are coming
> from that you would believe this is the best way forward... Can you
> help? :)
>
> To me, it's clearly just a bug in Lintian (fixed a few days ago in
> Git, pending upload..)

I admit this example is unfair since it's just a bug for a check that
would totally be worth it.

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.
-- 
The Public is merely a multiplied "me."
-- Mark Twain


signature.asc
Description: PGP signature

Bug#886014: ITP: libplacebo -- GPU-accelerated video/image rendering primitives

[Sebastian Ramacher]

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/image rendering primitives

libplacebo is essentially the core rendering algorithms and ideas of mpv turned
into a library. This grew out of an interest to accomplish the following goals:
* Clean up mpv's internal RA API and make it reusable for other projects.
* Provide a standard library of useful GPU-accelerated image processing
  primitives based on GLSL, so projects like VLC or Firefox can use them without
  incurring a heavy dependency on libmpv.
* Rewrite core parts of mpv's GPU-accelerated video renderer on top of
  redesigned abstractions. (Basically, I wanted to eliminate code smell like
  shader_cache.c and totally redesign gpu/video.c)


Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Re: Why do we list individual copyright holders?

[Chris Lamb]

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 relate or understand where you are coming
from that you would believe this is the best way forward... Can you
help? :)

To me, it's clearly just a bug in Lintian (fixed a few days ago in
Git, pending upload..)


Regarding the severity of tags, they are not extremely nuanced nor have
they been to much revision. Thus, there is a danger of inferring anything
from comparing the relative levels of things Lintian reports about.

In other words, just because two warnings are the same, it doesn't really
mean anything deep about how the Lintian developers look at the world. If
you believe something should be higher or lower, please simply open a bug
report.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#885986: ITP: node-knockout-sortable -- JQuery-UI "sortable" binding for knockout

[Daniel Ring]

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
  Programming Lang: JavaScript
  Description : JQuery-UI "sortable" binding for knockout

 Knockout-Sortable is a binding for Knockout.js designed to connect
 observableArrays with jQuery UI's sortable functionality. This allows a user
 to drag and drop items within a list or between lists and have the
 corresponding observableArrays updated appropriately.
 .
 Node.js is an event-based server-side JavaScript engine.