Re: Package EOL checklist

[Paul Wise]

On Tue, Feb 27, 2018 at 2:34 PM, Joseph Herlant wrote:

> Did I miss a step?

The first step when asking questions should always be to include
details so that we know what we are talking about.

> I have a package that is not maintained by upstream anymore and I was trying
> to find some sort of checklist on how to best manage its end of life.

What to do when a package is no longer maintained is highly dependent
on which software it is and the particular situation around it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#891429: RFS: urlwatch/2.8-1

[Paul Wise]

On Sun, Feb 25, 2018 at 10:34 PM, Maxime Werlen wrote:

> Cc: Paul Wise <p...@debian.org>

Please use X-Debbugs-CC to CC people when filing new bugs. This allows
the recipient to also find out about the bug number:

https://www.debian.org/Bugs/Reporting#xcc

> I am looking for a sponsor for my package "urlwatch"

Uploaded.

These additional issues would be nice to fix at some point:

Since the keyring module is only used by the urlwatch mailer plugin, I
think python3-keyring can be dropped to recommends:

https://bugs.debian.org/891456

Please upload a screenshot of typical first-time usage:

https://screenshots.debian.net/package/urlwatch

Please review and update the debtags:

https://debtags.debian.org/edit/urlwatch

Please check your binary .changes file with lintian from Debian
unstable before future RFS postings, two new lintian warnings were
added:

W: urlwatch source: spelling-error-in-patch-description
debian/patches/useEdiFStorBinaryIfPresent.diff attemps attempts
W: urlwatch source: spelling-error-in-patch-description
debian/patches/useEditorBinaryIfPresent.diff allow to allow one to

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#890203: RFS: gigalomania/1.0-1 [ITP]

[Paul Wise]

On Fri, Feb 16, 2018 at 3:34 AM, Jose G. López wrote:

> The package got rejected because I forgot to reference a copy of TinyXML.

Please ask upstream to remove the copy from their VCS and tarballs and
depend on it instead. If that does not work, please either repack the
tarball or ensure that the copy is removed before dh_auto_configure is
run.

https://wiki.debian.org/EmbeddedCodeCopies

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: GPLv3 source code with license check for some build configuration, DFSG ok?

[Paul Wise]

On Thu, Feb 15, 2018 at 8:29 AM, Thomas Preud'homme wrote:

> ultracopier's source code has a license check when built in ultimate mode.

What is the difference between ultimate mode and normal modes?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#887659: RFS: urlwatch/2.7-1 [ITA]

[Paul Wise]

On Fri, 2018-02-09 at 07:29 +0100, Maxime Werlen wrote:

> Thanks for your time reviewing my packages.

Thanks for adopting urlwatch!

> I've tried to fix as much issues as I'm capable.

There is only the blocker of ftp-masters accepting minidb now.

It would be nice to fix these extra issues at some point:

Upstream released 2.8 on 2018-01-28.

The upstream thpinfo.com website has a broken TLS certificate:

The certificate is only valid for thp.io
The certificate expired on 22/03/17 04:52.

I would suggest switching Debian copyright/control to thp.io
and or contacting upstream about fixing their TLS certificate.

I would suggest wrapping debian/watch between the URL and regex.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#887660: RFS: minidb/2.0.2-1 [ITP]

[Paul Wise]

On Fri, 2018-02-09 at 07:31 +0100, Maxime Werlen wrote:

> Thanks for your time reviewing this package.

Thanks for adopting urlwatch :)

> I've tried to fix as much issues as I'm capable.

Excellent.

Since you fixed the two blockers, I've uploaded it to NEW.

A few more things that might be nice to fix at some point:

The example file gets compressed in the package, I wonder if it would
be better for it to be uncompressed or not.

The ISC license in debian/copyright is missing the blank line that is
in minidb.py. Please note that blank lines are encoded in Debian
copyright as lines " ." (space followed by a dot and then newline).

I would wrap the watch file between the URL and regex too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: compiled binary file in source package

[Paul Wise]

On Fri, Feb 9, 2018 at 4:14 PM, Miroslav Kravec wrote:

> Could you please provide the name of the policy? I've just read it,
> and I haven't found one.

Debian Free Software Guidelines item 2:

https://www.debian.org/social_contract#guidelines

2. Source Code

The program must include source code, and must allow distribution in
source code as well as compiled form.

>  - Generated files, which is fine, as long as there's corresponding
> original form

In general, these should be removed from the upstream VCS and tarballs
and always built from the source.

Exceptions may apply, for example:

When the build takes a month or longer, but the build results should
ship in separate tarballs to source.

When the build requires specific hardware, but the build results
should ship in separate tarballs to source.

autotools, but packages should autoreconf. Personally, I would like to
autotools move to a model of shipping the autoreconf results in a
separate tarball.

>  - Source missing, which is fine too, because it's not missing, it's in 
> package

This isn't ideal because it usually results in static linking, which
means keeping track of when to rebuild the packages using the source,
which Debian does not yet do.

> I got interested in this, as I want to use a tool, which isn't
> packaged in debian. And upstream considers it to be a good idea to
> include tool's sources into project, where it's used. I like more
> clean solution - get the tool packaged into debian, then use the tool
> in my project.

That is a different scenario, it is an embedded code copy:

https://wiki.debian.org/EmbeddedCodeCopies

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: question about lintian overrides

[Paul Wise]

On Thu, Feb 1, 2018 at 7:47 AM, Elías Alejandro wrote:

> "Exec=env GDK_BACKEND=x11 uget-gtk %u"

I'm guessing this will break for users running apps under Wayland
instead of X11. I think it would be best to remove "env
GDK_BACKEND=x11" so that Wayland works and the lintian warning goes
away.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#888312: RFS: streamlink/0.10.0+dfsg-1

[Paul Wise]

On Thu, 2018-01-25 at 22:35 +0100, Alexis Murzeau wrote:

> Without this override, dh_installchangelogs uses "docs/changelog.rst"
> instead, which contains only an include statement and not the actual
> content (see diffoscope in attachment)
> 
> According to its sources, dh_installchangelogs iterates ".", "doc/",
> "docs/" directories in this order and takes the last found. Only if
> there are several matches in a given directory, it takes the first
> one found in that directory.

I see, thanks for the explanation. Seems I misread the code :)

> I've added a comment about that on top of
> override_dh_installchangelogs.

Great.

> Do you think there is something better to do here ?

Maybe debhelper could be smarter about not choosing tiny changelog
files over larger files, but you would still need the override for
older suites.

If it doesn't already, it would be a good idea for lintian to check
that the upstream changelog file is a sane one; it should have a
version number in it and not be too tiny.

If you would like to do some more research and file bugs for these,
that would be appreciated.

> The python3-iso3166 package is indeed available, the missing one is
> iso639 which I miss-written. When not using pycountry, streamlink
> need both iso3166 and iso639 python packages.
> I updated the comment with python3-iso639 instead of python3-iso3166.

I see, great.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#888312: RFS: streamlink/0.10.0+dfsg-1

[Paul Wise]

On Thu, Jan 25, 2018 at 5:26 AM, Alexis Murzeau wrote:

> I am looking for a sponsor for my package "streamlink" for a new
> upstream version 0.10.0.

Uploaded.

Some things that would be nice to fix at some point:

I'm surprised override_dh_installchangelogs is needed, the code seems
like it would match CHANGELOG.rst. Please build the package twice,
once with it and once without and then diffoscope the resulting binary
packages.

There is an incorrect statement in debian/rules, Debian has the
python3-iso3166 package.

Some grammar fixes for debian/rules:

s/need to have/needs to have/
s/Debian have/Debian has/

In future, I would suggest not mentioning check-all-the-things (or
lintian) in debian/changelog and instead mention what was fixed.

I would suggest using this as the donation link, since it won't go out
of date if they switch away from OpenCollective. It also mentions
Bountysource and individual team member donations.

https://streamlink.github.io/donate.html

I saw in the upstream code that they are manually building some URLs
with string concatenation. I think it would be much better to use a
URL class that knows how to encode parameters etc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#887660: RFS: minidb/2.0.2-1 [ITP]

[Paul Wise]

Control: owner -1 !
Control: tags -1 + moreinfo

I intend to sponsor this because the urlwatch RFS needs it.

On Fri, Jan 19, 2018 at 4:42 AM, Maxime Werlen wrote:

> I am looking for a sponsor for my package "minidb"

In future, I'd recommend using the BTS block command when filing an RFS
that depends on another RFS.

https://www.debian.org/Bugs/server-control#block

You can use this syntax when mailing submit@ or existing bugs (-1 means
the bug you are mailing or submitting):

Control: block 887659 by -1

These issues block the upload of minidb to Debian:

Since minidb only includes a Python 3 module, you need to rename the
binary package to python3-minidb. The source package can stay the same.

The orig.tar.gz you uploaded to Debian mentors is different to the one
that the debian/watch file downloads. You can use diffoscope to see the
differences, but it looks like you used the one from pip? That is
missing example.py but has a new PKG-INFO file.

It would be nice to fix these issues at some point:

Upstream is using distutils but debian/control has python3-setuptools.
The package still builds because python3-distutils is installed anyway.

Please include example.py from the github tar.gz as an example in the
binary package, using dh_installexamples.

Once minidb is accepted, please file a bug against gpodder asking the
maintainer to depend on minidb instead of using the internal copy.

I suggest licensing the debian/ directory under the same license as
upstream, so that they can include any patches or other info from
Debian with zero friction.

Please remove the comment characters, the ASCII minidb logo and the
Copyright line from the ISC license in debian/copyright.

Please remove the commented-out Vcs-* fields from debian/control unless
you intend to use them, please note that alioth has been replaced by
salsa.debian.org.

I like to wrap and sort the debian/ directory:

wrap-and-sort --short-indent --wrap-always --sort-binary-packages 
--trailing-comma

I like to wrap debian/watch to separate fields.

uscan fails unless I delete the filenamemangle:

$ uscan --verbose --download-current-version --destdir .
...
Could not read .//thp/minidb/archive/minidb-2.0.2.tar.gz: No such file or 
directory at /usr/bin/mk-origtargz line 397.
uscan: error: mk-origtargz --package minidb --version 2.0.2 --rename 
--compression gzip --directory . --copyright-file debian/copyright 
.//thp/minidb/archive/minidb-2.0.2.tar.gz subprocess returned exit status 2

Please add some upstream metadata:

https://wiki.debian.org/UpstreamMetadata

Please ask upstream to sign their commits and tarballs with OpenPGP:

https://mikegerwitz.com/papers/git-horror-story
https://wiki.debian.org/Creating%20signed%20GitHub%20releases

Automatic checks:

lintian

I: minidb source: binary-control-field-duplicates-source field "section" in 
package minidb
P: minidb source: file-contains-trailing-whitespace debian/changelog (line 3)
P: minidb source: file-contains-trailing-whitespace debian/control (line 4)
P: minidb source: package-uses-old-debhelper-compat-version 10
P: minidb source: insecure-copyright-format-uri 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
I: minidb source: testsuite-autopkgtest-missing
P: minidb source: debian-watch-may-check-gpg-signature
P: minidb: no-upstream-changelog
I: minidb: extended-description-is-probably-too-short

check-all-the-things

$ env PERL5OPT=-m-lib=. duck
I: debian/copyright:1: URL: 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/: INFORMATION 
(Certainty:possible)
   URL schema changed from HTTP to HTTPS during redirect(s): 
http://www.debian.org -> https://www.debian.org
   Please investigate and update the URL eventually, to avoid unneccesary 
redirects!

I: debian/copyright:48: URL: http://www.gnu.org/licenses/: INFORMATION 
(Certainty:possible)
   The web page at http://www.gnu.org/licenses/ works, but is also available 
via https://www.gnu.org/licenses/, please consider switching to HTTPS urls.

I: debian/control: Homepage: http://thp.io/2010/minidb/: INFORMATION 
(Certainty:certain)
   URL schema changed from HTTP to HTTPS during redirect(s): http://thp.io -> 
