Bug#893772: ITP: apertium-separable -- Reordering separable/discontiguous multiwords

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: apertium-separable
  Version : 
  Upstream Author : Francis M. Tyers  and others
* URL : https://www.apertium.org/
* License : GPL-3+
  Programming Lang:
  Description : Reordering separable/discontiguous multiwords

Apertium module for reordering separable/discontiguous multiwords.

 - why is this package useful/relevant? is it a dependency for
   another package? do you use it? if there are other packages
   providing similar functionality, how does it compare?

 A. Dependency for many Apertium packages.

 - how do you plan to maintain it? inside a packaging team
   (check list at https://wiki.debian.org/Teams)? are you
   looking for co-maintainers? do you need a sponsor?

 A. Under science-team umbrella.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Bug#893776: ITP: golang-github-marstr-collection -- implementation of a few basic data structures

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-marstr-collection
  Version : 0.3.3+git20171004.e631537-1
  Upstream Author : Martin Strobel
* URL : https://github.com/marstr/collection
* License : Expat
  Programming Lang: Go
  Description : implementation of a few basic data structures

Inspired by .NET's Linq, querying data structures used in this library
is a snap! Build Go pipelines quickly and easily which will apply
lambdas as they query your data structures. Converting between slices
and a queryable structure is as trivial as it should be.


This package is a dependency of the new upstream version of
golang-github-azure-azure-sdk-for-go.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

New lintian warning: vcs-deprecated-in-debian-infrastructure

[Andreas Tille]

Hi,

today I realised the lintian warning:

W: libbpp-core source: vcs-deprecated-in-debian-infrastructure vcs-git 
https://anonscm.debian.org/git/debian-med/libbpp-core.git
N: 
N:The specified Vcs-* field points to an area within the *.debian.org
N:infrastructure but refers to a version control system that has been
N:deprecated.
N:
N:After 1st May 2018, Debian will not offer hosting for any version
N:control system other than Git and the Alioth service will become
N:read-only in May 2018. Packages should migrate to Git hosting on
N:
N:For further information about salsa.debian.org, including how to add
N:HTTP redirects from alioth, please consult the Debian Wiki.
N:
N:Refer to
N:https://lists.debian.org/debian-devel-announce/2017/08/msg8.html and
N:https://wiki.debian.org/Salsa for details.
N:
N:Severity: normal, Certainty: certain
N:
N:Check: fields, Type: binary, udeb, source
N: 


I admit I do not agree with this and it was discussed here before.  Can
we please agree that anonscm.debian.org remains a valid URL and stop
starting another round of package uploads for the sake of changing Vcs
fields.

I could live with severity of "pedantic" for the lintian issue, thought.
However, I have not seen any argument why anonscm.d.o can not survive
the shutdown of Alioth and remain what it was when it was invented: A
generic Vcs URL for Debian packages no matter on what hostname the
packages really reside.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Alexander Wirt]

On Thu, 22 Mar 2018, Andreas Tille wrote:

> Hi,
> 
> today I realised the lintian warning:
> 
> W: libbpp-core source: vcs-deprecated-in-debian-infrastructure vcs-git 
> https://anonscm.debian.org/git/debian-med/libbpp-core.git
> N: 
> N:The specified Vcs-* field points to an area within the *.debian.org
> N:infrastructure but refers to a version control system that has been
> N:deprecated.
> N:
> N:After 1st May 2018, Debian will not offer hosting for any version
> N:control system other than Git and the Alioth service will become
> N:read-only in May 2018. Packages should migrate to Git hosting on
> N:
> N:For further information about salsa.debian.org, including how to add
> N:HTTP redirects from alioth, please consult the Debian Wiki.
> N:
> N:Refer to
> N:https://lists.debian.org/debian-devel-announce/2017/08/msg8.html and
> N:https://wiki.debian.org/Salsa for details.
> N:
> N:Severity: normal, Certainty: certain
> N:
> N:Check: fields, Type: binary, udeb, source
> N: 
> 
> 
> I admit I do not agree with this and it was discussed here before.  Can
> we please agree that anonscm.debian.org remains a valid URL and stop
> starting another round of package uploads for the sake of changing Vcs
> fields.
> 
> I could live with severity of "pedantic" for the lintian issue, thought.
> However, I have not seen any argument why anonscm.d.o can not survive
> the shutdown of Alioth and remain what it was when it was invented: A
> generic Vcs URL for Debian packages no matter on what hostname the
> packages really reside.
That was announced several times and it will not reside. 

Alex
 

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Jonas Smedegaard]

Quoting Alexander Wirt (2018-03-22 10:03:46)
> On Thu, 22 Mar 2018, Andreas Tille wrote:
> 
> > Hi,
> > 
> > today I realised the lintian warning:
> > 
> > W: libbpp-core source: vcs-deprecated-in-debian-infrastructure vcs-git 
> > https://anonscm.debian.org/git/debian-med/libbpp-core.git
> > N: 
> > N:The specified Vcs-* field points to an area within the *.debian.org
> > N:infrastructure but refers to a version control system that has been
> > N:deprecated.
> > N:
> > N:After 1st May 2018, Debian will not offer hosting for any version
> > N:control system other than Git and the Alioth service will become
> > N:read-only in May 2018. Packages should migrate to Git hosting on
> > N:
> > N:For further information about salsa.debian.org, including how to add
> > N:HTTP redirects from alioth, please consult the Debian Wiki.
> > N:
> > N:Refer to
> > N:https://lists.debian.org/debian-devel-announce/2017/08/msg8.html 
> > and
> > N:https://wiki.debian.org/Salsa for details.
> > N:
> > N:Severity: normal, Certainty: certain
> > N:
> > N:Check: fields, Type: binary, udeb, source
> > N: 
> > 
> > 
> > I admit I do not agree with this and it was discussed here before.  Can
> > we please agree that anonscm.debian.org remains a valid URL and stop
> > starting another round of package uploads for the sake of changing Vcs
> > fields.
> > 
> > I could live with severity of "pedantic" for the lintian issue, thought.
> > However, I have not seen any argument why anonscm.d.o can not survive
> > the shutdown of Alioth and remain what it was when it was invented: A
> > generic Vcs URL for Debian packages no matter on what hostname the
> > packages really reside.
> That was announced several times and it will not reside. 

Why? Lack of volunteers maintaining a redirector, or new service 
incompatible with indirections, or?

Please someone just point me to previous announcement covering this, If 
I am too stupid to have noticed that detail from the flow of information 
related to this.


 - 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

Bug#893777: ITP: golang-github-dimchansky-utfbom -- Detection of the BOM and removing as necessary

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-dimchansky-utfbom
  Version : 0.0~git20170328.6c6132f-1
  Upstream Author : Dmitrij Koniajev
* URL : https://github.com/dimchansky/utfbom
* License : Apache-2.0
  Programming Lang: Go
  Description : Detection of the BOM and removing as necessary

 The package utfbom implements the detection of the BOM (Unicode Byte
 Order Mark) and removing as necessary. It can also return the encoding
 detected by the BOM.


This package is a dependency of the new upstream version of
golang-github-azure-azure-sdk-for-go.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#893779: ITP: golang-github-djherbis-times -- file times (atime, mtime, ctime, btime)

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-djherbis-times
  Version : 1.0.1+git20170215.d25002f-1
  Upstream Author : Dustin H
* URL : https://github.com/djherbis/times
* License : Expat
  Programming Lang: Go
  Description : file times (atime, mtime, ctime, btime)

 Go has a hidden time functions for most platforms, this repo makes
 them accessible.


This package is a dependency of the new upstream version of rclone.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#893782: ITP: golang-github-sevlyar-go-daemon -- library for writing system daemons

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-sevlyar-go-daemon
  Version : 0.1.3+git20180305.32749a7-1
  Upstream Author : Sergey Yarmonov
* URL : https://github.com/sevlyar/go-daemon
* License : Expat
  Programming Lang: Go
  Description : library for writing system daemons

 Features:
  * Goroutine-safe daemonization
  * Out of box work with pid-files
  * Easy handling of system signals
  * Control of a daemon


This package is a dependency of the new upstream version of rclone.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Lars Wirzenius]

On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote:
> I admit I do not agree with this and it was discussed here before.  Can
> we please agree that anonscm.debian.org remains a valid URL and stop
> starting another round of package uploads for the sake of changing Vcs
> fields.

I'm repeating myself, but could we please find another way to store
this information than in the source package? I'd like to see all of
the following stored somewhere else than the source package:

* Maintainer, Uploaders
* Vcs-*
* Homepage
* debian/watch

Possibly also Section and Priority.

All of the above can change and it's silly to have to make a source
upload to change them. They also easily get out of date and so are
likely out of date for a stable release.

I envision a service, metadata.debian.org, with a suitable
authenticated API to allow Debian package maintainers to update the
information, and having tracker.debian.org, dak, and other parties
fetch the data from metadata service, for inclusion in, say, Packages
files.

I think this would be a better thing to spend time on than talking
again about keeping anonscm around.


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

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Andreas Tille]

Hi Lars,

On Thu, Mar 22, 2018 at 12:47:44PM +0200, Lars Wirzenius wrote:
> On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote:
> > I admit I do not agree with this and it was discussed here before.  Can
> > we please agree that anonscm.debian.org remains a valid URL and stop
> > starting another round of package uploads for the sake of changing Vcs
> > fields.
> 
> I'm repeating myself, but could we please find another way to store
> this information than in the source package?

I agree (and others did as well)

> I'd like to see all of
> the following stored somewhere else than the source package:
> 
> * Maintainer, Uploaders
> * Vcs-*
> * Homepage
> * debian/watch

 * debian/upstream/*
   (see Wiki[1])
 
> Possibly also Section and Priority.
> 
> All of the above can change and it's silly to have to make a source
> upload to change them. They also easily get out of date and so are
> likely out of date for a stable release.
> 
> I envision a service, metadata.debian.org, with a suitable
> authenticated API to allow Debian package maintainers to update the
> information, and having tracker.debian.org, dak, and other parties
> fetch the data from metadata service, for inclusion in, say, Packages
> files.

I think there is some general agreement about this.

> I think this would be a better thing to spend time on than talking
> again about keeping anonscm around.

On the other hand the current timing does not allow for a probably
complex implementation and a http redirect which is even implemented[2]
can help to relax the situation we are currently facing.  I admit I
expected the kind of response since it seems related but my posting was
targetting to help for the next couple of monthes and not for discussing
something that will hopefully implemented in the next couple of years.  

Kind regards

  Andreas.

[1] https://wiki.debian.org/UpstreamMetadata
[2] https://salsa.debian.org/salsa/AliothRewriter

-- 
http://fam-tille.de

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Raphael Hertzog]

Hi,

On Thu, 22 Mar 2018, Lars Wirzenius wrote:
> I'm repeating myself, but could we please find another way to store
> this information than in the source package? I'd like to see all of

Sure.

> I envision a service, metadata.debian.org, with a suitable
> authenticated API to allow Debian package maintainers to update the
> information, and having tracker.debian.org, dak, and other parties
> fetch the data from metadata service, for inclusion in, say, Packages
> files.

I don't think we need an entirely new service. tracker.debian.org
already has working authentication and I (as the main service maintainer)
am in favor of going into this direction.

It's just a matter of someone volunteering to do the work.

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: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Alexander Wirt]

On Thu, 22 Mar 2018, Andreas Tille wrote:

> Hi Lars,
> 
> On Thu, Mar 22, 2018 at 12:47:44PM +0200, Lars Wirzenius wrote:
> > On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote:
> > > I admit I do not agree with this and it was discussed here before.  Can
> > > we please agree that anonscm.debian.org remains a valid URL and stop
> > > starting another round of package uploads for the sake of changing Vcs
> > > fields.
> > 
> > I'm repeating myself, but could we please find another way to store
> > this information than in the source package?
> 
> I agree (and others did as well)
> 
> > I'd like to see all of
> > the following stored somewhere else than the source package:
> > 
> > * Maintainer, Uploaders
> > * Vcs-*
> > * Homepage
> > * debian/watch
> 
>  * debian/upstream/*
>(see Wiki[1])
>  
> > Possibly also Section and Priority.
> > 
> > All of the above can change and it's silly to have to make a source
> > upload to change them. They also easily get out of date and so are
> > likely out of date for a stable release.
> > 
> > I envision a service, metadata.debian.org, with a suitable
> > authenticated API to allow Debian package maintainers to update the
> > information, and having tracker.debian.org, dak, and other parties
> > fetch the data from metadata service, for inclusion in, say, Packages
> > files.
> 
> I think there is some general agreement about this.
> 
> > I think this would be a better thing to spend time on than talking
> > again about keeping anonscm around.
> 
> On the other hand the current timing does not allow for a probably
> complex implementation and a http redirect which is even implemented[2]
> can help to relax the situation we are currently facing.  I admit I
> expected the kind of response since it seems related but my posting was
> targetting to help for the next couple of monthes and not for discussing
> something that will hopefully implemented in the next couple of years.  
This was not was you were asking for. The temporary workaround is there (the
redirector), but that doesn't mean your vcs entries are right. The lintian
check is right. We expect you to fix those entries with the next upload and
thats where the check is coming in. And by the way: I implemented the
redirector especially for you.

Alex

P.S. There will be a longer answer from someone of the alioth team, I am just
too tired to explain that all again. 

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Andreas Tille]

On Thu, Mar 22, 2018 at 12:56:30PM +0100, Alexander Wirt wrote:
> > 
> > On the other hand the current timing does not allow for a probably
> > complex implementation and a http redirect which is even implemented[2]
> > can help to relax the situation we are currently facing.  I admit I
> > expected the kind of response since it seems related but my posting was
> > targetting to help for the next couple of monthes and not for discussing
> > something that will hopefully implemented in the next couple of years.  
> This was not was you were asking for. The temporary workaround is there (the
> redirector), but that doesn't mean your vcs entries are right. The lintian
> check is right.

Or rather lintian reflects the current status that was forced by the
Alioth to Salsa migration.  May be somebody can explain me in very
simple words why we can not point anonscm.d.o to salsa.d.o once Alioth
is shut down.

> We expect you to fix those entries with the next upload and
> thats where the check is coming in.

*We expect you to fix* is some quite unusual wording that's very rarely
used on this list.

> And by the way: I implemented the
> redirector especially for you.

While I'm especially thanking you for this service (and the Salsa
migration in general) I feel really shy if you say it was done
"especially" for me.  I consider the wording "motivated by a mail of
mine" more appropriate considering the facts:

AliothRewriter(master) $ git shortlog -s -n | head -n 10
   265  Alexander Wirt
17  Andreas Tille
15  Boris Pek
15  Daniel Kahn Gillmor
13  Anton Gladky
13  Mattia Rizzolo
 8  Andreas Metzler
 7  Maximiliano Curia
 7  Salvatore Bonaccorso
 7  Stuart Prescott
AliothRewriter(master) $ git shortlog -s -n | wc -l
105

> P.S. There will be a longer answer from someone of the alioth team, I am just
> too tired to explain that all again. 

Your mail sounds a bit like you are tired from the migration so once
again:  I'm very happy about all the good work the migration team did so
far.  Unfortunately I have somehow met a sore point with the anonscm.d.o
redirection which is not intended.  I'm just not that happy to reupload
close to 1000 packages[1] when not understanding the technical need for
doing this.

My personal policy is:  I will not change Vcs fields until cme is doing
this for me and I do not give up the hope that some redirect will be
possible.

Kind regards

 Andreas.

[1] https://people.debian.org/~eriberto/udd/uploaders_ranking.html

-- 
http://fam-tille.de

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Alexander Wirt]

On Thu, 22 Mar 2018, Andreas Tille wrote:

> On Thu, Mar 22, 2018 at 12:56:30PM +0100, Alexander Wirt wrote:
> > > 
> > > On the other hand the current timing does not allow for a probably
> > > complex implementation and a http redirect which is even implemented[2]
> > > can help to relax the situation we are currently facing.  I admit I
> > > expected the kind of response since it seems related but my posting was
> > > targetting to help for the next couple of monthes and not for discussing
> > > something that will hopefully implemented in the next couple of years.  
> > This was not was you were asking for. The temporary workaround is there (the
> > redirector), but that doesn't mean your vcs entries are right. The lintian
> > check is right.
> 
> Or rather lintian reflects the current status that was forced by the
> Alioth to Salsa migration.  May be somebody can explain me in very
> simple words why we can not point anonscm.d.o to salsa.d.o once Alioth
> is shut down.
Because it wouldn't work. URLs wouldn't magically work and on the other hand
the redirector will just stop working. 

Alex 

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[David Prévot]

Hi,

Le 22/03/2018 à 02:23, Andreas Tille a écrit :

> My personal policy is:  I will not change Vcs fields until cme is doing
> this for me

Did you miss the last announcement, almost two weeks ago, on this list?

https://lists.debian.org/debian-devel/2018/03/msg00266.html

(aka: you’re already in the future ;)

Regards

David



signature.asc
Description: OpenPGP digital signature

Re: ANNOUNCE: new cme script to update package VCS-Git field

[Andreas Tille]

Hi Dominique,

I've got an explicit pointer to this mail[1] (I admit I was a bit distracted
at that time (flu) ).

On Sat, Mar 10, 2018 at 06:36:42PM +0100, Dominique Dumont wrote:
> Since a lot of people are going to migrate their package repo from alioth to 
> salsa, I've created a small script for cme to help update debian/control file 
> for this new package repository.
> 
> Once you have updated your repo to the new remote (can be on salsa or 
> anywhere 
> else), run
> 
>  cme run set-vcs-git
> 
> This command will update Vcs-Browser and Vcs-Git in debian/control (from the 
> url of the "origin" remote) and commit the change.

I confirm this works nicely, specifically I like the "commit" feature.  (My
workflow is "cme fix ...; git diff ; git commit" - at first sight I assumed
nothing had happened since `git diff` was empty ;-) )
 
> This new script is available from libconfig-model-dpkg-perl 2.106 (and 
> requires cme package)

Thanks a lot.

In the discussion about the new lintian warning[2] I said: "I will not
change Vcs fields until cme is doing this for me."  To be more precise I
would now rather say:

   ... before  `cme fix dpkg-control`  is doing it for me.

While I disagree with the opinion of Alioth admins that there should be
no chance to save anonscm.d.o ("Because it wouldn't work." is no
sensible reason for me) it seems I need to face reality that things will
not happen if I do not setup a redirector for anonscm.d.o myself.  Do you
see any chance to add the set-vcs-git feature to

 cme fix dpkg-control

?  If lintian claims d/control is wrong cme could do this in the "fix"
step.  Does this make sense to you?

BTW, can you explain the philosophy behind `cme run` and `cme fix`.  Or
in other words, why is this

$ cme fix set-vcs-git
Can't locate model for application 'set-vcs-git'.
Run 'cme list' for the list of models available on your system.
You may need to install another Config::Model Perl module.
See the available models there: 
https://github.com/dod38fr/config-model/wiki/Available-models-and-backends
$ cme run dpkg-control
Error: cannot find script dpkg-control


not working?

As always thanks a lot for providing very useful features for cme

 Andreas.


[1] https://lists.debian.org/debian-devel/2018/03/msg00384.html
[2] https://lists.debian.org/debian-devel/2018/03/msg00382.html

-- 
http://fam-tille.de

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Guillem Jover]

Hi!

On Thu, 2018-03-22 at 12:47:44 +0200, Lars Wirzenius wrote:
> On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote:
> > I admit I do not agree with this and it was discussed here before.  Can
> > we please agree that anonscm.debian.org remains a valid URL and stop
> > starting another round of package uploads for the sake of changing Vcs
> > fields.

> I'm repeating myself, but could we please find another way to store
> this information than in the source package? I'd like to see all of
> the following stored somewhere else than the source package:

> * Maintainer, Uploaders
> * Vcs-*
> * Homepage
> * debian/watch
> 
> Possibly also Section and Priority.

I'm not sure now if this also has been said before, but I'm happy to
repeat it in any case. :) I'd very strongly object to completely moving
those fields out of the source packages, because it means when you get
or have a source package lying around then it's missing important
metadata and it stops being standalone, which would require checking
somewhere online, and you might first need to infer which distro/repo
was this coming from. I'll happily take outdated data than no data any
day, because usually you can use that outdated data to trace your way
to the current one, not so if it's missing.

> All of the above can change and it's silly to have to make a source
> upload to change them. They also easily get out of date and so are
> likely out of date for a stable release.

Yes, it might be silly to have to upload a package just and only to
update that information, or having that data being permanently
out-of-date on stable. But this problem can be easily solved already,
the archive, and most (if not all!?) repo managers have had the
concept of overrides for a very long time, starting with things like
dpkg-scanpackages/dpkg-scansources!

The only thing needed would be to provide that additional updated data,
to DAK so that it can override appropriately. Although ftp-masters got
such requests in the past and were apparently not very enthused (although
I don't see any reasoning behind the wontfix), maybe because of the
required manual work. Perhaps if the data was fed in a similar way how
debtags data is fed then they'd have less of an issue? Dunno really.

  

> I envision a service, metadata.debian.org, with a suitable
> authenticated API to allow Debian package maintainers to update the
> information, and having tracker.debian.org, dak, and other parties
> fetch the data from metadata service, for inclusion in, say, Packages
> files.

Sure, as long as it only provides up-to-date data to _override_, and not
the entire and only canonical place to store it.

> I think this would be a better thing to spend time on than talking
> again about keeping anonscm around.

And this is still missing the point, as I've also said in the past. The
worst part of this is not IMO to have to update the Vcs fields, which
TBH is one more time too many. It's that it implies any downstream, any
service pulling from the repo, any mirror and checkout, needs to be
noticed in time (while the redirect is in place, because there's now
recommendation to remove it after the next upload!) and then someone or
something needs to update all those references lying around. :(

Thanks,
Guillem

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Holger Levsen]

On Thu, Mar 22, 2018 at 03:40:21PM +0100, Guillem Jover wrote:
> [...] I'd very strongly object to completely moving
> those fields out of the source packages, because it means when you get
> or have a source package lying around then it's missing important
> metadata and it stops being standalone, which would require checking
> somewhere online, and you might first need to infer which distro/repo
> was this coming from. I'll happily take outdated data than no data any
> day, because usually you can use that outdated data to trace your way
> to the current one, not so if it's missing.
[...] 
> Yes, it might be silly to have to upload a package just and only to
> update that information, or having that data being permanently
> out-of-date on stable. But this problem can be easily solved already,
> the archive, and most (if not all!?) repo managers have had the
> concept of overrides for a very long time, starting with things like
> dpkg-scanpackages/dpkg-scansources!
[...]

Thanks, Guillem, you got my convinced by these (to me, new) arguments.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

improved alioth-salsa test script (calls for testing/improvements)s

[Antoine Beaupré]

So some of us have been working on streamlining the migration between
Alioth and GitLab, because clikety things are annoying.

At first, Christopher Berg wrote this script to trigger the GitLab API:

http://www.df7cb.de/blog/2017/Salsa_batch_import.html

Good start, but it triggered a bug in the GitLab API that happens on
large groups, which means it's slow.

Then Raphael Hertzog made a script to disable repos on Alioth. I
"improved" it a bit by expanding and reusing the description file,
having worked on my own hand-made equivalent, for some repos I
migrated. That lived for a while in ~rhertzog but now lives in
~anarcat/bin/disable-repository.

And then I got tired of doing things by hand or waiting for Berg's
script, so I merge both scripts in a hacky Python script. It's a little
more polished, but maybe not as well tested. I migrated half a dozen of
my repos, and shaken out most bugs (I think!), but I would love to get
more testing. The script now lives in ~anarcat/bin/migrate-repo.

Documentation for all that stuff is in the Debian wiki:

https://wiki.debian.org/Salsa/AliothMigration#Import_git_repository

The source code is in my home repo for now, but maybe it should live in
the salsa/ group (which I'm not a member of) or debian/ group (which I
am). Considering people can fork and send merge requests, I don't think
it matters much for now.

https://salsa.debian.org/anarcat/alioth-migration

The README there has more details & limitations as well.

So hack and migrate away! From what I understand, the migration is going
quite well, and a large number of repos have already moved. Hopefully,
this will make it easier.

Feedback, bug reports, pull requests all welcome of course.

A.
-- 
Pour marcher au pas d'une musique militaire, il n'y a pas besoin de
cerveau, une moelle épinière suffit.
- Albert Einstein

Bug#893807: ITP: libudis86 -- Disassembler Library for x86 and x86-64

[Robert Haist]

Package: wnpp
Severity: wishlist
Owner: Robert Haist 

* Package name: libudis86
  Version : 1.7.2
  Upstream Author : Vivek Thampi 
* URL : http://udis86.sourceforge.net
* License : BSD 2-Clause
  Programming Lang: C
  Description : Disassembler Library for x86 and x86-64

Udis86 is a disassembler for the x86 and x86-64 class of instruction set
architectures. It consists of a C library called libudis86 which
provides a clean and simple interface to decode a stream of raw binary
data, and to inspect the disassembled instructions in a structured
manner.

A lot of debian packages and even the linux kernel seem to reference this
library[1]. I need it as dependency for pev and libpe.

[1]https://codesearch.debian.net/search?q=udis86.h&page=1

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Andreas Tille]

On Thu, Mar 22, 2018 at 03:54:46PM +, Holger Levsen wrote:
> On Thu, Mar 22, 2018 at 03:40:21PM +0100, Guillem Jover wrote:
> > [...] I'd very strongly object to completely moving
> > those fields out of the source packages, because it means when you get
> > or have a source package lying around then it's missing important
> > metadata and it stops being standalone, which would require checking
> > somewhere online, and you might first need to infer which distro/repo
> > was this coming from. I'll happily take outdated data than no data any
> > day, because usually you can use that outdated data to trace your way
> > to the current one, not so if it's missing.
> [...] 
> > Yes, it might be silly to have to upload a package just and only to
> > update that information, or having that data being permanently
> > out-of-date on stable. But this problem can be easily solved already,
> > the archive, and most (if not all!?) repo managers have had the
> > concept of overrides for a very long time, starting with things like
> > dpkg-scanpackages/dpkg-scansources!
> [...]
> 
> Thanks, Guillem, you got my convinced by these (to me, new) arguments.

I admit I have also not read these arguments before and I agree that it
makes sense to have some set of metainformation inside a package since
we need to assume that users are dealing with packages differently than
how we expect.

To give an example how science oriented Blends are dealing with
citations (= very specific metadata):  The citations are part of the
source package (in debian/upstream/metadata[1]) but all real
applications that are consuming the data are taking them from UDD[2].
The UDD gatherer is not reading this information from uploaded source
packages but rather from VCS (since some weeks pointing to Salsa now).
So all (at least all that are known to me) applications get up to date
information about citations relevant for a package from Git without any
need to upload a package but the package contains the metadata that are
up to date at the time of upload.

If I understood correctly this is the principle Guillem wanted to
suggest.

Kind regards

Andreas.

[1] https://wiki.debian.org/UpstreamMetadata
[2] https://wiki.debian.org/UltimateDebianDatabase

-- 
http://fam-tille.de

Re: ANNOUNCE: new cme script to update package VCS-Git field

[gregor herrmann]

On Thu, 22 Mar 2018 15:17:52 +0100, Andreas Tille wrote:

> In the discussion about the new lintian warning[2] I said: "I will not
> change Vcs fields until cme is doing this for me."  To be more precise I
> would now rather say:
> 
>... before  `cme fix dpkg-control`  is doing it for me.
> 
> […] Do you
> see any chance to add the set-vcs-git feature to
> 
>  cme fix dpkg-control
> 
> ? 

Seems our mails crossed; for those reading along at home: We're
working on this in #889732.


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: Element of Crime: Die letzte U-Bahn geht später


signature.asc
Description: Digital Signature

Bug#893818: ITP: golang-github-okzk-sdnotify -- systemd's service notification protocol (sd_notify)

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-okzk-sdnotify
  Version : 0.0~git20160804.ed8ca10-1
  Upstream Author : okzk
* URL : https://github.com/okzk/sdnotify
* License : Expat
  Programming Lang: Go
  Description : systemd's service notification protocol (sd_notify)

 Go implementation of systemd's service notification protocol
 (sd_notify)


This package is a dependency of the new upstream version of rclone.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#893820: ITP: golang-github-patrickmn-go-cache -- in-memory key:value store/cache (similar to Memcached)

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-patrickmn-go-cache
  Version : 2.1.0-1
  Upstream Author : Patrick Mylund Nielsen
* URL : https://github.com/patrickmn/go-cache
* License : Expat
  Programming Lang: Go
  Description : in-memory key:value store/cache (similar to Memcached)

 go-cache is an in-memory key:value store/cache similar
 to memcached that is suitable for applications running on a single
 machine. Its major advantage is that, being essentially a thread-safe
 map[string]interface{} with expiration times, it doesn't need to serialize
 or transmit its contents over the network.


This package is a dependency of the new upstream version of rclone.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Markus Koschany]

Am 22.03.2018 um 15:40 schrieb Guillem Jover:
> Hi!
> 
> On Thu, 2018-03-22 at 12:47:44 +0200, Lars Wirzenius wrote:
>> On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote:
>>> I admit I do not agree with this and it was discussed here before.  Can
>>> we please agree that anonscm.debian.org remains a valid URL and stop
>>> starting another round of package uploads for the sake of changing Vcs
>>> fields.
> 
>> I'm repeating myself, but could we please find another way to store
>> this information than in the source package? I'd like to see all of
>> the following stored somewhere else than the source package:
> 
>> * Maintainer, Uploaders
>> * Vcs-*
>> * Homepage
>> * debian/watch
>>
>> Possibly also Section and Priority.

Yes!

> I'm not sure now if this also has been said before, but I'm happy to
> repeat it in any case. :) I'd very strongly object to completely moving
> those fields out of the source packages, because it means when you get
> or have a source package lying around then it's missing important
> metadata and it stops being standalone, which would require checking
> somewhere online, and you might first need to infer which distro/repo
> was this coming from. I'll happily take outdated data than no data any
> day, because usually you can use that outdated data to trace your way
> to the current one, not so if it's missing.

You need online access to make use of the above information in any way.
If you want to contact the maintainer you need internet access, if you
want to visit the upstream homepage you need internet access, etc. These
information are distribution-independent because they are either the
same like "Homepage" or you could simply look them up if you define a
common and central platform like tracker.debian.org as your main hub for
external/additional/random information about package X. Look how Fedora
have solved the same issue. They have https://src.fedoraproject.org/ and
everything is organized by convention in an identical way. There is no
need for them to put the same information into their spec files and they
also have derivatives. Be sure Ubuntu or Mint users don't care about our
Vcs or maintainer fields as well.

> 
>> All of the above can change and it's silly to have to make a source
>> upload to change them. They also easily get out of date and so are
>> likely out of date for a stable release.
> 
> Yes, it might be silly to have to upload a package just and only to
> update that information, or having that data being permanently
> out-of-date on stable. But this problem can be easily solved already,
> the archive, and most (if not all!?) repo managers have had the
> concept of overrides for a very long time, starting with things like
> dpkg-scanpackages/dpkg-scansources!

I don't understand why some people always think it is smart to create or
use some new program or tool to solve a problem when the most efficient
way would be to solve a problem non-programmatically. Reduce the
complexity by defining conventions which all developers have to follow
in Debian like maintaining external information in tracker.debian.org
instead of the source package. A switch of Vcs platform would become a
trivial matter in the future by replacing some strings on the server. It
would take seconds and could be solved by a single person. I have
already seen hundreds of uploads just for the sake of changing the
Vcs-fields in debian/control. That is crazy.

> The only thing needed would be to provide that additional updated data,
> to DAK so that it can override appropriately. Although ftp-masters got
> such requests in the past and were apparently not very enthused (although
> I don't see any reasoning behind the wontfix), maybe because of the
> required manual work. Perhaps if the data was fed in a similar way how
> debtags data is fed then they'd have less of an issue? Dunno really.
> 
>   
> 
>> I envision a service, metadata.debian.org, with a suitable
>> authenticated API to allow Debian package maintainers to update the
>> information, and having tracker.debian.org, dak, and other parties
>> fetch the data from metadata service, for inclusion in, say, Packages
>> files.
> 
> Sure, as long as it only provides up-to-date data to _override_, and not
> the entire and only canonical place to store it.
> 
>> I think this would be a better thing to spend time on than talking
>> again about keeping anonscm around.
> 
> And this is still missing the point, as I've also said in the past. The
> worst part of this is not IMO to have to update the Vcs fields, which
> TBH is one more time too many. It's that it implies any downstream, any
> service pulling from the repo, any mirror and checkout, needs to be
> noticed in time (while the redirect is in place, because there's now
> recommendation to remove it after the next upload!) and then someone or
> something needs to update all those references lying around. :(

If you store this information on tracker.debian.org

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Ben Finney]

Markus Koschany  writes:

> Am 22.03.2018 um 15:40 schrieb Guillem Jover:
> > I'd very strongly object to completely moving those fields out of
> > the source packages [&.3] I'll happily take outdated data than no
> > data any day, because usually you can use that outdated data to
> > trace your way to the current one, not so if it's missing.
>
> You need online access to make use of the above information in any
> way.

That's not true; you are incorrect in thinking that exhausts the common
uses of that information. For example:

> If you want to contact the maintainer you need internet access

With the maintainer email address, I do not need internet access to
compose an email message. Without that information I can't.

> if you want to visit the upstream homepage you need internet access

With the upstream home page URL, I do not need internet access to
bookmark a URL. Without that URL I can't.

> etc.

So, there are plenty of uses for information that do not require
internet access *at the time of using* the information.

Yes, some uses do require internet access; that doesn't eliminate all
usefulness of the information.

So, I concur with Guillem: This information is closely tied to the
source package, and the source package becomes less useful (lack of
imagination notwithstanding :-) by taking that information away from the
source package.

There may be good arguments for removing that information from the
source package. But let's dispose now of the “it's no use” claim;
that's simply false, so some other justification will be needed.

-- 
 \   “If consumers even know there's a DRM, what it is, and how it |
  `\ works, we've already failed.” —Peter Lee, Disney corporation, |
_o__) 2005 |
Ben Finney

Re: Different priorities on different architectures

[Ben Hutchings]

On Wed, 2018-03-21 at 23:18 +0300, kact...@gnu.org wrote:
> Hello!
> 
> Recently I got report (and I can confirm) that libgdbm5_1.14.1-6 have
> different priorities on x86 and amd64. In source package it is
> optional, I checked.

The package priority is architecture-independent.  The reason for the
difference you see is that you're comparing dpkg status with the apt
cche.  The dpkg status will have the priority that was set in the
source package, whereas the apt cache will have the priority that was
set by the FTP team.  Usuaully these are the same but not always.

> I doubt it matter, but that they have different versioned dependencies
> on libc. Any suggestions, what else to check and how to fix?
[...]

This is not (necessarily) a bug.  Sometimes glibc changes the ABI of a
function, and sometimes only for some architectures.  The version int e
dependency will be determined based on the functions libgdbm5 uses and
whenever they were introduced or last changed ABI.  (These changes are
backward-compatible because glibc maintains the old versions as well,
and uses symbol versioning to distinguish them.)

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.



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

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Ben Hutchings]

On Thu, 2018-03-22 at 15:40 +0100, Guillem Jover wrote:
> Hi!
> 
> On Thu, 2018-03-22 at 12:47:44 +0200, Lars Wirzenius wrote:
> > On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote:
> > > I admit I do not agree with this and it was discussed here before.  Can
> > > we please agree that anonscm.debian.org remains a valid URL and stop
> > > starting another round of package uploads for the sake of changing Vcs
> > > fields.
> > I'm repeating myself, but could we please find another way to store
> > this information than in the source package? I'd like to see all of
> > the following stored somewhere else than the source package:
> > * Maintainer, Uploaders
> > * Vcs-*
> > * Homepage
> > * debian/watch
> > 
> > Possibly also Section and Priority.
> 
> I'm not sure now if this also has been said before, but I'm happy to
> repeat it in any case. :) I'd very strongly object to completely moving
> those fields out of the source packages, because it means when you get
> or have a source package lying around then it's missing important
> metadata and it stops being standalone, which would require checking
> somewhere online, and you might first need to infer which distro/repo
> was this coming from. I'll happily take outdated data than no data any
> day, because usually you can use that outdated data to trace your way
> to the current one, not so if it's missing.
[...]

Yes, there should be a reference to the distribution.  Just one
reference per package, e.g. https://tracker.debian.org/pkg/foo for any
official Debian binary package.  And that should be enforced by a
lintian check on upload, and only need updating if the source package
is renamed.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.



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

Work-needing packages report for Mar 23, 2018

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1284 (new: 4)
Total number of packages offered up for adoption: 161 (new: 0)
Total number of packages requested help for: 53 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   collada2gltf (#893592), orphaned 2 days ago
 Description: COLLADA to glTF conversion library
 Installations reported by Popcon: 56
 Bug Report URL: http://bugs.debian.org/893592

   jetring (#893063), orphaned 6 days ago
 Description: gpg keyring maintenance using changesets
 Installations reported by Popcon: 97
 Bug Report URL: http://bugs.debian.org/893063

   o3dgc (#893593), orphaned 2 days ago
 Description: Open 3D Graphics Compression library
 Installations reported by Popcon: 62
 Bug Report URL: http://bugs.debian.org/893593

   rapidjson (#893199), orphaned 5 days ago
 Description: fast JSON parser/generator for C++ with SAX/DOM style
   API
 Reverse Depends: libcollada2gltfconvert-dev
 Installations reported by Popcon: 149
 Bug Report URL: http://bugs.debian.org/893199

1280 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 161 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   autopkgtest (#846328), requested 477 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker openstack-pkg-tools
 Installations reported by Popcon: 1090
 Bug Report URL: http://bugs.debian.org/846328

   balsa (#642906), requested 2370 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 658
 Bug Report URL: http://bugs.debian.org/642906

   broadcom-sta (#886599), requested 73 days ago (non-free)
 Description: Broadcom STA Wireless driver (non-free)
 Installations reported by Popcon: 2012
 Bug Report URL: http://bugs.debian.org/886599

   cargo (#860116), requested 345 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 607
 Bug Report URL: http://bugs.debian.org/860116

   cups (#532097), requested 3211 days ago
 Description: Common UNIX Printing System
 Reverse Depends: ayatana-indicator-printers bluez-cups boomaga
   chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd (71 more omitted)
 Installations reported by Popcon: 179716
 Bug Report URL: http://bugs.debian.org/532097

   cyrus-sasl2 (#799864), requested 911 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli
   autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper
   claws-mail-archiver-plugin (122 more omitted)
 Installations reported by Popcon: 202739
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 615 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg
   libdee-dev zeitgeist-core
 Installations reported by Popcon: 65278
 Bug Report URL: http://bugs.debian.org/831388

   developers-reference (#759995), requested 1300 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 13988
 Bug Report URL: http://bugs.debian.org/759995

   devscripts (#800413), requested 905 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   brz-debian bzr-builddeb customdeb debci debian-builder debmake (28
   more omitted)
 Installations reported by Popcon: 13110
 Bug Report URL: http://bugs.debian.org/800413

   ed (#886643), requested 73 days ago
 Description: classic UNIX line editor
 Reverse Depends: apt-cacher debbugs opensmtpd sn
 Installations reported by Popcon: 22623
 Bug Report URL: http://bugs.debian.org/886643

   ejabberd (#767874), requested 1235 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib ejabberd-mod-cron
   ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml
   ejabberd-mod-message-log ejabb

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Adam Borowski]

On Fri, Mar 23, 2018 at 10:22:52AM +1100, Ben Finney wrote:
> Markus Koschany  writes:
> > If you want to contact the maintainer you need internet access
> 
> With the maintainer email address, I do not need internet access to
> compose an email message. Without that information I can't.

apt show $PACKAGE

There's no need to duplicate the information inside .dsc/.deb and apt
indices.

> > if you want to visit the upstream homepage you need internet access
> 
> With the upstream home page URL, I do not need internet access to
> bookmark a URL. Without that URL I can't.

As above -- but pray tell, what will you do with that URL?  Unlike an e-mail
which you can compose then send later, a webpage you can't access is of no
use.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Ben Finney]

Adam Borowski  writes:

> but pray tell, what will you do with that URL?

Visit it later, when I *do* have internet access.

Many people have internet connections that are unreliable, slow,
expensive, arbitrarily blocked, or some combination of all those. We
should not assume that “has internet access” is a binary, all-or-nothing
property; and we should not dismiss the use cases of people who are
between those extremes.

-- 
 \“Pinky, are you pondering what I'm pondering?” “Wuh, I think |
  `\   so, Brain, but wouldn't anything lose its flavor on the bedpost |
_o__)   overnight?” —_Pinky and The Brain_ |
Ben Finney

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Guillem Jover]

On Fri, 2018-03-23 at 03:33:48 +0100, Adam Borowski wrote:
> apt show $PACKAGE
> 
> There's no need to duplicate the information inside .dsc/.deb and apt
> indices.

Do you realize that the point of the repository (not apt :) indices is
precisely to duplicate all the information from the .dsc/.deb? Plus
some extra stuff.

Thanks,
Guillem

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Guillem Jover]

On Thu, 2018-03-22 at 23:23:22 +0100, Markus Koschany wrote:
> Am 22.03.2018 um 15:40 schrieb Guillem Jover:
> > On Thu, 2018-03-22 at 12:47:44 +0200, Lars Wirzenius wrote:
> >> On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote:
> >>> I admit I do not agree with this and it was discussed here before.  Can
> >>> we please agree that anonscm.debian.org remains a valid URL and stop
> >>> starting another round of package uploads for the sake of changing Vcs
> >>> fields.
> > 
> >> I'm repeating myself, but could we please find another way to store
> >> this information than in the source package? I'd like to see all of
> >> the following stored somewhere else than the source package:
> > 
> >> * Maintainer, Uploaders
> >> * Vcs-*
> >> * Homepage
> >> * debian/watch
> >>
> >> Possibly also Section and Priority.
> 
> Yes!
> 
> > I'm not sure now if this also has been said before, but I'm happy to
> > repeat it in any case. :) I'd very strongly object to completely moving
> > those fields out of the source packages, because it means when you get
> > or have a source package lying around then it's missing important
> > metadata and it stops being standalone, which would require checking
> > somewhere online, and you might first need to infer which distro/repo
> > was this coming from. I'll happily take outdated data than no data any
> > day, because usually you can use that outdated data to trace your way
> > to the current one, not so if it's missing.

> You need online access to make use of the above information in any way.
> If you want to contact the maintainer you need internet access, if you
> want to visit the upstream homepage you need internet access, etc.

Not really. For starters, we'd need to have network access to be able
to run dch or lintian, because they do check whether an upload is
supposed to be an NMU, team upload, etc. This seems ridiculous.

Some people like to add branch information in the Vcs- fields, this
would then require to support adding that info before the package
exists in tha vcs or archive branch (which means less sanity checks)
or afterwards (which means it's prone to be forgotten).

The Section and Priority are overridden by ftp-masters, but the
maintainer tends to fill it more or less correctly. Without them,
ftp-masters would need to come up with values from scratch, which
is more difficult than correcting them if they seem off.

If one has got to update the data for several of those fields, it can
currently be done off-line, and then pushed when one's back on-line,
this is getting back into the centralized development model.

These fields/files are generally useful outside Debian, if we stop
providing them then it's to be expected that tooling might bit-rot.
While requiring someone with a tiny local archive to install a tracker
instance seems just onerous.

> These
> information are distribution-independent because they are either the
> same like "Homepage" or you could simply look them up if you define a
> common and central platform like tracker.debian.org as your main hub for
> external/additional/random information about package X.

This still means keeping the package and its metadata separate, which
is prone to be forgotten by maintainers when updating packaging locally.
So it's a locality problem too. Look at the current debtags coverage. :(

> Look how Fedora
> have solved the same issue. They have https://src.fedoraproject.org/ and
> everything is organized by convention in an identical way. There is no
> need for them to put the same information into their spec files and they
> also have derivatives. Be sure Ubuntu or Mint users don't care about our
> Vcs or maintainer fields as well.

Well, Fedora is not Debian, we have wildly different history, practices
and workflows for a reason, etc. And, I'd say what you provide is actually
a counter-example. They list the Group (our Section), Url (our Homepage)
and the SourceN (our watch file) in the spec file. And they do not need
(ahem) Vcs fields because they have a unified and properly namespaced (!)
git managed set of packaging-only repos. And when it comes to the
contributors, well in many cases it does not even reflect reality between
what's listed on the site and who is doing the changes, so there you go.

> >> All of the above can change and it's silly to have to make a source
> >> upload to change them. They also easily get out of date and so are
> >> likely out of date for a stable release.
> > 
> > Yes, it might be silly to have to upload a package just and only to
> > update that information, or having that data being permanently
> > out-of-date on stable. But this problem can be easily solved already,
> > the archive, and most (if not all!?) repo managers have had the
> > concept of overrides for a very long time, starting with things like
> > dpkg-scanpackages/dpkg-scansources!
> 
> I don't understand why some people always think it is smart to create or
> use some new program or tool to solve a problem w