Re: Why do we list individual copyright holders?

[Niels Thykier]

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

Also, there are packages that deliberately hold back on adopting new
debhelper compat levels because they want to be backportable as-is to
stable (even up to oldoldstable in some cases).

That said, I do agree that a maintainer should have to care about fewer
turning wheels in debian/control than what our current packaging design
requires us to do.

Thanks,
~Niels

Re: Why do we list individual copyright holders?

[Niels Thykier]

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.

This would just be a question of turning down the warning for
"old-standards-version" to an info.  We have a separate warning
(ancient-standards-version) that triggers when your S-V is (currently) 2
years behind.

IOW, trivially doable in lintian, please file a bug if you want this.

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

Lintian's architecture does not lend itself to doing this atm.  If you
want this behaviour, then I suspect you will have to invest some patches
in it.

That said, it would be a good start to add S-V to many the lintian tags,
so people can see which S-V they apply to.
  (You may be tempted to just apply a filter on the S-V; unfortunately
some tags will change iteratively between policy versions, so you would
end up hiding a tag that applies to the old S-V because policy required
a tweak of it - or not hiding a tag when you should; anyway, I digress)

Thanks,
~Niels

Re: Why do we list individual copyright holders?

[Jonas Smedegaard]

Quoting Niels Thykier (2018-01-02 09:23:00)
> 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.
>> 
>
> Also, there are packages that deliberately hold back on adopting new 
> debhelper compat levels because they want to be backportable as-is to 
> stable (even up to oldoldstable in some cases).
>
> That said, I do agree that a maintainer should have to care about 
> fewer turning wheels in debian/control than what our current packaging 
> design requires us to do.

Maybe extend debhelper to support compat file content of "latest". Or 
simply treat a missing compat file as implicitly meaning "latest".


 - 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

On debhelper compat levels (Was: Re: Why do we list individual copyright holders?)

[Niels Thykier]

Jonas Smedegaard:
> Quoting Niels Thykier (2018-01-02 09:23:00)
>> 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.
>>>
>>
>> Also, there are packages that deliberately hold back on adopting new 
>> debhelper compat levels because they want to be backportable as-is to 
>> stable (even up to oldoldstable in some cases).
>>
>> That said, I do agree that a maintainer should have to care about 
>> fewer turning wheels in debian/control than what our current packaging 
>> design requires us to do.
> 
> Maybe extend debhelper to support compat file content of "latest". Or 
> simply treat a missing compat file as implicitly meaning "latest".
> 
> 
>  - Jonas
> 

I have considered it, but it will effectively lead to a situation where
I cannot ever make a new compat level.

The point of compat levels is to change behaviour in an incompatible
way.  Because it is opt-in, a new compat level breaks 0 packages (except
a handful of early adopters).  Whereas if I implement a named "latest"
compat level, then I possibly break every single package with that named
compat level.
  As more and more adopt it, the compat bump will break more and more
packages leading to a situation where it is nearly impossible for me to
implement an actual compat bump.

(This would have been less problematic if we could determine exactly
which packages are affected and how they are affected, so we could do
MBF before the bump.  However, that it is impractical for many changes.)

Thanks,
~Niels

PS: For the curious, this is also why I retracted the named
"beta-tester" compat level that existed in most of debhelper 10 just
before announcing the compat 11 beta.

Re: On debhelper compat levels (Was: Re: Why do we list individual copyright holders?)

[Jonas Smedegaard]

Quoting Niels Thykier (2018-01-02 12:19:00)
> Jonas Smedegaard:
> > Quoting Niels Thykier (2018-01-02 09:23:00)
> >> 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.
> >>>
> >>
> >> Also, there are packages that deliberately hold back on adopting new 
> >> debhelper compat levels because they want to be backportable as-is to 
> >> stable (even up to oldoldstable in some cases).
> >>
> >> That said, I do agree that a maintainer should have to care about 
> >> fewer turning wheels in debian/control than what our current packaging 
> >> design requires us to do.
> > 
> > Maybe extend debhelper to support compat file content of "latest". Or 
> > simply treat a missing compat file as implicitly meaning "latest".
> > 
> > 
> >  - Jonas
> > 
> 
> I have considered it, but it will effectively lead to a situation where
> I cannot ever make a new compat level.
> 
> The point of compat levels is to change behaviour in an incompatible
> way.  Because it is opt-in, a new compat level breaks 0 packages (except
> a handful of early adopters).  Whereas if I implement a named "latest"
> compat level, then I possibly break every single package with that named
> compat level.
>   As more and more adopt it, the compat bump will break more and more
> packages leading to a situation where it is nearly impossible for me to
> implement an actual compat bump.

Breakage will not burden development of debhelper if you a) document 
clearly (perhaps even spew a warning at runtime) that no promise is made 
about stability when not using a fixed compatibility level, and b) you 
do not introduce a new compatibility level late in the release cycle.


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

[Andrey Rahmatullin]

On Tue, Jan 02, 2018 at 08:29:00AM +, Niels Thykier wrote:
> > 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.
> > 
> 
> Lintian's architecture does not lend itself to doing this atm.  If you
> want this behaviour, then I suspect you will have to invest some patches
> in it.
I don't want it or even think we should do that, it's more of "maybe the
premise is wrong".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#886129: ITP: mstch -- Mustache implementation in C++11

[Guus Sliepen]

Package: wnpp
Severity: wishlist
Owner: Guus Sliepen 

* Package name: mstch
  Version : 1.0.2 
  Upstream Author : Daniel Sipka
* URL : https://github.com/no1msd/mstch
* License : MIT
  Programming Lang: C++
  Description : Mustache implementation in C++11

Mstch is a complete implementation of {{mustache}} templates using
modern C++. It's compliant with specifications v1.1.3, including the
lambda module.

Mustache is a logic-less template language. As such, it is very well
suited for programs that are written in a compiled language, such as C
and C++, as they cannot easily evaluate code found in a template.
However, no C or C++ implementation of Mustache is in Debian yet, so
this package fills that gap, at least for C++.

Currently, this only builds a static library. The binary package will
be called libmstch-dev.

Re: Why do we list individual copyright holders?

[Russ Allbery]

Andrey Rahmatullin  writes:
> 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.

I don't see how that follows.  We still have a standard that we're trying
to maintain for packages in the archive, and the fact that maintainers of
one package have not had a chance to review the package against that
standard for the more fiddly and less important bits doesn't change what
the standard is.

I think of the Standards-Version header in a package is a bookmark: this
is where I last left off in updating the packaging.  It doesn't change the
standard by which the package should be judged.

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

Bug#886167: ITP: libmoosex-traitfor-meta-class-betteranonclassnames-perl -- helper for MooseX::Util to generate anonymous class names

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmoosex-traitfor-meta-class-betteranonclassnames-perl
  Version : 0.002003
  Upstream Author : Chris Weyl 
* URL : 
https://metacpan.org/release/MooseX-TraitFor-Meta-Class-BetterAnonClassNames
* License : LGPL-2.1
  Programming Lang: Perl
  Description : helper for MooseX::Util to generate anonymous class names

MooseX::TraitFor::Meta::Class::BetterAnonClassNames helps MooseX::Util's
with_traits() method to create better named anonymous classes.

 my $anon_class_name = with_traits('Zombie::Catcher', 'SomeTrait');

now becomes

 Zombie::Catcher::__ANON__::SERIAL::1

rather than

 Moose::Meta::Class::__ANON__::SERIAL::1

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

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#886169: ITP: libmoosex-util-perl -- Moose::Util extensions

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmoosex-util-perl
  Version : 0.006
  Upstream Author : Chris Weyl 
* URL : https://metacpan.org/release/MooseX-Util
* License : LGPL-2.1
  Programming Lang: Perl
  Description : Moose::Util extensions

MooseX::Util is a utility module that handles all of the same functions that
Moose::Util handles. In fact, most of the functions exported by this package
are simply re-exports from Moose::Util. However, a number of the functions
have been re-implemented, for a variety of reasons.

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

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#886170: ITP: ksmtp -- library for handling SMTP data

[Sandro Knauß]

Package: wnpp
Severity: wishlist
Owner: Sandro Knauß 

* Package name: ksmtp
  Version : 17.12.0
  Upstream Author : KDE Pim