https://thp.io
   Please investigate and update the URL eventually, to avoid unneccesary 
redirects!

# check if these can be switched to https://
$ grep -nHrF http: .
./PKG-INFO:5:Home-page: http://thp.io/2010/minidb/
./PKG-INFO:9:Download-URL: http://thp.io/2010/minidb/minidb-2.0.2.tar.gz
./test/test_minidb.py:277:# 
http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ever
./debian/copyright:1:Format: 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
./debian/copyright:48: along with this program. If not, see 

./debian/control:9:Homepage: http://thp.io/2010/minidb/
./debian/control:11:#Vcs-Browser: 
http://git.debian.org/?p=collab-maint/minidb.git;a=summary
./minidb.py:27:__url__ = 'http://thp.io/2010/minidb/'

$ find . -type f -iname '*.py' 

Bug#887659: RFS: urlwatch/2.7-1 [ITA]

[Paul Wise]

Control: owner -1 !
Control: tags -1 + moreinfo

I intend to sponsor this.

On Thu, 18 Jan 2018 21:42:33 +0100 Maxime Werlen wrote:

> I am looking for a sponsor for my package "urlwatch"

These issues block the upload of this package:

The package FTBFS in a clean chroot, you need to package minidb and
build-depend on python3-minidb, python3-setuptools, python3-keyring,
python3-appdirs and python3-requests.

https://wiki.debian.org/pbuilder

It would be nice to fix these issues at some point:

When you package minidb, if possible, please also make a python-minidb
package so that you can report a bug against gpodder to get it to use
the system minidb as it currently includes a minidb copy.

I would suggest stripping the DEPENDENCIES section from README.md in
the installed binary package since users of the binary package will
already automatically get the dependencies installed.

I would suggest adding a NEWS.Debian about migrating from the legacy
hooks to the new class-based filter system.

debian/copyright has an incorrect copyright year for the upstream code,
 upstream mentions 2016 but debian/copyright has 2018.

debian/copyright should have BSD-3-Clause rather than BSD-3-Clause.

debian/clean can probably be reduced to one line:

lib/urlwatch.egg-info/

I like to wrap and sort the debian directory:

wrap-and-sort --short-indent --wrap-always --sort-binary-packages 
--trailing-comma

I like to wrap debian/watch to separate fields:

version=3
opts="filenamemangle=s/(\d[\d\.]*)\.tar\.gz/urlwatch-$1.tar.gz/" \
https://github.com/thp/urlwatch/releases \
(?:.*/)?v?(\d[\d\.]*)\.tar\.gz

uscan fails unless I delete the debian/watch opts:

$ uscan --verbose --download-current-version --destdir . 
...
uscan info: Executing internal command:
   mk-origtargz --package urlwatch --version 2.7 --rename --compression gzip 
--directory . --copyright-file debian/copyright 
.//thp/urlwatch/archive/urlwatch-2.7.tar.gz
Could not read .//thp/urlwatch/archive/urlwatch-2.7.tar.gz: No such file or 
directory at /usr/bin/mk-origtargz line 397.
uscan: error: mk-origtargz --package urlwatch --version 2.7 --rename 
--compression gzip --directory . --copyright-file debian/copyright 
.//thp/urlwatch/archive/urlwatch-2.7.tar.gz subprocess returned exit status 2

Please add some upstream metadata:

https://wiki.debian.org/UpstreamMetadata

Please ask upstream to sign their commits and tarballs with OpenPGP:

https://mikegerwitz.com/papers/git-horror-story
https://wiki.debian.org/Creating%20signed%20GitHub%20releases

Upstream should give a warning when the legacy hooks are being used.

Upstream is storing a cache file in the xdg config directory, I suggest
that they probably need to read the specs and fix the code/docs:

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

examples_path.diff is still present in the source package but is not
present in the series file. IMO it should either get deleted or still
be present in the series file, possibly commented out and with a reason
for being disabled in a comment before that.

Automatic checks:

lintian

P: urlwatch source: file-contains-trailing-whitespace debian/changelog (line 5)
P: urlwatch source: file-contains-trailing-whitespace debian/control (line 5)
P: urlwatch source: file-contains-trailing-whitespace debian/control (line 21)
P: urlwatch source: file-contains-trailing-whitespace debian/rules (line 7)
P: urlwatch source: package-uses-old-debhelper-compat-version 10
P: urlwatch source: insecure-copyright-format-uri 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
I: urlwatch source: testsuite-autopkgtest-missing
P: urlwatch source: debian-watch-may-check-gpg-signature

build

/usr/lib/python3.6/distutils/dist.py:261: UserWarning: Unknown distribution 
option: 'copyright'

check-all-the-things

$ find .. -maxdepth 1 -type f -iwholename '../*.build' -exec grep -nHw E {} +
../urlwatch_2.7-1_amd64.build:375:E: pybuild pybuild:283: clean: plugin 
distutils failed with: exit code=1: python3.6 setup.py clean 

$ find .. -maxdepth 1 -type f -iwholename '../*.build' -exec grep -nHi error {} 
+
../urlwatch_2.7-1_amd64.build:374:ModuleNotFoundError: No module named 
'setuptools'
../urlwatch_2.7-1_amd64.build:378:make: *** [clean] Error 25
../urlwatch_2.7-1_amd64.build:379:dpkg-buildpackage: error: fakeroot 
debian/rules clean subprocess returned exit status 2

$ find .. -maxdepth 1 -type f -iwholename '../*.build' -exec grep -nHi warn {} +
../urlwatch_2.7-1_amd64.build:6:/usr/lib/python3.6/distutils/dist.py:261: 
UserWarning: Unknown distribution option: 'copyright'
../urlwatch_2.7-1_amd64.build:7:  warnings.warn(msg)

$ env PERL5OPT=-m-lib=. cme check dpkg
Warning in 'control source Standards-Version' value '4.1.3': Current standards 
version is '4.1.1'. Please read 
file:///usr/share/doc/debian-policy/upgrading-checklist.txt.gz to check what 
changes need to applied to your package to upgrade it from standard version 
'4.1.3' to '4.1.1'.

Re: ITA: pygithub/1.35-1

[Paul Wise]

On Sat, 2018-01-13 at 21:37 -0300, eamanu15 . wrote:

> I will send again the mail with the correct data. 

No need to do that.

> this is the only change that I have to make??

No idea, I didn't review the package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: ITA: pygithub/1.35-1

[Paul Wise]

On Sat, Jan 13, 2018 at 11:48 PM, Emmanuel Arias wrote:

> Source: https://pypi.python.org/pypi/PyGithub
>   Upstream Author : Emmanuel Arias 

This is incorrect, please do not claim authorship of code you did not write.

https://github.com/orgs/PyGithub/people
https://github.com/PyGithub/PyGithub/blob/master/MAINTAINERS

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Splitting source package into two

[Paul Wise]

On Thu, Jan 11, 2018 at 3:45 PM, Ole Streicher wrote:

> Recently, upstream announced a new version 3.0 of astropy, which
> supports Python 3 only, and I want to have a smooth migration path. I
> thought of a temporary package split: create a new source package
> "astropy" that inherits of the current python-astropy package, but only
> builds python3-astropy (and the utils + doc, which depend on
> python3-astropy), and update this to version 3.0. Then I would remove
> these binary packages from the python-astropy package.

Sounds like a good plan to me, especially since the upstream project
is 'astropy'.

> The question is now: what I have to do in which order to do that? When I
> upload a new "astropy" package, it offers the same Python 3 package as
> the (still existing) python-astropy package, but with a higher
> version. Is this a problem? Or need I to upload an updated
> python-astropy package (with the Python 3 content removed) first?

I think you should upload src:astropy taking over the python3-astropy
package before uploading src:python-astropy to drop python3-astropy.
This way you avoid making the reverse dependencies temporarily
uninstallable. I think you still need a trip through NEW for the new
src:astropy package though. After src:astropy is accepted, there will
be two versions of python3-astropy in unstable. I believe the
python3-astropy from src:python-astropy will get removed by the
automated decrufting process, once you drop it from the
src:python-astropy package.

> How should one then handle their reverse dependencies?

With the above plan, this is basically almost the same as a normal
Python API transition. You will need to ensure that the reverse deps
don't unconditionally use any of the removed APIs and are compatible
with any of the changed APIs, if there are any of either.

https://wiki.debian.org/Teams/ReleaseTeam/Transitions

BTW, if you are in contact with upstream, TLS on their domain seems a bit buggy.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Dependencies across architectures

[Paul Wise]

On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:

> Unfortunately, this is impossible: the assembler code creates a kind of
> sigsetjmp() (with its own calling interface) for Fortran 77. This cannot
> be simply remodelled in C. In principle, one could re-implement this
> with the libunwind library (see [1]), but since glibc scrambles stack
> information since some time, this does not work anymore.

Ok. I've mentioned it on #debian-ports, perhaps you'll get some help.

> Upstream is difficult for this package: the package has no new upstream
> version since five years and the communication is difficult.

Hmm, that sounds annoying.

> ... therefore I decided to create a temporary fork ...

Watch out, you could end up being the new upstream :)

> If we take Multi-Arch serious, this shouldn't be the case, right?

I guess the release team might accept patches to britney for this but
I've also a vague memory that they prefer arches to be self-contained.

> which is what I pargmatically did now (#886524). I was however not sure
> what the optimal way is, since I also don't know which architectures are
> co-runnable in practice. Theoretically, one could do anything with
> qemu-userland, however.

You can use arch-test to find out which arches a specific system can run.

I guess qemu-user can't run all arches though, like kFreeBSD.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Dependencies across architectures

[Paul Wise]

On Sat, Jan 6, 2018 at 5:43 PM, Ole Streicher wrote:

> "iraf" exists only on selected architectures due to some required
> assembler code for each arch and problems with big endian.

There could be a fallback in C for arches with no assembler yet
and any non-baseline instructions should be detected at runtime.
Upstream should fix the code to deal with endianness correctly.
Please file bugs upstream about these if you didn't already.

> From the description of "Multi-Arch: foreign" I would expect that this
> allows the dependency resolved by using another architecture. However,
> piuparts (and the migration excuses) claim a missing dependency on the
> archs not supported by IRAF.

piuparts.d.o only tests amd64 at this stage, could you quote the error
piuparts gives for you on other arches? I'm guessing you didn't add
the foreign architecture to the chroot that piuparts was using for
testing.

I'm pretty sure the testing migration doesn't support
cross-architecture dependencies, but the release team will hint things
into testing where that is the only thing blocking migration.

> My first thought was to limit the possible archs for python3-pyraf (by
> explicitly setting the arch list and/or build-depending on iraf), but
> this would not require the removal of the packages already build.

Looks like you already tried this option, to get it to work you will
have to ask the ftp-team to remove the obsolete binaries on the arches
where pyraf no longer builds.

https://qa.debian.org/excuses.php?package=pyraf

> And, in principle the dependency should work across archs (f.e. for
> x32). But why does it not work with the specification above?

It will work, but only in dpkg/apt.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Built-Using usage question

[Paul Wise]

On Sat, Dec 30, 2017 at 10:49 PM, Lukas Schwaighofer wrote:

> I read the update in policy 4.1.3 and I'm not sure how to handle the
> change / clarification of the Built-Using control field for the
> syslinux package (which I maintain in the debian-cd team).

I suggest you ask this question on the debian-policy list.

Personally, I feel this change to policy is a mistake.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#878268: RFS: streamlink/0.9.0-1 [ITP]

[Paul Wise]

On Sun, 2017-12-31 at 02:28 +0100, Alexis Murzeau wrote:

> The upload failed because the orig tarball was not included maybe
> because its -3 ?

Right, I forgot to include the orig tarball manually. Done now.

> The changes since version 0.8.1-2 should be included too I guess as this
> one has the Closes on the ITP.

Yeah, I remembered to do that one :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#878268: RFS: streamlink/0.9.0-1 [ITP]

[Paul Wise]

On Sat, 2017-12-30 at 22:04 +0100, Alexis Murzeau wrote:

> https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.9.0+dfsg.2-3.dsc

Uploaded to NEW, thanks a lot for your contribution, it saved me from
having yet another package removed from Debian on my system :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#878268: RFS: streamlink/0.9.0-1 [ITP]

[Paul Wise]

On Fri, Dec 29, 2017 at 7:54 PM, Alexis Murzeau wrote:

> Yes I will do that and consider check-all-the-things to be run at each
> version.

Ok, great. I'm also interested in any feedback you have on the tool.

> Indeed my bad. Also, the package got rejected because of a higher
> version in stable for the package livestreamer.
>
> Does the way to handle that is to add an epoch version, so it become
> 1:0.9.0~dfsg.2-2 ?

No, I would suggest to set the binary package version for livestreamer
only, that way you can drop the transitional package after buster
without having to keep the epoch around forever. You can set the
binary package version by passing the -v option to dpkg-gencontrol via
dh_gencontrol:

include /usr/share/dpkg/pkg-info.mk

override_dh_gencontrol:
dh_gencontrol -plivestreamer -- -v1.12.2+streamlink+$(DEB_VERSION)
dh_gencontrol --remaining-packages

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#878268: RFS: streamlink/0.9.0-1 [ITP]

[Paul Wise]

On Fri, Dec 29, 2017 at 9:43 AM, Alexis Murzeau wrote:

> https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.9.0+dfsg.2-1.dsc

Uploaded to NEW.

https://ftp-master.debian.org/new.html

For future uploads, please file an RFS bug as usual.

Please consider working through the other issues I mentioned as you
find time. Most of what I mentioned can just be forwarded to upstream
issues, I guess they would welcome patches if you have the time
though.

> In uploaded version, I've added a transitional package for livestreamer
> as they are compatible.

You have not included a livestreamer symlink in /usr/bin, please
address that in your next upload.

> You mean, so that `debian/streamlink.links` and
> `debian/streamlink.manpages` can be removed ?

Right.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#861011: RFS: qt5ct/0.31-2 [ITP]

[Paul Wise]

On Wed, Dec 27, 2017 at 5:25 AM, Tobias Frost wrote:

> - do not install AUTHORS. This information should be visible in
> d/copyright already.

The authors of a piece of software are not always the same as the
copyright holders of that software. There are various things that can
cause this, including employment law, employment contracts, commercial
copyright transfer, copyright donations etc. I would suggest
installing AUTHORS too, so the people who actually wrote the code also
get credit.

> however, those are small problems, so I've uploaded it.

Please also see my review earlier in the RFS bug report.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#884816: RFS: frontaccounting/2.4.3-1 [ITA]

[Paul Wise]

On Thu, 2017-12-21 at 23:51 +0100, Janusz Dobrowolski wrote:

> Taking into account the package is not part of any debian repo, can I
> just update the version published on my mentors.debian.net account
> without version change, or should I update package version to 2.4.3-2
> before upload?

You can overwrite versions on the mentors website.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#884816: RFS: frontaccounting/2.4.3-1 [ITA]

[Paul Wise]

On Wed, Dec 20, 2017 at 6:57 AM, Janusz Dobrowolski wrote:

>   This package was recently included in wheezy, but seems later was
> orphaned sometime back in 2013, and currently is absent from debian
> repositories. Now it is refreshed, and as one of upstream developers I'm
> ready to maintain it under kind supervision of some sponsor.

Please note the extra steps required when reintroducing removed packages:

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#878268: RFS: streamlink/0.9.0-1 [ITP]

[Paul Wise]

On Thu, Nov 23, 2017 at 5:41 AM, Alexis Murzeau wrote:

> https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.9.0-1.dsc

Here is a review:

These issues need to be resolved before upload:

I think docs/_static/flattr-badge.png is probably non-free. Upstream
stopped using a while ago so it should just get removed from their
repository and the Debian tarball.

These issues would be nice to fix at some point:

There has been a new Debian Policy version since your upload.

Please add some upstream metadata:

https://wiki.debian.org/UpstreamMetadata

Personally, I would drop the last paragraph of the description, or
possibly just the first sentence of the last paragraph of the
description.

It would be nice to have a transitional package that also contains a
symlink to the new name for the binary (assuming that they are
command-line compatible), so that external wrappers for livestreamer
still work with streamlink.

For use_debian_fonts, please note that Roboto Slab is now available in Debian.

Please note that python3-iso3166 is now available in Debian, so you
can switch back to the default.

Please note that python3-pycryptodome is now available in Debian, so
you can switch back to the default.

I'd suggest dropping the override_dh_builddeb for Debian.

It would be nice if the upstream build system would also install the
manual pages and binary in /usr/bin, you might want to send them a
patch.

Automatic checks:

check-all-the-things:

$ codespell --quiet-level=3 .


$ env PERL5OPT=-m-lib=. duck
...
I: debian/copyright:90: URL:
http://www.apache.org/licenses/LICENSE-2.0: INFORMATION
(Certainty:possible)
   The web page at http://www.apache.org/licenses/LICENSE-2.0 works,
but is also available via https://www.apache.org/licenses/LICENSE-2.0,
please consider switching to HTTPS urls.

I: debian/copyright:102: URL: http://scripts.sil.org/OFL: INFORMATION
(Certainty:possible)
   The web page at http://scripts.sil.org/OFL works, but is also
available via https://scripts.sil.org/OFL, please consider switching
to HTTPS urls.

$ find . -type f \( -iname '*.ttf' -o -iname '*.otf' -o -iname '*.sfd'
-o -iname '*.pfa' -o -iname '*.pfb' -o -iname '*.bdf' -o -iname '*.pk'
-o -iname '*.ttc' -o -iname '*.pcf' \) -exec
check-font-embedding-restrictions {} +
These fonts in Debian main/contrib have embedding
restrictions, which are not DFSG compatible:

./docs/_themes/sphinx_rtd_theme_violet/static/fonts/FontAwesome.otf: 0x0004
./docs/_themes/sphinx_rtd_theme_violet/static/fonts/fontawesome-webfont.ttf:
0x0004

https://www.microsoft.com/typography/otspec/os2.htm#fst

$ find . -type f \( -iname '*.ttf' -o -iname '*.otf' -o -iname
'*.woff' -o -iname '*.sfd' -o -iname '*.pfa' -o -iname '*.pfb' -o
-iname '*.bdf' -o -iname '*.pk' -o -iname '*.ttc' -o -iname '*.pcf' \)
-exec fontlint {} \;


# If you contact the owners of these keys, please point out OpenPGP
best practices:
# https://help.riseup.net/en/security/message-security/openpgp/best-practices
$ find . -type f -iname '*.asc' -exec cat {} + | hot dearmor | hokey lint
...
Checking user-ID- and user-attribute-related items:
  Charlie Drage :
Self-sig hash algorithms: [SHA-1]
...
Checking subkeys:
...
  fpr: CDEE D514 4E91 E633 6D0B  59CC 2523 80C9 D3E8 71F7
...
binding sig hash algorithms: [SHA-1]
...
cross-cert hash algorithms: [SHA-1]

# check if these can be switched to https://
$ grep -nHrF http: .


$ find . -type f -iname '*.py' -exec mypy {} +


# This command checks style. While a consistent style
# is a good idea, people who have different style
# preferences will want to ignore some of the output.
# Do not bother adding non-upstreamable patches for this.
$ proselint .


# This command checks style. While a consistent style
# is a good idea, people who have different style
# preferences will want to ignore some of the output.
# Do not bother adding non-upstreamable patches for this.
$ find . -type f -iname '*.py' -exec pycodestyle --ignore W191 {} +


# This command checks style. While a consistent style
# is a good idea, people who have different style
# preferences will want to ignore some of the output.
# Do not bother adding non-upstreamable patches for this.
$ pydocstyle .


$ find . -type f -iname '*.py' -exec pyflakes {} +
$ find . -type f -iname '*.py' -exec pyflakes3 {} +


$ find . -type f -iname '*.py' -exec pylint --rcfile=/dev/null
--msg-template='{path}:{line}:{column}: [{category}:{symbol}] {obj}:
{msg}' --reports=n {} +
$ find . -type f -iname '*.py' -exec pylint3 --rcfile=/dev/null
--msg-template='{path}:{line}:{column}: [{category}:{symbol}] {obj}:
{msg}' --reports=n {} +


$ python2-bandit -r .
$ python3-bandit -r .


$ vulture .


$ find . -type d \( -iname .bzr -o -iname .git -o -iname .hg -o -iname
.svn -o -iname CVS -o -iname RCS -o -iname SCCS -o -iname _MTN -o
-iname _darcs -o -iname .pc -o -iname .cabal-sandbox -o -iname .cdv -o
-iname .metadata -o -iname CMakeFiles -o -iname _build -o 

Bug#883611:

[Paul Wise]

On Wed, Dec 6, 2017 at 6:12 PM, Paolo Gigante wrote:

> As per the ITP (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880600)
> there is a lot of additional functionality that auter provides which goes
> way beyond what is offered by cron-apt and unattended-upgrades:

A comment on the ITP features:

> This allows servers to be configured to stop any critical
> applications cleanly using custom scripts before any actions are taken.

Critical applications should be cleanly integrated with the system so
that normal shutdown/reboot does the right thing.

> - Auter has the functionality to separate download schedules from install
> schedules which is great for organisations wanting to version control
> updates across multiple servers and environments while staggering the update
> process for the servers.

This is also supported by unattended-upgrades under systemd.

> - It also allows for customised scripts to be executed pre and post
> downloading updates, applying updates and rebooting the server

This is also supported by apt, except reboot hooks but those should
probably be integrated into the init system instead.

> - It has the option to automate reboots after the patching process has been
> applied

This is also supported by unattended-upgrades, including a set reboot time.

> - There is an option of setting up multiple patching profiles eg: weekly
> application patches and monthly system/kernel patching (This is entirely
> customiseable)

In theory this could be possible with unattended-upgrades but I think
it would be hard to setup.

> - In cases where admins have multiple servers with different rehdat or
> debian based distributions, the same application and configuration files can
> be deployed to servers regardless of the distribution.

That seems like a plus for those stuck in that situation indeed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#883611: RFS: auter/0.11 (ITP: Bug#880600)

[Paul Wise]

On Wed, Dec 6, 2017 at 1:54 AM, Paolo Gigante wrote:

>   auter - Automatic updates for Redhat and Debian based Linux servers

Please compare and contrast auter with the other packages in Debian
for this task: unattended-upgrades cron-apt packagekit

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Re-Uploading to mentors.debian.net

[Paul Wise]

On Fri, Dec 1, 2017 at 7:46 PM, Sascha Manns wrote:

> Now i have fixed these things, and built a new package version. Should
> i delete the old package before uploading the new package version?

IIRC, reuploading will replace the older version.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: orphaned open-cobol package should be replaced with new gnucobol package

[Paul Wise]

On Sun, Nov 26, 2017 at 11:24 PM, Simon Sobisch wrote:

> I'd like to know if there's something the GnuCOBOL project can do to
> allow the orphaned open-cobol package to be replaced with a new gnucobol
> package and provide updates for it.

I would suggest starting with the existing open-cobol packaging,
upgrading to the latest gnucobol release and renaming the packages to
gnucobol and adding an open-cobol transitional binary package.

https://tracker.debian.org/pkg/open-cobol
https://wiki.debian.org/RenamingPackages
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#s5.9.3

The commands to do this would be something like this:

sudo apt install devscripts build-essential pbuilder
apt source open-cobol
cd open-cobol*/
$EDITOR debian/watch
# Change things to the new location
uscan --verbose
uupdate ../open-cobol_2.2.orig.tar.xz
cd ../
rename 's{open-cobol}{gnucobol}' *cobol*2.2*
cd gnucobol*/
find debian/ -iname *open-cobol* | xargs rename 's{open-cobol}{gnucobol}'
grep -ril open-cobol debian/ | grep -v debian/changelog | grep -v
debian/patches | xargs sed -i 's/open-cobol/gnucobol/'
sed '1s/open-cobol/gnucobol/' debian/changelog
dch '  - Using renamed GNU Cobol upstream project'
dch '- Rename Debian package, add transitional package'
$EDITOR debian/control
pdebuild

Once you have created a new package based on the old one, you can
search for a sponsor, see the link below.

> Note: The package currently has a dependency on libdb, *if* this should
> not be kept for the new package the dependency could be removed (there
> are currently no debian packages for other libraries which can be used
> as a replacement, therefore a part of the GnuCOBOL runtime would be
> disabled [configure option --without-db]).

Debian has libdb 5.3 available:

https://packages.debian.org/source/sid/db5.3

> If this would help I'm willing to do package work, too - but this would
> need a mentor as I've packaged different software for different package
> managers already, but not for debian.

Please read through this intro:

https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: How to package support libraries for Tilde

[Paul Wise]

On Wed, Nov 15, 2017 at 5:03 PM, Gertjan Halkes wrote:

> My question is: how do I go about packaging them? Do I package each library
> separately, and if so, do I file ITP bugs for each of them? If, on the other
> hand, I am to package everything into a single 'tilde' package, how would I
> do the versioning?

Package them separately and file ITP bugs for each.

I can see these libraries being useful for other projects too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#862114: Bug#862115: RFS: xe/0.8-1 (ITP, #862114) & lr/0.4-1 (ITP, #862115)

[Paul Wise]

On Mon, 2017-10-30 at 15:01 +0100, Nicolas Braud-Santoni wrote:

> Oh, I didn't realise this wasn't a person  :O

Yeah, it probably should migrate to mentors and a more obvious sender address.

> I guess the obvious solution is for me to become a DD and sponsor uploads  :P

That would definitely help, I wish you the best of luck towards that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#862114: Bug#862115: RFS: xe/0.8-1 (ITP, #862114) & lr/0.4-1 (ITP, #862115)

[Paul Wise]

On Mon, Oct 30, 2017 at 9:45 PM, Nicolas Braud-Santoni wrote:

> This RFS is a pretty good example: there was no new upstream version, and
> no review (or any sort of activity on the RFS) since June, while the timeout
> on mentors.debian.net is only 20 days.

The best you can do in that situation is bump the changelog date and reupload.

> I appreciate that Bart was likely trying to triage RFSes, but closing it
> rather than asking to reupload to mentors.d.n feels somewhat unfriendly,
> especially when the packaging repo is available, and up-to-date, on alioth.

That is a cron job that syncs the state of RFSes with the archive and
mentors. The maintainer of the cron job is fairly MIA, so I'm not sure
it will change any time soon.

> Note that I'm not mentionning that to complain or vent, but to report a
> problem that I'm encountering, as a non-DD contributor, in the hopes that
> it might be possible to fix it rather than let it affect other people.

Given the current general package sponsorship resources don't appear
to be increasing much year on year, I doubt it will ever be possible
for Debian to accept all proposed packages in a timely manner, sorry.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#862115: RFS: xe/0.8-1 (ITP, #862114) & lr/0.4-1 (ITP, #862115)

[Paul Wise]

On Sat, Oct 28, 2017 at 5:38 PM, Nicolas Braud-Santoni wrote:

> As an aside, I find it very weird to close a RFS due to
> the inactivity of would-be sponsors: from the packager's
> side, it feels like a double punishment (getting ignored,
> then getting your RFS closed because you got ignored)...

Even if you haven't got a sponsor yet, RFS submitters should still be
maintaining the packages as they would if they were in the archive.
That means updating to new upstreams, fixing any review comments,
checking with new versions of lintian, running static analysis tools
and fixing issues etc. Those updates should prevent you from ever
hitting the inactivity timeout on mentors. If you really have nothing
to do, you could still bump the changelog and RFS every now and then,
while also spending some more time looking for sponsors.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#869692: RFS: cyclograph/1.9.1-1

[Paul Wise]

On Sat, Oct 14, 2017 at 4:46 AM, Federico Brega wrote:

> Is my proposal of adding a lintian override Ok?

lintian is only for the situation where it the lintian complaint is
not true. In this case, the problem is present so you should not
override it. If you intend to ignore this problem, just ignore the
lintian complaint, do not override it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Help with watchfile to Gitlab clone needed (Was: Source code of altree vanished)

[Paul Wise]

On Fri, Oct 6, 2017 at 6:50 PM, Andreas Tille wrote:

> Any hint how to fix this?

If you run uscan with --debug (or look at the HTML) you can see that
the URLs are domain absolute rather than relative, so you need to
either add /NGS/ALTree/ or .*/ to the repository regex:

version=4
https://gitlab.inria.fr/NGS/ALTree/tags \
.*/repository/v@ANY_VERSION@/archive\.tar\.gz

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#877296: Subject: RFS: dokuwiki-sync/0.1 ITP

[Paul Wise]

On Sat, Sep 30, 2017 at 6:30 PM, Andrew Worsley wrote:

> This is just a small shell script I have used from time to time - I am
> not sure how usable it is for others and it is mostly to get practise
> of packaging and getting feedback. So please feel free to comment on
> what might be a better tool or way to handle the task of synchronising
> two wiki'd (dokuwiki based in this case only).

Maybe this should get added to docuwiki upstream instead?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian Mentor

[Paul Wise]

On Mon, Aug 14, 2017 at 6:13 AM, Francois Gez wrote:

> I am honored to be in this list for so many years! Does it mean that I am a
> mentor and I did not know? I was be delighted to be of any help here.

This is the first mail from you on the debian-mentors list, I think to
be considered a mentor, one should have replied to some questions from
folks contacting the list.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: pypi.debian.net sending a 502 bad gateway

[Paul Wise]

On Sat, Aug 12, 2017 at 7:45 PM, Joseph Herlant wrote:

> https://pypi.debian.net/* sends back a  "502 Bad Gateway

I'd suggest contacting the maintainer of that service:

$ host -t txt pypi.debian.net | head -n1
pypi.debian.net descriptive text "Piotr O\197\188arowski "
$ finger pi...@db.debian.org | grep Email
Email: Piotr Ożarowski 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Replace cron with systemd timer unit?

[Paul Wise]

On Thu, Aug 3, 2017 at 9:19 PM, Ben Finney wrote:

> If the cron job is removed – necessarily entailed by “replace it”,
> surely? – then how can they continue to use it after it is replaced by
> something else?

I would discourage removal of the cron job, but it could still be
replaced by a systemd timer when running under systemd, without
removing the cron job, so machines running sysvinit+cron can work the
same.

The example I gave of apt has a cron job script that exits quickly
when run under systemd and for sysvinit it reimplements the features
of systemd that the apt systemd timer uses (require AC power,
randomise start time) and then calls the same script that the apt
systemd service uses.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Replace cron with systemd timer unit?

[Paul Wise]

On Thu, Aug 3, 2017 at 1:53 PM, Ben Hildred wrote:

> You do realise that there are people who do not run systemd?

They can use the cron job as usual.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Replace cron with systemd timer unit?

[Paul Wise]

On Thu, Aug 3, 2017 at 1:20 PM, Ricardo Fraile wrote:

> I like some aspects of the .timer, but I don't know if the change is a good
> idea or not at this moment? There are any other package that has changed
> from cron to .timer? What is the official recomendation?

One significant difference between the two is that all cron output is
sent via email, while output from systemd timers is not sent via
email. There is no official recommendation here, but other packages
have migrated from cron to systemd timers, with fallback to cron when
systemd is not running. You can see the apt package for an example and
there is also systemd-cron, which can be used to generate systemd
timers from cron jobs, the results are placed in the
/run/systemd/generator directory at boot time.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Linitian orig-tarball-missing-upstream-signature

[Paul Wise]

On Mon, Jul 31, 2017 at 5:41 AM, Christian Seiler wrote:
> On 07/31/2017 11:34 AM, Andrey Rahmatullin wrote:
>> uscan isn't used, or needed, in the git-only workflow at all.
>
> In purely git workflows (that pull remote git tags), sure, but
> then you'd not have debian/watch

That isn't necessarily true, since uscan now supports searching git
remotes for the latest tag. So you could have debian/watch (and
potentially an upstream signing keyring for verifying tags/commits)
but not any upstream tarball signature, since the tarball would be
generated by `git archive` run from mk-origtargz.

> And there I do want uscan to actually check the signature of
> the new orig tarball it downloads. But that also means that as
> I'm using the orig tarball from upstream (and pristine-tar is
> just a weird way of storing it) I think it is semantically
> correct to include the .asc files in the .changes file.

Perhaps you need pristine-tar to also store the .asc file and check it
out when appropriate.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Linitian orig-tarball-missing-upstream-signature

[Paul Wise]

On Mon, Jul 31, 2017 at 5:19 AM, Christian Seiler wrote:

> How does this interact with git-based workflows?

I don't use such workflows so I'm not sure, but at a guess; uscan and
upstream tarballs aren't involved in your workflow, so you won't have
upstream tarball signatures either and should manually verify the
signatures on git tags (and commits) instead, which I don't think
uscan can do yet, but I guess adding it to uscan would be feasible but
then the signatures would not be stored alongside the generated
tarball.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Linitian orig-tarball-missing-upstream-signature

[Paul Wise]

On Mon, Jul 31, 2017 at 4:24 AM, Ole Streicher wrote:

> is not really helpful to me; at least I did not find a mention in the
> Debian policy that the signature should be included in the .changes
> file. Also, it seems that the standard (pdebuild) toolchain does not
> include it by default.

Policy documents current practice rather than describing what
practices should be taken, so I think that we will only get this in
policy once it is more common.

The standard toolchain here is uscan, not pdebuild, and there is a bug
asking placing the signatures in the correct place open already, it
just needs someone to do the work:

https://bugs.debian.org/727096

> What is the preferred way to included the upstream signature?

Before building the source package, place the upstream signature file
alongside the orig.tar, with the same name, but with .asc appended to
it. When that is done, then dpkg-source will include the signature in
the .dsc and it will be copied to the .changes file too.

> Was there some discussion about this in debian-devel that I missed?

I guess the only discussion was in the lintian bug report:

https://bugs.debian.org/833585

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#870215: RFS: stendhal/0.1-1 [ITP] -- Multiplayer online adventure game with an old school feel

[Paul Wise]

On Sun, Jul 30, 2017 at 8:58 PM, Carlos Donizete Froes wrote:

> Sorry, I have a question, even though it is a project of my own.
>
> Do I have to add the Stendhal link?

In my first mail I was confused, since you previously had an ITP/RFS
for stendhal-installer and I assumed this package was the proper
package of Stendhal from source, instead of a wrapper script.

In addition; you are misrepresenting Stendhal as your own project.
Your project is not Stendhal, it is a wrapper script for Stendhal. I
suggest you rename your project to stendhal-installer,
stendhal-wrapper or similar and mention the original upstream project.
In addition, the claim "as that would breach copyright laws" seems to
be incorrect since the Stendhal project appears to be DFSG-free as it
is licensed under GPLv2+

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#870215: RFS: stendhal/0.1-1 [ITP] -- Multiplayer online adventure game with an old school feel

[Paul Wise]

On Sun, Jul 30, 2017 at 8:22 PM, Carlos Donizete Froes wrote:

>  * Package name: stendhal
> dget -x 
> https://mentors.debian.net/debian/pool/contrib/s/stendhal/stendhal_0.1-1.dsc

Since this does not include stendhal, just a script to download the
upstream JAR, I think you should call this stendhal-installer or
similar.

It would also be better to package stendhal properly, since it seems
to be DFSG-free.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#870215: RFS: stendhal/0.1-1 [ITP] -- Multiplayer online adventure game with an old school feel

[Paul Wise]

On Sun, Jul 30, 2017 at 8:22 PM, Carlos Donizete Froes wrote:

>  * URL : https://github.com/coringao/stendhal

This is the wrong link, it should be:

https://stendhalgame.org/

>  * License : GPL-2+
>Section : contrib/games

This is the wrong section for a package that seems to be DFSG-free at
first glance, it should be 'games'.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#869198: RFS: golang-github-shibukawa-configdir/0.0~git20170330.0.e180dbd-1 [ITP]

[Paul Wise]

On Sat, Jul 29, 2017 at 3:46 AM, Andreas Moog wrote:

> To: debian-mentors@lists.debian.org

I suggest mailing the bug instead, since debian-mentors is subscribed
to all RFS bugs but RFS bug submitters might be only subscribed to
their RFS bugs.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Request for sponsor for Stendhall Installer

[Paul Wise]

On Mon, Jul 24, 2017 at 10:59 AM, Carlos Donizete Froes wrote:

> Sorry, but I do not know about the "game-data-packager" and what has to do 
> with
> my installers.

It is a tool to convert upstream data packages into .deb files:

https://tracker.debian.org/pkg/game-data-packager

> Is there a wiki that I can understand better?

https://wiki.debian.org/Games/GameDataPackager

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#868378: RFS: nlohmann-json/2.1.1-1

[Paul Wise]

On Mon, Jul 17, 2017 at 8:09 AM, Christian Seiler wrote:

> [1] This takes a _long_ time with this package as you have huge
> test data in JSON form within the package, and if you do
> run it, redirect its output into a file, otherwise your
> terminal will be swamped with messages.
> (Also note that check-all-the-things has some false
> positives in your case, e.g. it checks for correct JSON as
> one of its checks, and your package has some intentionally
> broken JSON as unit tests.)

You can avoid the second part by turning off individual checks or
groups of checks via the flags option. There isn't yet an option to
ignore certain subdirectories, but patches for that or other ideas to
speed things up would be welcome.

check-all-the-things -c '- isutf8' -f '- json'

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Preferred source: a fundamental question was Re: - #859130 ITP: lina

[Paul Wise]

On Mon, Jul 3, 2017 at 7:34 PM, Albert van der Horst wrote:

> This is of course in the spirit of open source, and it is the
> "preferred source of modification" for the *target* audience.

"Preferred" in "preferred form of the work for making modifications to
it" does not refer to downstream consumers of the code, but the form
that upstream prefers when making modifications.

> If I publish the program as open source in the context of Debian, I give out
> the .s file because I honestly believe that the "preferred source of
> modication" for a Debianist is the native gnu assembler format. I myself
> change the master file in order to be able to deliver a service to those who
> prefer nasm.
>
> Note, that I could not have told that I use an internal representation and
> nobody could have guessed (nor benefited.)
>
> So is the .s accepted as source conform Debian policies?

In this case you have made it clear that the master file is the
"source code", not the generated assembly. IIRC you mentioned this
during earlier discussions too and I see on github that your Makefile
builds the .s files from the internal representation.

Some posts that you might like to read on this topic:

https://lwn.net/Articles/431566/
http://www.inventati.org/frx/essays/softfrdm/whatissource.html
https://b.mtjm.eu/source-code-data-fonts-free-distros.html
https://wiki.freedesktop.org/www/Games/Upstream/#source
http://compliance.guide/pristine

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#865515: RFS: pcc/1.2.0~20170614-1 [ITP]

[Paul Wise]

On Fri, Jun 23, 2017 at 5:52 AM, Adam Borowski wrote:

> It was briefly in the archive: https://packages.qa.debian.org/p/pcc.html
> Removed due to no upstream activity.  I see the upstream is somewhat alive
> nowadays, although I wouldn't call the development brisk.

Please read this advice about reintroducing packages:

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: experimental => unstable?

[Paul Wise]

On Sun, Jun 18, 2017 at 2:41 PM, Roger Shimizu wrote:

> So it should be fine to release various packages currently being held
> in experimental to unstable.

Unstable is back in business, but testing is still frozen.

Please note you still need to co-ordinate with the release team for transitions.

https://wiki.debian.org/Teams/ReleaseTeam/Transitions

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#864241: RFS: pnmixer/0.7.2-1 -- Simple mixer application for system tray

[Paul Wise]

On Tue, 2017-06-06 at 18:17 +0700, Arnaud wrote:

> Is it a correct way of doing things ?

If the tarball you upload to Debian is bit-for-bit identical to the
tarball you upload to or get from github, then yes, otherwise no.

I used diffoscope to compare the tarball uploaded to github with the
tarball github itself generates as well as the tarball uploaded to
Debian. The tarball generated by github and the tarball uploaded to
Debian are identical but the tarball uploaded to github uses a
different directory name internally and so it isn't identical.
I think you can just drop the extra tarball uploaded to github.

> Ok thanks for the clarification, I read the article a while ago, I'll
> have to check that again.

I've clarified the item about C & glib functions.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#864241: RFS: pnmixer/0.7.2-1 -- Simple mixer application for system tray

[Paul Wise]

On Mon, Jun 5, 2017 at 11:35 PM, Arnaud wrote:

> mentors.debian.net says there's a problem. I'm not sure what's wrong.

Probably due to the old version of uscan it uses.

> The package is now built with `gbp` from a git tag. I guess it fixes the 
> problem.

Please verify that is the case.

> I have no idea where are the source images, when I jumped in PNMixer 
> development there was only the PNG files, and I don't think the XCF files 
> will ever be found.

That is a shame, you might want to mention in the README that the XCF
files were lost so now any modifications will be to the PNG files.

>> Instead of g_spawn_command_line_async() you should use g_spawn_async().
>
> Sorry, disagreeing on this one, g_spawn_command_line_async() is definitely 
> what I want to use, it's the right tool for the job.

Looking more closely it seems I was wrong and the
g_spawn_command_line*() functions are actually safe. I had assumed
they would run the command-line by using the shell, which could mean
shell metacharacter injection attacks.

> And if the implementation is bad and uses too many pid, no worries.

I think you may have misunderstood the point of my blog post, it is
more about shell metacharacter injection attacks.

> Fixed a few things, but there's way too much stuff there, I didn't take time 
> to look through everything. For the next release :)

