Re: uscan - inherit version number of component from main package (SVN)

[Hugh McMaster]

Hi Andreas,

On Sun, 8 Oct 2023 at 00:22, Andreas Metzler wrote:
> [snip]
> The obvious problem is the versioning, I would like to make uscan simply use
> the main version for the userguide but afaik I cannot refer to it in
> uversionmangle.
>
> I can do
> uversionmangle=s/^0\.0/20.00/
> to makes uscan always (well unless upstream hits 20.00) consider
> userguide outdate and save it as
> ../netpbm-free_${netpbm main version}.orig-userguide.tar.xz
> with directory name
> netpbm-free-20.00~svn${revision}
>
> Afaik dpkg-source will ignore the dirname anyway, so this part should not
> be a problem.
>
> Is there anything else I am missing, is there a better approach?

You're trying to over-complicate it. :-)

Try this in your d/watch file:



version=4

# netpbm-free
opts="mode=svn, pgpmode=none" \
  https://svn.code.sf.net/p/netpbm/code/release_number \
  (\d[\d.]+)/

# netpbm-free user guide
opts="mode=svn, pgpmode=none, \
  component=userguide" \
  https://svn.code.sf.net/p/netpbm/code/userguide \
  HEAD ignore



You want to match against HEAD to download the most recent version,
and specify the 'ignore' keyword to avoid restricting the secondary
tarball version.

You'll probably want to adjust the userguide tarball name (not the
symlink) with filenamemangle.

Hugh

Bug#1051150: RFS: blender-doc/3.6-1 [ITP] -- Blender Manual by the Blender Foundation

[Hugh McMaster]

Hi Jonathan,

Thanks for your work on this package. Just two more things to do.

On Tue, 3 Oct 2023 at 05:53, Jonathan Rubenstein wrote:
>
> Hey, I've implemented the requested changes, again with some
> questions/exceptions.
>
> > * Not all files in tools*/* are explicitly marked Apache-2.0, but
> > given most are, I think it's okay to assume that. In any case, the
> > attributable copyright is the same as for the main package.
>
> Not sure if this is asking for any particular action or just a comment
> on the situation.

That was just a comment.

1. Add a debian/README.source file and add a comment that says package
builders must install the package git-lfs before cloning upstream's
git repository.
2. Run `dch -r` to update the timestamp in d/changelog.

Once both of those items are done, please upload the final version to
Debian Mentors, and we should be good to go.

Hugh

Bug#1051150: RFS: blender-doc/3.6-1 [ITP] -- Blender Manual by the Blender Foundation

[Hugh McMaster]

Hi Jonathan,

On Wed, 27 Sept 2023 at 05:48, Jonathan Rubenstein wrote:
>
> Control: tags -1 - moreinfo
>
> Hey, I have completed the requested changes with a few exceptions.

Nice work. We're almost there.

d/copyright:
* Please update your explanatory comment to the following:

Comment: A cursory search will find many ":License: GPL" lines in these files.
 Those ":License: GPL" lines are part of a template describing other software
 that is GPL-licensed but not included in this package. The file containing
 the template (and the template itself) is licensed as CC-BY-SA-4.0.

* Email addresses are optional in Files stanzas. I don't include them
because I find they add clutter, but it's a personal choice.
* Not all files in tools*/* are explicitly marked Apache-2.0, but
given most are, I think it's okay to assume that. In any case, the
attributable copyright is the same as for the main package.

d/control:
* Remove versioned dependency from libjs-mathjax.

d/rules:
* In override_dh_auto_build, the `export` command should only appear
once, and only at the start of the line.

d/source/overrides:
* I see you added an override for
'very-long-line-length-in-source-file' in
'resources/templates/footer.html'. Lintian also emits the tag for a
lot of .webp graphics files, so let's take care of them all with one
global override. Please change your source overrides to the following:

# This may appear to be a binary file to lintian, but it's not
source-is-missing [resources/templates/footer.html]

# WebP graphics files; resources/templates/footer.html
very-long-line-length-in-source-file

Bug#1051150: RFS: blender-doc/3.6-1 [ITP] -- Blender Manual by the Blender Foundation

[Hugh McMaster]

Control: tags -1 moreinfo

Hi Jonathan,

On Sun, 3 Sep 2023 17:51:51 +0300 Jonathan Rubenstein wrote:
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "blender-doc":
>
>   * Package name : blender-doc
> Version  : 3.6-1
> Upstream contact : Blender Documentation Team 
>   * URL  : https://docs.blender.org/manual/
>   * License  : Apache-2.0, GPL-2.0-or-later, MIT, CC-BY-SA-4.0
>   * Vcs  : https://salsa.debian.org/JJRcop/blender-doc
> Section  : doc

For your first package, this is great. Now, let's make it even better. :)

d/copyright:
* Please restructure this file so your licence stanzas are at the
bottom. The order of stanzas is header, files, licences.
* Please start filenames/paths and copyright information directly
after the field name, so:
Files: XXX
Copyright: XX. Multiple lines can be aligned with spaces.
* You are missing several files that are GPL-licensed. I saw them in
the Add-ons section. Please check every file in the source package
carefully.
* You need to add a copyright stanza for debian/*, attributed to you.
GPL-2.0-or-later is often a good choice here, but it's your decision.

d/control:
* You don't need to specify versions for your (build-)dependencies, as
we're targeting sid/unstable. The exception is debhelper-compat, which
does need to be versioned (= 13).
* In the short and (long) binary package description, please indicate
the manual is in HTML format.

d/rules:
* Please combine your dh_auto_build overrides and exports into a single recipe:

override_dh_auto_build:
export http_proxy=127.0.0.1:9 https_proxy=127.0.0.1:9 PYTHONPATH=.
dh_auto_build -- html

* To disable the dh_auto_tests, add `export DEB_BUILD_OPTIONS +=
nocheck` to the top of d/rules and remove the override.
* Please add a line break between each target.

d/upstream/metadata
* Please add the Bug-Database, Bug-Submit and Changelog fields as
flagged by Lintian.

d/source/overrides
* While the line in footer.html is very long, it is not a binary. It's
actually a hyperlink that creates a new bug report upstream.
Please also override the very-long-line-length-in-source-file tag
(refer to your blender-doc mentors page to see what I mean).

d/blender-doc.doc-base:
* Is there a reason you've limited the line length to ~40 characters?
You can go up to 79, although you probably want less so the lines look
more balanced.

d/blender-doc.install:
* Install paths don't need a forward slash (/usr -> usr). You can also
simplify the line to:
build/html usr/share/doc/blender-doc

* Please run Lintian using `lintian -EviI *amd64.changes` and review the output.
  + Lintian identified some images files that have a .jpg extension
but according to `file` are actually PNG files. You might want to
raise this discrepancy with upstream.
  + Lintian also identified file-references-package-build-path when
blender-doc is built via sbuild. This could be another upstream bug.



Once you've addressed all of the points above, please remove the
'moreinfo' tag and I'll have another look. It might take me a few days
to get back to you once you've done that.

Hugh

Bug#1031981: RFS: fonts-material-design-icons-iconfont/6.7.0+dfsg-1 -- Material Design Icons DX

[Hugh McMaster]

Hi Pierre,

On Mon, 27 Feb 2023 at 05:54, Pierre Gruet wrote:
>
> Hi again,
>
> Le 26/02/2023 à 12:20, Pierre Gruet a écrit :
> > Hell Hugh,
> >
> > Uploaded, thanks for your work on this package!

Thank you for the upload!

> > I have two minor suggestions for the next upload:
> > - dversionmangle=s/@DEB_EXT@// can be slightly simplified into
> > dversionmangle=auto, which is totally equivalent (but one does not have
> > to!);
> > - You could/should add a comment on the first line of
> > debian/source/lintian-overrides, to explain that you checked the files
> > that raised the Lintian warning and that the long lines are innocuous.
> > This would ease the handling of the package by others in the future.

Thanks for the suggestions. I'll make these updates shortly.

> > Best,
> >
>
> Also I noticed these is a mismatch between the version I uploaded (from
> mentors.d.o) and the state of the Salsa repo. This may be your wish as
> you were asking for sponsorship; anyway, can I please let you make sure
> the Salsa repo catches up with the uploaded version? You can also tag
> the tip of the branch.

Done! I forgot to push the changelog commit to Salsa. :/

Bug#1031981: RFS: fonts-material-design-icons-iconfont/6.7.0+dfsg-1 -- Material Design Icons DX

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package
"fonts-material-design-icons-iconfont":

 * Package name : fonts-material-design-icons-iconfont
   Version  : 6.7.0+dfsg-1
   Upstream contact : https://github.com/jossef/material-design-icons-iconfont
 * URL  : https://github.com/jossef/material-design-icons-iconfont
 * License  : Apache-2.0
 * Vcs  :
https://salsa.debian.org/hmc/fonts-material-design-icons-iconfont
   Section  : fonts

The source builds the following binary packages:

  fonts-material-design-icons-iconfont - Material Design Icons DX

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/fonts-material-design-icons-iconfont/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-material-design-icons-iconfont/fonts-material-design-icons-iconfont_6.7.0+dfsg-1.dsc

Changes since the last upload:

 fonts-material-design-icons-iconfont (6.7.0+dfsg-1) unstable; urgency=medium
 .
   * New upstream version.
   * debian/copyright: Update for 2023.
   * debian/control:
 + Update Standards-Version to 4.6.2 (no changes needed).
 + Update short description.
   * debian/source/lintian-overrides: Update tags and syntax.

Regards,

-- 
  Hugh McMaster

Bug#1020951: RFS: raptor2/2.0.15-3 [QA] -- Raptor 2 RDF syntax library

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "raptor2":

 * Package name : raptor2
   Version  : 2.0.15-3
   Upstream contact : Dave Beckett 
 * URL  : https://librdf.org/raptor/
 * License  : GPL-3+, LGPL-2.1+ or GPL-2+ or Apache-2.0,
LGPL-2.1+, public-domain
 * Vcs  : [fill in URL of packaging vcs]
   Section  : devel

The source builds the following binary packages:

  libraptor2-dev - Raptor 2 RDF syntax library development libraries and headers
  libraptor2-0 - Raptor 2 RDF syntax library
  raptor2-utils - Raptor 2 RDF parser and serializer utilities
  libraptor2-doc - Documentation for the Raptor 2 RDF syntax library

raptor2 does not have a repository on Salsa yet. As this is a QA Team
upload, can someone please create an empty repository in the Debian
namespace and grant me (hmc) privileges, so I can build it out?

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/raptor2/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/r/raptor2/raptor2_2.0.15-3.dsc

Changes since the last upload:

 raptor2 (2.0.15-3) unstable; urgency=medium
 .
   * QA upload.
   * debian/changelog: Fix some typos.
   * debian/control:
 + libraptor2-dev: Drop Depends on pkg-config.
 + raptor2-utils: Drop Conflicts/Replaces (no longer needed).
 + libraptor2-doc:
   - Mark package Multi-Arch: foreign.
   - Remove documentation path from package description.
   * debian/patches:
 + Fix FTBFS when libxml2 is detected via pkg-config (Closes: #949490).
 + Fix a typo in an existing patch name.
   * debian/rules:
 + Don't install upstream's README file in all binary packages.
   The README file is now only installed in libraptor2-doc.
 + Drop dh_installchangelogs override.
 + Drop dh_strip override; dbgsym-migration is complete.
   * Drop "debian/tmp" from installation paths.
   * libraptor2-0: Add symbols file.
   * libraptor2-doc: Replace .install file with .docs.
   * lintian-overrides: Add overrides for very-long-line-length-in-source-file
 and source-is-missing messages.
   * Add debian/upstream/metadata file.

Regards,
-- 
  Hugh McMaster

Bug#1016864: RFS: librcc/0.2.13+ds-1 [QA] -- RusXMMS Charset Conversion library

[Hugh McMaster]

Hi Tobi,

On Sat, 27 Aug 2022 at 20:45, Tobias Frost wrote:

> On Wed, 24 Aug 2022 22:30:26 +1000 Hugh McMaster wrote:
> + Update Vcs-* fields and point to GitHub.
> > >
> > > VCS* is for the packaging, not for upstream. The link on Github seems
> not to
> > > have the (latesdt) packaging
> >
> > Good point. I've dropped the Vcs-* fields, since there is no Salsa
> > packaging repository at the moment.
> >
> > I checked the GitHub repository and it has the latest version 0.2.13.
> > Older versions are available from a different (non-GitHub) repository.
>
> Fixed: I've created a repo for you on salsa, populated it from debsnap and
> granted
> rights to you. Let me know if it does not work as expected…


Thanks for creating the librcc repo on Salsa [1].

I’ve pushed librcc 0.2.13+ds-1 to the repo.

A revised package (with updated Vcs fields) is on Mentors.

Hugh

[1] https://salsa.debian.org/debian/librcc

>

Bug#1016864: RFS: librcc/0.2.12-1 [QA] -- RusXMMS Charset Conversion library

[Hugh McMaster]

Dear mentors,

I am looking for a sponsor for my package "librcc".

Upstream has just released a new version of librcc, fixing some libxml
bugs and incorporating patches sent upstream from Debian.

I've also dropped the GTK package. Thanks to Chris Hofstaedler and
Bastian Germann for suggesting this.

The upload needs to go to NEW, due to the added librccui0 and
librcc-doc binary packages.

 * Package name: librcc
   Version : 0.2.13+ds-1
   Upstream Author : Suren A. Chilingaryan 
 * URL : http://rusxmms.sourceforge.net/
 * License : public-domain, ISC, FSFAP, LGPL-2.1+
 * Vcs : https://github.com/RusXMMS/librcc
   Section : libs

The source builds the following binary packages:

  librcc0 - RusXMMS Charset Conversion library
  librcc-dev - RusXMMS Charset Conversion library (development files)
  librcc-doc - RusXMMS Charset Conversion library (documentation)
  librccui0 - RusXMMS Charset Conversion library (user interface)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/librcc/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libr/librcc/librcc_0.2.13+ds-1.dsc

Changes since the last upload:

 librcc (0.2.13+ds-1) unstable; urgency=medium
 .
   * QA upload.
   * New upstream version (Closes: #829889, #949409).
   * Set Maintainer to Debian QA Group (see #875348).
   * Drop librcc GTK+ packaging due to minimal use.
   * debian/changelog: Trim trailing whitespace.
   * debian/control:
 + Priority: extra -> optional.
 + Switch to debhelper-compat v13 and drop debian/compat file.
 + Declare Rules-Requires-Root: no.
 + Update Vcs-* fields and point to GitHub.
 + Raise Standards-Version to 4.6.1 from 3.9.5 (no changes needed).
 + Drop build dependency on libgtk2.0-dev (Closes: #967587).
 + Remove librccgtk2-0 binary package.
 + Add separate librccui0 binary package.
 + Split documentation and examples into a new package: librcc-doc.
 + Add Multi-Arch fields to all binary packages.
 + Update package descriptions.
 + Remove duplicated Section fields.
 + Trim trailing whitespace.
   * debian/copyright: Convert to DEP-5 format and update.
   * debian/rules:
 + Let dh_auto_configure pass --host to ./configure (Closes: #864625).
 + Let dh_auto_clean remove build-time files.
 + Install the development documentation in librcc-dev but package the
   files in librcc-doc (as preferred by Debian Policy section 12.3).
 + Add hardening flags to DEB_BUILD_MAINT_OPTIONS.
 + Manually strip the western_engine.a static library.
   * debian/watch: Update to version 4 and point to new upstream repository.
   * Use multi-arch installation paths in all binary packages.
   * Add symbols files.
   * librcc-dev:
 + Install librcc's pkg-config file.
 + Don't install the *.la files.
 + Move the development documentation and examples into librcc-doc.

Regards,
-- 
  Hugh McMaster

Bug#1009619: RFS: nd/0.8.2-8.1 [NMU] -- small command line interface to WebDAV servers

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "nd":

 * Package name: nd
   Version : 0.8.2-8.1
   Upstream Author : Yuuichi Teranishi 
 * URL : http://gohome.org/nd/
 * License : MPL-1.1 or GPL-2.0 or LGPL-2.1, other
 * Vcs :
https://anonscm.debian.org/viewvc/collab-maint/deb-maint/nd/trunk/
   Section : net

The source builds the following binary packages:

  nd - small command line interface to WebDAV servers

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/nd/

Alternatively, you can download the package with 'dget' using this command:

  dget -x https://mentors.debian.net/debian/pool/main/n/nd/nd_0.8.2-8.1.dsc

Changes since the last upload:

 nd (0.8.2-8.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * debian/control:
 - Build-Depend on pkg-config.
 - Use debhelper-compat v13 to enable dh_autoreconf.
   * Use pkg-config to detect libxml2 (Closes: #949416).
   * debian/patches:
 - Drop 65_autotools_update.diff (use dh_autoreconf instead).

Regards,
-- 
  Hugh McMaster

Bug#1009365: RFS: rarcrack/0.2-1.1 [NMU] -- Password cracker for rar archives

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "rarcrack":

 * Package name: rarcrack
   Version : 0.2-1.1
   Upstream Author : N/A
 * URL : http://rarcrack.sourceforge.net/
 * License : GPL-2+
 * Vcs : N/A
   Section : utils

The source builds the following binary packages:

  rarcrack - Password cracker for rar archives

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/rarcrack/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rarcrack/rarcrack_0.2-1.1.dsc

Changes since the last upload:

 rarcrack (0.2-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Build-Depend on pkg-config.
   * Use pkg-config to find libxml2 (Closes: #949491).
   * Do not strip during 'make install' (Closes: #901217).
 Thanks to Helmut Grohne for the patch.

Regards,
-- 
  Hugh McMaster

Bug#998103: RFS: loudgain/0.6.8+ds-2 [RC] -- ReplayGain 2.0 loudness normalizer

[Hugh McMaster]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "loudgain":

 * Package name: loudgain
   Version : 0.6.8+ds-2
   Upstream Author : Matthias C. Hormann 
 * URL : https://github.com/Moonbase59/loudgain
 * License : BSD-2-Clause
 * Vcs : https://salsa.debian.org/hmc-guest/loudgain
   Section : sound

The source builds the following binary packages:

  loudgain - ReplayGain 2.0 loudness normalizer based on the EBU R128 standard

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/loudgain/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/l/loudgain/loudgain_0.6.8+ds-2.dsc

Changes since the last upload:

 loudgain (0.6.8+ds-2) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Remove version constraints on build-dependencies unnecessary since Buster.
 .
   [ Hugh McMaster ]
   * debian/gbp.conf: Use DEP-14 branch naming.
   * debian/control:
 - Build-Depend on zlib1g-dev | libz-dev (Closes: #997233).
 - Raise Standards-Version to 4.6.0 from 4.5.0 (no changes needed).
   * debian/source/lintian-overrides: Silence a line-length warning in
the upstream README.md file.

Regards,

-- 
  Hugh McMaster

Bug#971067: RFS: libexif-gtk/0.5.0-1

[Hugh McMaster]

Hallo Andreas,

On Sun, 18 Oct 2020 at 23:18, Andreas Metzler wrote:

>
> afaict the build against GTK2 and GTK3 produes identical header files,
> only the library differ. So a combined dev package is possible.
>
> Draft atached.


Sorry for the long delay. Real life got in the way.

I’ve adapted your patch and made some other changes.

The latest version is on d-mentors or salsa.

Please review it when you have time.

Thanks,

Hugh

>

Bug#971067: RFS: libexif-gtk/0.5.0-1

[Hugh McMaster]

Hi Andreas,

mlt was taken care of.

I spoke with the Debian QA Team and they were reluctant to remove gtkam
because of popcon numbers.

Myon said I should file a Serious bug against the package (#972085).

Options for libexif-gtk seem to be reverting to GTK2 only, or building GTK2
and GTK3 packages. I’m not entirely sure how that would work for the -dev
package, although I could create a new -dev package for GTK3, I suppose.

What do you think?

Hugh

Documenting automatically generated files in debian/copyright

[Hugh McMaster]

I’m doing a copyright check on a source package and it contains a number of
automatically generated Makefile.in files.

These files are most likely the result of upstream not fully cleaning their
source tree before compressing into a tarball.

Each Makefile.in file includes a Free Software Foundation copyright line
and their licence (FSFULLR).

As these files are transient and automatically generated by automake, do
they need to be documented in debian/copyright?

The same could be asked of the configure script and other files.

I’ve been documenting these files to be safe, since they are shipped with
the source tarball, but I’d like to know if this detail is required.

I couldn’t find anything in Policy on this.

Thank you,

Hugh

Re: gbp export-orig for multiple source tarballs

[Hugh McMaster]

On Sun, 29 Mar 2020 at 12:07, Eriberto Mota wrote:
>
> Thanks a lot Mattia. I will use 'pristine-tar list' and 'pristine-tar
> checkout'[1].

You should also be able to use `gbp export-orig --pristine-tar
--component=foo --component=bar'.

Re: RFS: idzebra/2.1.4-1

[Hugh McMaster]

Dear Mentors,

On Mon, 30 Sep 2019 at 9:52 pm, Hugh McMaster wrote:

> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for the package "idzebra".
>
>  * Package name: idzebra
>Version : 2.1.4-1
>Upstream Author : Adam Dickmeiss 
>  * URL : http://www.indexdata.com/zebra
>  * License : GPL-2+
>  * Vcs : https://salsa.debian.org/debian/idzebra
>Section : text
>
> It builds the following binary packages:
>
>   idzebra-2.0 - IDZebra metapackage (the works)
>   libidzebra-2.0-modules - IDZebra modules
>   idzebra-2.0-common - IDZebra common files
>   idzebra-2.0-examples - IDZebra example configurations
>   idzebra-2.0-utils - IDZebra utility programs
>   libidzebra-2.0-dev - IDZebra development
>   libidzebra-2.0-0 - IDZebra libraries
>   libidzebra-2.0-mod-alvis - IDZebra filter alvis (XSLT filter for XML)
>   libidzebra-2.0-mod-dom - IDZebra filter 'dom' (XML DOM internal
> document model with XSLT)
>   libidzebra-2.0-mod-safari - IDZebra filter 'safari' (DBC)
>   libidzebra-2.0-mod-text - IDZebra filter text
>   libidzebra-2.0-mod-grs-marc - IDZebra filter grs.marc (ISO2709 MARC
> reader)
>   libidzebra-2.0-mod-grs-regx - IDZebra filters grs.regx, grs.tcl
>   libidzebra-2.0-mod-grs-xml - IDZebra filter grs.xml (XML filter)
>   idzebra-2.0-doc - IDZebra documentation
>
> To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/idzebra
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x
> https://mentors.debian.net/debian/pool/main/i/idzebra/idzebra_2.1.4-1.dsc
>
> Changes since the last upload:
>
>* New upstream release (Closes: #777515, #920343).
>* debian/control:
>  - Update Build-Depends list.
>  - Build-Depend on libyaz-dev (Closes: #917611).
>  - Raise Standards-Version to 4.4.1 from 3.9.5 (no changes needed).
>  - Drop Build-Conflicts field.
>  - Update Vcs-* fields to point to Salsa.
>  - Update Homepage URI.
>  - Add Rules-Requires-Root field.
>  - Mark the 'common', 'docs' and 'examples' packages Multi-Arch:
> foreign.
>* debian/patches: Drop all patches (no longer needed).
>* debian/rules:
>  - Add 'hardening=+all' to DEB_BUILD_MAINT_OPTIONS
>  - Automatically generate the minimum package version for
> dh_makeshlibs.
>  - Remove dh_auto_configure override
>  - Remove dh_install override.
>  - Remove unused DH_OPTIONS variable.
>  - Remove some comments.
>  - Remove legacy targets.
>* debian/upstream: Add metadata file.
>* Add new symbols to libidzebra-2.0-0.symbols.
>* libidzebra-2.0-dev:
>  - Re-order install file to follow alphabetical sorting order.
>  - Update manpages file.
>* idzebra-2.0-utils:
>  - Update manpages file.
>  - Install idzebra-abs2dom binary and manpage.
>* Add new package: libidzebra-2.0-mod-safari.
>
> The current maintainer, Vincent Danjean, does not have time to update
> idzebra at the moment and asked me to seek sponsor on the mailing
> list.
> I have added myself as an Uploader at Vincent Danjean's invitation. I
> am happy to forward any potential sponsor his email as proof of this.


I am still looking for a sponsor for IDZebra, which needs to go through
NEW, targeting experimental.

Thank you,

Hugh

Bug#935901: RFS: fonts-material-design-icons-iconfont/5.0.1-1 [ITP] -- Material Design icons DX

[Hugh McMaster]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package
"fonts-material-design-icons-iconfont".

 * Package name: fonts-material-design-icons-iconfont
   Version : 5.0.1-1
   Upstream Author : Jossef Harush
 * URL : https://github.com/jossef/material-design-icons-iconfont
 * License : Apache-2.0
 * Vcs :
https://salsa.debian.org/hmc-guest/fonts-material-design-icons-iconfont
   Section : fonts

The source produces the following binary package:

fonts-material-design-icons-iconfont - Material Design icons DX

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/fonts-material-design-icons-iconfont

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-material-design-icons-iconfont/fonts-material-design-icons-iconfont_5.0.1-1.dsc

Changes since the last upload:

* Initial release. (Closes: #934598)

Regards,

Hugh McMaster

Re: Google use clause conflicting with Apache 2.0

[Hugh McMaster]

Hi Jens,

Apologies for the delayed reply.

On Sat, 24 Aug 2019 at 1:17 am, Jens Reyer wrote:

> I guess you refer to
> https://github.com/google/material-design-icons/blob/master/README.md

[...]

> 
> ~
> Given
>  "We'd love attribution [...], but it's not required."
> the next sentence
>  "The only thing [...]"
> seems to be a real requirement (practically being a part of the license).
>
> But a clarification from upstream would indeed be helpful.  Both the
> language ("ask") and the split over separate files is at least confusing.


Unfortunately, upstream never provided a definite answer to anyone asking
about the licence.

> Alternatively, there is an active fork [2], which contains Google’s font
> > files with fixes for missing icons etc., but no icon files or images.
> > Thefork is licensed with Apache 2.0 as well, but with no extra clauses.
> >
> > Is it more sensible (and feasible) to package the fork instead of the
> > official package?
>
> For license reasons: no, a fork can't change the license without
> upstream's consent.  But looking at the fork's README.md I see the same
> paragraph there anyway.


Good to know.

>
> For content reasons it might be a good idea.


Agreed. I’ll package the fork.

Hugh

>
>

Google use clause conflicting with Apache 2.0

[Hugh McMaster]

Dear mentors,

I filed an ITP for Google’s Material Design Icons. [1]

In the ITP thread, Jonas pointed out that Google requests users of the font
to not sell the icons – a request that is seemingly incompatible with the
Apache 2.0 licence.

Unfortunately, there is no official clarification on this conflict,
although non-official interpretations say Google just don’t want people
reselling the icons by themselves.

How should I manage this conflict with the Apache 2.0 licence?

Also, as the package ships icon images, sprites etc., there is a massive
number of files. Given this, I’m thinking about packaging each icon
category separately.

Alternatively, there is an active fork [2], which contains Google’s font
files with fixes for missing icons etc., but no icon files or images.
Thefork is licensed with Apache 2.0 as well, but with no extra clauses.

Is it more sensible (and feasible) to package the fork instead of the
official package?

Thank you,

Hugh


[1] https://bugs.debian.org/934598
[2]
https://github.com/jossef/material-design-icons-iconfont

Re: debian/copyright and po files

[Hugh McMaster]

Hi Ben,

Apologies for the delayed response.

On Saturday, 16 June 2018 11:09 AM, Ben Finney wrote:
> Whether a person's creative work is restricted by copyright law, is a
> matter less for Debian project members and more for experts in copyright
> law.
>
> So your question could be intepreted in multiple ways:
> 
>Are you asking, Does copyright law in some specific jurisdiction
> restrict the actions of the recipient conditional on license from the
> translators who contributed to that work?
> 
> (That's what I understand by “do these people count as copyright
> holders”. It's a vexed question in many cases.)
>
> Are you asking, Must the Debian package list the translators separately
> in its ‘debian/copyright’ document?

> That question depends in part on the vexed legal question, above; it
> also depends in part on what level of documentation the FTP masters will
> accept for a package.

Definitely the second option, although I see how it relies on the answer
to the first question.

> As a practical matter, I find it sufficient to list “© 1984–1997 Foo Bar
> and others” (where “Foo Bar” is whatever primary party is recorded in
> the upstream source work) — *if* there is no special effort in the
> source work to document copyright more explicitly for translators.

Okay. Thanks for this. I'll need to go back and check all of the po files
again to see if an explicit copyright holder is listed.

> In the case (which I have not encountered) where the upstream work does
> specially record the copyright held by translators, I would use that
> information for the ‘debian/copyright’ document.

Good advice.

Thanks for your help.

Hugh

debian/copyright and po files

[Hugh McMaster]

Dear mentors,

I'm currently creating a DEP-5 copyright file for a new package,
but I'm confused about how I should handle po files.

Many of the files contain the following format:

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
#
# Translators:
# Name 1 , Year
# Name 2 , Year 1 - Year 2

Do names listed under the "Translators" heading count as copyright holders?

If this is the case, then what about the "Last Translator", whose name may not
appear in the above list?

Do I need to record these names, or is there a generic attribution that I can 
use?

Thank you,

Hugh

Bug#894615: RFS: libexif/0.6.21-5

[Hugh McMaster]

Hi Andreas,

Thank you for sponsoring libexif.

On Tuesday, 3 April 2018 2:44 AM, Andreas Metzler wrote:
> looks good except for the watchfile, you need uversionmangle
> instead of oversionmangle.

Right. I did wonder about using the oversionmangle option. I've fixed
the watch file options to use uversionmangle in the latest build on d.mentors.

https://mentors.debian.net/debian/pool/main/libe/libexif/libexif_0.6.21-5.dsc

> Also I have searched in vain for your gnupg key, is it aailable
> somewhere?

Sorry about this. I've now published my public key to the key servers
listed under Step 3 of https://wiki.debian.org/Keysigning

Kind regards,

Hugh

Bug#894615: RFS: libexif/0.6.21-5

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors and Debian PhotoTools Team,

I am looking for a sponsor for a Team Upload of the package "libexif".

* Package name: libexif
  Version : 0.6.21-5
  Upstream Author : Dan Fandrich 
* URL : https://libexif.github.io
* License : LGPL-2.1+
  Section : libs

The source builds the following binary packages:

* libexif12  - library to parse EXIF files
* libexif-dev - library to parse EXIF files (development files)
* libexif-doc - library to parse EXIF files (documentation)

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/libexif

Alternatively, you can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/libe/libexif/libexif_0.6.21-5.dsc

More information about libexif can be obtained from https://libexif.github.io

Changes since the last upload:

  * Team upload.
  * debhelper update:
- Update package compatibility to level 11.
  * debian/changelog:
- Remove trailing whitespace.
  * debian/control:
- Build-Depend on debhelper version 11.
- Raise Standards-Version from 4.1.1 to 4.1.3 (no changes needed).
- Update the Homepage field to point to https://libexif.github.io
  (Closes: #894183).
- Update the Vcs fields to point to https://salsa.debian.org.
  * debian/copyright:
- Update the Source URL field to point to https://libexif.github.io.
  * debian/patches:
- Add .patch file extensions to existing patches.
- add-am_prog_ar.patch: Add the AM_PROG_AR macro to configure.ac to avoid
  an automake warning.
- ac_lang_source-macro.patch: Use AC_LANG_SOURCE macros to avoid several
  automake warnings in configure.ac.
- fix-size_t-warnings.patch: Cast %u format specifiers to unsigned long to
  prevent compiler warnings on 32-bit and 64-bit platforms.
  * debian/rules:
- Update dh_installdocs overrides.
- Remove '--parallel' (now handled by debhelper >= level 11).
  * debian/source/options:
- Remove from package. Debhelper handles the specified options by default.
  * debian/watch:
- Update to version 4 and switch to upstream's github repository.

Regards,

Hugh McMaster

Re: .dput.cf WAS: Upload failed: 301 Moved Permanently

[Hugh McMaster]

On Wednesday, 21 March 2018 10:58 PM, Mattia Rizzolo wrote:
> As an admin of mentors.d.n (and as a chronically lazy person) I'm
> curious as to why anybody would go to the extra length of using a local
> configuration when both dput and dput-ng ship with good enough default
> one.

Well, another reason is that https://mentors.debian.net/qa says FTP uploads 
can take up to 30 minutes to be processed, compared to 2 minutes for HTTP.

Some people don't want to wait that long.

--
Hugh McMaster

Re: Upload failed: 301 Moved Permanently

[Hugh McMaster]

Hi Elimar,

On Monday, 19 March 2018 9:23 PM, Elimar Riesebieter wrote:
> I tried to upload via dput a modified package and get:
> [...]
>  Uploading mailfilter_0.8.6-3.dsc: Upload failed: 301 Moved Permanently

I also encountered this issue today. On #debian-mentors, Ansgar Burchardt said
uploads now required use of https, which worked for me.

So try modifying the 'method' line in your .dput.cf file to use https.

--
Hugh McMaster

Bug#893491: RFS: libexif-gtk/0.4.0-1

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors and Debian PhotoTools Team,
  
I am looking for a sponsor for a Team Upload of the package "libexif-gtk".

 * Package name: libexif-gtk
   Version : 0.4.0-1
   Upstream Author : Dan Fandrich 
 * URL : https://libexif.github.io
 * License : LGPL-2.1+
   Section : libs

The source builds the following binary packages:

 * libexif-gtk-dev - Library providing GTK+ widgets to display/edit EXIF tags 
(develop
 * libexif-gtk5 - Library providing GTK+ widgets to display/edit EXIF tags

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libexif-gtk

Alternatively, you can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/libe/libexif-gtk/libexif-gtk_0.4.0-1.dsc

More information about libexif-gtk can be obtained from 
https://libexif.github.io

Changes since the last upload:

  * Team upload.

  [ Emmanuel Bouthenot ]
  * Remove the DM-Upload-Allowed field from debian/control.

  [ Hugh McMaster ]
  * New upstream release.
  * debhelper update:
- Update package compatibility to level 11.
  * Package libexif-gtk5 symbols.
  * debian/*.docs:
- Package the NEWS file.
  * debian/*.install:
- Use multi-arch directories.
  * debian/control:
- Build-Depend on debhelper version 11.
- Build-Depend on libexif-dev 0.6.21.
- Remove dh-autoreconf from the Build-Depends list.
- Raise Standards-Version from 3.9.2 to 4.1.3.
- Update the Homepage field to point to https://salsa.debian.org.
- Update the Vcs-fields to point to https://salsa.debian.org.
- Update the package order.
- Mark libexif-gtk5 and libexif-gtk-dev Multi-Arch: same.
  * debian/copyright:
- Update the Format specification URI.
- Update the Source URL field to point to https://libexif.github.io.
- Update copyright information for libexif-gtk 0.4.0.
- Switch to LGPL-2.1+ for libexif-gtk 0.4.0.
  * debian/patches:
- Drop patches superseded upstream: use_autoreconf, use_deprecated_gtk,
  french_translation and german_translation.
- Rebase pkgconfig_require_gtk2.patch for libexif-gtk 0.4.0.
- add-am_prog_ar.patch: Add the AM_PROG_AR macro to configure.ac to avoid
  some automake warnings.
  * debian/rules:
- Remove excess whitespace.
- Remove '--with autoreconf' (now handled by debhelper >= level 10).
- Remove dh_auto_build overrides.
- Override dh_auto_clean to remove left-over build files.
- Add 'hardening=+all' to DEB_BUILD_MAINT_OPTIONS.
  * debian/source/options:
- Remove from package. Debhelper handles the specified options by default.
  * debian/watch:
- Update to version 4 and switch to upstream's github repository.

Regards,

Hugh McMaster

Bug#890898: RFS: exif/0.6.21-2

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a Team Upload of the package "exif".

* Package name: exif
  Version : 0.6.21-2
  Upstream Author : Dan Fandrich ,
Lutz Müller 
* URL : https://libexif.github.io
* License : GNU LGPL 2.1
  Section : graphics

It builds those binary packages:
  exif - command-line utility to show EXIF information in JPEG files

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/exif

Alternatively, one can download the package with dget using this command:
  dget -x https://mentors.debian.net/debian/pool/main/e/exif/exif_0.6.21-2.dsc

More information about "exif" can be obtained from https://www.example.com.

Changes since the last upload:

  * Team upload.
  * debhelper update:
- Update package compatibility to level 11. 
  * debian/control:
- Build-Depend on debhelper version 11.
- Build-Depend on libexif-dev 0.6.21.
- Remove dh-autoreconf and autotools-dev from the Build-Depends list.
- Raise Standards-Version from 3.9.4 to 4.1.3.
- Update the Homepage field to point to https://libexif.github.io.
- Update the Vcs fields to point to https://salsa.debian.org.
- Mark exif Multi-Arch: foreign.
  * debian/copyright:
- Update the Format specification URI.
- Update the Source URL field to point to https://libexif.github.io.
  * debian/patches:
- add-am_prog_ar.patch: Add the AM_PROG_AR macro to configure.ac to avoid
  an automake warning.
- cross-build-pkg-config.patch: Replace the macro GP_PKG_CONFIG with
  PKG_PROG_PKG_CONFIG to allow exif to cross-compile from source
  (thanks to Helmut Grohne for the patch) (Closes: #858102).
- fix-hyphens-in-manpage.patch: Add .patch file extension and
  update the patch description.
- fix-size_t-warnings.patch: Cast size_t precision and width specifiers
  to unsigned int to avoid compile-time warnings with printf().
  * debian/rules:
- Add 'hardening=+all' to DEB_BUILD_MAINT_OPTIONS.
- Remove '--with autotools_dev,autoreconf', as these options are now
  handled by debhelper level 11.
  * debian/source/options:
- Remove from package. Debhelper handles the specified options by default.

Regards,
Hugh McMaster

Bug#887595: RFS: xft/2.3.2-1.1 [NMU]

[Hugh McMaster]

Hi Tobi,

Julien downgraded the severity of #884176 to 'wishlist'. [1] So it looks like 
this could be 'wontfix'.

That said, I'm still unclear whether Julien is going to fix this himself or 
not, as he never said.

I can still do the NMU, but if it's going to get rejected, there seems little 
point.

Hugh

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884176

Bug#887595: RFS: xft/2.3.2-1.1 [NMU]

[Hugh McMaster]

Hi Mattia

On Tuesday, 23 January 2018 5:18 AM, Mattia Rizzolo wrote:
> So, in #884176 you attacted a debdiff also fixing #843837 - where did it
> end?
> Anyway, if you want to fix that but by that patch, please first forward
> it upstream and put valid DEP-3 headers on it.

The patch for #843837 is incorrect and no longer needed. The Debian 
motif maintainers patched configure.ac in August 2017 to use the correct 
cflags and libs for freetype2 at compile time.

Also note that the Freetype2 developers no longer recommend using 
#include 
in source files (which was the intent of my patch). The following should be 
used instead:
#include 
#include FT_FREETYPE_H

Developers would then use either freetype-config or pkg-config to 
obtain the cflags etc.

Kind regards,

Hugh

Bug#887595: RFS: xft/2.3.2-1.1 [NMU]

[Hugh McMaster]

Hi Tobias,

On Tuesday, 23 January 2018 6:16 PM, Tobias Frost wrote:

On Mon, Jan 22, 2018 at 10:58:00AM +, Hugh McMaster wrote:
>> 1. Cyril Brulebois is listed in Uploaders, but he hasn't been part of 
>>    Debian XFS for some years now.
>
>Did you ask him if he still is interested in maintaining the package?

Yes, I contacted him shortly after New Year. On 3 January 2018, he 
wrote in an email that he no longer maintained the package:
"I left that team [Debian XFS] a long while ago (several years): 
https://lists.debian.org/debian-x/2013/10/msg00292.html";

>> 2. The VCS URL in the Package Tracker no longer functions, due to the 
>>    recent migration to Debian Salsa.
>
>That is unrelated. alioth is still working. However this is another sign
>that the package is no longer in active maintaince.

Re-reading what I wrote, I can see I wasn't clear. Julien updated the 
VCS URL in xft's repository on Salsa a week ago. [1] I was implying that 
the VCS URL in the Package Tracker would not work until the package 
is updated. (Correct me if I'm wrong, however.) 

> I suggest to mail kibi and just ask him whether it is and maybe (if you
> want) whether you could add yourself as Co-Maintainer.
> (You maybe also want to file a bug the the repository is defunc.)

Julien is in a better place to tell us about xft's status. That said, I'd be 
happy to help with maintenance, if Julien would welcome that.

>> 3. The package standards version is 3.9.2 ("ancient").
>> 4. The lack of Multi-Arch awareness blocks multi-arch support for 
>>    libpango1.0-dev and libfontforge-dev. These packages, in turn, 
>>    block Wine.
>
> Thanks for the explanation, but then this should be documented in the bug and
> the severity increased (IMHO to important).

I'll raise the severity and add information about the lack of multi-arch 
support blocking other packages.

>> 5. As for fixing other bugs, #843837 should be tagged 'wontfix', 
>>    since it is an upstream issue (fixed some time ago). I don't know 
>>    enough about the other three bugs to comment.
>
> How is it fixed upstream? The bug has no info...
> Looking for upstream... It seems that there is no newer release
> at the site mentioned in d/copyright.

Ah, sorry. This was a misuse of terminology. Debian maintainers for 
motif added a patch for #843837 in August last year [2].

Thanks for the advice.

--
Hugh McMaster

[1] 
https://salsa.debian.org/xorg-team/lib/xft/commit/32a69bcd3d9b4919376e00e21dbf17b6672bcef6
[2] 
https://anonscm.debian.org/cgit/collab-maint/motif.git/tree/debian/patches/fix_ac_find_xft.patch

Bug#887595: RFS: xft/2.3.2-1.1 [NMU]

[Hugh McMaster]

Hi Julien,

On Monday, 22 January 2018 7:49 AM, Julien Cristau wrote:
> IMO this is nothing that warrants a NMU, or an upload on its own.

Sure, perhaps not in the current RFS form. That said, I'm hoping we can 
reach some agreement on releasing a new version of xft. Here are some 
reasons why.

1. Cyril Brulebois is listed in Uploaders, but he hasn't been part of 
   Debian XFS for some years now.
2. The VCS URL in the Package Tracker no longer functions, due to the 
   recent migration to Debian Salsa.
3. The package standards version is 3.9.2 ("ancient").
4. The lack of Multi-Arch awareness blocks multi-arch support for 
   libpango1.0-dev and libfontforge-dev. These packages, in turn, 
   block Wine.
5. As for fixing other bugs, #843837 should be tagged 'wontfix', 
   since it is an upstream issue (fixed some time ago). I don't know 
   enough about the other three bugs to comment.

Marking libxft-dev Multi-Arch: same is particularly important to me,
so I'm hoping you can update the package with the above points 
in mind.

Thanks for your email.

--
Hugh McMaster

Bug#887595: RFS: xft/2.3.2-1.1 [NMU]

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for an NMU of the package "xft".

* Package name: xft
  Version : 2.3.2-1.1
  Upstream Author : Keith Packard
* URL : https://freedesktop.org/wiki/Software/Xft/
* License : BSD
  Section : devel

The source builds the following binary packages:
 * libxft-dev - FreeType-based font drawing library for X (development files)
 * libxft2- FreeType-based font drawing library for X
 * libxft2-dbg - FreeType-based font drawing library for X (unstripped)
 * libxft2-udeb - FreeType-based font drawing library for X (udeb)

To access further information about this package, please visit the following 
URL:
  https://mentors.debian.net/package/xft

Alternatively, you can download the package with dget using this command:
dget -x https://mentors.debian.net/debian/pool/main/x/xft/xft_2.3.2-1.1.dsc

More information about xft can be obtained from 
https://www.freedesktop.org/wiki/Software/Xft/.

Changes since the last upload:
  * Non-maintainer upload.
  * debian/control:
- Mark libxft-dev Multi-Arch: same (Closes: #884176).

Regards,

Hugh McMaster

Bug#887481: RFS: freetype/2.8.1-1.1 [NMU]

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for an NMU of the package "freetype".

* Package name: freetype
  Version : 2.8.1-1.1
  Upstream Author : The FreeType Project
* URL : https://www.freetype.org/
* License : FreeType License / GPLv2
  Section : libs

It builds the following binary packages:
  * freetype2-demos - FreeType 2 demonstration programs
  * libfreetype6 - FreeType 2 font engine, shared library files
  * libfreetype6-dev - FreeType 2 font engine, development files
  * libfreetype6-udeb - FreeType 2 font engine for the debian-installer (udeb)

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/freetype

Alternatively, download the package with 'dget' using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/f/freetype/freetype_2.8.1-1.1.dsc

More information about hello can be obtained from https://www.freetype.org

Changes since the last upload:
  * Non-maintainer upload.
  * debian/rules:
- Update a 'sed' expression to prevent it replacing all occurrences
  of SIZEOF_LONG in ftconfig.h (Closes: #887087).

Regards,
Hugh McMaster

Bug#884769: RFS: freetype/2.8.1-0.2 [NMU]

[Hugh McMaster]

Hi Adam and Gianfranco,


Steve accepted almost all of my NMU changes last Friday, when he released a 
maintainer version of freetype.


So this RFS bug can be closed.


Thank you for your advice during the process.


Hugh


From: Hugh McMaster 
Sent: Friday, 22 December 2017 11:30:57 PM
To: Gianfranco Costamagna
Cc: Adam Borowski; 884...@bugs.debian.org
Subject: Bug#884769: RFS: freetype/2.8.1-0.2 [NMU]

Hi Gianfranco,

On Friday, 22 December 2017 3:11 AM, Gianfranco Costamagna wrote:
> ok, so fix all the reverse dependencies *before* dropping it, not after.
> We don't usually "break stuff and let maintainers fixup things", but:
> 1) open bugs (maybe with patches)

Okay, I'll start filing bugs to encourage the use of pkg-config to detect 
freetype2.
IIRC, some of the 33 already use pkg-config for other packages.

> Anyhow, we are really blocked by Steve, I pinged him on irc, maybe we can fix 
> this old bug
> now!

We should keep trying, but I don't want to pressure him to respond.

On another note, when should I prepare an NMU fixing #883698 (an RC bug)?
I'd also like to try removing the libdir code from freetype-config to make the 
package
multi-arch compatible.

Thanks,
Hugh

Bug#884769: RFS: freetype/2.8.1-0.2 [NMU]

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am once again looking for a sponsor for an NMU of the package "freetype".
This version addresses concerns raised by Adam Borowski and Gianfranco 
Costamagna, 
and removes the arch-dependent libdir output instead of freetype-config itself.

* Package name: freetype
  Version: 2.8.1-0.2
  Upstream Author: Werner Lemberg/Freetype Team, freetype-de...@nongnu.org
* URL: https://www.freetype.org
* License: FTL or GNU GPLv2
  Section: libs

The source builds the following binary packages:
* freetype2-demos - FreeType 2 demonstration programs
* libfreetype6 - FreeType 2 font engine, shared library files
* libfreetype6-dev - FreeType 2 font engine, development files
* libfreetype6-udeb - FreeType 2 font engine for the debian-installer (udeb)

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/freetype

Alternatively, you can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/f/freetype/freetype_2.8.1-0.2.dsc

More information about freetype can be obtained from https://www.freetype.org.

Changes since the last upload:
* Non-maintainer upload.
* debian/control:
  - Add pkg-config to the Build-Depends list (Closes: #885324).
  - Mark libfreetype6-dev Multi-Arch: same (Closes: #666761).
  - Remove the deprecated Priority: extra field from libfreetype6-udeb.
* debian/patches/patches-*: Refresh existing patches.
* debian/patches/patches-freetype/freetype-config-multi-arch.patch:
  - Remove the arch-dependent output of `freetype-config --libs`.
  - Exit with an error if freetype-config is called with --libtool.
* debian/rules:
  - Include /usr/share/dpkg/architecture.mk.
  - Dynamically generate the shlibs dependency version (Closes: #883698).
  - Replace the autoconf definition of SIZEOF_LONG with the compile-time
constant __SIZEOF_LONG__ to make libfreetype6-dev multi-arch compatible

Bug#884769: RFS: freetype/2.8.1-0.2 [NMU]

[Hugh McMaster]

Hi Gianfranco,

On Friday, 22 December 2017 3:11 AM, Gianfranco Costamagna wrote:
> ok, so fix all the reverse dependencies *before* dropping it, not after.
> We don't usually "break stuff and let maintainers fixup things", but:
> 1) open bugs (maybe with patches)

Okay, I'll start filing bugs to encourage the use of pkg-config to detect 
freetype2.
IIRC, some of the 33 already use pkg-config for other packages.

> Anyhow, we are really blocked by Steve, I pinged him on irc, maybe we can fix 
> this old bug
> now!

We should keep trying, but I don't want to pressure him to respond.

On another note, when should I prepare an NMU fixing #883698 (an RC bug)?
I'd also like to try removing the libdir code from freetype-config to make the 
package
multi-arch compatible.

Thanks,
Hugh

Bug#884769: RFS: freetype/2.8.1-0.2 [NMU]

[Hugh McMaster]

On Wednesday, 20 December 2017 4:44 AM, Gianfranco Costamagna wrote:
> https://codesearch.debian.net/search?q=freetype-config

> this is a big no-go, first, please ask Steve to review, but I would assume 
> this patch
> is wrong, because a lot of packages are right now calling freetype-config in 
> their build
> script.
33 reverse build dependences FTBFS after the removal of freetype-config.
11 don't care, and 42 already use pkg-config to detect freetype2.

freetype-config is a wrapper for pkg-config if the latter is installed. 
Unfortunately, 
this outputs the wrong libdir when cross-compiling. This is also the case when 
using the autoconf-detected path via the 'else' block.

> (in libpng1.6 we kept it with removing of the multi-arch bits, to make it 
> have the same
> md5sum across multiple architectures).
> See:  
> https://sources.debian.org/src/libpng1.6/1.6.34-1/debian/patches/libpng-config.patch/

This has possibilities, since Debian searches /usr/lib and /usr/lib/, 
skipping 
incompatible libraries. I can't find the thread immediately, but I remember a 
similar 
proposal being rejected in favour of cleanly removing freetype-config.

Ultimately, the goal is to enable multi-arch support in libfreetype6-dev. That 
can 
probably be achieved with or without freetype-config.

Hopefully Steve can give us some guidance on how to move forward.

Bug#884769: RFS: freetype/2.8.1-0.2 [NMU]

[Hugh McMaster]

On Wednesday, 20 December 2017 2:47 AM, Adam Borowski wrote:
> Hmm, there are two RC bugs on the package, but you're not fixing either of
> them.  Instead, you fix wishlist wontfix bugs.

One of the RC bugs is tagged 'wontfix' -- and that is also upstream's response.
I've had a look at the second RC bug. I need to confirm this, but it seems that 
the 'dependency' variable needs to be 2.8. This can be hard-coded, or we 
could take a set and forget approach and do something like:

dependency = $(libpkg) (>= `echo $(ver) | sed 's|\([0-9]\.[0-9]\).*|\1|'`)

> Reading the bugs logs, I see the attitude to them has changed, but I don't
> know the package well enough to do a meaningful review without spending some
> time to see what's going on.  As at least two big-name DDs are involved, I'd
> ask them first.

Yes, the attitude turned towards removing freetype-config. Previous attempts
to fix freetype-config did not impress [1]. That aside, I'll try to contact
Steve and Matthias.

> I'm wondering why you aimed this RFS specifically at me, as have no
> experience with freetype.
I CC'd you, since you have sponsored my packages in the past. Of course, 
I can't expect you to have in-depth knowledge of every package.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870618#17

Bug#884769: Changelog for RFS: freetype/2.8.1-0.2 [NMU]

[Hugh McMaster]

Sorry, I forgot to add the changelog entries for freetype to my original RFS 
email.

Changes since the last upload:
* Non-maintainer upload.
* debian/control:
  - Mark libfreetype6-dev Multi-Arch: same
(Closes: #642354, #666761, #870618).
  - Remove the deprecated Priority: extra marking from libfreetype6-udeb.
* debian/rules:
  - Include /usr/share/dpkg/architecture.mk.
  - Replace the autoconf definition of SIZEOF_LONG with the
compile-time constant __SIZEOF_LONG__.
  - Exclude freetype-config, freetype-config.1 and freetype2.m4
from installation in libfreetype6-dev.

Bug#884769: RFS: freetype/2.8.1-0.2 [NMU]

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for an NMU of the package "freetype".

* Package name: freetype
  Version: 2.8.1-0.2
  Upstream Author: Werner Lemberg/Freetype Team, freetype-de...@nongnu.org
* URL: https://www.freetype.org
* License: FTL or GNU GPLv2
  Section: libs

The source builds the following binary packages:
* freetype2-demos - FreeType 2 demonstration programs
* libfreetype6 - FreeType 2 font engine, shared library files
* libfreetype6-dev - FreeType 2 font engine, development files
* libfreetype6-udeb - FreeType 2 font engine for the debian-installer (udeb)

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/freetype

Alternatively, you can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/f/freetype/freetype_2.8.1-0.2.dsc

More information about freetype can be obtained from https://www.freetype.org.

Changes since the last upload:
  [your most recent changelog entry]

This release contains some breaking changes. Please upload the package to 
Delayed/10. Once accepted,
I will file bugs with the affected packages (severity: Important). If there is 
no response when the
package reaches Sid, I will raise the bug severity to Serious.

Regards,
Hugh McMaster

Bug#881035: RFS: unixodbc/2.3.4-1.1 [NMU]

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for an NMU of the package "unixodbc".

* Package name: unixodbc
  Version: 2.3.4-1.1
  Upstream Author: Nick Gorham 
* URL: http://www.unixodbc.org
* License: LGPL v2.1
  Section: libs

The source builds the following binary packages:
* libodbc1   - ODBC library for Unix
* odbcinst   - Helper program for accessing odbc ini files
* odbcinst1debian2 - Support library for accessing odbc ini files
* unixodbc   - Basic ODBC tools
* unixodbc-dev - ODBC libraries for UNIX (development files)

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/unixodbc

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/u/unixodbc/unixodbc_2.3.4-1.1.dsc

More information about unixodbc can be obtained from http://www.unixodbc.org.

Changes since the last upload:
  * Non-maintainer upload.
  * debian/control:
- Mark unixodbc-dev Multi-Arch: same (Closes: #872411).
- Depend on libltdl-dev instead of libltdl3-dev.
  * debian/rules:
- Compile with --enable-fastvalidate to avoid performance degradation
  when working with large numbers of handles (Closes: #819622).
- Move unixodbc_conf.h to /usr/include/ to avoid
  a file conflict on multi-arch systems.

I am aware that the package needs work to clean it up - e.g. converting to 
package format 3.0,
fixing lintian issues and so on. This work is not possible in a general NMU 
and, as a result, has
not been included in this release.

Regards,
Hugh McMaster

Bug#880568: RFS: libexif/0.6.21-4 [RC]

[Hugh McMaster]

Hi Adam,

Thanks for uploading libexif yet again!  :-)

On Friday, 3 November 2017 10:30 AM, Adam Borowski wrote:
> Oif, my fault for not noticing the file move wasn't ok.  Time to dust off
> that piuparts thingy...
>
> Piuparts-tested and uploaded, thanks for the fix.

I tried to reproduce the upgrade failure in piuparts a few times, but
the upgrades always succeeded. So I'm not sure which commands
Andreas was using when he found the bug.

My piuparts command line: piuparts -d buster -d sid -a libexif-dev libexif-doc
I even tried using the changes file, but the upgrades succeeded in that test as 
well.

--
Hugh McMaster

Bug#880568: RFS: libexif/0.6.21-4 [RC]

[Hugh McMaster]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "libexif", as part of my
work with the Debian Photo Tools Team.

* Package name: libexif
  Version: 0.6.21-4
  Upstream Author: Dan Fandrich 
* URL: http://libexif.sourceforge.net/
* License: LGPL v2.1
  Section: libs

The package builds the following binary packages:
* libexif12  - library to parse EXIF files
* libexif-dev - library to parse EXIF files (development files)
* libexif-doc - library to parse EXIF files (documentation)

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/libexif

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/libe/libexif/libexif_0.6.21-4.dsc

More information about libexif can be obtained from 
http://libexif.sourceforge.net/

Changes since the last upload:
* Team upload.
* debian/control:
  - Allow libexif-doc to take ownership of all documentation files
previously packaged with libexif-dev (Closes: #880213).
  - Remove the Replaces field from libexif12 and libexif-dev.
* debian/rules:
  - Include /usr/share/dpkg/architecture.mk.

Regards,
Hugh McMaster

Re: Multi-arch header conflict and pkg-config

[Hugh McMaster]

Hi Wookey,

Apologies for the delayed response.

On Thursday, 26 October 2017 12:23 AM, Wookey wrote:    
>> The header was previously installed with other headers in 
>> /usr/include/.
>> Due to the conflict, I've modified debian/rules to:
>> 1. Override dh_auto_install,
>> 2. Create a directory in debian/tmp/usr/include//
>> using mkdir -p; and
>> 3. Move the conflicting header to the newly created directory using mv.

> OK, that sounds sensible, presuming that the header _should_ be 
> arch-dependent.
>The alternative is to fix up the header so it's no longer arch-dependent.

The header contains an arch-specific path to Python plugins.

> This is because the debian toolchain puts both 
> /usr/include, and /usr/include/${DEB_HOST_MULTIARCH} on the system search 
> path so a
> #include  should find header.h in both
> /usr/include/package/ and /usr/include/${DEB_HOST_MULTIARCH}/package/
>or at least I think that's how it's expected to work.

I tested this and can confirm that your explanation is correct.
Headers are found in both of those directories.

> How exactly are you testing this?
I was including the header directly; i.e. without the package prefix.
That didn't work; hence this email to the D-Mentors list. 

Replacing
#include 
with
#include 
allowed gcc to find the header, even though it was installed in the multi-arch 
include path.

Thank you for providing detailed explanations for Debian's toolchain behaviour.

--
Hugh McMaster

Bug#879933: RFS: libexif/0.6.21-3

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "libexif", as part of my work
for the Debian Photo Tools Team.

* Package name: libexif
  Version: 0.6.21-3
  Upstream Author: Dan Fandrich 
* URL: http://libexif.sourceforge.net/
* License: LGPL v2.1
  Section: libs

The package builds the following binary packages:
* libexif12  - library to parse EXIF files
* libexif-dev - library to parse EXIF files (development files)
* libexif-doc - library to parse EXIF files (documentation)

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/libexif

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/libe/libexif/libexif_0.6.21-3.dsc

More information about hello can be obtained from 
http://libexif.sourceforge.net/

Changes since the last upload:
  * Team upload.
  * Import changes from NMU version 0.6.21-2.1.
  * Introduce libexif-doc:
- Move the development documentation from libexif-dev to
  avoid PNG file conflicts during multi-arch installation.
- Update the package's doc-base registration.
  * debian/control:
- Revise package order.
- Update package Depends lists.
  * debian/copyright:
- Fix a formatting error.
  * debian/rules:
- Exclude doxygen md5 files from installation during the
  'dh_installdocs' phase.
  * Do not package the AUTHORS file, since all developers are
listed in the debian/copyright file.

Regards,
Hugh McMaster

Re: Multi-arch header conflict and pkg-config

[Hugh McMaster]

Hi Gianfranco,

On Tuesday, 24 October 2017 1:49 AM, Gianfranco Costamagna wrote:
>> pkg-config --cflags also just outputs -I/usr/include/.
>> Does pkgconfig support multiple paths like this?
> add the triplet to your .pc shipped file
> /usr/lib/x86_64-linux-gnu/pkgconfig/python-3.6m.pc:Cflags: 
> -I${includedir}/python3.6m -I${includedir}/x86_64-linux-gnu/python3.6m

> Other programs do this too, so with some sort of patch this should be possible
> (they are sometimes created during build, otherwise you will need some sed 
> during install or similar

Many thanks for this advice. Using sed to handle the substitution works 
perfectly.  :-)

--
Hugh McMaster

Multi-arch header conflict and pkg-config

[Hugh McMaster]

Hi all,

I'm attempting to resolve a multi-arch conflict with a header file in a package
I'm working on.

The header was previously installed with other headers in 
/usr/include/.
Due to the conflict, I've modified debian/rules to:
1. Override dh_auto_install,
2. Create a directory in debian/tmp/usr/include//
using mkdir -p; and
3. Move the conflicting header to the newly created directory using mv.

While these steps resolve the conflict, allowing the package to become
M-A: same, test programs no longer find the header in the triple include path.

pkg-config --cflags also just outputs -I/usr/include/.

Does pkgconfig support multiple paths like this?
If so, how do I modify the pkg-config file to handle multiple /usr/include 
paths?

Any advice or package examples I could look at is appreciated.

--
Hugh McMaster

Bug#877610: RFS: libexif/0.6.21-2.1 [NMU]

[Hugh McMaster]

Dear Mentors,

I am looking for a sponsor for an NMU to the package "libexif". The current 
maintainer
has given approval for this NMU [1].

* Package name: libexif
  Version: 0.6.21-2.1
  Upstream Author : Dan Fandrich 
* URL: http://libexif.sourceforge.net/
* License: LGPL v2.1
  Section: libs

The package builds the following binary packages:
* libexif-dev - library to parse EXIF files (development files)
* libexif12  - library to parse EXIF files

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/libexif

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/libe/libexif/libexif_0.6.21-2.1.dsc

More information about libexif can be obtained from 
http://libexif.sourceforge.net/

Changes since the last upload:
* Merge paragraphs that refer to the same source file in debian/copyright to 
avoid lintian warnings.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786562#20

Bug#877610: RFS: libexif/0.6.21-2.1 [NMU]

[Hugh McMaster]

Hi Adam,

On Friday, 6 October 2017 1:17 PM, Adam Borowski wrote:
> # Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g. 
> # wishlist bugs for packaging a new upstream version, but care should be
> # taken to minimize the impact to the maintainer.) Fixing cosmetic issues or
> # changing the packaging style (e.g. switching from cdbs to dh) in NMUs is
> # discouraged.

> These rules are less strict than, for example, a stable upload, but there's
> still a good reason to minimize changes not coordinated with the maintainer.

Ah, so package compatibility and lintian issues are considered to be "cosmetic"
in this case?

> Sorry for not being clear: I've put "hostile" into quotation marks, as it's
> irrational to be angry for someone else making fixes in your packages -- at
> least if the fixes are important enough, and the maintainer didn't do so in
> a timely matter.  But it happens that certain maintainers consider their
> packages a fiefdom and treat everyone as intruders even if they don't do
> their job properly.

Thanks for the explanation.

> In #786562:
> } I am no longer active in libexif maintenance but I had a look at the
> } NMU diff and it looks fine to me; I'd suggest you to go ahead and
> } upload that.

> Ie, we're here.  As the changes were okay'ed, we can proceed with cosmetic
> changes.

Perfect. Looks like I moved too quickly on this. Lesson learnt.

>> Files: po/en_GB.po
>> Copyright: 2009, Bruce Cowan
>> License: LGPL-2.1+
>> [...]
>> Files: po/en_GB.po
>> Copyright: 2010, Robert Readman
>> License: LGPL-2.1+
>> 
>> This causes lintian to complain that the first occurrence is not used.

> That's because the first occurrence indeed is not used.  The second one
> overrides it.  You instead need to write:
>
> Files: po/en_GB.po
> Copyright: 2009, Bruce Cowan
>    2010, Robert Readman
> License: LGPL-2.1+
> 
> (Any line starting with whitespace is a continuation.)

Okay, that makes sense. I'm now re-reading the 
Debian copyright specifications document.

Thanks for your help. I hope to upload a new version
of this package in the next few days.

Hugh

Bug#877610: RFS: libexif/0.6.21-2.1 [NMU]

[Hugh McMaster]

Hi Adam,

Thanks for your email.

On Thursday, 5 October 2017 11:03 AM +1100, Adam Borowski wrote:
> This drastically exceeds what is appropriate for a NMU without the
> maintainer's consent.  Sure, the package looks neglected, but if you're
> taking steps to salvage it, it wouldn't be a NMU (at least without an
> explanation).  And a NMU requires following the procedure.
This puts me in a catch-22 situation, doesn't it? While I agree that there are 
a large number of changes, if I don't update the package standards or fix
lintian issues, someone on Debian Mentors will (most likely) reject the 
package until the work is done.

Also, I have read through section 5.11 of the Developer's Reference [1] several
times, but I cannot see which part of the NMU procedure I have missed.

> The package is marked as team maintained, but neither do I see you among
> the PhotoTools team, nor did you claim a team upload.
That's correct. I'm not part of the PhotoTools team.

> Thus, while your changes are welcome, I see confusion wrt what you're
> trying to do here.  Options include:
> * a traditional "hostile" NMU: targetted fixes only, posting a NMU diff is
>   required prior to upload
I sent the diff and intent to NMU to #786562 a few days ago [2]. That mail 
was automatically sent to the PhotoTools mailing list. I'm not sure what you  
mean by "hostile".

> * an authorized (ie, with maintainer's consent) NMU: everything goes
I sent an email to Emmanuel Bouthenot a week ago asking whether he or 
Frederic Peters were able to update the package with the upstream 
CVE patches and Multi-Arch: same field. I also flagged my intent to NMU 
if they could not update the package. He did not respond.

I also tried contacting him via PM on OFTC -- again, no response.

> * a team upload: you'd need to talk with folks of the PhotoTools team, then
>   it's no longer a NMU (mark as "Team upload", regular version number)
Unfortunately, their mailing list seems largely abandoned. But I'll try again.
I do know a developer maintaining another of the team's packages, but he 
doesn't have upload rights for libexif.

> * a non-team salvage: doesn't look appropriate as other packages of that
>   team look alive
Agreed.

> That lintian override is wrong, only one paragraph can apply to a file.
> I haven't done any real review other than a quick glance, thus there might
> be more issues.
The debian/copyright file follows the usual structure, with the exception of
a few paragraphs, which refer to the same file. For example:

Files: po/en_GB.po
Copyright: 2009, Bruce Cowan
License: LGPL-2.1+
[...]
Files: po/en_GB.po
Copyright: 2010, Robert Readman
License: LGPL-2.1+

This causes lintian to complain that the first occurrence is not used.
I'm not sure how to fix this, as in one case, the licence is different.

[1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786562

--
Hugh McMaster

Bug#877610: RFS: libexif/0.6.21-2.1 [NMU]

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "libexif".

* Package name: libexif
  Version: 0.6.21-2.1
  Upstream Author : Dan Fandrich 
* URL: http://libexif.sourceforge.net/
* License: LGPL v2.1
  Section: libs

The package builds the following binary packages:
* libexif-dev - library to parse EXIF files (development files)
* libexif12  - library to parse EXIF files

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/libexif

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/libe/libexif/libexif_0.6.21-2.1.dsc

More information about libexif can be obtained from 
http://libexif.sourceforge.net/

Changes since the last upload:

  * Non-maintainer upload.
  * debhelper update:
- Update package compatibility to level 10.
  * debian/control:
- Bump debhelper build-dep to >= 10~.
- Remove dh-autoreconf from the Build-Depends list, as debhelper
  enables the 'autoreconf' sequence by default.
- Bump Standards-Version from 3.9.5 to 4.1.1.
- Use the https protocol in the Vcs-Browser field.
- Update the URI referenced by the Vcs-Git field.
- Mark libexif-dev Multi-Arch: same (Closes: #786562).
  * debian/copyright:
- Update the format specification URI.
- Remove references to libjpeg/* and configure.in (lintian).
  * debian/patches:
- Add upstream patches to fix CVE-2016-6328 and CVE-2017-7544 
  (thanks to Marcus Meissner) (Closes: #873022, #876466).
  * debian/rules:
- Add 'hardening=+all' to DEB_BUILD_MAINT_OPTIONS.
- Exclude doxygen md5 files from installation (lintian).
- Remove '--with autoreconf' (now handled by debhelper level 10).
- Fix grammatical errors in a comment.
  * debian/source/lintian-overrides:
- Override 'unused-file-paragraph-in-dep5-copyright' warnings.

Regards,

Hugh McMaster

Bug#877047: RFS: sane-backends-extras/1.0.22.5 [QA]

[Hugh McMaster]

On Friday, 29 September 2017 5:37 AM, Herbert Fortes wrote:
> Uploaded. Thanks for you time.

Thank you, Herbert.

Kind regards,
Hugh

Bug#877047: RFS: sane-backends-extras/1.0.22.5 [QA]

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sane-backends-extras".

* Package name: sane-backends-extras
   Version: 1.0.22.5
   Upstream Author: SANE
* URL: http://www.sane-project.org/
* License: GPL v2
   Section: graphics

It builds the following binary packages:
  * libsane-extras - API library for scanners -- extra backends
  * libsane-extras-common - API library for scanners -- documentation and 
support files
  * libsane-extras-dev - API development library for scanners [development 
files]

To access further information about this package, please visit the following 
URL:
  https://mentors.debian.net/package/sane-backends-extras

Alternatively, you may download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends-extras/sane-backends-extras_1.0.22.5.dsc

Changes since the last upload:
  * QA upload.
  * debhelper update:
- Update package compatibility to level 10
  * debian/control:
- Bump debhelper build-dep to >= 10~.
- Remove autotools-dev from the Build-Depends list, as debhelper
  enables the 'autoreconf' sequence by default.
- Bump Standards-Version from 3.9.8 to 4.1.0 (no changes needed).
- Convert libsane-extras-common to Architecture: all.
- Mark libsane-extras-dev Multi-Arch: same (Closes: #862263).
  * debian/extras-backends/geniusvp2:
- Fix a spelling error in the BUGS file (lintian).
  * debian/rules:
- Remove '--with=autotools_dev' (now handled by debhelper level 10).
  * doc/sane-geniusvp2.man:
- Fix spelling errors (lintian).
  * Rename configure.in to configure.ac (lintian).

Regards,

Hugh McMaster