Re: Automated removal of RC buggy packages
On Tue, 2019-11-12 at 00:51 +0100, Matthias Klose wrote: > why do you even consider such uploads suitable for unstable? That's > something > which should go to experimental. With packages from experimental, users do not get updates by default even for packages installed from experimental and/or only available via experimental. But for packages like firefox, users should really get updates by default. Unstable is arguably also easier to use than experimental (no extra source entries, no pinning, ...). I believe binNMUs are also mostly only scheduled for packages in unstable. Ansgar
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On 11/11/19 12:50 PM, Jeremy Bicha wrote: > On Mon, Nov 11, 2019 at 2:59 AM Thomas Goirand wrote: >> On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote: >>> On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote: Please, *never* do that. It's generally a very bad idea to write anything to debian/gbp.conf. It's as if you were adding your text editor preferences in the package. Instead, please prefer writing in ~/.gbp.conf. >>> >>> I keep most of my git-buildpackage settings which are specific to my >>> developer environment in ~/.gbp.conf. However, there are some gbp >>> settings which are specific to the repository set up, and those I >>> think, IMHO, *are* appropriate for debian/gbp.conf. For example: >>> >>> [DEFAULT] >>> pristine-tar = True >>> upstream-tag='v%(version)s' >>> debian-branch=debian/master >> >> The first 2, yes. The last one, it's my opinion that it's useless, and >> that you only need it because "ignore-branch = True" isn't the default >> in git-buildpackage. It's ok as long as you always keep the same >> packagig branch, but if, like in my team, we need a new branch name >> every 6 months, and for 400+ repositories, then keeping the branch name >> declared in debian/gbp.conf becomes super annoying (as it forces one to >> change the "debian-branch" each time). > > Could you please add debian/gbp.conf back to your packages? As I > understand it, I think your preferred settings would look something > like this: > > [DEFAULT] > ignore-branch = True > pristine-tar = False > > [buildpackage] > sign-tags = True > > [dch] > multimaint-merge = True > > [import-orig] > upstream-tag = %(version)s > > [pq] > patch-numbers = False > > > > It is absolutely not possible to set the correct > pristine-tar=True/False in ~/.gbp.conf to work with your packages > (which avoid pristine-tar) and the vast majority of gbp packages in > Debian which do use pristine-tar. Those settings are specific to the > workflow for that repo, and everyone using that repo needs to use > those same settings to avoid issues. Hi Jeremy, I don't think what you wrote above is correct. None of the options you mentioned are mandatory. If GBP doesn't see the use of pristine-tar, it will assume that we're using an upstream tag, which is fine. If you're rebuilding a package which is already in the archive, you're supposed to take the .orig.tar.xz from the archive, and if not, you're supposed to generate it with git archive (or with the shortcut for that command: ./debian/rules gen-orig-xz). Either ways, you don't need to set pristine-tar to do that. So, as I wrote, the only single thing you need, is: ignore-branch = True and it is my view that it should be good to have it become the default. I also think this should become the default too: no-create-orig = True because otherwise, you easily get a generated wrong file, which will not be the same as the archive one (because pristine-tar is broken in many ways, as many of us know already). Besides this, nobody is forced to use gbp. Just typing "sbuild" to build a package is also perfectly valid. So why adding preferences for one set of tooling, when there's many alternatives? It doesn't make sense. Cheers, Thomas Goirand (zigo)
Bug#944608: ITP: octave-database -- interface to SQL databases in Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-database Version : 2.4.4 Upstream Author : Olaf Till * URL : https://octave.sourceforge.io/database/ * License : GPL-3+ Programming Lang: C++, Octave Description : interface to SQL databases in Octave The database package enables accessing SQL databases from Octave, a scientific computation software. Currently, however, this package only supports the PostgreSQL database. This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the DOG (Debian Octave Group) and is available in the Git repository at Salsa : https://salsa.debian.org/pkg-octave-team/octave-database -- Rafael Laboissière, on behalf of the DOG
Re: Usage of DEP5
Hello, On Sat 09 Nov 2019 at 03:07PM +01, gregor herrmann wrote: > Lately we as a project, guided by the DPL, have been in > recommendation mode anyway: "Use dh(1) unless you have a reason not > to", "Use git(1) and salsa unless …". > > I think "Write d/copyright in Copyright-Format 1.0 unless you have a > specific reason not to do this for a specific package" would be a > good continuation of this streak. I too find this a bit strong -- given what I've said about about optimising for writing these files, I don't think we should be expecting people to come up with a package-specific reason if they find themselves wanting to use the old format. I'd like to suggest this recommendation could be of the same strength as the "use salsa" recommendation, i.e., weaker than the dh recommendation, and directed at people with no reasons to prefer either who are wondering which to use. -- Sean Whitton signature.asc Description: PGP signature
Re: Usage of DEP5
On Tue, 12 Nov 2019 15:08:56 -0700, Sean Whitton wrote: > On Sat 09 Nov 2019 at 03:07PM +01, gregor herrmann wrote: > > Lately we as a project, guided by the DPL, have been in > > recommendation mode anyway: "Use dh(1) unless you have a reason not > > to", "Use git(1) and salsa unless …". > > I think "Write d/copyright in Copyright-Format 1.0 unless you have a > > specific reason not to do this for a specific package" would be a > > good continuation of this streak. > I too find this a bit strong -- given what I've said about about > optimising for writing these files, I don't think we should be expecting > people to come up with a package-specific reason if they find themselves > wanting to use the old format. Fair enough (and I'm not wed to the throw-away wording in any way.) > I'd like to suggest this recommendation could be of the same strength as > the "use salsa" recommendation, i.e., weaker than the dh recommendation, > and directed at people with no reasons to prefer either who are > wondering which to use. I was not aware of a difference in strength between the two recommendation [0] but yes, the "people with no reason to prefer either" was the direction I was heading at. Cheers, gregor [0] I'm probably not in the target group as I'm doing it anyway -- .''`. 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: Black and White signature.asc Description: Digital Signature
Bug#944629: RFP: libcatalyst-plugin-session-store-redis-perl -- Redis Session store for Catalyst
Package: wnpp Severity: wishlist Tags: patch * Package name: libcatalyst-plugin-session-store-redis-perl Version : 0.09 Upstream Author : Thomas Klausner * URL : https://metacpan.org/release/Catalyst-Plugin-Session-Store-Redis * License : Artistic or GPL-1+ Programming Lang: Perl Description : Redis Session store for Catalyst Catalyst::Plugin::Session::Store::Redis is a session storage plugin for Catalyst that uses the Redis (https://redis.io/) key-value database. This package is useful when wanting to interact via Perl using the Catalyst framework with a Redis instance. Attached a working and tested packaging, where only the ITP bug number needs to be filled in the debian/changelog, Maintainer changed, and Vcs fields added if appropriate. Thanks, Guillem libcatalyst-plugin-session-store-redis-perl_0.09-1.debian.tar.xz Description: application/xz