Please consider running lintian/check-all-the-things/etc as often as
you can (such as before each release or before every commit) and
chipping away at the issues when you have time.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Packaging PythonQt for Qt 5

[Paul Wise]

On Tue, May 23, 2017 at 4:56 AM, Erik Lundin wrote:

> We're using PythonQt built for Qt 5 at work, and I have been looking at the
> possibility to package it for Debian. Here is what I have found so far:

I note that PythonQt is orphaned, so you may want to adopt it:

https://packages.qa.debian.org/p/pythonqt.html
https://tracker.debian.org/pkg/pythonqt

The Debian QT/KDE team can probably provide advice/sponsorship:

https://pkg-kde.alioth.debian.org/qtkde.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: artifacts in upstream, re: pristine source

[Paul Wise]

On Tue, May 16, 2017 at 12:42 PM, Brian Smith wrote:

> Regarding the "pristine source" requirement (i.e. no build artifacts) in the
> source archive: should the upstream tarball be imported to the upstream
> branch "as is", and the tar command for orig.tar.gz should be configured to
> omit build artifacts? Or should artifacts either be removed from or not
> imported to the upstream branch?

Contact upstream and ask them to remove them from their VCS and source
tarballs and put them into their binary tarballs/packages. If they
refuse, then add Files-Excluded to debian/watch so you have a
mechanism to automatically remove the files from tarballs downloaded
using uscan. It is completely up to you how to structure any
additional Debian VCS repository. Personally I'd import the tarball
after uscan repacks it, since that is what will be uploaded to the
archive.

https://wiki.debian.org/UscanEnhancements

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: how best to package when using hardware vectorization with vector-unit specific code?

[Paul Wise]

On Thu, May 11, 2017 at 12:01 AM, Kay F. Jahnke wrote:

> While this is tempting, I'd like to keep my code as general as possible.
> Also, I prefer compiling with clang++, which, for my use case, produces
> faster code, and clang++ does not support constructs like

Apparently clang supports something similar, some links I found:

http://clang.llvm.org/docs/AttributeReference.html#ifunc-gnu-ifunc
https://github.com/davisking/dlib/issues/36
http://llvm.org/devmtg/2014-10/Slides/Christopher-Function%20Multiversioning%20Talk.pdf

> Additionally, I find the notion of target_clones to compile a specific
> 'function' hard to digest. What do they mean, function? I write generic code
> in C++, most of my stuff is inlined from header-only libraries, it's all
> object-oriented. There are next to no 'functions' in my code.

I guess FMV is mostly suited to C style programs.

> I had something simpler in mind. I had hoped that a debian package would
> provide some sort of target-side script which is run when the application
> deploys with the user. Then it would be easy to have a bit of code à la

I think it would be better to put that in a wrapper script that is
always installed and executes the right binary.

> #! /bin/bash

Best use /bin/sh if possible.

> mv myprogram_$bestarch $target_bin/myprogram

Change this to exec myprogram_$bestarch "$@"

> ... and optionally delete the binaries for the other ISAs.

Packages should not delete their own files, especially in this case
since you could move your Debian install from one system to another
and then get a different CPU at runtime and need a different pv
binary.

> I am using Vc, so whatever Vc supports, my software supports as well. Vc is
> a generic C++ library to abstract away the architecture, so I just compile
> with -mmx -sse or whatever and Vc adapts and produces the code for the
> specific target. I've coded so that my program will also run without using
> the vector units, this is done by simple #ifdefs, and I pass the definition
> in via a -D directive (or I don't, to produce code without vectorization).
> Alternatively Vc can produce a scalar interpretation of the vector code
> which runs on any platform and is equivalent.

This sounds like the multi-binary plus wrapper script approach would
be best, unless you can figure out how to compile everything into one
binary and select the right code at runtime.

>> ... just not a RC bug.
>
> pardon me, but what's an RC bug?

Release-critical, which usually means it would not be allowed in Debian stable.

> So, yes, I can create base-level machine code and machine code for every
> platform Vc supports. Which still leaves me with the open question how best
> to proceed.

For now: multi-binary plus wrapper script.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: how best to package when using hardware vectorization with vector-unit specific code?

[Paul Wise]

On Wed, May 10, 2017 at 3:17 PM, Kay F. Jahnke wrote:

> I have code which optionally makes use of hardware vectorization.
...
> When compiling with Vc, the resultant machine code is for a specific vector
> unit only, like AVX or SSE.
...
> I'd like some advice on how to proceed to get my code to be easily packaged
> and deployed under the constraints I've outlined.

I suggest you compile all accelerated versions of the code for the
target platform (for eg no SSE on powerpc) into the main binary and
use FMV to automatically select the correct one at runtime:

https://lwn.net/Articles/691932/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#861757: RFS: fonts-fandol/0.3-1 [ITP]

[Paul Wise]

On Thu, 4 May 2017 00:38:24 +0200 Adam Borowski wrote:

> I'm not entirely sure .otf are the real sources, despite the upstream
> providing only otf.  For now, let's assume they are, unless there's evidence
> to the contrary (not sure what the README means).

The README is pretty clear that the fonts are compile to OpenType using
AFDKO from FontForge and or Inkscape source. AFDKO is not in Debian
main so this font should go to contrib. In addition, no FontForge
source format or SVG files were released and the font is under the
GPL so I don't think we can distribute this at all. Please ask the
ftp-masters to reject this package from NEW.

Here are the contents of the README for the record:

README

These are the Fandol fonts for Chinese typesetting.
Current version of Fandol fonts contains four
styles: Song, Hei, Kai, Fang.
All the fonts are OpenType.

These fonts are developed by Fandol team.
The member of Fandol team: Clerk Ma & Jie Su.

These fonts's licensing is GPL + GPL font exception.

CHANGELOG

v0.1 2013/07/31
* initital version.
v0.2 2013/08/03
* change GID to CID (Adobe-GB1-5)
* using AFDKO to compile to OpenType
* CID ranges: 940-7702, 7717-8895, 29064-30220
* XUID: 1440
* fontforge + inkscape as outline editor
v0.3 2015/07/18
* added two braille fonts
* fixed bugs of kanji fonts

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#847608: RFS: zodbpickle/0.6.0-1 [ITP]

[Paul Wise]

On Fri, 9 Dec 2016 21:24:48 +0100 Julien Muchembled wrote:

>python-zodbpickle - Fork of pickle module, for ZODB

If this enters Debian, please make sure that you notify the security
team to update their embedded-code-copies file, which tracks both
embedded copies and forks of projects.

https://wiki.debian.org/EmbeddedCodeCopies

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#861011: RFS: qt5ct/0.31-2 [ITP]

[Paul Wise]

On Mon, Apr 24, 2017 at 12:41 AM, Mateusz Łukasik wrote:

> qt5ct - Qt5 Configuration Utility

Since Lisandro is a Debian member and a co-maintainer of the package,
will he be uploading this?

I don't intend to sponsor this package, but here is a quick review:

There do not appear to be any issues that block the upload to Debian.

These issues would be nice to fix at some point:

It is common to put the debian/ dir under the same license as upstream
instead of a different one. This is especially important for patches,
so that upstream can just include the patches directly without asking
you for a relicense.

Please get the manual page included upstream if it isn't already.

Please get the patch included upstream if it isn't already.

Please set some more DEP-3 headers, especially Forwarded:

http://dep.debian.net/deps/dep3/

The watch file can be shortened by using @ARCHIVE_EXT@

You could eliminate README.Debian if you do this:

Alternatively, create the file /etc/X11/Xsession.d/100-qt5ct with
the following line:

export QT_QPA_PLATFORMTHEME=qt5ct

Please run this command so that diffs of debian/ are easier to read:

wrap-and-sort --short-indent --wrap-always --sort-binary-packages
--trailing-comma

The Priority field should be optional rather than extra.

Transifex is no longer a Free Software service, it would be nice if
upstream could switch to something else.

https://mako.cc/writing/hill-free_tools.html

utils/update_ts.sh should probably run lupdate from $PATH instead of /opt

Please add some upstream metadata: https://wiki.debian.org/UpstreamMetadata

Automated checks:

build

Project MESSAGE: This project is using private headers and will
therefore be tied to this specific Qt module build version.
Project MESSAGE: Running this project against other versions of the Qt
modules may crash at any arbitrary point.
Project MESSAGE: This is not a bug, but a result of using Qt
internals. You have been warned!

dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/qt5ct/usr/lib/x86_64-linux-gnu/qt5/plugins/platformthemes/libqt5ct.so
was not linked against libX11.so.6 (it uses none of the library's
symbols)


lintian

P: qt5ct source: debian-watch-may-check-gpg-signature

check-all-the-things

# is a good idea, people who have different style
# preferences will want to ignore some of the output.
# Do not bother adding non-upstreamable patches for this.
$ find . -type f \( -iname '*.sh' -o -iname '*.bash' \) -exec bashate
--ignore E002,E003 {} +
E010: Do not on same line as for: 'for tr_dir in `find ../src/ -type d
-name "translations"`'
 - ./utils/update_tx.sh : L10
E010: Do not on same line as for: 'for RESOURCE_NAME in qt5ct'
 - ./utils/update_tx.sh : L29
E010: Do not on same line as for: 'for tr_dir in `find ../src/ -type d
-name "translations"`'
 - ./utils/update_ts.sh : L7
E010: Do not on same line as for: ' for code in $LOCALES'
 - ./utils/update_ts.sh : L17
E010: Do not on same line as for: ' for qm_file in $qm_files'
 - ./utils/update_ts.sh : L34
5 bashate error(s) found

$ env PERL5OPT=-m-lib=. cme check dpkg
...
Warning in 'copyright Format' value
'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/':
Format uses insecure http protocol instead of https
...

$ codespell --quiet-level=3
./ChangeLog.svn:553: inital  ==> initial

$ env PERL5OPT=-m-lib=. duck
I: debian/copyright:3: URL:
http://downloads.sourceforge.net/project/qt5ct: INFORMATION
(Certainty:possible)
   URL schema changed from HTTP to HTTPS during redirect(s):
http://downloads.sourceforge.net -> https://sourceforge.net
   Please investigate and update the URL eventually, to avoid
unneccesary redirects!

$ fdupes -q -r . | grep -vE
'/(\.(git|svn|bzr|hg|sgdrawer|pc)|_(darcs|FOSSIL_)|CVS)(/|$)' | cat -s
./src/qt5ct/translations/qt5ct_pt_BR.ts
./src/qt5ct/translations/qt5ct_pt.ts

$ grep -nHEr '/(home|srv|opt)(\W|$)' .
./utils/update_ts.sh:27: /opt/qt56/bin/lupdate -no-obsolete
-silent -extensions "cpp,ui" ${tr_dir}/../ -ts ${ts_files}

$ flawfinder -Q -c .


# check if these can be switched to https://
$ grep -nHrF http: .
./README:42:http://doc.qt.io/qt-5/qloggingcategory.html (paragraph
"Configuring Categories")
./debian/watch:2:http://sf.net/qt5ct/qt5ct-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
./debian/copyright:1:Format:
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
./debian/copyright:3:Source: http://downloads.sourceforge.net/project/qt5ct
./debian/copyright:46: along with this program. If not, see


$ find . -type f \( -iname '*.sh' -o -iname '*.bash' -o -iname '*.zsh'
\) -exec shellcheck {} +


$ find . -type d \( -iname .bzr -o -iname .git -o -iname .hg -o -iname
.svn -o -iname CVS -o -iname RCS -o -iname SCCS -o -iname _MTN -o
-iname _darcs -o -iname .pc -o -iname .cabal-sandbox -o -iname .cdv -o
-iname .metadata -o -iname CMakeFiles -o -iname _build -o -iname
_sgbak -o -iname autom4te.cache -o -iname blib -o -iname 

Re: someone knows about https://archive.debian.net/

[Paul Wise]

On Fri, Apr 21, 2017 at 10:02 PM, PICCORO McKAY Lenz wrote:

> some one noted or using any time the https://archive.debian.net/ service..
...
> today this service are changed and now only put a static page in
> frontend.. anybocy knows about related?

The service will not be available until the maintainer has time to
work on it. It is only for obsolete insecure Debian releases, we
strongly recommend you upgrade to a supported release and use
packages.debian.org instead. squeeze and lenny should *definitely* not
be used any longer. What is blocking your upgrade to
wheezy/jessie/stretch?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#860123: RFS: gsignond/1.0.6 [ITP] -- gSSO daemon and default plugins

[Paul Wise]

On Wed, Apr 12, 2017 at 1:05 AM, Corentin Noël wrote:

> https://mentors.debian.net/debian/pool/main/g/gsignond/gsignond_1.0.6.dsc

I don't intend to sponsor this, but here is a quick review:

debian/source/format should be 3.0 (quilt) instead of 3.0 (native) and
the version number should be 1.0.6-1 instead of 1.0.6.

Usually DH_VERBOSE is not set in debian/rules, you might want to
comment that out or remove it.

DEB_CONFIGURE_EXTRA_FLAGS is a cdbs-specific make variable but your
debian/rules doesn't use cdbs, I would suggest removing those lines
and the associated comment from debian/rules.

dh --parallel is the default with debhelper compat 10, I would suggest
you read the debhelper manual page for more information about compat
level 10, remove --parallel from debian/rules and bump debian/compat
to 10. One thing this will do is enabling autoreconf, which should
always be done, even in lower compat levels.

Please remove override_dh_auto_test, all packages should run their
build time tests. If they currently fail on Debian you can run them
but not fail the build.

Why does debian/rules override the upstream location for the configuration file?

debian/README.Debian doesn't look useful, I would suggest removing it.

The maintainer scripts contain a lot of boilerplate comments that can
be removed.

The handling of gsignond.conf in the maintainer scripts looks very
strange, is that needed?

I'm not sure, but I think ldconfig should never be run manually from
maintainer scripts.

I don't think a -dev package is the right place for dbus service definitions?

debian/install should be removed because you have all the other
debian/*.install files.

debian/gsignond-doc.docs looks strange, I'd suggest removing it.

The Vcs-* fields refer to the Debian packaging VCS, not the upstream VCS.

You should use unstable rather than UNRELEASED as the target suite in
debian/changelog.

You should close your ITP in debian/changelog, I'd suggest retitling
the RFP you filed to ITP:

https://bugs.debian.org/831747
https://www.debian.org/Bugs/server-control#retitle

The upstream README.md doesn't contain any information useful to users
of the binary packages, I'd suggest not installing it.

The upstream NEWS file is empty, I'd suggest contacting upstream to
ask them to remove it or put useful information in it. Also, don't
install it in the Debian binary packages.

You might want to setup some tests for ci.debian.net:

https://ci.debian.net/doc/

tools/archive.sh contains some commands for creating tarballs but
hardcodes the version number to 0.0.2, you might want to talk to
usptream about fixing that.

We generally encourage upstreams to not distribute debian/
directories, even in subdirs like dists/debian/

The tests and dbus files hard-code paths in /tmp but they should never
do that, instead they should only ever use random filenames for /tmp/.

Are you sure the package build needs vala? There is only one *.vala
file and it doesn't seem to be touched by the build.

Automatic checks:

build:

gsignond-signonui-data.c:390: Warning: gSignond:
gsignond_signonui_data_set_forgot_password: invalid return annotation
gsignond-signonui-data.c:424: Warning: gSignond:
gsignond_signonui_data_set_forgot_password_url: invalid return
annotation
gsignond-signonui-data.c:793: Warning: gSignond:
gsignond_signonui_data_set_url_response: invalid return annotation
gsignond-utils.c:311: Warning: gSignond: gsignond_variant_to_sequence:
return value: Invalid non-constant return of bare structure or union;
register as boxed type or (skip)
gsignond-utils.c:366: Warning: gSignond: gsignond_array_to_sequence:
return value: Invalid non-constant return of bare structure or union;
register as boxed type or (skip)
gsignond-utils.c:394: Warning: gSignond:
gsignond_copy_array_to_sequence: return value: Invalid non-constant
return of bare structure or union; register as boxed type or (skip)
gsignond-session-data.c:218: Warning: gSignond:
gsignond_session_data_get_allowed_realms: return value: Invalid
non-constant return of bare structure or union; register as boxed type
or (skip)
...
gtkdoc-mkdb --module=gsignond --output-format=xml
--expand-content-files="" --main-sgml-file=gsignond-docs.sgml
${_source_dir} --xml-mode --output-format=xml
../include/gsignond/gsignond.h:41: warning: Section gsignond is not
defined in the gsignond-sections.txt file.
...
gtkdoc-fixxref --module=gsignond --module-dir=html
--html-dir=/usr/share/gtk-doc/html
html/GSignondPlugin.html:154: warning: no link for: 'GStrv' -> (GStrv).
html/GSignondPlugin.html:179: warning: no link for:
'G-SIGNAL-RUN-FIRST:CAPS' -> (Run First).
html/GSignondPlugin.html:247: warning: no link for: 'GObject' ->
(GObject).
html/GSignondPlugin.html:637: warning: no link for: 'GError' -> (GError).
html/GSignondPlugin.html:897: warning: no link for: 'GTypeInterface'
-> (GTypeInterface).
html/GSignondSessionData.html:277: warning: no link for: 'GVariant' ->
(GVariant).
html/GSignondSessionData.html:525: warning: 

Bug#860145: RFS: openscap-daemon/0.1.6-1 [ITP] -- SCAP security policy compliance daemon for a complete infrastructure

[Paul Wise]

On Wed, Apr 12, 2017 at 3:10 PM, Philippe Thierry wrote:

> https://mentors.debian.net/debian/pool/main/o/openscap-daemon/openscap-daemon_0.1.6-1.dsc

I don't intend to sponsor this, but here is a quick review:

Please encourage upstream to port the project to Python 3, we are
getting closer to the point where Python 2 may be unsupported in some
distributions.

The Debian systemd service file has an incompatible name with upstream
but is identical. Please remove the Debian copy and just use the
upstream systemd service file. If you want to add the full name
upstream, IIRC systemd supports service aliases so you could talk
upstream into adding an alias.

There are typos in debian/README.Debian, please use a spell checker on it.

I think the sysvinit-start-stop-daemon test should use the service
script instead of directly running the init scripts.

I don't think mentioning DEP-3 in patch headers is useful, thanks for
following DEP-3 though.

Please try to get all the patches included upstream or fix upstream so
they are not needed.

ISTR sysvinit supports initially-disabled services, so I think you
should drop OSCAPD_START and the /etc/default/openscap-daemon file and
use that instead if possible.

The short Description is slightly awkward, I'd suggest running it by
the debian-l10n-english list.

Typos in debian/control:

s/that allow/that allows/
s/check/checks/
s/associated to/associated with/


I would suggest replacing the specific product name 'Docker' in
debian/control with the generic word 'container', unless it doesn't
support checking other container types?

You might want to strip the installation instructions from the
upstream README.md file before installing that into the binary
package, since users of the binary packages do not need install
instructions.

debian/openscap-daemon-docs.docs mentions a README.source file but I
can't see that anywhere in the package.

I'd suggest running this command. It will make diffs of the debian/
dir easier to view:

wrap-and-sort --short-indent --wrap-always --sort-binary-packages
--trailing-comma

Please add some upstream metadata: https://wiki.debian.org/UpstreamMetadata

Some of the below automated checks are upstream issues, please talk to
upstream about automatically running these tools in their CI systems.

Automated checks:

build:

E: dh_python2 dh_python2:408: no package to act on (python-foo or one
with ${python:Depends} in Depends)

adequate:

openscap-daemon: py-file-not-bytecompiled
/usr/lib/python2.7/dist-packages/openscap_daemon/__init__.py


lintian:

P: openscap-daemon source: debian-watch-may-check-gpg-signature

check-all-the-things:

$ find . -type f -iname '*.sh' -exec checkbashisms {} +


$ env PERL5OPT=-m-lib=. cme check dpkg
Warning in 'control source Build-Depends:2' value 'python (>> 2.7)':
unnecessary versioned dependency: python (>> 2.7). Debian has
oldstable -> 2.7.3-4+deb7u1; stable -> 2.7.9-1; testing -> 2.7.13-2;
unstable -> 2.7.13-2;
Warning in 'control binary:"openscap-daemon" Depends:2' value 'python
(>> 2.7)': unnecessary versioned dependency: python (>> 2.7). Debian
has oldstable -> 2.7.3-4+deb7u1; stable -> 2.7.9-1; testing ->
2.7.13-2; unstable -> 2.7.13-2;
Warning in 'source options tar-ignore' value '.git|.*.pyc': There's a
missing element in Dpkg::Source::Option. Please log a bug against
libconfig-model-dpkg-perl mentioning the missing element and its
relevant documentation.

$ codespell --quiet-level=3


$ debmake -k


$ fdupes -q -r . | grep -vE
'/(\.(git|svn|bzr|hg|sgdrawer|pc)|_(darcs|FOSSIL_)|CVS)(/|$)' | cat -s
./atomic-git/f24_spc/Dockerfile
./atomic-git/f23_spc/Dockerfile

./oscapd.service
./debian/openscap-daemon.service

./atomic/f24_spc/install.sh
./atomic/rhel7_spc/install.sh
./atomic/centos7_spc/install.sh
./atomic/f23_spc/install.sh

./atomic/f24_spc/config.ini
./atomic/rhel7_spc/config.ini
./atomic/f23_spc/config.ini

# check if these can be switched to https://
$ grep -rF http: .


$ env PERL5OPT=-m-lib=. license-reconcile


# These command check style. While a consistent style
# is a good idea, people who have different style
# preferences will want to ignore some of the output.
# Do not bother adding non-upstreamable patches for these.
$ find . -type f -iname '*.py' -exec pep8 --ignore W191 {} +
$ proselint .
$ pydocstyle .


$ find . -type f -iname '*.py' -exec pyflakes {} +
./openscap_daemon/cli_helpers.py:54: local variable 'total_width' is
assigned to but never used
./openscap_daemon/compat.py:46: redefinition of unused
'subprocess_check_output' from line 23

$ find . -type f -iname '*.py' -exec pyflakes3 {} +
./openscap_daemon/cli_helpers.py:27: undefined name 'raw_input'
./openscap_daemon/cli_helpers.py:54: local variable 'total_width' is
assigned to but never used
./openscap_daemon/compat.py:46: redefinition of unused
'subprocess_check_output' from line 23
./debian/lib/release.py:33:34: invalid syntax
print 'Loading ReleaseNotes from ' + BASEURL + VERSION

$ find . -type f -iname '*.py' -exec 

Re: rejection

[Paul Wise]

On Wed, Apr 12, 2017 at 2:42 PM, Dominique Dumont wrote:
> On Tue, 11 Apr 2017 17:53:41 +0200 Paride Legovini wrote:
> Coalescing entries can be done by 'scan-copyrights' or 'cme update dpkg-
> copyright' (provided by cme and libconfig-model-dpkg-perl packages)

For reference, there are some more copyright tools available too:

https://wiki.debian.org/CopyrightReviewTools

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Trigger to activate bash-completion

[Paul Wise]

On Mon, Apr 10, 2017 at 10:09 AM, Eriberto Mota wrote:

> My current problem is I need to execute 'exec bash' to completion
> work. Is there a trigger to activate completion after the package
> install? Any postinst action?

Packages don't get to interfere with user processes, so no you cannot do this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: How to build scala source

[Paul Wise]

On Fri, Feb 24, 2017 at 5:19 AM, Stuart Prescott wrote:

> I don't know what sbt is (I know little about scala). I get the impression
> there are quite a few commonly used bits of the scala tool chain that aren't
> in Debian.
...
> (or alternatively, package sbt?! ;)

See this thread/bug about packaging sbt:

https://bugs.debian.org/639910
https://lists.debian.org/msgid-search/20160105155845.gc29...@kin.test.toulouse-stg.fr.ibm.com

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#855355: RFS: nasm/2.12.02-1 [ITA]

[Paul Wise]

On Fri, 17 Feb 2017 07:50:21 + (UTC) Gianfranco Costamagna wrote:

> side note: the reproducible patch might be changed in something little 
> different
> -const char nasm_date[] = __DATE__;
> +const char nasm_date[] = __DATE_DEBIAN__;

It is far better to just remove build dates, they are very pointless.

> and then use dpkg-parsechangelog to feed that value on CFLAGS
> this way you will get the date from the latest changelog entry.

That isn't necessary because Debian has implemented SOURCE_DATE_EPOCH:

https://reproducible-builds.org/specs/source-date-epoch/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Adding a new package to Debian

[Paul Wise]

On Fri, Feb 17, 2017 at 4:23 AM, Iban Eguia wrote:

> already was a package named `super` in the Debian repositories.
>
> We first thought of changing our package name to something other than
> `super`, but we then noticed that the package had not been updated in more
> than 9 years, and we thought it would make sense to ask if it was possible
> to replace it in Debian by our package.

'super' is not an appropriate package name, for either the package of
your software, nor of any other software; it is far too generic. In
any case you shouldn't hijack the existing package name. Please name
your package super-android-analyzer or superanalyzer or similar.

The same applies to the command-line tool shipped in the package.

BTW, subjective words like 'super' are not suitable for use in package
descriptions.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [RFC] How to review RFS package

[Paul Wise]

On Wed, Feb 8, 2017 at 10:15 PM, Roger Shimizu wrote:

> Yes, but those docs didn't provide info detailed enough for me to start.
> Probably I too much rely on the high level tools, and lack of ability
> to use plumbing level tools such as dpkg-*.

I think most people encounter all these tools early on when they read
the maint-guide for the first time before they start doing any
packaging.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [RFC] How to review RFS package

[Paul Wise]

On Wed, Feb 8, 2017 at 9:50 PM, Roger Shimizu wrote:

> During my attempt to review RFS package in mentors list, I find actually 
> there's no good manual for this activity.

Did you see the existing documentation?

http://mentors.debian.net/intro-reviewers
https://wiki.debian.org/SponsorChecklist

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Popcon statistics over time for set of packages

[Paul Wise]

On Tue, Feb 7, 2017 at 3:56 PM, Andreas Tille wrote:

> I wonder if there is some way to get popcon statistics for a set of
> packages to compare their usage over time.  The background is that
> I consider to compare the dependencies of Blends metapackages in one
> graph.

The popcon graph script supports multiple binary packages, for e.g.

https://qa.debian.org/popcon-graph.php?packages=autorevision+nsis_vote=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Forth compiler has been gitted, request for sponsoring lina32

[Paul Wise]

On Fri, 2017-01-13 at 03:00 +0100, Albert van der Horst wrote:

> [Sorry for the long quote]

Sorry for the delay :)

> The generic system for ciforth is now present in github.
> https://github.com/albertvanderhorst/ciforth

Great :)

> This is a complete copy of the rcs/cvs system with all versions,
> logs and tags since 2000.

Nice.

I noticed the CVS tags don't seem to have been converted to git tags.

How do you intend to modify the ssort binary if you need to?

The README.ciforth file says "Contact me if you want source." and
looking at the `strings ssort` output it seems like the source for
ssort is a C++ file called ssort.cc.

I would suggest removing the ssort binary from your git repository.

You could then either commit the ssort.cc file and a Makefile update to
the ciforth repository, or you could convert any existing ssort
repository to git and then publish it.

If you chose the latter option then the ssort github repository would
need to be mentioned in README.ciforth, ssort would need to be packaged
for Debian as well as ciforth and the ssort package would then become a
build dependency of ciforth.

On one hand ssort is a small program that probably isn't used by any
other software than ciforth so merging it into ciforth should be fine.
On the other hand ssort is a generic utility so it might be or become
useful outside the ciforth project.

> The latest releases for up to eight targets are in the subdirectory 
> release. Relevant for Debian are the 32 and 64 bit linux versions.

I think it might be better for you to create github tags/releases and
then attach the prebuilt binaries to those tags via the web interface,
instead of committing generated files and tarballs to the git repo.

In addition, Debian will want to build the executables on our buildds
rather than using the pre-built versions. This is so that we know we
can guarantee to our users that they can also build from scratch and
then modify and rebuild as they need to.

> I would be happy to find a sponsor for lina32, which is a runtime 
> package without dependancies. Building the package requires pdftex,
> texinfo and gas.

The way it would work is that you would create a ciforth source
package, containing the output of `git archive` which github produces
and then that source package would contain a debian/ directory listing
the binary packages it produces and instructions on how to run the
upstream build system to build and install the right files.

> I'm willing to invest in understanding the making of deb files
> and maybe add that to the generic system.

Please start by reading through this:

https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: mpgrafic - mpirun test program as root in automatic build

[Paul Wise]

On Thu, Jan 19, 2017 at 7:44 AM, Sean Whitton wrote:

> This is temporarily false: #852071

Is there a typo in that bug? I get a 404

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: mpgrafic - mpirun test program as root in automatic build

[Paul Wise]

On Wed, Jan 18, 2017 at 3:58 PM, Ole Streicher wrote:

> Also when using cowbuilder? At least I see the whole build done by root
> when running in my cowbuilder chroot. That was the point that lead to
> the trouble here...

Yep. I tested this with id and override_dh_auto_* in cowbuilder:

 fakeroot debian/rules clean
   debian/rules override_dh_auto_clean
uid=0(root) gid=0(root) groups=0(root),1234(pbuilder)
 debian/rules build
   debian/rules override_dh_auto_configure
uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
   debian/rules override_dh_auto_build
uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
   debian/rules override_dh_auto_test
uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
 fakeroot debian/rules binary
   debian/rules override_dh_auto_install
uid=0(root) gid=0(root) groups=0(root),1234(pbuilder)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: mpgrafic - mpirun test program as root in automatic build

[Paul Wise]

On Wed, Jan 18, 2017 at 3:37 PM, Boud Roukema wrote:

> I guess by "both of these" you mean "most of the build steps (apart from
> the 'debian/rules install' step)"?

What I wrote wasn't clear and wasn't strictly true, sorry!

When manually building from source:

You always build/test as a normal user.
You install as either root or normal user, depending on the install prefix.

When doing Debian package builds:

You always build/test as a normal user.
You always install using fakeroot.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: mpgrafic - mpirun test program as root in automatic build

[Paul Wise]

On Wed, Jan 18, 2017 at 5:13 AM, Boud Roukema wrote:

> I've looked a bit at buildd.debian.org, but it's not completely
> trivial to decide which is correct - do the buildd builds on the
> debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged
> user running fakeroot, or as (iii) an unprivileged user?

(iii) an unprivileged user

fakeroot is only used at `debian/rules install` time.

Both of these are the same as if you were building manually from source.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: watch file with multiple download url

[Paul Wise]

On Tue, Jan 17, 2017 at 2:47 PM, PICCA Frederic-Emmanuel wrote:

> so it seems that I have a problem with the upstream versioning
...
> the final release is tango-9.2.5a which is considered lower than 
> tango-9.2.5-rcx
>
> how should I change my watch file to take this into account.

This has nothing to do with that you have multiple download URLs.

You are simply missing to replace - with ~ to sort RCs before final versions.

uversionmangle=s/-rc/~rc/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: watch file with multiple download url

[Paul Wise]

On Mon, Jan 16, 2017 at 11:01 PM, PICCA Frederic-Emmanuel wrote:

> No issues, I just wanted to know if I could have something with uscan which 
> work out of the box with both URL's.
> So I would like something without the comment / uncomment trick.

uscan works out of the box with both URLs as far as I can tell.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: watch file with multiple download url

[Paul Wise]

On Mon, Jan 16, 2017 at 5:34 PM, PICCA Frederic-Emmanuel wrote:

> Here my current watch content where I comment and uncomment the URL.

Just uncommenting both seems to work for me, what issue do you get?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: What GPU can be assumed for autopkgtests

[Paul Wise]

On Mon, Jan 16, 2017 at 12:12 AM, Andreas Tille wrote:

> I remember these messages in connection with some (other?) package on
> autobuilders but I can't make up my mind which one and I'm obviously
> doing the wrong web search queries.

I don't know enough about OpenMPI and the logs you posted don't seem
to mention the underlying cause of not being able to start the daemon,
so I'm not sure, sorry. Maybe try stracing it?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: What GPU can be assumed for autopkgtests

[Paul Wise]

On Sun, Jan 15, 2017 at 9:07 PM, Andreas Tille wrote:

> Is there any hint how this test can be run on the autopkgtest
> hardware?

It is unlikely any buildd, puiparts host or debci host has a GPU.
Often they are virtual machines with only serial console for input if
any. So the safe bet for OpenCL is the CPU-based ICD, pocl-opencl-icd.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: debian/watch: FTP with version encoded (only) in directory

[Paul Wise]

On Sun, Jan 8, 2017 at 3:55 AM, Ole Streicher wrote:

> Thank you. I am however a bit afraid since this depends that upstream
> keeps both really consistent.

You could use the github tarball but I'm not sure how it differs from
the stilts zipballs.

> I will have a look; however it may be faster to ask upstream to have a
> better supported url.

Agreed. Just adding the version numbers to the zipball names would work.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Mixed kloak anti keystroke / mice deanonymization tool package or better two separate packages?

[Paul Wise]

On Sat, 2017-01-07 at 01:35 +, Patrick Schleizer wrote:

> Would 'sudo systemctl mask kloak' be a good enough an option to
> selectively disable that component etc.?

That sounds reasonable to me, as long as it is documented.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Mixed kloak anti keystroke / mice deanonymization tool package or better two separate packages?

[Paul Wise]

On Sat, Jan 7, 2017 at 2:50 AM, Patrick Schleizer wrote:

> kloak is an anti keystroke deanonymization tool. [1] A major enhancement
> for the privacy software ecosystem. It's new and currently called a
> prototype. We're currently discussing it [2] with upstream, Debian
> packaging it [3] [4].

Interesting project.

> I am currently wondering if I should suggest to upstream to create two
> separate packages for anti keyboard and anti mice deanonymization or if
> a shared package with both tools would be better?

One would be better, with the option to turn off mice/keyboard as needed.
Adding joystick/touchscreen/etc anonymisation might be interesting too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: debian/watch: FTP with version encoded (only) in directory

[Paul Wise]

On Thu, Jan 5, 2017 at 10:40 PM, Ole Streicher wrote:

> How can I get this right?

With just the ftp site alone it can't work (see below), luckily for
you there is a github page:

http://www.star.bristol.ac.uk/~mbt/stilts/#install
https://github.com/Starlink/starjava/releases

So this monstrosity should work:

version=3
options="uversionmangle=s/\-/./,downloadurlmangle=s{.*/stilts-([\d\.\-]+)\.zip}{ftp://andromeda.star.bris.ac.uk/pub/star/stilts/v$1/stilts_src.zip};
\
https://github.com/Starlink/starjava/releases .*/archive/stilts-([\d\.\-]+).zip

It won't work with the ftp site because uscan doesn't let the version
number be in the directory name and the downloadurlmangle workaround
doesn't work with ftp. I think both of these are probably things that
uscan needs to support. There may be bugs for them, please check and
if not, file new ones.

uscan info: line:
ftp://andromeda.star.bris.ac.uk/pub/star/stilts/v([\d\.\-]+)/stilts_src.zip
Use of uninitialized value $filepattern in pattern match (m//) at
/usr/bin/uscan line 2612,  line 3.
uscan warn: Filename pattern missing version delimiters () without
filenamemangle
  in watch, skipping:
  ftp://andromeda.star.bris.ac.uk/pub/star/stilts/v([\d\.\-]+)/stilts_src.zip

uscan warn: downloadurlmangle option invalid for ftp sites,
  ignoring downloadurlmangle in watch:
  ftp://andromeda.star.bris.ac.uk/pub/star/stilts/v([\d\.\-]+)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends vs Depends

[Paul Wise]

On Wed, Jan 4, 2017 at 1:52 AM, Taylor Kline wrote:

> Thanks, that does help a lot, and it helped me to realize that the packages
> are built on the Debian machines and sent to users already built, so there's
> no need for the users to install the Build-Depends, right?

Right, except users might want to build packages themselves, in that
case they would have to install the Build-Depends on the machine or
chroot where they are doing the building. There are several tools to
setup an isolated environment and install build-depends automatically.

https://wiki.debian.org/sbuild
https://wiki.debian.org/pbuilder
https://wiki.debian.org/cowbuilder
https://wiki.debian.org/qemubuilder
https://packages.debian.org/whalebuilder

There are a few reasons users might want to build packages:

Customising the packages for their needs.

Rebuilding packages against newer versions of dependencies.

Rebuilding packages for older Debian releases.

Verifying that the source corresponds to the binaries:

https://wiki.debian.org/ReproducibleBuilds

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends vs Depends

[Paul Wise]

On Fri, Dec 30, 2016 at 12:31 PM, Taylor Kline wrote:

> What is the difference? How are they treated differently during the
> apt installation process? Thanks :)

You might be interested in looking at some of these diagrams to
discover more about how Debian works:

https://wiki.debian.org/Diagrams

You can look up any confusing jargon you find in this glossary:

https://wiki.debian.org/Glossary

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Paul Wise]

On Fri, Dec 30, 2016 at 12:10 PM, Nicholas D Steeves wrote:

> I'm collecting a list of mistakes I'm likely to make when I'm not 100%
> focused on the work I'm doing; in the future, I plan to use it as a
> personal checklist.  If any of these mistakes fall into the "useful
> for other new packages" category, please let me know and I'll find a
> wiki.d.org article to contribute to.  On the other hand, maybe they're
> just dumb mistakes ;-)

I think it would be best to add detection of those issues to the
appropriate packages, probably lintian, check-all-the-things and or
dependencies of the two.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#832941: RFS: 4pane (debian: to exclusive)

[Paul Wise]

On Sun, Dec 25, 2016 at 3:53 AM, David Hart wrote:

> However will it be accepted into debian? The project is moribund: apart from a
> single commit 3 years ago, it's been unmaintained for 6 years. That was
> supposed to give time for a rewrite which hasn't happened.

I might be a good idea for 4pane upstream to switch to a long-term
maintained build system like autotools/cmake or something new-fangled
like bazel.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: tool to rebuild all build-deps of a package

[Paul Wise]

On Mon, Dec 19, 2016 at 1:54 PM, gustavo panizzo (gfa) wrote:

> Is there any tool I can use to rebuild all packages which B-D/D on my
> package? i want to do a local test before bumping it on the archive

apt install ratt

> Extra points for running the autopkgtests (if any)

You should use autopkgtest for that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Help: r-cran-treescape does not build on i386, armel and armhf any more

[Paul Wise]

On Tue, Dec 13, 2016 at 3:47 PM, Andreas Tille wrote:

> Well, adding xvfb was the usual trick to cope with "unable to open X11
> display" messages and thus I added it ...

To me it looks like you didn't add it yet, at least not to the version
in Debian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Help: r-cran-treescape does not build on i386, armel and armhf any more

[Paul Wise]

On Mon, Dec 12, 2016 at 5:46 PM, Andreas Tille wrote:

> I admit I do not only lack the hardware I'm also lacking experience to
> track down this kind of problems.  I discussed the issue with upstream
> and they also do not have any clue.
>
> Any help would be really appreciated.

Looking at the build logs, even the architectures that succeeded are
getting the warning about X11. So that is completely unrelated and the
issue is the segfault not the xvfb stuff. Someone need to run the
crashing program under gdb and debug the crash.

https://buildd.debian.org/status/fetch.php?pkg=r-cran-treescape=arm64=1.10.18-1=1481535210

If you can't find someone to help out, the only option to solve the RC
bug is removal from those architectures:

https://wiki.debian.org/ftpmaster_Removals

Also, you build-depend on xvfb but I can't see it being used at all in
the build log nor the packaging:

https://codesearch.debian.net/search?q=package%3Ar-cran-treescape+xvfb

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

reminder: Uploaders and RFS bug closing

[Paul Wise]

Hi all,

A reminder for those who aren't aware:

The Uploaders field is for co-maintainers, not sponsors:

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Uploaders

RFS bugs should be closed with -done not debian/changelog:

https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#846348: RFS: capstone/4.0.0-next-0.1 [NMU]

[Paul Wise]

On Wed, Nov 30, 2016 at 10:32 PM, Pranith Kumar wrote:

> Bug#846348: RFS: capstone/4.0.0-next-0.1 [NMU]

This should not be an NMU because the package is orphaned and you
intend to adopt it. So you should change the version to 4.0.0-next-1,
add yourself to the maintainer field and remove any mention of NMU
from this RFS bug title and from the changelog.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: when salvage a package?

[Paul Wise]

On Wed, Nov 30, 2016 at 4:27 PM, Adam Borowski wrote:

> Thus, popcon is useless here.

The vote data should give some useful info about how many people used
it recently.

> If you think this software is important, it
> is, and fixes would be welcome.

Indeed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Copyright for Autoconf stuff

[Paul Wise]

On Sat, Nov 26, 2016 at 3:51 AM, Russ Allbery wrote:

> For those who think it's important to document the licenses of these
> files, I would encourage you to work on writing a well-tested and reliable
> tool to automatically generate those stanzas (the notices are fairly
> consistent and open for that sort of automation) rather than asking people
> to do tedious and not very productive manual work.

There are various tools for this, FOSSology looks the most promising
but Kate Stewart hasn't had the chance to finish her packaging of it.

https://wiki.debian.org/CopyrightReviewTools

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: upload to mentors

[Paul Wise]

On Wed, Nov 23, 2016 at 11:04 PM, Werner Detter wrote:

> both packages are now showing up. Thanks for your help, what was the
> reason / the problem?

One of the files in the upload queue was already in the incoming area
so it was deleting it from the upload queue, but then that made the
upload in the incoming area incomplete. Not sure what was going on
really.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise