Re: Debian Trends updated

2021-04-13 Thread Bastian Blank
Hi Lucas

I would like to add:

- Removing Berkeley DB.

Bastian

-- 
Violence in reality is quite different from theory.
-- Spock, "The Cloud Minders", stardate 5818.4



Re: Debian Trends updated

2021-04-13 Thread Lucas Nussbaum
On 13/04/21 at 11:18 +0200, Bastian Blank wrote:
> Hi Lucas
> 
> I would like to add:
> 
> - Removing Berkeley DB.

To clarify, I was focusing on stuff that is already tracked via Trends.

Lucas



Relicensing APT's methods/rsh.cc from GPL-2 to GPL-2+

2021-04-13 Thread Julian Andres Klode
Hi folks,

I noticed today that methods/rsh.cc was GPL-2 only, which is an
outlier in the licensing that should be fixed, as it prevents GPL-3
components from making it into apt-pkg.

Apart from DonKult and me, we have the following contributors who
we need permission for relicensing from:

* Ben Collins
- got permission @ https://twitter.com/benmcollins13/status/1381982744788545536
* Adam Heath (doogie)
* Daniel Hartwig  (CCed)

If anyone knows doogie's contact, please forward.

Thanks!
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en



Epoch bump for kworkflow

2021-04-13 Thread João Seckler
Hi,

I am currently in process of updating the kworkflow package[1][2]. I am
having issues providing a debian/watch file for the following reasons:

- Upstream maintains no tags nor releases. I am in touch with them to
  ask them to create tags or releases;
- Current version of the package is 20191112-1.1. The date in it doesn't
  seem to be related to any information provided by the upstream;
- Even if upstream isn't willing to use tags or releases, the
  alternative "go-like" version of the package, gathered from the latest
  upstream commit (0.0~git20201226.e30ce3a), compares erroneously to the
  current version format.

By suggestion of sergiodj and kanashiro, I intend to use an epoch when
versioning future releases of this package, which will allow the
adoption of a more sensible version format.

Any feedback is welcome.

João Seckler

[1] tracker.debian.org/pkg/kworkflow
[2] salsa.debian.org/jseckler-guest/kworkflow


signature.asc
Description: PGP signature


Re: Epoch bump for kworkflow

2021-04-13 Thread Cyril Brulebois
Hi João,

João Seckler  (2021-04-13):
> I am currently in process of updating the kworkflow package[1][2]. I am
> having issues providing a debian/watch file for the following reasons:
> 
> - Upstream maintains no tags nor releases. I am in touch with them to
>   ask them to create tags or releases;
> - Current version of the package is 20191112-1.1. The date in it doesn't
>   seem to be related to any information provided by the upstream;
> - Even if upstream isn't willing to use tags or releases, the
>   alternative "go-like" version of the package, gathered from the latest
>   upstream commit (0.0~git20201226.e30ce3a), compares erroneously to the
>   current version format.
> 
> By suggestion of sergiodj and kanashiro, I intend to use an epoch when
> versioning future releases of this package, which will allow the
> adoption of a more sensible version format.
> 
> Any feedback is welcome.

What about using a similar versioning scheme but without the 0.0~git
prefix?

Going for 20201226.e30ce3a(-1) or something similar would sort higher
than the current version number, and you could just wait for an
hypothetical switch to a “tag/version-based format” to introduce the
epoch? Introducing an epoch and an artificial 0.0 release right now
would seem a little odd to me.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature