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

[Nikolaus Rath]

On Mar 23 2018, Ben Finney  wrote:
>> 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
>
> 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.

Are that practical concerns or theoretical objections to the generality
of the statement?

You can still compose the email message, you'll just add the recipient
address later once you have internet.

Yeah, you can't bookmark the URL - but why would you? Just "bookmark"
the name of the package, and once you have internet access use the
(pre-existing) bookmark to the site that will give you a link to the
upstream homepage.

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

Does "plenty" refer to the two examples you gave? 

Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

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

[Simon McVittie]

On Sat, 24 Mar 2018 at 11:02:17 +0100, Alexander Wirt wrote:
> On Sat, 24 Mar 2018, Ole Streicher wrote:
> > Given the fact that nobody strongly questioned the limitation of
> > salsa.d.o to git (and therefore the requirement to migrate from other
> > VCSs), I would have no objection against git.d.o -- if using
> > programmatically (f.e. via Python) you anyway rely on the specific VCS
> > API.
>
> Unfortunately that will never work properly for git:// or ssh+git://

I'm not sure that's really a problem? Lintian already gives us warnings
if the Vcs-Git isn't https://, because git:// doesn't have integrity
protection and ssh+git:// isn't open to the public.

(DDs and other contributors with Salsa accounts can use insteadOf or
pushInsteadOf to switch https:// URLs to git+ssh:// if they want to.)

smcv

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

[Alexander Wirt]

On Sat, 24 Mar 2018, Ole Streicher wrote:

> Joerg Jaspert  writes:
> > packages.d.o/packagename and you are there. Nothing else needed.
> 
> packages.d.o does not provide a canonical URL for the repository.
> 
> It is even more difficult: I have first to select the package name, then
> select the distribution, go to the tracker.d.o, and select one of the
> VCS links.
> 
> Also tracker.d.o does not have a canonical URL for this (which would IMO
> be a more natural place): I can't just do a 
> 
> git clone https://tracker.debian.org/<>/vcs
> 
> or put
> 
> Vcs-Browser: https://tracker.debian.org/<>
> 
> into d/control (and be safe against future changes of the location).
> 
> > Even independent of the underlying vcs, not hardcoded to git or one
> > provider of hosting it.
> 
> Given the fact that nobody strongly questioned the limitation of
> salsa.d.o to git (and therefore the requirement to migrate from other
> VCSs), I would have no objection against git.d.o -- if using
> programmatically (f.e. via Python) you anyway rely on the specific VCS
> API.
Unfortunately that will never work properly for git:// or ssh+git://

Alex
 

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

[Ole Streicher]

Joerg Jaspert  writes:
> packages.d.o/packagename and you are there. Nothing else needed.

packages.d.o does not provide a canonical URL for the repository.

It is even more difficult: I have first to select the package name, then
select the distribution, go to the tracker.d.o, and select one of the
VCS links.

Also tracker.d.o does not have a canonical URL for this (which would IMO
be a more natural place): I can't just do a 

git clone https://tracker.debian.org/<>/vcs

or put

Vcs-Browser: https://tracker.debian.org/<>

into d/control (and be safe against future changes of the location).

> Even independent of the underlying vcs, not hardcoded to git or one
> provider of hosting it.

Given the fact that nobody strongly questioned the limitation of
salsa.d.o to git (and therefore the requirement to migrate from other
VCSs), I would have no objection against git.d.o -- if using
programmatically (f.e. via Python) you anyway rely on the specific VCS
API.

Best

Ole

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

[Lars Wirzenius]

On Fri, 2018-03-23 at 04:07 +0100, Guillem Jover wrote:
> 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.

This is in fact not the case. The information in the Packages file
does not necessarily come from the source package. For example,
package tags does not come from the source package, but from an
external source.

Section and priority information only partially comes from the source
package, and primarily from the ftp master overrides file. Worse, the
values in the source package (even in unstable) may be entirely wrong
for the binary package.

Having, say, Homepage come from an external source insted of
debian/control does not seem to me like a big revolution to me.


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

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

[Joerg Jaspert]

On 14986 March 1977, Ole Streicher wrote:

>  which IMO proves that a sophisticated "layout" with namespaces or
> subdirs is a bad idea for canonical URLs.
> Why can't we have a flat name space with redirection
> https://git.debian.org/
> (or similar) that just redirects to the proper real location within salsa?
> Our source package names are unique, so there should be no conflicts.

Thats called packages.debian.org in combination with the vcs urls and
exists for a long time. It can be argued that the way of updating the
vcs urls stuff ought to be different, but the above wish already exists.

> That would make the discovery of a certain package *much* easier than
> the current structured approach.

packages.d.o/packagename and you are there. Nothing else needed.
Even independent of the underlying vcs, not hardcoded to git or one
provider of hosting it.

-- 
bye, Joerg

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

[Daniele Nicolodi]

On 23/03/2018 17:04, Ole Streicher wrote:
> Why can't we have a flat name space with redirection
> 
> https://git.debian.org/
> 
> (or similar) that just redirects to the proper real location within salsa?
> Our source package names are unique, so there should be no conflicts.
> 
> That would make the discovery of a certain package *much* easier than
> the current structured approach.

Isn't this in essence the idea at the base of the Vcs- fields in
debian/control?  Namely providing an universal way to map from packages
to repositories independently of where they are hosted?

Cheers,
Daniele

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

[Ole Streicher]

Joerg Jaspert  writes:
> So that got us to "It would be nice. It does not work usefully. -> It
> won't happen". And basically you can expect another hostname change to
> happen *AGAIN* in the future, should we switch from gitlab to
> whatever-is-good-then, UNLESS that hypothetical thing is about identical
> on the whole layout. THEN one can do a "switchover day is X, all repos
> and groups and whatnot will be forcefully migrated then, no user action
> needed".

 which IMO proves that a sophisticated "layout" with namespaces or
subdirs is a bad idea for canonical URLs.

Why can't we have a flat name space with redirection

https://git.debian.org/

(or similar) that just redirects to the proper real location within salsa?
Our source package names are unique, so there should be no conflicts.

That would make the discovery of a certain package *much* easier than
the current structured approach.

Best

Ole

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

[Joerg Jaspert]

On 14984 March 1977, Jonas Smedegaard wrote:

>> That was announced several times and it will not reside. 
> Why? Lack of volunteers maintaining a redirector, or new service 
> incompatible with indirections, or?

Multiple things, and it ended up a decision we took at the meeting in
Hamburg.

First off we (the salsa admins) would have liked to take over the
hostname. But then we discussed and thought through it. What would it
get us? A host of problems and not much gain actually. It sounds simple
"Hey the host is same, no need to change packages" - but that is not
true. Gitlab is very different in its layout and handling of things than
old alioth.

Before you come "Well, apache redirect map", think of it. We have that
right now already. Actually twice. There is one map on alioth itself,
trying to map old stuff into cgit, and there is the new alioth
redirector mapping migrated stuff to alioth. Now what, that only does a
small subset of requests, http. Not git. (Not ssh). And it needs manual
action for each and every migrated package...

Very much not optimal. And the cgit one, while being there for a long
time, still does not work for all cases, is a mess, declared as
"unmaintainable" by its maintainer.

So redirecting is a bad way, its hard to maintain and only does it for a
subset of the needed pieces. The redirector WILL go away in the not-too
distant future, it is a hacky interims solution.

So, moving the hostname. Could have done that. When? How about

"Here is salsa, its all new gitlab, entirely different to alioth, btw,
anonscm moved over, if you didn't migrate your repos yet, you won't see
them on anonscm anymore"?

Or would

"Here is salsa, its all new gitlab, entirely different to alioth, btw,
in half a year, anonscm moves over, if you migrate your repos before,
you won't see them on anonscm until then"

be better?

And both leave out that part of "And hey, the whole entirely different
to alioth means its a new url, please immediately update your packages
vcs-whatever entries for it", which means an upload anyways..


So that got us to "It would be nice. It does not work usefully. -> It
won't happen". And basically you can expect another hostname change to
happen *AGAIN* in the future, should we switch from gitlab to
whatever-is-good-then, UNLESS that hypothetical thing is about identical
on the whole layout. THEN one can do a "switchover day is X, all repos
and groups and whatnot will be forcefully migrated then, no user action
needed".

-- 
bye, Joerg

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

[Simon McVittie]

On Fri, 23 Mar 2018 at 13:56:09 +0100, Markus Koschany wrote:
> If you were involved in team maintenance you would know that the
> Uploaders field is often completely outdated. The only way you can see
> who maintains a package is by looking at the Git history or upload
> history in tracker.debian.org. We had/have contributors who were
> mentioned as Uploaders in hundreds of packages and now they only can be
> removed by uploading a new package.

Or, alternatively, you work around the current d/control arrangement like
the GNOME team does, and auto-generate the Uploaders at upload-time from a
list of team members and the most recent uploaders in the changelog, which
to be honest seems fairly pointless: consumers of this information typically
have access to the changelog and can equally well see who uploaded the
package for themselves.

(I don't recommend going this route: it's fighting against generic
packaging infrastructure assumptions like "d/control is its own source
code".)

> Well, you can adjust Lintian in a way to check the web service for the
> information which was formerly present in debian/control and get all the
> warnings and errors people like

By design, Lintian can't actually do this (it looks at individual
packages in isolation), but a Lintian-like service definitely could
(like the way we now get warnings on tracker.d.o or on UDD about
Multi-arch fields, duplicated data files, failing uscan runs, and similar
external-to-the-package issues that Lintian cannot check).

smcv

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

[Markus Koschany]

Am 23.03.2018 um 05:27 schrieb 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:
[...]
>> 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.

It is not that difficult to pass dch --team, dch --nmu or gbp dch manually.

If you were involved in team maintenance you would know that the
Uploaders field is often completely outdated. The only way you can see
who maintains a package is by looking at the Git history or upload
history in tracker.debian.org. We had/have contributors who were
mentioned as Uploaders in hundreds of packages and now they only can be
removed by uploading a new package. A web based solution with a database
would solve this problem in seconds. NMU or Team uploads are
interchangeable terms and not very interesting when all you want to know
is: Who did the last upload?


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

I don't mind if you have special requirements but I don't see a reason
why this should get in the way of the majority of contributors who can
live with the standards. My point is that the default should be
different. Don't require contributors to maintain information which can
be maintained more efficiently in tracker.debian.org. Prefer convention
over configuration.

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

Almost all packages are priority optional. That could simply be the
default. Our essential, required or standard packages change very
rarely. If you have to introduce a new package with a higher priority as
optional it has to go through NEW as every other package. While this
processing takes place we could find a way to ensure that the priority
is correct.

Removing Section and Priority from debian/control would not be an urgent
priority for me because they don't change frequently like
Vcs/homepage/maintainer but if we think outside the box it could be done.

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

I don't see how this outweighs the benefit of adding and changing
information _once_ when you are back online. Instead of preparing
hundreds of uploads, compiling the packages on our infrastructure and
duplicating the same information on hundreds of mirrors around the world
(which wastes time, energy and disk space) you maintain your _meta
information_ in a web application. Most, especially younger people, are
familiar with this concept and I would expect this would seem more
natural to them and probably even attract more contributors.

That doesn't stop you from doing the real development work offline.
Besides a web based solution like tracker would provide the unique
opportunity to get more people without upload permissions involved.
Imagine a contributor that corrects your outdated homepage entry and
upstream Git repository while you are offline and as soon as you are
back online the only thing you have to do is to approve it.

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

There is no need for a local tracker instance. An offline feature is not
important as long as you are online once in a while which is to be
expected nowadays. The meta information just moves to a new central
place. Yes, you have to adapt some tools but you gain all the benefits
of a REST API with a unique interface and data in JSON/XML/YAML/HTML
whatever. It will be easier to access for random people and I can
imagine it would simplify the information exchange between different
distributions not just Debian derivatives.

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

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

[Lars Wirzenius]

On Thu, 2018-03-22 at 15:40 +0100, Guillem Jover wrote:
> 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.

I believe I understand your point of view, but I still disagree.


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

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 

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

[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

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

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

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

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

[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: 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

[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:

> 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

[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

[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

[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

[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

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