Re: Debian part of a version number when epoch is bumped

Hi! Given that other parts of the original thread have started to repeat the same that has been discussed in previous referenced discussions, or even within this thread iteration, I've sat down and written a dpkg FAQ entry:

Work-needing packages report for Feb 16, 2018

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: 1262 (new: 3) Total number of packages offered up for adoption: 164 (new: 1) Total number of packages reques

Re: How to report bugs with the new git repo?

Hello Pavlo, On Thu, Feb 15 2018, Pavlo Solntsev wrote: > I am very excited to see that Debian has moved to GitLab ( > https://salsa.debian.org). With this change, I am wondering how bug > report process should look like? Now, I want to submit patches to > packages, e.g. libgdamm. What would be

Re: How to report bugs with the new git repo?

OK, it looks like it is clear. Thanks. -Pavlo Solntsev - *Please avoid sending me Word or PowerPoint attachments.See http://www.gnu.org/philosophy/no-word-attachments.html

Bug#890540: ITP: libtest-postgresql-perl -- sets up and destroys temporary PostgreSQL instances for testing

Package: wnpp Owner: Don Armstrong Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libtest-postgresql-perl Version : 1.23 Upstream Author : Toby Corkindale Kazuho Oku Peter Mottram plus various contributors. * URL

Re: How to report bugs with the new git repo?

On Thu, Feb 15, 2018 at 08:24:21PM +0500, Andrey Rahmatullin wrote: > If the question is "how should I send a patch to the maintainer" then a > pull request is just one of the available ways, and the best one was > always opening a bug report in the BTS, sending the changes in some other > way dire

Re: How to report bugs with the new git repo?

"W. Martin Borgert" writes: > If it is (probably) a Debian bug, submit bug (and patch) to the > Debian BTS. Ideally, using the "reportbug" command. I would prefer a merge request over a bug with an attached patch: the gitlab workflow is quite effective, especially when compared to a (randomly for

Bug#890523: ITP: python3-anosql -- A Python library for using SQL

Package: wnpp Severity: wishlist Owner: Florian Grignon * Package name: python3-anosql Version : 0.2.0 Upstream Author : Honza Pokorny * URL : https://github.com/honza/anosql * License : BSD Programming Lang: Python Description : A Python library for u

Re: How to report bugs with the new git repo?

On Thu, Feb 15, 2018 at 09:00:28AM -0600, Pavlo Solntsev wrote: > I am very excited to see that Debian has moved to GitLab ( > https://salsa.debian.org). With this change, I am wondering how bug report > process should look like? I don't think anything has changed. > Now, I want to submit patche

Re: How to report bugs with the new git repo?

Quoting Pavlo Solntsev : Now, I want to submit patches to packages, e.g. libgdamm. What would be the best process: submit a patch via push request in the Debian repo, or push patches to upstream? If it is (probably) a Debian bug, submit bug (and patch) to the Debian BTS. Ideally, using the "rep

How to report bugs with the new git repo?

Hello, I am very excited to see that Debian has moved to GitLab ( https://salsa.debian.org). With this change, I am wondering how bug report process should look like? Now, I want to submit patches to packages, e.g. libgdamm. What would be the best process: submit a patch via push request in the De

Bug#890520: ITP: webext-privacy-badger -- Privacy Badger blocks spying ads and invisible trackers

Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: webext-privacy-badger Version : 2018.2.5 Upstream Author : Electronic Frontier Foundation and other contributors * URL : https://github.com/EFForg/privacybadger * License : GPL v3+ Program

Bug#890519: ITP: intel-ipsec-mb -- Intel(R) Multi-Buffer Crypto for IPSec library

Package: wnpp Severity: wishlist Owner: Colin Ian King * Package name: intel-ipsec-mb Version : 0.48 Upstream Author : tomasz.kante...@intel.com * URL : https://github.com/intel/intel-ipsec-mb * License : BSD-3-clause Programming Lang: C, assembler Descript

Re: Debian part of a version number when epoch is bumped

Le 15/02/2018 à 14:15, Vincent Bernat a écrit : ❦ 15 février 2018 13:36 +0100, Thibaut Paumard  : I meant not implemented for java, specifically. But I was wrong: we do have e.g. java8-runtime-headless listed in https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt So t

Re: Debian part of a version number when epoch is bumped

> Simon McVittie writes: > 3.1 > 3.11 > 95 > 98 > 2000 > 1:5.1+XP # or 2001+XP or something > 1:5.2+Vista # or 2006+Vista or something > 1:7 > 1:8 > 1:8.1 > 1:10 > Ignoring the epoch would be actively harmful here: if you have a ve

Re: Debian part of a version number when epoch is bumped

On Thu, Feb 15, 2018 at 10:58:01AM +0100, Thibaut Paumard wrote: Well, in retrospect it would have been good to declare: Depends: default-jre-headless (>= 1:1.8), default-jre-headless (<< 2:) Honestly, the best thing would have just been to depend on openjdk-8-jre-headless instead of messing

Re: Debian part of a version number when epoch is bumped

❦ 15 février 2018 13:36 +0100, Thibaut Paumard  : > I meant not implemented for java, specifically. But I was wrong: we do > have e.g. java8-runtime-headless listed in > https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt > > So the package mentioned by Vincent may be bett

Bug#890510: ITP: gnome-usage -- simple system monitor app for GNOME

Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Owner: jbi...@debian.org Package Name: gnome-usage Version: 3.27.90 Upstream Authors : Red Hat, Felipe Borges License : GPL-3+, parts are LGPL-2.1+ or LGPL-3+ Programming Lang: Vala, C H

Re: Debian part of a version number when epoch is bumped

Le 15/02/2018 à 13:03, gregor herrmann a écrit : On Thu, 15 Feb 2018 10:58:01 +0100, Thibaut Paumard wrote: The "Provides: foo-api (>= 1.8)" mentioned elsewhere in the thread sounds also neat for java packages, but it does not seem to be implemented. It's '(= $version') and we do have these v

Re: Debian part of a version number when epoch is bumped

(Please follow-up to debian-curiosa) Le 15/02/2018 à 11:41, Simon McVittie a écrit : We don't have to look far to find a weird versioning scheme that can't be represented without epochs: our largest competitor in the field of general-purpose operating systems has such a versioning scheme. Imagi

Re: Debian part of a version number when epoch is bumped

On Thu, 15 Feb 2018 10:58:01 +0100, Thibaut Paumard wrote: > The "Provides: foo-api (>= 1.8)" mentioned elsewhere in the thread sounds > also neat for java packages, but it does not seem to be implemented. It's '(= $version') and we do have these versioned Provides since a couple of years [0], th

Re: Debian part of a version number when epoch is bumped

On Thu, Feb 15, 2018 at 10:41:23AM +, Simon McVittie wrote: > On Thu, 15 Feb 2018 at 11:09:08 +0100, Wouter Verhelst wrote: > > I was thinking it might be better to go to a "wildcard" epoch: > > > > Depends: X (>= *:1.8) > > > > would mean > > > > "For this comparison, ignore the epoch, and

Re: Debian part of a version number when epoch is bumped

or instance, if your upstream uses a date-based version number (20180215 or 18.01 or something) but later decides that they don't like that version scheme and switches to 1.0, 1.1, ..., adding an epoch is the only way to make such versions sort correctly (if you have predicted this situation

Re: Debian part of a version number when epoch is bumped

On Wed, Feb 14, 2018 at 04:28:41PM -0500, Michael Stone wrote: > On Wed, Feb 14, 2018 at 12:54:05PM -0800, Russ Allbery wrote: > > Since there are two goals, a more correct implementation would be to split > > these into two versions. The simplest would be to have an integer > > "version epoch" fi

Re: Debian part of a version number when epoch is bumped

On Wed, Feb 14, 2018 at 04:29:20PM +0100, Michael Biebl wrote: > Am 14.02.2018 um 16:08 schrieb Andrey Rahmatullin: > > On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote: > >> It's not only an infrastructure problem. If you Depends on X (>= 1.8), > >> this will be true with X 1:1.6 as

Re: Debian part of a version number when epoch is bumped

Le 14/02/2018 à 18:52, Vincent Bernat a écrit : More concrete example (now a bit in the past). On Wheezy, you want to depend on a 1.8 JRE (you package independently). You put default-jre-headless (>= 1.8). Since you have forgotten about the epoch, this pulls Wheezy default-jre-headless (1:1.7-47+

Bug#890492: ITP: node-localstorage -- substitute for the browser native localStorage API

Package: wnpp Severity: wishlist Owner: ju xor * Package name: node-localstorage Version : 1.3.0 Upstream Author : Larry Maccherone (http://maccherone.com) * URL : https://github.com/lmaccherone/node-localstorage * License : Expat Programming Lang: JavaScript

Re: Debian part of a version number when epoch is bumped

On Thu, Feb 15, 2018 at 08:50:58AM +0100, gregor herrmann wrote: > On Thu, 15 Feb 2018 08:45:23 +0100, Adam Borowski wrote: > > > Package foo > > Version: 2.0-really1.5-1 > > Provides: foo-api-1.5 > > Or: > Provides: foo-api (= 1.5) There is a difference -- some features might be added (usually