* URL : https://projects.kde.org/projects/kde/pim/ksmtp
* License : LGPL-2.1+
  Programming Lang: C++
  Description : library for handling SMTP data

 This library provides an API for handling SMTP services.
 SMTP (Simple Mail Transfer Protocol) is the most prevalent
 Internet standard protocols for e-mail transmission.

 It is a job-based API for interacting with SMTP servers used inside
 kdepim.


This package is part of KDE Applications 17.12.0 and is needed build
kmailtranspart 17.12.0. As everything else from KDE Applications,
it will be packaged/handled by "Debian/Kubuntu Qt/KDE Maintainers"-team.

Re: Why do we list individual copyright holders?

[Markus Koschany]

Am 02.01.2018 um 19:38 schrieb Russ Allbery:
[...]
> I think of the Standards-Version header in a package is a bookmark: this
> is where I last left off in updating the packaging.  It doesn't change the
> standard by which the package should be judged.

I believe that the Standards-Version header should not be part of a
debian/control file. I understand your reasoning why you want to keep it
and why it is useful for you. Though in my opinion a debian/control
file, or generally speaking all information in debian/, should be hard
requirements and either technically necessary for building a package or
legally required. The Standards-Version header is a soft requirement,
someone may or may not find it useful for maintaining the package. For
team-maintained packages, which all can look very similar, updating this
header quickly becomes a repetitive task.

This is comparable to the Vcs-{Git/Svn} and Vcs-Browser fields. IMO this
kind of information should be maintained outside of debian/control
where it can be modified and controlled independently, as it is deemed
necessary by the maintainer. As people on this list have already pointed
out, updating the Standards-Version header doesn't change whether your
package is Policy-compliant or not which makes it rather expendable.

A bookmark can surely be useful in the individual case but it is not a
requirement to read or understand a book.

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#886173: general: ls quotes results with special characters in its output

[mqudsi]

Package: general
Severity: normal

Dear Maintainer,

On a clean installation of debian buster, I ran into an issue where the
output of `ls` in various modes led me to confusedly attempt to figure
out where my scripting had gone wrong.

In particular, `ls` output (both in regular and `-l` modes) wraps in
single quotes the names of files that contain special characters (or, at
least, a parenthesis), meaning its output is not an accurate reflection
of the actual contents of the directory.

Observe:

```
mqudsi@buster ~> touch test\(
mqudsi@buster ~> ls -l
mqudsi@buster ld ~> ls -l
-rw-r--r-- 1 mqudsi mqudsi 0 Jan  2 14:22 'test('
```

In my case, I had downloaded a file via `wget` that contained a
parenthesis in its filename. After running `ls`, I presumed that there
was a bug in my shell that passed in the parentheses to `wget`, as I
presumed that `ls` was showing me what was actually there.

Additionally, the output cannot be copied-and-pasted as it is. What is
the point of injecting quotes if they don't actually escape/quote their
content? To illustrate with an example:

```
mqudsi@buster ~> touch \$\(test\)
mqudsi@buster ~> ls -l
-rw-r--r-- 1 mqudsi mqudsi0 Jan  2 14:27 '$(test)'
```

That's not shell-safe, but the quotes might lead you to think it were.

Moreover, the quoting behavior is... weird. I'm not sure what is meant
to be quoted below -- actually, after seeing the output of ls, I'm no
longer sure of anything and have no clue what actually exists on my
filesystem and what doesn't:

```
mqudsi@buster ~> touch \'\test\(\'
mqudsi@buster ~> ls -l
-rw-r--r-- 1 mqudsi mqudsi0 Jan  2 14:22 ''\''test('\'''
```

I think we can all agree that's a bit confusing?

(I'm not clear on whether this is simply a bug or by design, so I'm
hedging my bets and pointing out why it's not a good idea just in case
this behavior was intentional.)

There's no good way to account for all inputs or to account for the
idiosyncrasies of the quoting behavior of all the different shells. It's
not `ls`'s job to insulate the user from making quotes mistakes when
referencing files, if only because in attempting to do so it makes
things a lot worse:

```
mqudsi@buster ~> ls -l
-rw-r--r-- 1 mqudsi mqudsi0 Jan  2 14:27 '$(test)'
mqudsi@buster ~> rm '$(test)' #copy-and-pasted unsafely w/ side-effects
# operation fails, with potentially dangerous side effects
mqudsi@buster ~> rm \'\$(test\)\' #presuming ls output is not quoted
# operation fails because file does not exist
mqudsi@buster ~> rm test\(
# all it took to doing it right
```

Hopefully this behavior can be changed to simply listing the contents of
the specified directory as-is.

Thank you,

Mahmoud Al-Qudsi
NeoSmart Technologies

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Re: Why do we list individual copyright holders?

[Tollef Fog Heen]

]] Markus Koschany 

> Am 02.01.2018 um 19:38 schrieb Russ Allbery:
> [...]
> > I think of the Standards-Version header in a package is a bookmark: this
> > is where I last left off in updating the packaging.  It doesn't change the
> > standard by which the package should be judged.
> 
> I believe that the Standards-Version header should not be part of a
> debian/control file. I understand your reasoning why you want to keep it
> and why it is useful for you. Though in my opinion a debian/control
> file, or generally speaking all information in debian/, should be hard
> requirements and either technically necessary for building a package or
> legally required.

Why should we only include that information?  There is other
information that is neither, but where it's clearly useful to version it
together with the rest of the package, such as the changelog or the
description.  Or, you know, the Standards-Version for the reasons
described elsethread.

Also, the Standards-Version header is only recommended to be included,
it's not mandatory.  If its existence offends you so much and you have
so few bugs to fix in your packages that the primary effort of
maintaining your package is updating the Standards-Version header then
just don't include it?

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

Bug#886176: ITP: libmail-transport-perl -- perl library for sending email

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmail-transport-perl
  Version : 3.001
  Upstream Author : Mark Overmeer
* URL : https://metacpan.org/release/Mail-Transport
* License : Artistic
  Programming Lang: Perl
  Description : perl library for sending email

Mail::Transport is a base class providing common functionality for sending
and receiving mail.

Included in this package are modules for sending mail via various means -
smtp, mailx, exim, qmail and sendmail.

-

This is the second (and last) part separated from libmail-box-perl in version
3.

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

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Re: Why do we list individual copyright holders?

[Vincent Bernat]

 ❦  2 janvier 2018 21:57 +0100, Tollef Fog Heen  :

> Also, the Standards-Version header is only recommended to be included,
> it's not mandatory.  If its existence offends you so much and you have
> so few bugs to fix in your packages that the primary effort of
> maintaining your package is updating the Standards-Version header then
> just don't include it?

Good to know. Unfortunately, I get "E: x source:
no-standards-version-field" from Lintian. Won't the package be rejected
by FTP masters?
-- 
Write clearly - don't be too clever.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Raphael Hertzog]

On Thu, 28 Dec 2017, Marc Haber wrote:
> On Tue, 26 Dec 2017 14:48:50 +0100, Mattia Rizzolo 
> wrote:
> >On Tue, Dec 26, 2017 at 02:45:38PM +0100, Marc Haber wrote:
> >> The time before the last time I asked about tracker, the answer was
> >> that this was not yet possible due to old lintian doing automated
> >> rejects on ftpmaster.
> >
> >That's now fixed, and you can use $pack...@packages.debian.org in the
> >Maintainer field.
> 
> Where does that one forward to? To dispatch+$package_contact@t.d.o?

Yes. But the "contact" keyword will be overriden when you get mails that
can be classified more precisely (like DAK or BTS mails).

That said while it is possible to use @packages.debian.org email
addresses in Maintainer fields it hat not been "validated" yet and you
will likely see multiple problems. Some of them have been identified
already (see Mehdi's mail in this thread) but I expect more of them to
show up (in particular duplicate mails and misclassified mails). IOW,
further work is needed here.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Team naming policy on salsa.debian.org

[Raphael Hertzog]

Hi,

On Sun, 31 Dec 2017, Riku Voipio wrote:
> On Tue, Dec 26, 2017 at 02:17:24PM +0100, Arturo Borrero Gonzalez wrote:
> > Following with your example (pkg-suricata-team) I prefer to make it
> > explicit for people outside debian that this is about packaging.
> > So I usually put the 'pkg' string also in individual repos, i.e.:
> > pkg-suricata-team/pkg-suricata.git
> 
> If your git tree has only debian/ directory, that is accurate. However,
> in case you have the whole upstream tree there, that is misleading. 
> Especially if you have delta against upstream. It would be good to
> signal casual visitors that this repo has upstream changes that might
> be interesting for them.
> 
> So I would limit the pkg- prefix for repos that really only carry debian
> packaging.

Furthermore, naming the repository like the source package makes it
easier to forward mails via the package tracker. You can just send
the commit notifications to dispa...@tracker.debian.org. Otherwise
you have to use something like dispatch+_...@tracker.debian.org
to override the automatic guess of the package name.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#886173: general: ls quotes results with special characters in its output

[Ben Hutchings]

Control: reassign -1 coreutils

On Tue, 2018-01-02 at 20:38 +, mqu...@neosmart.net wrote:
[...]
> In particular, `ls` output (both in regular and `-l` modes) wraps in
> single quotes the names of files that contain special characters (or, at
> least, a parenthesis), meaning its output is not an accurate reflection
> of the actual contents of the directory.

The output of ls on a terminal has never, in general, been an accurate
reflection of the contents of a directory.  Consider that filenames can
contain *any* byte value other than '\0' or '/', so including carriage
return, newline, backspace and escape characters.

ls also uses multiple columns by default, but without quoting you can't
generally tell where the columns are, e.g. is:

aa  ba  ca
ab  bb  cb

a list of 6 two-letter filenames, or 2 filenames with spaces in, or
something else again?

[...]
> Additionally, the output cannot be copied-and-pasted as it is. What is
> the point of injecting quotes if they don't actually escape/quote their
> content? To illustrate with an example:
> 
> ```
> mqudsi@buster ~> touch \$\(test\)
> mqudsi@buster ~> ls -l
> -rw-r--r-- 1 mqudsi mqudsi0 Jan  2 14:27 '$(test)'
> ```
> 
> That's not shell-safe, but the quotes might lead you to think it were.[...]

It is shell-safe.  No $-expansion is done within single-quoted text.

> There's no good way to account for all inputs or to account for the
> idiosyncrasies of the quoting behavior of all the different shells.

I think that the behaviour of single-quoting is very consistent across
shells, in part because it is specified by POSIX.

[...]
> Hopefully this behavior can be changed to simply listing the contents of
> the specified directory as-is.

Be careful what you wish for.  But I think this will revert the recent
change:

alias ls='ls --literal'

and this will disable all transformation of filenames (the same as if
output is not sent to a terminal):

alias ls='ls --literal --color=never --show-control-chars -1'

Ben.

-- 
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.


signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#886173: general: ls quotes results with special characters in its output

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 coreutils
Bug #886173 [general] general: ls quotes results with special characters in its 
output
Bug reassigned from package 'general' to 'coreutils'.
Ignoring request to alter found versions of bug #886173 to the same values 
previously set
Ignoring request to alter fixed versions of bug #886173 to the same values 
previously set

-- 
886173: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886173
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Why do we list individual copyright holders?

[Markus Koschany]

Am 02.01.2018 um 21:57 schrieb Tollef Fog Heen:
> ]] Markus Koschany 
> 
>> Am 02.01.2018 um 19:38 schrieb Russ Allbery:
>> [...]
>>> I think of the Standards-Version header in a package is a bookmark: this
>>> is where I last left off in updating the packaging.  It doesn't change the
>>> standard by which the package should be judged.
>>
>> I believe that the Standards-Version header should not be part of a
>> debian/control file. I understand your reasoning why you want to keep it
>> and why it is useful for you. Though in my opinion a debian/control
>> file, or generally speaking all information in debian/, should be hard
>> requirements and either technically necessary for building a package or
>> legally required.
> 
> Why should we only include that information?  There is other
> information that is neither, but where it's clearly useful to version it
> together with the rest of the package, such as the changelog or the
> description.  Or, you know, the Standards-Version for the reasons
> described elsethread.

The changelog is something which can be naturally derived from the
changes made to a source package and excellent tools like
git-buildpackage ("gbp dch") make this kind of work rather simple. A
package description usually doesn't change. Only in rare circumstances
it has to be adjusted. A Standards-Version header changes frequently,
gets obsolete even faster and provides no valuable information to the
end-user of a package (which a package description and changelog
obviously do)

> Also, the Standards-Version header is only recommended to be included,
> it's not mandatory.  If its existence offends you so much and you have
> so few bugs to fix in your packages that the primary effort of
> maintaining your package is updating the Standards-Version header then
> just don't include it?

I'm neither offended by this field nor emotionally affected by it. I'm
just concerned about the fact that we maintain information in our source
packages which

 a ) can be modified more efficiently outside of them
 b ) are redundant for a large group of maintainers

In fact my primary effort is to improve all packages which I maintain
and touch and by raising my voice on this list I hope that future
maintainers will suffer less from obvious design flaws. I am not aware
of a good reason why keeping the Standards-Version field would help me
in achieving this goal.

If the Standards-Version field is optional, great! Then let's get rid of
it right now. The Lintian error is presumably as mistake, isn't it?

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Re: Why do we list individual copyright holders?

[gregor herrmann]

On Tue, 02 Jan 2018 22:19:26 +0100, Vincent Bernat wrote:

> Good to know. Unfortunately, I get "E: x source:
> no-standards-version-field" from Lintian. Won't the package be rejected
> by FTP masters?

Doesn't seem so:

% grep no-standards-version-field 
/usr/share/lintian/profiles/debian/ftp-master-auto-reject.profile
%


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Paco de Lucia: El Chorruelo [Buleria]


signature.asc
Description: Digital Signature

Re: Why do we list individual copyright holders?

[Russ Allbery]

Markus Koschany  writes:

> I believe that the Standards-Version header should not be part of a
> debian/control file. I understand your reasoning why you want to keep it
> and why it is useful for you. Though in my opinion a debian/control
> file, or generally speaking all information in debian/, should be hard
> requirements and either technically necessary for building a package or
> legally required. The Standards-Version header is a soft requirement,
> someone may or may not find it useful for maintaining the package. For
> team-maintained packages, which all can look very similar, updating this
> header quickly becomes a repetitive task.

> This is comparable to the Vcs-{Git/Svn} and Vcs-Browser fields.

Unlike the Vcs-* headers, which hold information that can change
independently of the package and therefore are a poor match for being
hard-coded into the source package and requiring an upload to change (we
just didn't have a better mechanism at the time), Standards-Version
documents information about the source package itself, and changes are
necessarily linked to changes to the source package (to make it comply
with later versions).

So no, I don't agree with this analysis; I think the Standards-Version
header is a fairly good match for being in the source package itself.

I'm also very reluctant to move too much maintenance information outside
of the source package, because we do not require everyone in Debian to use
the same way to maintain packages.  If we forced everyone maintaining a
package to use Launchpad, for instance, it might make sense to store this
information in Launchpad.  But right now anyone can use whatever methods
and data stores that make them the most productive, and the only common
link between us is the source package and archive.  Therefore, any
information that should survive changes of maintainers (possibly
uncoordinated due to people losing contact with the project) needs to be
in the source package where the next maintainer, QA folks, NMUers, and so
forth can find it.  Or elsewhere in the Debian infrastructure, of course,
but there's currently nowhere else in the Debian infrastructure that the
maintainer has to always keep up to date.

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

Re: Why do we list individual copyright holders?

[Steve Langasek]

On Tue, Jan 02, 2018 at 12:55:36PM +0500, Andrey Rahmatullin wrote:
> 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.

No, they should not.  S-V is a declaration to the packager of what version
they have done the work to update to, but the policy that the package should
comply with is still the most current one and the tools should facilitate
that.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#886197: ITP: node-js-cookie -- Lightweight JavaScript cookie API

[Daniel Ring]

Package: wnpp
Severity: wishlist
Owner: Daniel Ring 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-js-cookie
  Version : 2.2.0
  Upstream Author : Klaus Hartl
* URL : https://github.com/js-cookie/js-cookie
* License : Expat
  Programming Lang: JavaScript
  Description : Lightweight JavaScript cookie API

 JS-Cookie is a simple, lightweight JavaScript API for handling cookies. It
 supports JSON data, custom encodings, and standard JavaScript module loaders.
 .
 Node.js is an event-based server-side JavaScript engine.

Re: Why do we list individual copyright holders?

[Steve Robbins]

On Sunday, December 31, 2017 8:42:29 PM CST Stuart Prescott wrote:
> Vincent Bernat wrote:

> > Lintian is full of opinions. For example, I often get:
> > 
> > W: python-pysnmp4-doc: extra-license-file
> > usr/share/doc/python-pysnmp4-doc/html/_sources/license.txt
> 
> That is not an opinion, it is a statement of fact that there is an
> additional licence file in the package

True.  But it is an *opinion* that this is a fact that one ought to care 
about.  


-Steve


signature.asc
Description: This is a digitally signed message part.

Re: Why do we list individual copyright holders?

[Andrey Rahmatullin]

On Tue, Jan 02, 2018 at 04:25:07PM -0800, Steve Langasek wrote:
> > 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.
> 
> No, they should not.  S-V is a declaration to the packager of what version
> they have done the work to update to, but the policy that the package should
> comply with is still the most current one and the tools should facilitate
> that.
That's not what the Policy thinks though:
"The most recent version of the standards (the policy manual and
associated texts) with which the package complies."

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Why do we list individual copyright holders?

[Steve Langasek]

On Wed, Jan 03, 2018 at 10:22:19AM +0500, Andrey Rahmatullin wrote:
> On Tue, Jan 02, 2018 at 04:25:07PM -0800, Steve Langasek wrote:
> > > 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.

> > No, they should not.  S-V is a declaration to the packager of what version
> > they have done the work to update to, but the policy that the package should
> > comply with is still the most current one and the tools should facilitate
> > that.
> That's not what the Policy thinks though:
> "The most recent version of the standards (the policy manual and
> associated texts) with which the package complies."

These statements are not in contradiction.  Saying "this package complies
with policy version X" doesn't say anything about what version of policy the
package *should* comply with.  Our tooling should absolutely be optimized
for reporting discrepancies against the current policy version, not for
second-guessing the correctness of a given Standards-Version declaration.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Why do we list individual copyright holders?

[Lars Wirzenius]

On Tue, Jan 02, 2018 at 09:33:08PM -0800, Steve Langasek wrote:
> These statements are not in contradiction.  Saying "this package complies
> with policy version X" doesn't say anything about what version of policy the
> package *should* comply with.  Our tooling should absolutely be optimized
> for reporting discrepancies against the current policy version, not for
> second-guessing the correctness of a given Standards-Version declaration.

In my opinion, we don't want a situation where packages get to choose
which versions of the Policy they comply to. They should always comply
to the current version.

The reason we have a Policy document at all is so that all the
packages work together. Some of this is simple: all manpages go under
/usr/share/man, all executables go in one of /bin, /sbin, /usr/bin,
/usr/sbin. Some things are more complicated. All in all there's a lot
of details to get right for 50,000 packages maintained by 1000 people
to form a cohesive, working whole.

The Standard-Version header in debian/control is one of the mechanisms
we use to keep track of where each package is, as far as compliance.
lintian is another. Unfortunately, many of the details are difficult
to test automatically, so can't only rely on lintian.

Over the past several years, I've spent less time updating
Standard-Version in my own packages than I've spent reading this email
thread. I don't want to ridicule anyone's concerns, but I'm of the
opinion that when it comes to S-V, the concerns seem rather overblown
to me.

(I would like to offer a tiny squeak of support for those willing to
do work to move stuff from out of the source package, when it doesn't
need to be there. Homepage, Vcs-*, Maintainer, and Upladers from
debian/control, at least, and debian/watch files entirely. Possibly
Section and Priority fields as well.)

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Why do we list individual copyright holders?

[Vincent Bernat]

 ❦  3 janvier 2018 08:43 +0200, Lars Wirzenius  :

> Over the past several years, I've spent less time updating
> Standard-Version in my own packages than I've spent reading this email
> thread. I don't want to ridicule anyone's concerns, but I'm of the
> opinion that when it comes to S-V, the concerns seem rather overblown
> to me.

According to [1], you did 4 uploads last year. If true, no wonder your
perception doesn't match mine.

[1]: https://people.debian.org/~eriberto/udd/uploaders_ranking.html#sid_uplp
-- 
Format a program to help the reader understand it.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature