Re: how to override piuparts for package transition to testing

[Jonas Smedegaard]

Quoting Rebecca N. Palmer (2020-09-06 18:08:16)
> Ask the release team ("unblock" bug against release.debian.org, or 
> debian-release@l.d.o): they can override the automated checks.

Thanks.

(in the meantime the package magically entered testing, but still 
helpful for eventual future cases)


 - 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: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS

[Christian Kastner]

On 2020-09-06 23:27, Mattia Rizzolo wrote:
> On Sun, Sep 06, 2020 at 10:53:05PM +0200, Christian Kastner wrote:
> The thing is, according to the build profile spec, if you specify nodoc
> or nocheck in _PROFILES you *MUST* also specify it on _OPTIONS (talking
> about when you do the build), so…

That's why I find this part odd:

>> Looking at random packages, newer packages seem to favor just checking
>> DEB_BUILD_PROFILES

Given what was said above for the major use cases nodoc and nocheck,
_OPTIONS > _PROFILES, so I wonder why _PROFILES is favored.

>From Niels' response, I guess one can conclude why this isn't an issue
for the nodoc case.

> You should read the manpages for more details.

I did, and while _OPTIONS and_PROFILES are both explained, the
relationship between them (if any) is not.

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

(Resending without the attachment for posterity sinte the message didn't
make it to -devel, but I also had no bounce notifying me that it was
discarded...)

Hello,

On Sun, 30 Aug 2020, Richard Laager wrote:
> You could use debian/experimental all the time and then merge down to
> debian/unstable only when you're ready to upload and have chosen
> unstable. But I suspect your objection would be: that's unnecessary
> busywork. And I see that point. I would probably make the same
> objection, which means I think I agree with the debian/latest concept in
> your situation.

You perfectly understood my reasoning. Thank you for making that effort.

> I'm not sure if most package maintainers are doing this or not. I've
> always assumed that most people are targetting only unstable most of the
> time and that use of experimental is relatively rare. I could easily be
> wrong on that.

I don't think that you are wrong. Most packages definitely only target
unstable and never use experimental. 

But most packages also never need to maintain two development branches
in parallel. Only very big packages, linux or django for example, will
maintain different upstream versions in two parralel branches.

Another thing that's quite certain is that you never know what the future
will bring you. And while you never had to use experimental, you might
have to at some point.

In that sense, I find debian/latest more future-proof but I also
agree that for the few cases where we would have to use experimental,
it's not a big deal to have to create debian/experimental.

Another thing to take into account is that DEP-14 has been drafted
as a vendor-neutral recommendation. I use it in the context of Kali
and there's no "unstable" release in Kali. We have "kali-dev". Ubuntu
only has codenames even for their development release.

Thus /latest is a better default for tools like git-buildpackage
and it makes sense for DEP-14 to endorse such a default branch as the
recommended name.

> That is, I'm generally always targetting unstable and _not_ regularly
> using multiple releases, so the DEP-14 language "prohibits" me from
> using debian/unstable. This is what feels backwards to me. If I'm always
> targetting unstable, debian/latest (and previously debian/master) is
> less clear than debian/unstable.
> 
> At a minimum, can we rework this in some way so the language does not
> require me to be regularly using multiple releases to use
> debian/unstable as a branch name?

That seems entirely reasonable, yes. Can you try to make a proposal ?

I attach the current markdown file with my not-yet pushed change that I
submitted for review here.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

On Fri, 04 Sep 2020, The Wanderer wrote:
> As long as this is being patched anyway, how about fixing the "others
> vendors" duplicate pluralization? I'd suggest either "but all other
> vendors should do so" or "as all others should do", but other variations
> are possible and I don't have a strong preference.

Fixed locally.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

On Sat, 05 Sep 2020, Richard Laager wrote:
> > OK to use debian/unstable as default branch even if you are not a
> > complex package that require multiple branches, provided that you will
> > not use debian/unstable when you decide to push something to
> > experimental.
> 
> I do not see why we have to prohibit occasional uploads to experimental
> from debian/unstable. If this is permitted, then that also avoids the
> busywork of creating debian/experimental in that scenario.

To me it feels awkward to allow this. You can't really get it both ways
IMO. If you decide to use codename-based branches, then you should use
debian/experimental for an experimental upload.

What do other people think?

> > I don't think that you are wrong. Most packages definitely only target
> > unstable and never use experimental. 
> 
> Then why give up the simplicity of only one choice and the clarity (and
> tooling advantages) of debian/unstable as the typical case, in favor of
> debian/latest?

It's not clear to me that debian/latest has major disadvantages over
debian/unstable. It's a single choice too.

The "clarity" of debian/unstable is limited to Debian developers, upstream
developers might not know that unstable is the development branch. Random
outsiders neither.

And using codename by default for the development branch means that you
don't have uniformitiy across multiple vendors, which I find desirable
for the purpose of letting git packaging helper tools having a sane
cross-vendor default.

> > Another thing to take into account is that DEP-14 has been drafted
> > as a vendor-neutral recommendation. I use it in the context of Kali
> > and there's no "unstable" release in Kali. We have "kali-dev". Ubuntu
> > only has codenames even for their development release.
> 
> What's wrong with kali/kali-dev?

We have kali twice in the name. We used to have "kali/stable" and
"kali/dev" at some point and we switched to "kali/master" when we
switched to a rolling-release model to standardize on DEP-14.

But what I meant is that "unstable" is only applicable to Debian and
that derivatives have different models and that we should not impose
too much to make sure we cater to the needs of derivatives too.

> I'd love to hear someone from Ubuntu weigh in on why ubuntu/latest would
> be better there. From my point of view (as someone who occasionally SRUs
> something in Ubuntu), having ubuntu/ is the right choice. When
> a new development release opens up, you would branch e.g. ubuntu/focal
> into ubuntu/groovy. Then ubuntu/focal continues to exist for SRUs
> (stable release updates). To me, my proposed branching model feels like
> it matches the Ubuntu development model 1:1.

Sure, if you put yourself in the feet of someone doing stable release
uploads, it's convenient to have a branch ready to use. But if you put
yourself in the shoes of someone doing Debian syncs, then maybe
ubuntu/latest would save you some hurdle.

In any case, Ubuntu has no "suite" name and it's to be expected that they
would use only "codename" even for their development releases. That
doesn't mean that it's the right choice for everybody nor that it should
be the default.

> DEP-14 starts this section with a broad, "In general, packaging branches
> should be named according to the codename of the target distribution."
> On that, I think we all agree. Then it continues, "We differentiate
> however the case of development releases from other releases."
> Fundamentally, the scope of that exception is what we are discussing.

Yes. (Though I would have hoped that it would not require so much
discussion at this point :-))

> Diffs available here (since this list refuses attachments and I can't
> figure out how to disable line wrapping in Thunderbird):
> https://paste.debian.net/1162793/

Bah 503 service unavailable right now.

> My personal view is now: B > A > D > C

Without having read your precise diff, I would believe my personal view
would be: C > D > B > A

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS

[Mattia Rizzolo]

On Mon, Sep 07, 2020 at 08:03:20AM +0200, Niels Thykier wrote:
> Mattia Rizzolo:
> >> Or do dpkg or debhelper apply some kind of mapping logic from _OPTIONS
> >> to _PROFILES for the popular options nocheck, nodoc, noopt?
> > 
> > debhelper does.  various helpers do things differently with such
> > options.  You should read the manpages for more details.
> > 
> 
> It does not in the general case.  It does for nodoc because
> $HISTORICAL_REASONS.

Oh, sorry.  I misunderstood the question, I read is as "does debhelper
apply some logic for _OPTIONS or _PROFILES", nothing relating to mapping
from one to the other.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Mass bugs filing: autopkgtest should be marked superficial

[Antonio Terceiro]

On Sun, Sep 06, 2020 at 12:31:22AM +0100, Sudip Mukherjee wrote:
> Hi Paul,
> 
> On Sat, Sep 5, 2020 at 1:56 AM Paul Wise  wrote:
> >
> > On Fri, Sep 4, 2020 at 6:53 PM Sudip Mukherjee wrote:
> >
> > > If the test done in the autopkgtest does not provide significant test
> > > coverage then it should be marked with "Restrictions: superficial".
> > ...
> > > I am still trying to figure out a generalized method to find them but
> > > an initial script has found 83 packages. Attached is the dd-list.
> >
> > This sort of thing seems like something that will be an ongoing
> > problem so a more efficient way to solve it would be a lintian
> > warning, which should hopefully help prevent new occurrences. OTOH it
> > would be pretty hard to automatically check for these without a robust
> > shell parser. Perhaps morbig from Project CoLiS could be used for the
> > shell parsing and then a script could process the morbig output.
> > ShellCheck might be another option but it doesn't yet output parse
> > trees.
> 
> We were hoping that this check can be added in lintian, but looking at
> #932862 it seems you have already requested that. :)
> I will have a look at morbig and see if I can use that in my script.
> Thanks for the idea.

FWIW I don't think that opening bugs about the packages we already know
are using silly tests without "Restrictions: superficial" needs to wait
for that.

Thanks for your work on this.


signature.asc
Description: PGP signature

Bug#969743: ITP: svim: Structural variant caller for long sequencing reads

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: svim
  Version : 1.4.1+ds-1
  Upstream Author : David Heller
* URL : https://github.com/eldariont/svim/

* License : GPL-3+
  Programming Lang: Python
  Description : Structural variant caller for long sequencing reads
 SVIM is a structural variant caller for long sequencing reads.
 It is able to detect, classify and genotype five different
 classes of structural variants. Unlike existing methods, SVIM
 integrates information from across the genome to precisely
 distinguish similar events, such as tandem and interspersed
 duplications and simple insertions.

I shall maintain this package.

Bug#969745: ITP: libaperture -- Camera library for GTK3

[Henry-Nicolas Tourneur]

Package: wnpp
Severity: wishlist
Owner: Henry-Nicolas Tourneur 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: libaperture
  Version : 0
  Upstream Author : James Westman 
* URL : https://gitlab.gnome.org/jwestman/libaperture
* License : LGPL3+
  Programming Lang: C
  Description : Camera library for GTK3

Library which allows one to take photos or videos through Gstreamer.
GStreamer is used to control camera devices. 
It ships vala bindings as well as GObject Introspection bindings.
It is a dependency for the (future) gnome-camera package.

This package will be maintained with the Debian On Mobile team.

Bug#969746: ITP: gnome-camera -- Take photos and videos on your computer or smartphone

[Henry-Nicolas Tourneur]

Package: wnpp
Severity: wishlist
Owner: Henry-Nicolas Tourneur 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: gnome-camera
  Version : 0
  Upstream Author : James Westman 
* URL : https://gitlab.gnome.org/jwestman/camera
* License : GPL3+
  Programming Lang: Vala
  Description : Take photos and videos on your computer or smartphone

Simple camera app designed for Phosh or GNOME.
It is designed to work well on mobile Linux devices (such as the PinePhone or 
Librem 5)
but it will run on any Linux computer with a connected camera.

This package will be maintained with the Debian On Mobile team.

Bug#969763: ITP: proftpd-mod-statsd -- ProFTPD module mod_statsd

[Hilmar Preusse]

Package: wnpp
Severity: wishlist
Owner: Hilmar Preusse 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: proftpd-mod-statsd
  Version : 0.1
  Upstream Author : TJ Saunders
* URL : https://github.com/Castaglia/proftpd-mod_statsd/
* License : GPL2+
  Programming Lang: C
  Description : ProFTPD module mod_statsd

The mod_statsd module for ProFTPD emits metrics to a configured statsd
server, for obtaining/graphing data rather than having to parse log
files.

Sounds useful to me for stats of large ftp sites.

I plan to maintain it in the "Debian ProFTPD Team".

Bug#969764: ITP: proftpd-mod-geoip2 -- ProFTPD module mod_geoip2

[Hilmar Preusse]

Package: wnpp
Severity: wishlist
Owner: Hilmar Preusse 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: proftpd-mod-geoip2
  Version : 0.1
  Upstream Author : TJ Saunders
* URL : https://github.com/Castaglia/proftpd-mod_geoip2
* License : GPL2+
  Programming Lang: C
  Description : ProFTPD module mod_geoip2

The mod_geoip2 module for ProFTPD uses the MaxMind GeoIP library to look
up geographic information on connecting clients, and to provide ACLs based
on that geographic information.

I plan to maintain it in the "Debian ProFTPD Team".


signature.asc
Description: PGP signature

Bug#969766: ITP: python-multipledispatch -- multiple dispatch in Python

[Christian Kastner]

Package: wnpp
Severity: wishlist
Owner: Christian Kastner 

* Package name: python-multipledispatch
  Version : 0.6.0
  Upstream Author : Matthew Rocklin
* URL : https://github.com/mrocklin/multipledispatch/
* License : BSD-3-clause
  Programming Lang: Python
  Description : multiple dispatch in Python

This implementation of multiple dispatch is efficient, mostly complete,
performs static analysis to avoid conflicts, and provides optional namespace
support. It looks good too.

What this does:
 * Dispatches on all non-keyword arguments
 * Supports inheritance
 * Supports instance methods
 * Supports union types, e.g. (int, float)
 * Supports builtin abstract classes, e.g. Iterator, Number, ...
 * Caches for fast repeated lookup
 * Identifies possible ambiguities at function definition time
 * Provides hints to resolve ambiguities when they occur
 * Supports namespaces with optional keyword arguments
 * Supports variadic dispatch

What this doesn't do:
 * Diagonal dispatch
 * Efficient update: The addition of a new signature requires a full resolve
   of the whole function. This becomes troublesome after you get to a few
   hundred type signatures.

This will be maintained within the Debian Python Team.

Bug#969781: RFP: libtoml-tiny-perl -- minimal, pure perl TOML parser and serializer

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: libtoml-tiny-perl
  Version : 0.09
  Upstream Author : Jeff Ober 
* URL : https://metacpan.org/release/TOML-Tiny
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : minimal, pure perl TOML parser and serializer

 TOML::Tiny implements a pure-perl parser and generator for the
 TOML (https://github.com/toml-lang/toml) data format. It currently conforms
 to TOML v5 (with a few caveats) with support for more recent changes in
 pursuit of v6.
 .
 TOML::Tiny strives to maintain an interface compatible to the TOML and
 TOML::Parser modules, and could even be used to override $TOML::Parser.


This package contains both an encoder and decoder that can handle new
TOML formats, in contrast with the existing TOML and TOML::Parser in
the archive that cannot handle encoding decoded data for new formats.

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. I've also included a patch to make
the heavy dependency on DateTime::Format::RFC3339 a Suggests, as that
ended up pulling tons of packages and is only needed when passing data
with such objects (which I've sent upstream as
).

Thanks,
Guillem


libtoml-tiny-perl_0.09-1.debian.tar.xz
Description: application/xz

Bug#969783: ITP: kylin-scanner -- Scanning utility based on SANE

[handsome_feng]

Package: wnpp
Severity: wishlist
Owner: handsome_feng 
X-Debbugs-Cc: debian-devel@lists.debian.org, jianfen...@ubuntukylin.com

* Package name: kylin-scanner
  Version : 1.0.0
  Upstream Author : yushuoqi 
* URL : http://www.github.com/ubuntukylin/kylin-scanner
* License : GPL-3+
  Programming Lang: C++
  Description : Scanning utility based on SANE

 Kylin-scanner can scan according to the resolution, size and color
 mode of the scanning device.
 And it provides post-processing features for scanned images, such as
 clipping, rotation, one-click beautification, intelligent correction
 and text recognition, etc.

 It will been maintained by the Kylin team.

 Thanks,
 handsome_feng

Bug#969785: ITP: fenics-performance-tests -- solvers for testing the parallel performance of DOLFIN

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org, 
lu...@debian.org

* Package name: fenics-performance-tests
  Version : git20190115.e866927
  Upstream Author : Chris N. Richardson 
* URL : https://bitbucket.org/fenics-project/performance-tests/
* License : MIT
  Programming Lang: C++
  Description : solvers for testing the parallel performance of DOLFIN

This package contains solvers for testing the parallel performance of
DOLFIN and the underlying linear solvers. It tests elliptic equations
- Poisson equation and elasticity - in three dimensions.

The intention of this package is help demonstrate and monitor the HPC
performance of Debian's FEniCS/DOLFIN packages. HPC compute time has
been graciously offered for HPC package testing by France's Grid5000
consortium, grid5000.fr.

To be maintained alongside fenics under the Debian Science Team.

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Richard Laager]

On 9/7/20 5:33 AM, Raphael Hertzog wrote:
> On Sat, 05 Sep 2020, Richard Laager wrote:
>> I do not see why we have to prohibit occasional uploads to experimental
>> from debian/unstable. If this is permitted, then that also avoids the
>> busywork of creating debian/experimental in that scenario.
> 
> To me it feels awkward to allow this. You can't really get it both ways
> IMO. If you decide to use codename-based branches, then you should use
> debian/experimental for an experimental upload.

That view is: A > B.

FWIW, my justification for B > CD is:

Since the parallel branch scenario is already debian/unstable &
debian/experimental, then I'll take a small inconsistency for the
occasional upload to experimental to be able to use a strict subset of
those choices (debian/unstable) as the normal scenario, rather than a
whole new thing (debian/{master,latest}).

> The "clarity" of debian/unstable is limited to Debian developers, upstream
> developers might not know that unstable is the development branch. Random
> outsiders neither.

Whatever it is called, the main development branch will normally be the
HEAD, so an unqualified `git clone` will give that branch. (Exceptions
include when the repository is mixed upstream and packaging.) That
probably covers the upstreams and random outsiders.

> But what I meant is that "unstable" is only applicable to Debian and
> that derivatives have different models and that we should not impose
> too much to make sure we cater to the needs of derivatives too.

I think you were following, but to be clear, the proposal isn't
/unstable, it's /. So
debian/unstable, ubuntu/groovy (changes as time moves on),
kali/kali-dev, etc.

I do acknowledge that /latest is undoubtedly easier for the
tooling to implement, and that is a serious advantage of C.

> Without having read your precise diff, I would believe my personal view
> would be: C > D > B > A
That is what I expected your view to be. You might be A > B rather than
B > A, though, as discussed above.

Anyway, I think I'm into dead horse territory here. Unless someone else
speaks up, I assume the next step is for you to pick an option, which I
assume will be C (in principle; not necessarily my wording).

Thanks for taking the time to hear me out and thanks for DEP-14!

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS

[Niels Thykier]

Christian Kastner:
> On 2020-09-06 23:27, Mattia Rizzolo wrote:
>> On Sun, Sep 06, 2020 at 10:53:05PM +0200, Christian Kastner wrote:
>> The thing is, according to the build profile spec, if you specify nodoc
>> or nocheck in _PROFILES you *MUST* also specify it on _OPTIONS (talking
>> about when you do the build), so…
> 
> That's why I find this part odd:
> 
>>> Looking at random packages, newer packages seem to favor just checking
>>> DEB_BUILD_PROFILES
> 
> Given what was said above for the major use cases nodoc and nocheck,
> _OPTIONS > _PROFILES, so I wonder why _PROFILES is favored.
> 
>>From Niels' response, I guess one can conclude why this isn't an issue
> for the nodoc case.
> 
>> You should read the manpages for more details.
> 
> I did, and while _OPTIONS and_PROFILES are both explained, the
> relationship between them (if any) is not.
> 

Fundamentally, the difference between the two are:

 * _PROFILES is a "new"[0] thing with a specific purpose to reduce
   build-dependencies (at least in this case).  It ends up in d/rules
   for skipping builds of specific packages (e.g. "nopython")

 * _OPTIONS is the thing that has been here since the "dawn of time" to
   enable the builder to tweak the build in a standardized way.

(Note that their definitions do not overlap)

Basically, we ended up in the situation like this with nocheck[1]:

 * We had _OPTIONS with nocheck for at least a decade and probably more.
   - I.e. _OPTIONS is what everyone wrote in their d/rules file to
 implement policy.

 * We invented _PROFILES and supported nocheck to assist cross-builders
   and bootstrappers, who generally want as few build-depends as
   possible even at the expense of running tests (cross-builders often
   cannot run them anyway).
   - I.e. _PROFILES is what the dependency resolvers look for when
 deciding which build-depends to install.

And that is how you end up with WET Debian packaging.

I hope that cleared the relationship between _OPTIONS and _PROFILES and
how we got here.


At this level, it might look deceptively easy to "fix" this problem
("Couldn't we just do X and then it will solve everything?").  However,
I have deliberately avoided to dive into "X" - among other because I am
not sure I can accurately represent the /current/ views of everyone.  If
you are interested in that, I would recommend some off-list research first.

~Niels