Re: Processes for new maintainer and upstream

[Riley Baird]

On Tue, 3 Nov 2015 16:17:03 -0500
Jacob Adams  wrote:

> I have just filed an ITA on 9wm (#660496)
> 
> It has been orphaned for a while and in that time the old upstream sadly
> passed away. A new upstream has popped up and continues to maintain the
> package.
> Is there any special process I need to follow here because upstream changed?

Not really. Just change the watch file and homepage field in d/control,
and anything else that refers to the old upstream.


pgpV4rh0dBp9z.pgp
Description: PGP signature

Re: RFS: Looking for a mentor for my dspdfviewer package

[Riley Baird]

On Sat, 1 Aug 2015 15:57:08 +0200
Danny Edel deb...@danny-edel.de wrote:

 Dear Debian mentors,
 
 I have created a debian package for my project dspdfviewer, a
 dual-screen pdf viewer specifically made for LaTeX-Beamer presentations.
 I have been programming and maintaining this since winter 2012/2013, and
 I believe it is stable and mature enough now to be included in Debian.
 
  Where the package can be obtained from
 
 Download from [my server] or if that is better I will also post it to
 debian mentors server.
 
 [my server]:
 http://danny-edel.de/deb/pool/main/d/dspdfviewer/dspdfviewer_1.13-2.dsc

Hi Danny,

I'm not a DD, so I can't sponsor your package, but I had a look and
here are some things that I noticed:

d/changelog:
-Since the package hasn't been uploaded to Debian yet, you should only
have one changelog entry; you should get rid of version 1.13-2.

d/compat:
-Have you considered upgrading to debhelper 9?

d/control:
-Priority should be optional.

d/docs:
-You could add INSTALL and README.md to this file

d/manpages:
-You don't need this file.

d/README:
-You don't need this file.

General:
-If m...@danny-edel.de isn't being accepted by the Debian mailing
lists, you can get whitelisted by subscribing to this list:
https://lists.debian.org/whitelist/
-Seeing as you're upstream, you should be able to fix the lintian
error debian-watch-may-check-gpg-signature
-Also seeing as you're upstream, in future releases
you might consider fixing no-upstream-changelog. You don't have to do
that now, though. :)

Good luck getting your package into Debian,

Riley Baird


pgplVJkRv8csM.pgp
Description: PGP signature

Re: Bug#793659: RFS: ori/0.8.1+ds1-1 [ITP]

[Riley Baird]

  -You forgot to add a license section for the MIT license.

 I didn't forget. It's at the bottom of the file.

Thanks, I can see that now. Maybe I missed it before.

  d/patches:
  -Some patches don't have author/last-update information.
 
 I thought those were optional. I will add author information.

That's great!

  -You should forward to upstream the patches that they can use.
 
 I've already been doing that. I maybe just didn't indicate it in the
 patches.

Thanks for indicating in the patches.

  General:
  -Your chances of finding a sponsor will greatly increase if you use a
  VCS for the Debian packaging. You can then reference this using the
  Vcs-Browser/Vcs-Git sections in d/control.
 
 That's a good tip. I'll publish my repository on launchpad or something
 with the necessary changes and report back

Good work.


pgpR9NPGvnmdp.pgp
Description: PGP signature

Re: Bug#793659: RFS: ori/0.8.1+ds1-1 [ITP]

[Riley Baird]

 I am looking for a sponsor for my package ori

Hi!

I'm not a DD, so I can't sponsor your package, but I had a look, and
here are some notes:

d/changelog:
-The only point you really need is the Initial release line

d/copyright:
-For the Source: field, you accidentally wrote
http://http://ori.scs.stanford.edu/
-You forgot to add a license section for the MIT license.

d/patches:
-Some patches don't have author/last-update information.
-You should forward to upstream the patches that they can use.

General:
-Your chances of finding a sponsor will greatly increase if you use a
VCS for the Debian packaging. You can then reference this using the
Vcs-Browser/Vcs-Git sections in d/control.

Good luck getting ori into Debian,

Riley Baird


pgpnt0CTurFAJ.pgp
Description: PGP signature

Re: Bug#793651: RFS: hdump/2.3-1 [ITP] -- Hexadecimal and ASCII dumper for binary files

[Riley Baird]

 I am looking for a sponsor for my package hdump

Hi Paulo,

I'm not a DD, so I can't sponsor your package, but I had a look and I
can't see any problems.

Congratulations on a superb packaging effort, and good luck finding a
sponsor.

Cheers,

Riley Baird


pgpR_ofRJru6b.pgp
Description: PGP signature

Bug#792757: RFS: coq-highschoolgeometry/8.4+20150620-1 [ITP]

[Riley Baird]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package coq-highschoolgeometry

* Package name: coq-highschoolgeometry
  Version : 8.4+20150620
  Upstream Author : Frédérique Guilhot frederique.guil...@sophia.inria.fr
* URL :
http://www.lix.polytechnique.fr/coq/pylons/coq/pylons/contribs/view/HighSchoolGeometry/trunk
* License : LGPL-2.1+
  Section : math

  It builds those binary packages:

coq-highschoolgeometry - coq library for high school geometry
proofs/formalisation

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

  http://mentors.debian.net/package/coq-highschoolgeometry


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

dget -x
http://mentors.debian.net/debian/pool/main/c/coq-highschoolgeometry/coq-
highschoolgeometry_8.4+20150620-1.dsc

This package is a dependency of geoproof.

Regards,
Riley Baird



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150718065436.3319.44117.reportbug@debian.fleetstreet

Re: Bug#792144: RFS: cunit/2.1-2.dfsg-3 -- Unit Testing Library for C [ITA]

[Riley Baird]

 I am looking for a sponsor for my package cunit

Hi!

I'm not a DD, so I can't sponsor your package, but I had a look, and
here are some notes:

d/control:
-The link to your git repository doesn't seem to work.

d/copyright:
-In the LGPL license text, you've accidentally referred to the wrong
license:
 You should have received a copy of the GNU General Public License

-The conventional way of referring to the GFDL with no invariant
sections can be seen here:
https://sources.debian.net/src/speech-dispatcher/0.8-7/debian/copyright/?hl=113#L113

-Are you sure that cunit is under LGPL-2 *or any later version*?

-Make sure that the names and years are ordered. Also, if you don't know
the year, you can put a question mark. For an example of how to order
names and years, see this:
https://sources.debian.net/src/2vcard/0.5-4/debian/copyright/?hl=9#L9

d/compat:
-This should be 9 to match the debhelper version.

d/patches:
-You should add DEP-3 headers to your patches

d/README.source:
-This is unnecessary as most packages use quilt now.

d/rules:
-You can simplify this a lot by switching to the debhelper 9 style of
d/rules

d/watch:
-When I run uscan, it seems that there's a new upstream version

General:
Run lintian --pedantic -I -E. You will see a variety of tags that may
or may not be errors.

Good luck getting your package into Debian,

Riley


pgp3sn7Z9MUcN.pgp
Description: PGP signature

Re: my WNPP list is empty but it is not

[Riley Baird]

On Sat, 04 Jul 2015 01:41:57 +0200
Jerome BENOIT sphericaltrian...@rezozer.net wrote:
 Since a couple of weeks, my list of WNPP bugs is empty,
 but I know that I have a couple of them around:
 is a temporary bug ? is there a way to re-fill the list ?

I'm not sure. Which WNPP bugs do you have open?


pgpSttpma3jOc.pgp
Description: PGP signature

Re: Making Debian package with multiple opensource package

[Riley Baird]

On Sun, 07 Jun 2015 19:35:03 -0700
dp dee...@att.net wrote:
 Hi Mentors,
 
 I am trying to create a .deb that has dependency on multiple
 opensource packages.
 
 These packages come from different sources . Few are available through
 apt-get, but few are on git clone or mirrored on personal websites.
 They have variety of compression mechanism such as .gzip, .bz2 etc.
 and individual make files.
 
 I wonder how do I pull the sources and/or binary to create .deb out of
 multiple opensources ? this .deb need to be installable on architecture 
 types
 i386, amd64 etc.
 
 I would highly appreciate any pointers. Please respond.
 
 Best Regards,
 Deeps

It depends on whether or not you want your .deb to be in Debian. If you
do, then you'll need to package all of the the dependencies first. If
you don't, you could just make a script and ask people to run it before
installing your package.


pgp7Dfpixm8L3.pgp
Description: PGP signature

Bug#781136: RFS: pyqso/0.2-1 [ITP]

[Riley Baird]

 I am looking for a sponsor for my package pyqso

That's great! I'm not a DD, so I can't sponsor your package, but here
are my thoughts:

d/changelog:
-As this is a new package, priority should be low.

d/copyright:
-Remove the copyright symbol.
-If you worked on the package this year, you should probably add 2015
to the years. Similarly, upstream development has continued past 2013
so you should probably give 2013-2015 as the years for the non-Debian
parts.

d/docs:
-Include README.md as well.

d/pyqso.1:
-You should try submitting this upstream.

General:
-I got the below error when building. Have you forgotten a
build-depends, or is this message to be expected?

ERROR:root:Could not import a non-standard Python module
needed by the GreyLine class, or the version of the non-standard module
is too old. Check that all the PyQSO dependencies are satisfied.
ERROR:root:Could not import the Hamlib module! ERROR:root:Could not
import the Hamlib module! reading sources...

Good luck getting your package into Debian,

Riley


pgpIqZsdeXJBq.pgp
Description: PGP signature

Bug#780935: RFS: bakefile/1.2.5.1-1 [ITP]

[Riley Baird]

On Sun, 22 Mar 2015 16:28:08 +0100
Paul Gevers elb...@debian.org wrote:
 On 22-03-15 06:39, Riley Baird wrote:
  -The upstream tarball contains embedded code copies of the java
  version of antlr, which violates Debian policy.
 
 This depends on the license, but in general this statement is not
 completely true.

Since it's a precompiled version of antlr, without source, does this
change anything?

  You'll need to repack
  the tarball and add +ds to the version number, add a dependency on
  libantlr-java and possibly modify the build process to accommodate this
  change.
 
 Indeed, you should not USE the embedded copy if it can be avoided at all
 (yes, you may have to jump through some hoops). If you are not doing a
 repack (and certainly if you really can't avoid using the embedded
 copy), you must notify the security team. However, I would not do a
 repack only to get rid of the embedded copy. Removing it in the clean
 target to make sure it doesn't get used is quite acceptable IMHO.

I didn't know that, but you're right - policy 4.13 states Debian
packages should not *make use of* these convenience copies [emphasis
mine].


pgpxa5RMz3f2M.pgp
Description: PGP signature

Bug#780935: RFS: bakefile/1.2.5.1-1 [ITP]

[Riley Baird]

 I am looking for a sponsor for my package bakefile

That's great! I'm not a DD, so I can't sponsor your package, but here's
my overview:

General:
-The upstream tarball contains embedded code copies of the java
version of antlr, which violates Debian policy. You'll need to repack
the tarball and add +ds to the version number, add a dependency on
libantlr-java and possibly modify the build process to accommodate this
change.
-Remove the .pc directory

d/bakefile.lintian-overrides:
-Since you're going to have to repack the tarball anyway, would you be
able to use libjs-query and libjs-underscore?

d/bkl.1:
-If you haven't already, you should try sending this upstream.

d/control:
-You should use a Vcs for the Debian packaging, as most sponsors will
require one. If you *really* don't want to, then remove the Vcs-*
fields.

d/copyright:
-Not all files are under the license in COPYING. For example:
 *extras/vim/bkl.vim
 *docs/bkl_lexer.py
 *docs/gen_reference.py
 *Any embedded code copies
-Get rid of the Copyright (C) on line 6

d/README.source:
-I understand your reasoning, but would it be possible to have separate
packages for each incompatible python-antlr3 version, as needed?

Good luck getting your package into Debian,

Riley Baird


pgpz8m7QXb15K.pgp
Description: PGP signature

Re: Please criticize the package I have been working on, https://github.com/pelliott80/simplescreenrecorder-dpm.git

[Riley Baird]

  d/changelog:
  +You should only list versions of the package that will actually be in
  Debian, so get rid of the vivid entry.
  +The changes you make before the initial release generally aren't
  important enough to go in the changelog.
  +Generally, new packages should have priority low.
  *Close the ITP bug.
 
 Yes, but remember I don't own this bug, I want to
 show these change to upstream and the bug owner.
 Perhaps they will clone, or pull these changes.
 
 If I get it working, let them have the fun of
 closing the bug.

Sorry, I wasn't clear enough. What I meant was that the bug should be
closed automatically by an entry in d/changelog. A lintian tag
new-package-should-close-itp-bug has been created for this purpose.

You can close the bug by including something like:

* Initial release (Closes: #)

In fact, this is really the only entry that you should have in your
changelog for a new package.

  
  d/control:
  *Where is simplescreenrecorder-lib?
 
 This is a very important point. Usually, libs
 are more difficult... But often initial version
 is not bad. it is a good idea to insure easy update.

I'm not sure if you can do this, but I'm not sure. Perhaps someone else
on the list can advise you whether or not this is allowed?


pgpT9REQq5xFk.pgp
Description: PGP signature

Re: Should VCS fields refer to the packaging source or upstream source?

[Riley Baird]

   Please criticize the package I have been working on
   https://github.com/pelliott80/simplescreenrecorder-dpm.git
   in a git repo in dpm format.
  
  -Vcs-Git and Vcs-Browser refer to the VCS of the Debian packaging, not
  of upstream development
 
 Debian Policy Manual
 Chapter 5 - Control files and their fields
 5.6.26 Version Control System (VCS) fields
 
 https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields
 
 clearly states:
 
  Debian source packages are increasingly developed using VCSs. The
  purpose of the following fields is to indicate a publicly accessible
  repository where the Debian source package is developed.
 
 I interpreted repository where the Debian source package is developed
 to mean that the VCS fields should point to the packaging source,
 not the upstream source.
 
 Experenced package maintainers please comment.
 
 Am I wrong?

No, your interpretation is correct. My concern is that
https://github.com/MaartenBaert/ssr is the upstream source, not the
Debian source. Wouldn't the Debian source be
https://github.com/pelliott80/simplescreenrecorder-dpm/blob/upstream/debian/control


pgppuANv3IuTE.pgp
Description: PGP signature

Re: Should VCS fields refer to the packaging source or upstream source?

[Riley Baird]

Sorry, I gave the wrong link in the previous email. I meant to say
https://github.com/pelliott80/simplescreenrecorder-dpm instead of
https://github.com/pelliott80/simplescreenrecorder-dpm/blob/upstream/debian/control


pgpDyu20yEhxs.pgp
Description: PGP signature

Re: Please criticize the package I have been working on, https://github.com/pelliott80/simplescreenrecorder-dpm.git

[Riley Baird]

On Thu, 12 Mar 2015 16:42:36 -0500
Paul Elliott pelli...@blackpatchpanel.com wrote:
 Please criticize the package I have been working on
 https://github.com/pelliott80/simplescreenrecorder-dpm.git
 in a git repo in dpm format.

Okay, sure. I'm not a DD, so I can't sponsor your package, but I
thought that I'd take a look anyway.

d/changelog:
-Make sure that you use the Debian names, not the Ubuntu names (e.g.
experimental, not vivid)
-Your changelog needs to close the ITP bug. A good entry would be:
 * Initial release (Closes: #)

d/control:
-The latest Standards-Version is 3.9.6
-Wrap your lines if they go over 80 characters
-Vcs-Git and Vcs-Browser refer to the VCS of the Debian packaging, not
of upstream development
-Is there any reason that you are limited to i386 and amd64?
-Where is simplescreenrecorder-lib?

d/copyright:
-DEP-5 convention is to use GPL-3+ instead of GPL-3.0+
-Remove the  and  signs from the Source: field.
-Include the licensing information for the build files like aclocal.m4,
configure, m4/* and build-aux/*
-There are some files in glinject/ that are MIT licensed.

d/postinst:
-What is the point of this file? If you don't need it, remove it.

general:
-Did Maarten Baert (v2) make the Debian package? In any case, if it's
your package, you should be listed as the maintainer.

Good luck getting your package into Debian,

Riley Baird


pgpp4cfI0Nj4x.pgp
Description: PGP signature

Bug#779377: Fw: Re: Bug#779377: RFS: classified-ads/0.03-1 / ITP

[Riley Baird]

 So, does it look any better now?

Yes, a lot better! You're almost there, but just two more things:

-Add a d/source/format containing the only the string 3.0
(quilt) (without the quotation marks). This ensures that your package
will use the new format for any patches you may make in future.

-You can add a d/watch file to check for upstream releases. I made one
that you can use from the uscan manpage:

version=3
https://github.com/operatornormal/classified_ads/tags (?:.*/)?v?(\d[\d
\.]*)\.tar\.gz

By the way, I just sent you a message using classified-ads!


pgpUHj9LMQufE.pgp
Description: PGP signature

Bug#779377: Changelog bug closing in classified-ads

[Riley Baird]

Oh, and I forgot to mention: The bug you close in d/changelog should be
the ITP, not the RFS. The RFS will be closed automatically once the ITP
is closed.


pgpTpT7nOdACw.pgp
Description: PGP signature

Re: btpd torrent client lost in history

[Riley Baird]

 Now btpd is not in Debian. Where can I find what happened to it,
 can I revive it and where is last debianization repository?

From this bug, it seems that it never was in Debian at all:
https://bugs.launchpad.net/ubuntu/+bug/158447

The links to the repositories are contained in the above report, but
I'm not sure how accurate they are.


pgprL5lAuOXJR.pgp
Description: PGP signature

Bug#779377: Dual licensed LGPL2.1/GPL3 linking to GPL3 with OpenSSL exception

[Riley Baird]

 Or they could keep the files from Nokia under LGPL2.1, and use 
 GPL3+openssl exception for the rest of the files. Given that they have 
 proper headers, I don't see a problem with that, although I would 
 mention that in the readme.

But what license would the work as a whole be distributed as, then?

 PS: I don't see the OpenSSL exception anywhere there.

It's in the debian directory, but I agree that it could be made more
clear.


pgpxhXuVyaYr_.pgp
Description: PGP signature

Bug#779377: Dual licensed LGPL2.1/GPL3 linking to GPL3 with OpenSSL exception

[Riley Baird]

Hi -legal!

I was reviewing a package classified-ads for Debian, and I noticed a 
potential problem in the process. Namely, the author of the program has decided 
to use GPL3 with the OpenSSL exception. However, they have taken some files 
from Nokia which are dual licensed under either LGPL2.1 or GPL3. I think that 
since Nokia did not make the OpenSSL exception, Debian cannot legally 
distribute the result. However, I assume that it would be okay if the 
maintainer decided to change their license to LGPL2.1. Can someone confirm 
whether all of this is correct?

The project is here: https://github.com/operatornormal/classified_ads/
and the Nokia-licensed files are here: 
https://github.com/operatornormal/classified_ads/tree/master/textedit

Yours thankfully,

Riley Baird


pgpgNcejyDLEq.pgp
Description: PGP signature

Bug#779377: RFS: classified-ads/0.03-1 / ITP

[Riley Baird]

   I am looking for a sponsor for my package classified-ads

That's great! I'm not a DD, so I can't sponsor your package, but I've had a 
look at it, and here are some things that I've noticed:

d/changelog:
-This file should only contain Debian-related changes. Upstream changes 
-You won't be able to upload to unstable at the moment, since it's frozen for 
jessie. You should change this to experimental.

d/compat:
-Debhelper 7 is old. You should switch to 9.

d/classified-ads.1:
-You should include this with the software, not just in Debian.
-You should get rid of the comments explaining what nroff is.
-You note that Upon uninstall of the program, the datafile is left lingering 
around. You might want to ask someone else, but this seems like bad practice.

d/control:
-Priority should be optional, not extra.
-Either fill in the Vcs-* fields, or get rid of them.
-You've listed some dependencies twice: once in d/classified-ads.substvars, and 
once in d/control.
-The long description of your package has some spelling/grammatical errors and 
is a bit short. Perhaps you could take some of the information off your 
homepage and put it there?

d/copyright:
-You should use DEP-5 copyright

d/docs:
-If you don't have any docs, get rid of this file. Otherwise, put them in there.

d/README.source:
*Delete this file if there is no reason to keep it.

d/rules:
-You'll need to update this to dh9 syntax. See here for a guide: 
https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules

General:
-It's a good idea to keep Debian development and upstream development separate. 
Don't include the debian/ directory with your upstream tarballs.
-I don't think that Debian can legally distribute classified-ads, since Nokia 
has not made the OpenSSL exception. On the other hand, I'm not sure if the LGPL 
cancels this out. I'm going to ask debian-legal.

Good luck getting your package into Debian,

Riley Baird


pgpXjmJ8luLC3.pgp
Description: PGP signature

Bug#765893: Changing streql to RFP

[Riley Baird]

Since I have not found a sponsor for this package, and I have lost interest in 
it, I am changing this ITP to an RFP.

If you are interested in packaging it, you might want to use the work I've 
already done as a starting point:
https://gitorious.org/streql_debian/streql_debian


pgpBNkHZ0amRO.pgp
Description: PGP signature

Re: Is #694703 RFP: unvanquished unsful?

[Riley Baird]

 I found unvanquished, which in my opinion is a good game:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694703
 
 But there is already a debian package, which is not part of debian repository:
 http://debs.unvanquished.net/unstable/
 
 Is it useful to repackage it from sources?
 Otherwise what should be done?

If you want the package to be in main, it has to be compilable from
source. However, you may be able to use their package as a starting point.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54da61aa.7070...@bitmessage.ch

Bug#777434: RFS: slides/1.0.1-14 [ITA] -- Python-based Slide Maker

[Riley Baird]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package slides

 * Package name: slides
   Version : 1.0.1-14
   Upstream Author : Itamar Shtull-Trauring sli...@itamarst.org
 * URL : http://itamarst.org/software/slides/
 * License : LGPL-2
   Section : python

It builds those binary packages:

 python-slides - Python-based Slide Maker
 slides-doc - Python-based Slide Maker -- documentation

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

  http://mentors.debian.net/package/slides


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

dget -x
http://mentors.debian.net/debian/pool/main/s/slides/slides_1.0.1-14.dsc

More information about slides can be obtained from
http://itamarst.org/software/slides/.

Changes since the last upload:

  * New maintainer (closes: #623271).
  * Upgraded to Debhelper 9/pybuild
  * Bumped standards version to 3.9.6
  * Added Vcs and Homepage fields to d/control
  * Changed dependencies
  * Added DEP-5 copyright
  * Extended the description of slides-doc
  * Updated source format to 3.0 (quilt)

Regards,

Riley Baird



-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150208054003.8563.4726.reportbug@fleetstreet

Re: `apt-get source` and recompile and gerenate deb

[Riley Baird]

 But why i mail to this list? I always compile my packages and install them 
 into 
 /opt/ .  I don't decide to you help me how to do them, I need to introduce me 
 a 
 good documenation above apt-get source and make package from apt-get source.

To install in opt for programs with a ./configure script, you pass the
option --prefix=/opt to configure.

For ffmpeg specifically, edit the line in debian/rules which says
--prefix=/usr to say --prefix=/opt.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54cbdb64.1020...@bitmessage.ch

Re: How do I split a source package into several binaries?

[Riley Baird]

On 24/01/15 09:39, Jacob Adams wrote:
 I have a source package, a game, that has a lot of resources. I
 was installing these at /usr/share/beret but I then received a
 lintian warning, arch-dep-package-has-big-usr-share, which
 recommends that I split up the package. How can I spilt this
 package into binary and data packages? I am using dh and initially
 set single binary

You'll need to add another package description in d/control, and then
add beret.install, beret-data.install and possibly beret-data.docs.

See https://wiki.debian.org/PkgSplit for more information, and see
this package for an example:
http://sources.debian.net/src/blender/2.73.a%2Bdfsg0-1/debian/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54c2d324.2020...@bitmessage.ch

Bug#773861: Signify-openbsd v9

[Riley Baird]

Hi Eriberto,

Upstream has just released version 9 of the signify-openbsd package.
I've packaged it and uploaded it to mentors:

dget -x
http://mentors.debian.net/debian/pool/main/s/signify-openbsd/signify-openbsd_9-1.dsc

If I am correct, the only remaining problems are:

*Which ISC license text should I keep?
*What do I do when the copyright year is unknown?

Yours sincerely,

Riley Baird


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b71cbc.6000...@bitmessage.ch

Bug#773861: Signify - OpenBSD's cryptographic signing tool

[Riley Baird]

On 14/01/15 12:46, Paul Wise wrote:
 On Sat, Jan 10, 2015 at 1:31 PM, Riley Baird wrote:
 Typos in upstream code:
 equivilent - equivalent
 ouput - output

 Do these really have to be fixed? They won't be visible to the user, and
 it's likely to annoy upstream more than anything. I'll do it if I have
 to, though.
 
 If upstream are so hostile as to be annoyed by fixes for typos, I
 would personally question if their software is worth packaging at all.
 
 https://www.debian.org/doc/manuals/developers-reference/developer-duties.html#upstream-coordination

Okay, I've sent a correction to the maintainer of the portable version:

https://github.com/aperezdc/signify/pull/4

It wasn't that I didn't think that they would accept it, it was just
that I had sent them three similar pull requests already.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b5ded2.5000...@bitmessage.ch

Bug#773861: Signify - OpenBSD's cryptographic signing tool

[Riley Baird]

On 13/01/15 21:40, Henrique de Moraes Holschuh wrote:
 On Tue, 13 Jan 2015, Riley Baird wrote:
 On 12/01/15 12:37, Brian White wrote:
 I don't maintain Signify it any longer (or even use it) so feel free to do
 with it whatever you like.

 Hmm... does that mean that I need to adopt signify before
 signify-openbsd will be accepted?
 
 Well, you cannot take over its package name without a transition that will
 take at least one stable-release, either (so, it is a long-term thing).
 Otherwise, you will regress the systems that have the old package installed
 (and want it).
 
 We went through one such package-name-swap recently, involving the old git
 package becoming gnuit, and the old git-core package becoming git.  You can
 ask the people involved for the details.
 
 While signify's popcon is low, it is still non-zero and the kind of thing
 that is going to be hooked inside a crontab or login script.  So, a
 transition of some sort is required to avoid breaking things for its users.
 
 And if the transition also involves renaming /usr/bin/signify, not just the
 package's name, it also needs to be handled with care.

Okay, thanks for pointing this out. A name change seems like it is going
to be a lot more problematic than it is worth.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b5df8a.3010...@bitmessage.ch

Bug#773861: Signify - OpenBSD's cryptographic signing tool

[Riley Baird]

On 12/01/15 12:37, Brian White wrote:
 I don't maintain Signify it any longer (or even use it) so feel free to do
 with it whatever you like.

Hmm... does that mean that I need to adopt signify before
signify-openbsd will be accepted?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b4c4b7.8030...@bitmessage.ch

Bug#773861: signify-openbsd

[Riley Baird]

On 09/01/15 09:02, Eriberto wrote:
 Hi Riley, how are you?

Good! How are you? Thank you for the review.

 I reviewed your package. My considerations:
 
 1. d/changelog: upload to experimental, to honor the freeze policy[1].
 
 [1] https://release.debian.org/jessie/freeze_policy.html

Done.

 2. d/control: please, be more specific in Homepage field.

Changed to https://github.com/aperezdc/signify

 3. d/copyright:
 
 - Please, use 'ISC' only, not generic or official. I understood your
 POV. But all licenses are ISC (even with some differences).

Which ISC license text should I keep?

 - In base64.c we have:
 
 base64.c: * Portions Copyright (c) 1995 by International Business Machines, 
 Inc.
 
 This uses the IBM license.

Added to d/copyright.

 - debian/patches/move-manpage.patch have copyright
 
 debian/patches/move-manpage.patch:+.\Copyright (c) 2013 Marc Espie
 es...@openbsd.org
 debian/patches/move-manpage.patch:+.\Copyright (c) 2013 Ted Unangst
 t...@openbsd.org
 
 You must quote the copyright in d/copyright.

This patch no longer exists, after a recommendation from Jakub Wilk
against using patches to move files.

 - I think that if you want to use 'Files: * / Copyright: 2014 Adrian
 Perez ape...@igalia.com', you need to consider the GitHub as main
 site (in d/control too).

I've done it in d/control, but where am I supposed to change the site in
d/copyright?

 - In crypto_api.h, where you found the 2014 year? I found 2013.

Good pickup. I've fixed this in the new d/copyright.

 - In fe25519.c and others (in the same line), the year isn't 2013. I
 think that the year is undetermined. Can you check?

The version of supercop that fe25519.c (and others) were taken from was
released in 2013. However, you are right in saying that these files were
in previous years' versions. It would be difficult to find the exact
year; each older version of supercop would need to be downloaded. Should
I remove the year?

 - In smult_curve25519_ref.c, where you found the year for D. J.?

I didn't find a year, so I thought it would be okay to assume that D. J.
had the same copyright year as Matthew Dempsky. Should I remove the year?

 - Please, add an ENTER in end of file.

Done.

 4. d/patches/rename-manual.patch: I think that the description must be
 'from signify', not 'to signify'.

Even with from, the sentence is still grammatically correct, but I
admit that it is confusing, so I've replaced 'to signify' with 'from
signify'

 5. blhc --all produces:
 
 # blhc --all signify-openbsd_8-1_amd64.build
 
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o crypto_api.o crypto_api.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o mod_ed25519.o mod_ed25519.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o mod_ge25519.o mod_ge25519.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o fe25519.o fe25519.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o sc25519.o sc25519.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o smult_curve25519_ref.o
 smult_curve25519_ref.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o bcrypt_pbkdf.o bcrypt_pbkdf.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o timingsafe_bcmp.o timingsafe_bcmp.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o explicit_bzero.o explicit_bzero.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o blowfish.o blowfish.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o base64.o base64.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o sha2.o sha2.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall -D_FORTIFY_SOURCE=2
 -D'__bounded__(a,b,c)='  -c -o sha256hl.o sha256hl.c
 CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security   -Wall 

Bug#773861: Signify - OpenBSD's cryptographic signing tool

[Riley Baird]

Thanks for the review

 http://mentors.debian.net/debian/pool/main/s/signify-openbsd/signify-openbsd_8-1.dsc

 
 The package FTBFS here:
 |dh_auto_clean
 | make[1]: Entering directory
 '/build/signify-openbsd-EGTooy/signify-openbsd-8'
 | /bin/sh: 1: pkg-config: not found
 | Makefile:52: *** libbsd is not installed or version is older than
 0.7.  Stop.
 | make[1]: Leaving directory
 '/build/signify-openbsd-EGTooy/signify-openbsd-8'
 | dh_auto_clean: make -j1 distclean returned exit code 2
 | make: *** [clean] Error 2

I've added pkg-config as a Build-Depends, and tested the package using
cowbuilder. This error is no longer be present.

 Renaming files using patches (move-manpage.patch) is a bad idea. Rename
 it in debian/rules instead.

Done.

 Have you talked with upstream about the name collision?

No, I haven't. OpenBSD is definitely not going to change the name,
although the maintainer of the portable version might.

Before I ask the maintainer of the portable version to do so, I'd like
to see what the maintainer of Debian's signify thinks about this. If he
would be willing to rename /usr/bin/signify and
/usr/share/man/man1/signify.1.gz to something else, signify-openbsd
would be easier to maintain, and more consistent with upstream.

There hasn't been an upload of the signify package since 2004, so it
should be easier to keep up with upstream changes (if there are any more).

I've CC'd this message to the signify maintainer for input.

 Typos in upstream code:
 equivilent - equivalent
 ouput - output

Do these really have to be fixed? They won't be visible to the user, and
it's likely to annoy upstream more than anything. I'll do it if I have
to, though.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b0b91b.3000...@bitmessage.ch

Bug#773861: Lintian errors

[Riley Baird]

Sorry, I just accidentally uploaded a package with two lintian tags
about d/copyright. I've just fixed them and the new package is now on .
You can get it using the command:

dget -x
http://mentors.debian.net/debian/pool/main/s/signify-openbsd/signify-openbsd_8-1.dsc


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b0c660.1050...@bitmessage.ch

fbpdf license doubt

[Riley Baird]

Hi,

There has been some discussion on the debian-mentors list about
copyright and we'd like to get advice from debian-legal.

The original message (not written by me) is below.

Yours thankfully,

Riley Baird



Hello!

I personally use fbpdf pdf-viewer. I packaged it for myself,
but I have some doubts about including it in Debian Archive.

First, it have no LICESNSE file, only main source file mention
modified BSD. I twice mailed author, but seems that he ignored my
request to add full-fledged LICENSE file. Second is that it do not
make releases. And third, pure technical problem is that package
provides binaries `fbpdf` and `fbpdf2`, functionally identical, but
having different dependencies. I am not sure what to do with it.

It is not perfect, but the only sane solution for framebuffer I know,
so I would bother with it.

Upstream-Name: fbpdf
Homepage: http://litcave.rudi.ir
Source: http://repo.or.cz/w/fbpdf.git
Description: Framebuffer pdf viewer
 Fbpdf is a framebuffer pdf and djvu viewer.  There are three make
 targets: fbpdf uses mupdf library for rendering pdf, fbpdf2 uses
 poppler for the same purpose, and fbdjvu uses djvulibre library for
 rendering djvu files.

--
Best regards, Dmitry Bogatov kact...@gnu.org,
Free Software supporter, esperantisto and netiquette guardian.
GPG: 54B7F00D


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54af3e85.5050...@bitmessage.ch

Re: fbpdf license doubt

[Riley Baird]

 Please note that I am not a lawyer.
 If in doubt, please bring this issue to  debian-legal.

I'm not a lawyer either, but I seem to have interpreted this differently
to you. I've forwarded this to debian-legal, so hopefully they can give
us a definitive answer.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54af3ecc.6050...@bitmessage.ch

Bug#773861: Signify - OpenBSD's cryptographic signing tool

[Riley Baird]

Greetings, debian-security!

OpenBSD has recently developed a tool called signify for cryptographic
signing and verifying. It is extremely lightweight, and produces
extremely small signatures. For an idea of how small, note that this is
a complete signature:

RWSRtYZ5JArIEj7Q2Q5qTHD1c2JCvWAu7z0s0ARhlA4s/ac3lc1T5PLplmq1x/LTRZxl9J27Re/QVnUkU9wp14vN/+3Wnb2Tyw4=

It is currently being used to sign not only the releases of OpenBSD (and
its forks, Bitrig and LibertyBSD), but also LibreSSL, OpenBSD's fork of
the OpenSSL library created after heartbleed.

I've packaged signify for Debian, and I'm currently looking for a
sponsor. You can download the package with this command:

dget -x http://mentors.debian.net/debian/pool/main/s/signify-openbsd
/signify-openbsd_8-1.dsc

The mentors summary page is here:
http://mentors.debian.net/package/signify-openbsd

More information about signify can be obtained from
http://www.tedunangst.com/flak/post/signify

Yours sincerely,

Riley Baird


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54ae2908.60...@bitmessage.ch

Re: fbpdf license doubt

[Riley Baird]

 First, it have no LICESNSE file, only main source file mention
 modified BSD. I twice mailed author, but seems that he ignored my
 request to add full-fledged LICENSE file. Second is that it do not
 make releases. And third, pure technical problem is that package
 provides binaries `fbpdf` and `fbpdf2`, functionally identical, but
 having different dependencies. I am not sure what to do with it.

Hmm... modified BSD license typically means the 3-clause BSD license:
https://directory.fsf.org/wiki/License:BSD_3Clause

It would be better if the author had put a LICENSE file, but it doesn't
seem like including it in the archive would do any harm.

Not making releases isn't important; many packages in Debian don't.
Since it's maintained in git, you can just use the git revision number
(checksum) as the version.

Having two binaries is weird, but it doesn't mean that fbpdf shouldn't
be included in Debian.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54ad9e99.40...@bitmessage.ch

Re: Bug#774175: RFS: libgaminggear/0.5.0-1 [ITP]

[Riley Baird]

On 30/12/14 09:20, Tristan Schmelcher wrote:
 Package: sponsorship-requests
 Severity: wishlist
 
 Dear mentors,
 
 I am looking for a sponsor for my package libgaminggear. Packaging this 
 library is a prerequisite for packaging roccat-tools, which I intend to do 
 too.
 
  * Package name: libgaminggear
Version : 0.5.0-1
Upstream Author : Stefan Achatz erazor...@users.sourceforge.net
  * URL : https://sourceforge.net/projects/libgaminggear/
  * License : GPL-2+ with CC-BY-3.0 icons
Section : libs
 
 It builds those binary packages:
 
   libgaminggear-common - Icons for libgaminggear
   libgaminggear-dev - Development files for libgaminggear
   libgaminggear-doc - Documentation for libgaminggear
   libgaminggear0 - Provides functionality for gaming input devices
 
 To access further information about this package, please visit the following 
 URL:
 
 http://mentors.debian.net/package/libgaminggear
 
 
 Alternatively, one can download the package with dget using this command:
 
   dget -x 
 http://mentors.debian.net/debian/pool/main/libg/libgaminggear/libgaminggear_0.5.0-1.dsc
 
 Regards,
  Tristan Schmelcher

Hi, I'm not a DD, so I can't sponsor your package, but I looked at your
package and here are some things that I noticed:

* You should add DEP-3 headers to your patches:
http://dep.debian.net/deps/dep3/

* To comply with Debian's policy on convenience copies, you'll have to
remove the local copy of jquery.js and depend on libjs-query. (Unless,
of course your version is different. I haven't checked.)

* In d/control, since you've already defined Section:libs in the source
package, you can remove the section field from libgaminggear0 and
libgaminggear-common.

Good luck getting your package into Debian!

Riley Baird


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54a5be17.3050...@bitmessage.ch

Re: Bug#774175: RFS: libgaminggear/0.5.0-1 [ITP]

[Riley Baird]

On 02/01/15 09:11, Tristan Schmelcher wrote:
 On Jan 1, 2015 4:37 PM, Riley Baird 
 bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch wrote:

 Hi, I'm not a DD, so I can't sponsor your package, but I looked at your
 package and here are some things that I noticed:

 * You should add DEP-3 headers to your patches:
 http://dep.debian.net/deps/dep3/

 * To comply with Debian's policy on convenience copies, you'll have to
 remove the local copy of jquery.js and depend on libjs-query. (Unless,
 of course your version is different. I haven't checked.)

 * In d/control, since you've already defined Section:libs in the source
 package, you can remove the section field from libgaminggear0 and
 libgaminggear-common.

 Good luck getting your package into Debian!

 Riley Baird
 
 Thanks for the feedback. I'll add the DEP-3 headers and remove the
 redundant sections fields. I am unsure what to do about jquery though. That
 file gets embedded into the binary package by the doxygen run. It's not
 even shipped in upstream libgaminggear. It seems to me that depending on
 libjs-query would be fragile since doxygen's internal jquery version and
 libjs-query's version would not be guaranteed to have compatible APIs as
 those packages evolve.
 
 It seems there are lots of doxygen-generated package violating this policy.
 Is this considered an exception to the rule, I wonder?

Thanks for making the other changes.

I've just checked, and it seems that the doxygen thing actually is a
sort of unofficial exception to the rule, while the issue is being
worked out:

https://www.marshut.net/kqzhpi/doxygen-and-embedded-jquery-problem-how-to-solve.html


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54a5c869.5000...@bitmessage.ch

Re: Bug#774348: RFS: hebrew-cal/1.0 [ ITP]

[Riley Baird]

On 01/01/15 21:46, Avi Software wrote:
 Package: sponsorship-requests
 Severity: wishlist
 
 Dear mentors,
 
 I am looking for a sponsor for my package hebrew-cal
 
 * Package name: hebrew-cal
Version : 1.0
Upstream Author : avisoftware...@gmail.com
 * URL : https://github.com/avi-software/hebrew-cal
 * License : GPL
Section : misc
 
   It builds those binary packages:
 
 hebrew-cal - Hebrew Calendar
 
   To access further information about this package, please visit the
 following URL:
 
   http://mentors.debian.net/package/hebrew-cal
 
 
   Alternatively, one can download the package with dget using this command:
 
 dget -x 
 http://mentors.debian.net/debian/pool/main/h/hebrew-cal/hebrew-cal_1.0.dsc
 
 
   Changes since the last upload:
 
   [your most recent changelog entry]
 
 
   Regards,
Avi Software

Hi, I'm not a DD, so I can't sponsor your package, but I've had a look
and here are some things I've noticed:

* Your package should be a non-native package, because it isn't
exclusive to Debian.

* You need to update the standards version in d/control to 3.9.6

* You say that hebrew-cal is based on libhdate and zmanim-java-API.
Debian policy forbids convenience copies, so would it be possible to
simply depend on the libhdate packages? You might also have to package
kosherjava to meet this policy, but maybe someone else on the list can
confirm this.

* You need to make a manpage for hebrew-cal.

* You should have a watch file.

* In data/hebrew-cal.desktop, you do not need to specify the encoding.

* In data/hebrew-cal.desktop, add a Keywords field. See
https://lintian.debian.org/tags/desktop-entry-lacks-keywords-entry.html
for more information.

* Your short description would ideally give more information than
Hebrew Calendar. How about a beautiful, Qt-based Hebrew calendar

* Your long description doesn't sound natural. How about:
 hebrew-cal is a beautifully designed Hebrew calendar
 which is very easy to use and customize.
 The calendar includes Hebrew dates, holidays,
 times, Parshiot Hashavua, Daf Yomi, and more.
 .
 The appearance can be changed, the colors are editable
 and calendars can be printed.
 .
 It is written in C++ using the Qt libraries, and is
 based on the libhdate code and zmanim-java-API.

Good luck getting your package into Debian!

Riley Baird


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54a5b1d1.1010...@bitmessage.ch

Re: debian-watch-file-missing-version

[Riley Baird]

 I'm not a DD, so I can't sponsor your package, but if you want,
 I'll take a look at it over the next couple of days.
 
 That would be great! I have just uploaded an updated version that
 is lintian clean although the watchfile still appears to be
 broken.
 
 Thank you for your quick response!

As promised, here is my review:

* Remove d/README.source, since you don't have anything to say there
* Remove the unnecessary commented out lines in d/rules
* d/copyright does not list all copyright holders/years. Look in each
source file, and try to note the copyright data for each file.
* d/watch still appears to be broken - it seems to be having
difficulties differentiating between the different ways of versioning
- v1.xx, and swapspace-1.xx. The output of uscan --verbose is below:

-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
   opts=pgpsigurlmangle=s/$/.gpg/
https://github.com/tookmund/swapspace/releases .*/v?(\d\S*)\.tar\.gz
-- Found the following matching hrefs:
 /Tookmund/Swapspace/releases/download/v1.12/swapspace-1.12.tar.gz
(1.12/swapspace-1.12)
 /Tookmund/Swapspace/archive/v1.12.tar.gz (1.12)
 /Tookmund/Swapspace/releases/download/v1.11/swapspace-1.11.tar.gz
(1.11/swapspace-1.11)
 /Tookmund/Swapspace/archive/v1.11.tar.gz (1.11)
 /Tookmund/Swapspace/archive/v1.10.tar.gz (1.10)
dpkg: warning: version '1:1.12/swapspace-1.12-0' has bad syntax:
invalid character in version number
Newest version on remote site is 1.12/swapspace-1.12, local version is
1.12
dpkg: warning: version '1:1.12/swapspace-1.12-0' has bad syntax:
invalid character in version number
 = swapspace-1.12.tar.gz already in package directory
-- Scan finished


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54a28242.2090...@bitmessage.ch

Re: debian-watch-file-missing-version

[Riley Baird]

 * d/copyright does not list all copyright holders/years. Look in
 each source file, and try to note the copyright data for each
 file.
 I assume you are referring here to the Software Industry Promotion 
 Agency which I have now added to d/copyright

Yep! Except, I just noticed one more thing :) The license is GPL-2+,
not GPL-2.

Good luck getting sponsored.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54a39dd0.4010...@bitmessage.ch

Re: code reuse in debian/package.config

[Riley Baird]

On 29/12/14 09:08, Yuri Oleynikov (יורי אולייניקוב wrote:
 Hello all
 
 So happened i'm maintainer of debian packages in my company.
 And i have the following situation:
 There're several deb packages that using debconf to ask user input during
 installation, apply initial configuration, etc with:
  * debian/package.config
  * debian/package.preinst
  * debian/package.postinst
 
 Seems quiet simple, until number of packages were grown and i noticed that
 packageA.configs, pacakgeB...packageZ.config (the same for
 debian/package.postinsts) script code is 90% same (or atleast VERY similar)
 code, a lot of same mistakes and bugs because of copy-pastes.
 
 OK, i wrote some shell library that covers that 90% code base, created a
 package (call it libxyz-common-tools with just
 /usr/share/libxyz/config-tool, without config or pre-postinst - just
 unpack), let make packageA-packageZ be depends or pre-depends on it.
 
 apt-get install libxyz-common-tools
 apt-get install packageA
 
 Everything is OK.
 
 But, when installing packageA without libxyz-common-tools is preinstalled -
 packageA.config script won' run?
 
 Is there any way to solve the problem?

I'm confused as to what you mean. If libxyz-common-tools is a dependency
of packageA, then why would you be trying to install packageA without
libxyz-common-tools installed?





--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54a08504.1060...@bitmessage.ch

Re: code reuse in debian/package.config

[Riley Baird]

Okay, my mistake. When you apt-get install packageA, is
libxyz-common-tools installed as well? If so, is it installed before or
after packageA?

On 29/12/14 09:39, Yuri Oleynikov (יורי אולייניקוב wrote:
 because 'apt-get install packageA' should pick up and install all its
 dependencies automatically
 
 2014-12-29 0:32 GMT+02:00 Riley Baird 
 bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch:
 
 On 29/12/14 09:08, Yuri Oleynikov (יורי אולייניקוב wrote:
 Hello all

 So happened i'm maintainer of debian packages in my company.
 And i have the following situation:
 There're several deb packages that using debconf to ask user input during
 installation, apply initial configuration, etc with:
  * debian/package.config
  * debian/package.preinst
  * debian/package.postinst

 Seems quiet simple, until number of packages were grown and i noticed
 that
 packageA.configs, pacakgeB...packageZ.config (the same for
 debian/package.postinsts) script code is 90% same (or atleast VERY
 similar)
 code, a lot of same mistakes and bugs because of copy-pastes.

 OK, i wrote some shell library that covers that 90% code base, created
 a
 package (call it libxyz-common-tools with just
 /usr/share/libxyz/config-tool, without config or pre-postinst - just
 unpack), let make packageA-packageZ be depends or pre-depends on it.

 apt-get install libxyz-common-tools
 apt-get install packageA

 Everything is OK.

 But, when installing packageA without libxyz-common-tools is
 preinstalled -
 packageA.config script won' run?

 Is there any way to solve the problem?

 I'm confused as to what you mean. If libxyz-common-tools is a dependency
 of packageA, then why would you be trying to install packageA without
 libxyz-common-tools installed?





 --
 To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/54a08504.1060...@bitmessage.ch


 


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54a08878.4080...@bitmessage.ch

Re: debian-watch-file-missing-version

[Riley Baird]

On 29/12/14 12:52, Jacob Adams wrote:
 I have been working to fix all the lintian warnings for my package 
 swapspace ( http://mentors.debian.net/package/swapspace )
 
 The only outstanding warning is debian-watch-file-missing-version
 which I cannot figure out how to fix. My watchfile has a version=
 line. However mentors.d.n reports that the watchfile is broken so
 this could simply be a result of that.
 
 Could someone please help me understand what I did wrong with my
 watchfile?
 
 (And while you are at it a complete review of my package would be 
 appreciated :)
 
 Thanks for your help!
 
 Jacob Adams GPG Key: AF6B 1C26 E2D0 A988 432B  94F4 24C0 2B85 B59F
 E5A9

The version field refers to the watch file format, not the package
version.

You should have version=3. I'm not a DD, so I can't sponsor your
package, but if you want, I'll take a look at it over the next couple
of days.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54a0bdd8.6080...@bitmessage.ch

Re: Bug#773632: RFS: pcsx2/1.2.1-783-g1f54bb7+dfsg-1 [ITP]

[Riley Baird]

 * There's a newer upstream version
 
 The package contains the HEAD of the master branch from a few hours
 ago since upstream just committed some new changes. There is
 technically no newer version. What upstream branched/tagged as 1.2.2
 is 1.2.1 + a cherry pick of 1 commit but due to the migration from svn
 to git the branching is kind of funny currently. Git describe will
 give 1.2.1-783-since there are 783 commits since the last tag. I could
 stop using git describe and change it to something like
 1.3.0~git20141221-1

Okay, sorry, I was mistaken. Keep the version numbering as is.

 * Unfortunately, the FTP masters require PDF files to be distributed
 with source code (https://ftp-master.debian.org/REJECT-FAQ.html). You
 can ask upstream if they still have it, but for now I think it would be
 easier just to not package the pdf documentation.
 
 The source is there in:
 pcsx2/Docs/PCSX2_FAQ.doc
 pcsx2/Docs/PCSX2_Readme.doc
 
 Since you failed to find it I guess the ftpmaster could fail to find
 it too. So I documented it in Readme.source just to be safe.

Thanks, I should have seen that.

 * You don't need d/lintian-overrides when you already have
 d/source/lintian-overrides.
 
 d/source/lintian-overrides is for the source
 d/lintian-overrides is for the 1st binary in the control file.
 
 Not sure what you mean by this.

Again, my mistake. Don't worry about it. :)

 * It seems that, to make use of this package, a non-free BIOS is needed.
 I don't have one, so I can't really do any more testing. Also, is it
 possible to make much use of this package without a non-free BIOS? If
 not, the package may have to go into non-free, instead of main.
 
 I'm not sure about this since it's something that any user that wants
 to use the software must already own.. The same argument could be made
 for DVD movies or the game disk themselves then.

Debian policy 2.2.1 requires that None of the packages in the main
archive area require software outside of that area to function.

The argument couldn't be made for the game disk. After all, maybe you
just want to run NetBSD on it?
(http://www.netbsd.org/ports/playstation2/index.html)

In any case, I might be wrong on this. I'm CC-ing Debian-legal to see
what they think.

 I can tell that you've gone to a LOT of work to package this. Please
 don't let this last obstacle (the package review) discourage you. Thank
 you, and I hope to soon see your package in Debian!
 
 I probably spent too much time in the copyright due to missing headers
 but upstream slowly added them but it's still a mess tbh.

Oh well, it should be fine. d/copyright is generally a best attempt sort
of thing anyway.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5497ecc4.9050...@bitmessage.ch

Re: Bug#773611: Fwd: RFS: histring/1.1.1-1 [ITP] - general purpose highlighting tool

[Riley Baird]

 * It may be a good idea to make releases as tarballs still, instead of
 just making Debian releases, so that other distros can benefit as
 well.

 Alternatively, he/she can tag the releases in git.

 True, that would also work. (Although it has the disadvantage that it
 makes it difficult to automatically check for new releases using things
 like watch files.)
 
 Yeah, that's unfortunate. All my release histring tarballs are under
 https://github.com/suntong001/histring/archive/
 however github block the access to that folder. 
 Do other distros user watch files or something alike? 

I've looked it up, and it seems Fedora does something sort of like it:
https://fedoraproject.org/wiki/Upstream_release_monitoring

In any case, you're right that I can't access
https://github.com/suntong001/histring/archive/, but I can still access
your release tarballs at https://github.com/suntong001/histring/releases!

I've made a sample d/watch:

version=3
opts=dversionmangle=s/-[0-9]//,uversionmangle=s/-[0-9]// \
https://github.com/suntong001/histring/releases
/suntong001/histring/archive/(.+)\.tar\.gz


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5497ffe1.4010...@bitmessage.ch

Re: Bug#773632: RFS: pcsx2/1.2.1-783-g1f54bb7+dfsg-1 [ITP]

[Riley Baird]

On 22/12/14 23:40, gregor herrmann wrote:
 On Mon, 22 Dec 2014 15:50:59 +0500, Andrey Rahmatullin wrote:
 
 On Mon, Dec 22, 2014 at 09:30:45PM +1100, Riley Baird wrote:
 * In d/changelog, urgency should be low since it's a new
  package
 Is this documented somewhere?
 My mentor had told me upon the second upload of my package
 that I could optionally change the priority to medium (and the
 New Maintainer Guide recommends not going above low), so that
 is how I came to believe this.
 Medium is default for about an year.
 
 Correct.
 
 Testing migration for packages not in testing still is 10 days.
 Cf. 
 https://lists.debian.org/debian-devel-announce/2013/11/msg7.html


 
(Default Urgency); maybe that's what Riley's mentor had in mind.

Ah, okay, thanks. Should I file a bug against maint-guide? (urgency
shouldn't be changed to anything higher than low)

https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#changelog


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/549870b0.1020...@bitmessage.ch

Re: Bug#773760: RFS: kcm-systemd/0.7.0-1 [ITP]

[Riley Baird]

On 23/12/14 10:56, Shawn Sörbom wrote:
 Package: sponsorship-requests
 Severity: wishlist
 
 Dear mentors,
 
 I am looking for a sponsor for my package kcm-systemd
 
  * Package name: kcm-systemd
Version : 0.7.0-1
Upstream Author : Ragnar Thomsen rthoms...@gmail.com
  * URL : https://github.com/rthomsen/kcmsystemd
  * License : GPL3
Section : kde
 
 It builds those binary packages:
 
   kcm-systemd - KDE control center module for Systemd
 
   To access further information about this package, please visit the 
 following 
 URL:
 
   http://mentors.debian.net/package/kcm-systemd
 
 
   Alternatively, one can download the package with dget using this command:
 
 dget -x 
 http://mentors.debian.net/debian/pool/main/k/kcm-systemd/kcm-systemd_0.7.0-1.dsc
 
   More information about kcm-systemd can be obtained from 
 https://github.com/rthomsen/kcmsystemd.
 
  
 
 
   Regards,
Shawn Sörbom

Hi! I'm not a DD, so I can't sponsor your package, but I've had a look
at it and I can't see any problems. The only thing which I can think of
would be that the no-upstream-changelog lintian tag could be solved by
considering the upstream NEWS file to be a changelog file.

Good luck getting your package into Debian!

Riley Baird


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5498bbb3.1000...@bitmessage.ch

Re: Bug#773505: python-descartes/1.0.1-1 [ITP]

[Riley Baird]

On 19/12/14 20:47, Johan Van de Wauw wrote:
 X-Debbugs-CC: pkg-grass-de...@lists.alioth.debian.org
 Package: sponsorship-requests
 Severity: wishlist
 
   Dear mentors,
 
   I am looking for reviews/a sponsor for my package python-descartes
 
  * Package name: python-descartes
Version : 1.0.1-1
Upstream Author :  Sean Gillies, descartesdevelopers
 * URL :
 https://pypi.python.org/pypi/descartes,https://bitbucket.org/sgillies/descartes
 * License : BSD-3
   Programming Lang: Python
 
 python-descartes - Matplotlib extension to work with geometric
 objects (Python2)
  python3-descartes - Matplotlib extension to work with geometric
 objects (Python3)
 
   To access further information about this package, please visit the
 following URL:
 
   http://mentors.debian.net/package/python-descartes
 
 
   Alternatively, one can download the package with dget using this command:
 
 dget -x 
 http://mentors.debian.net/debian/pool/main/p/python-descartes/python-descartes_1.0.1-1.dsc
 
 
   Changes since the last upload:
 
 Initial upload
 
 
   Regards,
Johan Van de Wauw

Hi! I'm not a DD, so I can't sponsor your package, but I've had a look
at it, and here are some things I've noticed:

* In d/copyright, the copyright symbol (©) is unnecessary.

* To fix the lintian tag debian-control-has-unusual-field-spacing,
make sure that there is only one space after each of the Depends:
fields, instead of two. (You'll need to change lines 25 and 32.)

Good luck getting your package into Debian!

Riley Baird


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5498c791.9030...@bitmessage.ch

Re: Bug#773611: Fwd: RFS: histring/1.1.1-1 [ITP] - general purpose highlighting tool

[Riley Baird]

On 21/12/14 19:58, Cameron Norman wrote:
 El sáb, 20 de dic 2014 a las 11:30 , Riley Baird
 bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch escribió:
 On 21/12/14 07:02, Tong Sun wrote:
  Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  Please sponsor for my newly uploaded package histring.

  It's a general purpose highlighting tool that works with arbitrary
  input text file (e.g. all sorts of log files), and highlight different
  keywords in different colours (e.g., warnings and errors are
  highlighted with different colours). You can use this single small
  tool to replace all kinds of special purpose log parsing tools, and it
  can do much more, like highlighting results from vcsdiff, etc. E.g.,


 Hi! I'm not a DD, so I can't sponsor your package, but here are some
 things that I've noticed:

 * It may be a good idea to make releases as tarballs still, instead of
 just making Debian releases, so that other distros can benefit as well.
 
 Alternatively, he/she can tag the releases in git.

True, that would also work. (Although it has the disadvantage that it
makes it difficult to automatically check for new releases using things
like watch files.)


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54968d71.3040...@bitmessage.ch

Re: Bug#773632: RFS: pcsx2/1.2.1-783-g1f54bb7+dfsg-1 [ITP]

[Riley Baird]

On 21/12/14 19:04, Miguel A. Colón Vélez wrote:
 Package: sponsorship-requests
 Severity: wishlist
 
   Dear mentors,
 
   I am looking for a sponsor for my package pcsx2
 
  * Package name: pcsx2
Version : 1.2.1-783-g1f54bb7+dfsg-1
Upstream Author : PCSX2 Dev Team
  * URL : http://pcsx2.net/
  * License : GPL-3
Section : games
 
   It builds those binary packages:
 
 pcsx2 - Playstation 2 emulator
  pcsx2-dbg  - Debug symbols for PCSX2
 
   To access further information about this package, please visit the
 following URL:
 
   http://mentors.debian.net/package/pcsx2
 
 
   Alternatively, one can download the package with dget using this command:
 
 dget -x 
 http://mentors.debian.net/debian/pool/main/p/pcsx2/pcsx2_1.2.1-783-g1f54bb7+dfsg-1.dsc
 
   or go directly to the VCS:
   http://anonscm.debian.org/cgit/pkg-games/pcsx2.git
 
   Regards,
Miguel A. Colón Vélez
 
 

Hi, I'm not a DD so I can't sponsor your package, but here are some
things I've noticed:

* There's a newer upstream version

* In d/changelog, urgency should be low since it's a new package

* Even though, technically, public domain software does not have a
copyright holder, it is typical to put the author in this field in
d/copyright anyway. Remove the phrase Author's Note, and just leave
the author's note in the License field. Because there are multiple
different public domain declarations, you'll need to give them different
names, e.g. public-domain-mark and public-domain-casper.

* Unfortunately, the FTP masters require PDF files to be distributed
with source code (https://ftp-master.debian.org/REJECT-FAQ.html). You
can ask upstream if they still have it, but for now I think it would be
easier just to not package the pdf documentation.

* You don't need d/lintian-overrides when you already have
d/source/lintian-overrides.

* Upon starting the program for the first time, there is a link labelled
Readme / FAQ (Offline/PDF), which points to
/usr/games/Docs/PCSX2_FAQ.pdf, which does not exist (due to Debian's FHS).

* It seems that, to make use of this package, a non-free BIOS is needed.
I don't have one, so I can't really do any more testing. Also, is it
possible to make much use of this package without a non-free BIOS? If
not, the package may have to go into non-free, instead of main.

I can tell that you've gone to a LOT of work to package this. Please
don't let this last obstacle (the package review) discourage you. Thank
you, and I hope to soon see your package in Debian!

Riley Baird


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54969b07.4050...@bitmessage.ch

Re: Bug#773611: Fwd: RFS: histring/1.1.1-1 [ITP] - general purpose highlighting tool

[Riley Baird]

On 21/12/14 07:02, Tong Sun wrote:
 Package: sponsorship-requests
 Severity: wishlist
 
 Dear mentors,
 
 Please sponsor for my newly uploaded package histring.
 
 It's a general purpose highlighting tool that works with arbitrary
 input text file (e.g. all sorts of log files), and highlight different
 keywords in different colours (e.g., warnings and errors are
 highlighted with different colours). You can use this single small
 tool to replace all kinds of special purpose log parsing tools, and it
 can do much more, like highlighting results from vcsdiff, etc. E.g.,
 
 http://sfxpt.wordpress.com/2013/06/02/highlighting-strings-in-text-output-with-histring/
 
 Once again, I am looking for a sponsor for my newly upgraded package
 histring. It's *lintian clean*, and without any build problems. Ref
 http://mentors.debian.net/package/histring
 
  * Package name: histring
Version : 1.1.1-1
   * URL : https://github.com/suntong001/histring
  * License : GPL-2.0+
Section : utils
 
   It builds those binary packages:
 
 histring   - highlight strings using ANSI terminal escape sequences
 
   To access further information about this package, please visit the
 following URL:
 
   http://mentors.debian.net/package/histring
 
 
   Alternatively, one can download the package with dget using this command:
 
 dget -x 
 http://mentors.debian.net/debian/pool/main/h/histring/histring_1.1.1-1.dsc
 
   More information about hello can be obtained from
 
 http://sfxpt.wordpress.com/2014/11/30/use-new-dbab-to-set-proxy-automatically/#advantages.
 
 Thanks 
 Best Regards,
 
 Tong Sun

Hi! I'm not a DD, so I can't sponsor your package, but here are some
things that I've noticed:

* It may be a good idea to make releases as tarballs still, instead of
just making Debian releases, so that other distros can benefit as well.

* As far as I can see, you can fix deprecated-configure-filename. All
you would need to do is change the name of configure.in to configure.ac.

* Unless you have a compelling reason, the priority of the package (in
d/control) should be optional, not extra.

* This isn't important, but it would be nice if you put the histring
manpage outside of the Debian directory when you make your next upstream
release. This way, other distros and people who build from source will
also benefit from the manpage.

* There are a few minor grammatical errors in histring --help:
useage should be usage
your self should be yourself
hilighting should be highlighting

Good luck getting your package into Debian!

Riley Baird


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/549676fc.4050...@bitmessage.ch

Re: Please sponsor dbab, the dnsmasq-based ad-blocker

[Riley Baird]

 * d/docs is empty. You should include dbab.html.
 
 You meant this?
 
  echo 'dbab.html'  debian/docs

Yep!


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/548d1122.2080...@bitmessage.ch

Re: How to let different programs use same man page

[Riley Baird]

On 14/12/14 15:15, T o n g wrote:
 Hi, 
 
 What's the trick to have different programs use same man page when 
 packaging a Debian package? 
 
 E.g., say I'm packaging gzip, and I want both `man gzip` and `man gunzip` 
 goes to the same man file. How can I make it happen? 

Looking at the gzip source, it seems that the solution is to make one
manpage a link to another manpage. Look at gunzip.1 to see what I mean:
http://sources.debian.net/src/gzip/1.6-4/gunzip.1/


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/548d133d.4060...@bitmessage.ch

Re: Sample systemd service init file please

[Riley Baird]

On 14/12/14 14:50, T o n g wrote:
 Hi, 
 
 Can you provide me a sample systemd service init file, that correspond to 
 init.d script please? I.e., the corresponding file for systemd to 
 replace /etc/init.d/service. 
 
 My package have that /etc/init.d/service file, but I want to create one 
 for systemd as well. I am asking because I don't even know what that file 
 is called, so I didn't find any relevant info from the internet.

The manual page for systemd.service should give you general
information on systemd service files. This link [1] describes methods
for converting init scripts to systemd.

As for an example, here is a sysvinit script [2]. The corresponding
systemd script is slightly down the page in [1].

Hopefully, this has been clear. :)

Yours sincerely,

Riley Baird



[1] http://0pointer.de/blog/projects/systemd-for-admins-3.html
[2] http://0pointer.de/public/abrtd


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/548d1094.4060...@bitmessage.ch

Re: Please sponsor dbab, the dnsmasq-based ad-blocker

[Riley Baird]

 I'd like to bring your attention again to dbab, the innovative
 dnsmasq-based ad-blocker that will benefit most people. I'll keep
 reposting this request regularly in hoping someone will pay attention
 to it. Here is my sales-pitch again:

I'm not a DD, so I can't sponsor your package, but here are some things
that I've noticed:

* You don't have a d/watch file, despite the fact that you use Github's
'release' feature. https://wiki.debian.org/debian/watch

* d/changelog should only document Debian-related changes. Since your
package has not yet been included in Debian, you only need one entry for
the release that you are actually packaging.

* In d/control, you say that debhelper version 9 or greater is required,
but d/compat contains 8. I've successfully compiled after changing
d/compat to 9, so unless you had a special reason to use 8, I think
that you should change it.

* d/docs is empty. You should include dbab.html.

Good luck getting your package into Debian!

Riley


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/548b4c9a.3070...@bitmessage.ch

Bug#769375: RFS: lightmdeditor/1.0-2 [ITP]

[Riley Baird]

On 13/12/14 05:50, Bhavyanshu Parasher wrote:
 
 Adding a follow-up to the RFS informing about the update in package. The
 new URL for .dsc file has changed since the version has been incremented
 after adding new patches. Please use this one.
 
 dget -x
 http://mentors.debian.net/debian/pool/main/l/lightmdeditor/lightmdeditor_1.0-3.dsc
 
 
 To access further information about this package, please visit the
 following URL:
 http://mentors.debian.net/package/lightmdeditor
 
 Also you can check github repository :
 https://github.com/bhavyanshu/lightmd_editor
 
 Changes since last upload:
 
 lightmdeditor (1.0-3) unstable; urgency=medium
 
   * Minor performance tweaks
   * Fixed file dialog issues
   * Fixed tab size bug and handling of tab index when tabs are closed
 
  -- Bhavyanshu Parasher a...@bhavyanshu.me  Fri, 12 Dec 2014 19:20:43
 +0530
 
 Regards,
 Bhavyanshu Parasher

I'm not a DD, so I can't sponsor your package, but here are some things
I've noticed:

* You've accidentally made a native package, but this software has an
upstream and is not solely developed for Debian. Replace the contents of
d/source/format with 3.0 (quilt) and create a .orig.tar.xz file.

* d/changelog records only Debian-specific changes, not upstream changes.

* The way you've done versioning upstream is likely to be incompatible
with Debian's way of versioning. In Debian, everything after the dash
(-) is seen as a Debian-specific revision. It would make more sense to
call your upstream version 1.0.3, and make the Debian version 1.0.3-1


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/548b5296.3070...@bitmessage.ch

Re: Facilitating contributions by newcomers

[Riley Baird]

 Tasks
 =

 I see a task having, at least, the following properties:

   * A specific objective (bug fix, enhancement, debugging, cleanup,
 documentation, translation, ...). This should probably be tied to a
 Debian bug number.
 
 I would like for check-all-the-things to have support matching files
 based on MIME type and most of the existing tests to have associated
 MIME types.
 
 https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git

I'm thinking that I could just create a new file data/mime and put the
following in it:

[mime]
command = file --mime-encoding {files}

It seems to work, but when it is run, most non-text files just read as
'binary', so I doubt that this would be very helpful. If file is run
without the --mime-encoding flag, it normally guesses correctly, but it
doesn't present it in a 'mime' format.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54611d6f.20...@bitmessage.ch

Re: Facilitating contributions by newcomers

[Riley Baird]

I agree, it is sometimes difficult to get someone to actually upload
your package.

Perhaps to encourage mentors, they too could get accomplishments for
sponsoring packages. There could even be a small prize for the DD who
sponsors the most packages in a given year.

On 11/11/14 08:12, Roger Light wrote:
 Hi there,
 
 I think this is a worthwhile idea, but would like to suggest that if
 you're going to go down the approach of badges/accomplishments then it
 would be good to consider how to encourage existing DDs to become
 active in mentoring.
 
 My experience is that making the package is the easy bit - the tricky
 bit is getting someone to take notice, provide feedback and eventually
 upload the package.
 
 Regards,
 
 Roger
 
 
 On Sun, Nov 9, 2014 at 7:20 PM, Christian Kastner deb...@kvr.at wrote:
 The first steps in contributing to Debian are usually the hardest.
 Normally, new contributors are pointed to the standard docs [eg:
 1,2,3,4,5], but processing such an amount of information is often a
 daunting task, and not a very fun one either.

 On the other hand, we have quite a few mentors who would like to help,
 but often do not have the bandwidth to walk a mentee through the entire
 process of, say, packaging a new software, or to mentor someone
 responding to a RFH.

 The WNPP list in itself is useful, but when looking at it again
 recently, I distinctly recalled how foreign most of the packages were to
 me when I first started contributing -- not a great motivator into
 getting involved with something. And I recognized a number of RFHs that
 have received numerous replies over the time, but couldn't be followed
 up upon with because RFHs are frequently the result of a lack of time in
 the first place (openldap anyone?).


 With the recent gamification of just-about-everything, I was wondering
 whether following such an achievement-oriented approach, with
 opportunities for contribution formulated as a list of specific tasks,
 instead of general avenues, would be helpful in overcoming this initial
 difficulty. (This would be in addition to mentors.debian.net and other
 established avenues for entry to Debian, not a replacement).


 Tasks
 =

 I see a task having, at least, the following properties:

   * A specific objective (bug fix, enhancement, debugging, cleanup,
 documentation, translation, ...). This should probably be tied to a
 Debian bug number.

   * A description of the required skills (packaging, debugging, C, ...)

   * A difficulty rating (1:low to 5:very high)

   * An estimation for the amount of work to be done (hours, days)

   * An urgency (influenced by severity, popcon, ...)

   * A list of one or more mentors will to help.


 Benefits for Mentees
 

 For mentees, this would:

   * Provide a much simpler entry point into contributing to Debian.
 Mentees would be able to start with smallish tasks fitting their
 skill and interest profile. They could start contributing without
 becoming overwhelmed with dozens of pages of dense documentation.

   * I expect that would to eventually lead to a better understanding
 of Debian technically, and to closer personal contacts to the
 community.

   * Later on, they could progress to the more difficult tasks, in
 preparation towards eventual DM or DD status.


 Benefits for Mentors
 

 For mentors, I believe the benefits are even greater:

   * Mentors willing to help but lacking time for full mentorship could
 still help with smaller tasks. Every little bit counts.

   * A new avenue for getting things fixed in Debian (QA). Instead of
 having ancient O, RFA, and RFH bugs, some of which have been
 proven to be insurmountable, the relevant packages can be improved
 step-by-step.

   * In a similar vein, regular Maintainers could off-load some of
 their work to mentees. I've seen enough bugs in packages where the
 only blocker seems to be lack of time.

   * Mentors could get another perspective on the history of a mentee's
 work within Debian.


 Costs
 =

 All in all, I think the additional cost to mentors wouldn't be that
 great. It should be easy to write up the tasks: that does not require
 time, only a lot of experience.


 I'd appreciate feedback on the idea; and if this turns out to be
 worthwhile I'll look into an implementation.

 Christian


 [1] https://www.debian.org/doc/debian-policy/
 [2] https://www.debian.org/doc/manuals/maint-guide/
 [3] https://www.debian.org/doc/manuals/developers-reference/
 [4] http://mentors.debian.net/
 [5] Package how-can-i-help


 --
 To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/545fbe79.8020...@kvr.at

 
 


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 

Bug#765893: streql - Constant-time string comparison

[Riley Baird]

If your only concern is if the strings are equal, or which is the
shortest, then I agree that constant-time evaluation would not be
important to you. For that reason, you probably wouldn't need streql;
you could just use the built-in functions.

On 30/10/14 14:44, Leslie S Satenstein wrote:
 Here is a question for you
 Why is it necessary to test the string match for the entire length if the 
 strings disagree with the first byte?
 When one uses a string compare, we want to know if the strings are equal, or 
 which of the two is the lower collating one.   
 That would be done, for example in a logic design where one has multiple 
 strings, and one wants to choose the lowest collating string or at least the 
 string that is equal. 
 
 Consider merging two files sorted in string order and now you wish to perform 
 a merge.
 Suppose the files are in the order of 200,000 records each. Or, if in 
 banking, or government applications, in the order of 20 million records per 
 file. 
 
  Regards 
  Leslie
  Mr. Leslie Satenstein
 Montréal Québec, Canada
 
 
  
   From: Riley Baird bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch
  To: Leslie S Satenstein lsatenst...@yahoo.com 
 Cc: debian-secur...@lists.debian.org debian-secur...@lists.debian.org; 
 765...@bugs.debian.org 
  Sent: Wednesday, October 29, 2014 4:16 PM
  Subject: Re: streql - Constant-time string comparison

 On 30/10/14 01:34, Leslie S Satenstein wrote:
 Hi Riley

 Suppose the strings are 10k bytes each (10240), but they differ at byte 
 zero, 
 where is the break instruction to stop the compare?
 
 Why would there need to be a break instruction? That would mean that the
 time taken to compare strings of equal length would change depending on
 the length of the string, unless I'm mistaken.
 
 The code needs an addition to the for loop as shown below. 
 In place of xor, the return of a comparison when non zero is encountered 
 would allow one to know if string x  string y or the contrary.
 
 Sorry, but I don't understand what you mean. Why is it important to be
 able to know whether string x  string y or vice versa?
 
 
 
   Regards 
   Leslie
   Mr. Leslie Satenstein
 Montréal Québec, Canada
 
 
 
 --
 To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/54514b28.70...@bitmessage.ch
 
 

 


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5452bf08.6090...@bitmessage.ch

Bug#765893: streql - Constant-time string comparison

[Riley Baird]

On 29/10/14 17:00, Joel Rees wrote:
 2014/10/29 4:59 Riley Baird 
 bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch:

 On 29/10/14 00:20, Joel Rees wrote:
 On Tue, Oct 28, 2014 at 12:08 PM, Riley Baird
 bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch wrote:
 Dear debian-security,

 I am looking for a sponsor for my package streql.

 In Python, the code for testing the equality of strings is susceptible
 to a timing side channel attack. The package 'streql' provides a
 function for comparing strings of equal length in equal time,
 regardless
 of the content of the strings.

 * Package name: streql
   Version : 3.0.2-1
   Upstream Author : Peter Scott pe...@cueup.com
 * URL :https://github.com/PeterScott/streql
 * License : Apache 2.0
   Section : python

 It builds those binary packages:

 python-streql - Constant-time string comparison (Python 2)
 python3-streql - Constant-time string comparison (Python 3)
 pypy-streql - Constant-time string comparison (PyPy)

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

 http://mentors.debian.net/package/streql

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

 dget -x
 http://mentors.debian.net/debian/pool/main/s/streql/streql_3.0.2-1.dsc

 Changes since last upload:

 * Initial release (Closes: #764443)

 Regards,
 Riley Baird

 Let me try this suggestion again:

 ---
 // The core function: test two regions of memory for bytewise equality.
 static int equals_internal(const char *x, unsigned int xlen, const
 char *y, unsigned int ylen) {

 int minlen = ( xlen  ylen ) ? ylen : xlen;
 int i, result = 0;

 for (i = 0; i  minlen; i++) result |= x[i] ^ y[i];

 return ( xlen == ylen )  ( result == 0 );
 ---

 I haven't tested it, but I think the corner case I'm thinking about is
 fairly clear.

 As far as I can tell, your code ensures that even if the strings are of
 different length, an equality calculation should be performed anyway,
 however returning 0, on the grounds that this would make it more
 difficult for an attacker to know that the two strings entered were of
 different lengths. Is this right?

 
 Yeah.
 
 It still leaks length information, but not as obviously.
 
 You could add a busy loop to push the leak to the other side of the sweep.
 
 You could even play games with the busy loop to randomly extend it beyond
 the place it would naturally terminate, just to reduce the incentive to
 look. (Making sure your pseudo-random selection code is not data dependent,
 of course.)
 
 You could change the semantics of the API to allow making the execution
 time depend on the length of attacker's guess.
 
 Of course, it's not really hard to get true constant compare times, and
 that's what I think I'd aim at.

I've taken your code, and I've also done the required Python
translation. You can see the pull request here:
https://github.com/PeterScott/streql/pull/3

I'm reluctant to make the changes that you mentioned above, because from
what I can tell, the objective of streql is to ensure that for a given
length of string, the time taken to determine equality is constant.

Of course, the changes that you mentioned could be applied only to
strings where the length is unequal, but if the same input is used
twice, and the time taken for each operation is different, then that
would alert an attacker that the strings are of different lengths, which
takes away the whole point of the exercise.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54509f7d.9050...@bitmessage.ch

Bug#765893: streql - Constant-time string comparison

[Riley Baird]

On 29/10/14 19:55, Richard van den Berg wrote:
 On 28-10-14 20:59 , Riley Baird wrote:
 As far as I can tell, your code ensures that even if the strings are of
 different length, an equality calculation should be performed anyway,
 however returning 0, on the grounds that this would make it more
 difficult for an attacker to know that the two strings entered were of
 different lengths. Is this right?
 
 Pardon my ignorance, but how much more difficult does it actually become
 to determine the two inputs are of different length? In the original the
 function returns right away if xlen != ylen. If the attacker can control
 one of the inputs (say x), the change proposed by Joel will cause the
 time of the compare to increment when xlen in increased until xlen ==
 ylen. If this can be observed with enough precision the same objective
 can be achieved.

Good point. Perhaps this could be fixed by,

origleny=len(y)

while len(x) = len(y):
y += '0'

result = i = 0
for i in xrange(len(x)):
result |= ord(x[i]) ^ ord(y[i])
return result == 0 and len(y) == origleny

This way, the time taken to complete the function will increase even
after xlen = ylen

However, with this I'm concerned that the 'while' loop will take up too
much time, thus still allowing an attacker to see when the string
lengths become equal. Is there a quicker way to append zeros to a string
such that it is equal in length to the other string?


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/545146d3.5060...@bitmessage.ch

Bug#765893: streql - Constant-time string comparison

[Riley Baird]

On 30/10/14 01:34, Leslie S Satenstein wrote:
 Hi Riley
 
 Suppose the strings are 10k bytes each (10240), but they differ at byte zero, 
 where is the break instruction to stop the compare?

Why would there need to be a break instruction? That would mean that the
time taken to compare strings of equal length would change depending on
the length of the string, unless I'm mistaken.

 The code needs an addition to the for loop as shown below. 
 In place of xor, the return of a comparison when non zero is encountered 
 would allow one to know if string x  string y or the contrary.

Sorry, but I don't understand what you mean. Why is it important to be
able to know whether string x  string y or vice versa?

  Regards 
  Leslie
  Mr. Leslie Satenstein
 Montréal Québec, Canada


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54514b28.70...@bitmessage.ch

Bug#765893: RFS: streql/3.0.2-1 [ITP] -- Constant-time string comparison

[Riley Baird]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package streql

* Package name: streql
  Version : 3.0.2-1
  Upstream Author : Peter Scott pe...@cueup.com
* URL : https://github.com/PeterScott/streql
* License : Apache 2.0
  Section : python

It builds those binary packages:

python-streql - Constant-time string comparison (Python 2)
python3-streql - Constant-time string comparison (Python 3)
pypy-streql - Constant-time string comparison (PyPy)

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

http://mentors.debian.net/package/streql

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

dget -x
http://mentors.debian.net/debian/pool/main/s/streql/streql_3.0.2-1.dsc

Changes since last upload:

* Initial release (Closes: #764443)

Regards,
Riley Baird


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54430851.5050...@bitmessage.ch

Re: new to linux

[Riley Baird]

On 04/09/14 07:01, FERNANDO CROWLEY wrote:
 looking  for some direction where to start contributing newbie
 Thanks  
 
https://www.debian.org/intro/help

sudo apt-get install how-can-i-help


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5408016b.3030...@bitmessage.ch

Bug#758266: RFS: air-quality-sensor/0.1.1-3 [ITP]

[Riley Baird]

Hi Benedikt,

I'm not a DD, so I can't sponsor your package, and I don't have the
Indoor Air Monitor, so I can't test it. However, looking over your
package, afaict everything is fine, except you should remove the
unnecessary comments in d/rules and d/watch.

Great job on the package!

Riley Baird


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53fe677e.4080...@bitmessage.ch

Re: Bug#759479: RFS: profanity/0.4.4-1 [ITP]

[Riley Baird]

Hi Dariusz,

I'm not a DD, so I can't sponsor your package, but here's my review:

d/changelog:
-Remove the note about the UNRELEASED 0.4.3

d/copyright:
-You should release the Debian-specific changes also with the OpenSSL
exception
-src/tools/p_sha1.c and src/tools/p_sha1.h appear to be in the public domain

I haven't been able to test the software yet since libstrophe hasn't
been accepted yet, but I can see that it's in the NEW queue.

Good luck on getting your package into Debian,

Riley Baird


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53fe7143.4020...@bitmessage.ch

Bug#759311: RFS: node-base64-url/1.0.0-1 [ITP]

[Riley Baird]

Hi Joseph,

Thanks for making the package for Debian! I'm not a DD, so I can't
sponsor your package, but here's my review:

d/control:
-Don't put each dependency on a different line.
-In your description, you don't need to include a description of what
node.js is, rather, you can mention that your package makes use of node.js

d/copyright:
-Use the author's full name (Joaquim José F. Serafim) instead of their
Github username.

d/rules:
-Remove the commented lines; only keep what is necessary.

d/watch:
-Why have you used fakeupstream? Can it actually detect new upstream
versions, and if so, how? If not, then you should just make a watch file
with some comments explaining that upstream doesn't provide a
uscan-compatible method of getting releases.

README.md:
This is really upstream's problem, but the sample usage of
base64url.escape needs to have quotes around the input to run correctly;
furthermore all outputs should have quotes around them as well. Perhaps
you could patch this and then send the fix upstream?

Once you have done this, you may wish to contact the Debian JavaScript
Maintainers[1] to see if you can get one of them to sponsor your package.

Good luck in getting your package into Debian!

Riley Baird


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53fc3b53.4080...@bitmessage.ch

Bug#759311: RFS: node-base64-url/1.0.0-1 [ITP]

[Riley Baird]

 d/control:
 -Don't put each dependency on a different line.
 
 This is actually common practice as having them on separate lines makes it 
 easier to review a diff for future versions. 

Okay, thanks, I didn't know that.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53fc4eb5.80...@bitmessage.ch

Bug#758918: RFS: python3-pyelliptic/1.5.3-1 [ITP] -- High level Python 3 wrapper for OpenSSL

[Riley Baird]

 1. d/control: create a VCS to control your debian/ versions. You can
 use github or other. So, add the Vcs-Browser and Vcs-{Git|Svn|Cvs} to
 d/control.

Done (I've used Gitorious).

 2. d/copyright:
   - The code is GPL-3, not GPL-3+.
   - The upstream range years is 2010-2014.

Changed.

 3. Add a d/watch file and put inside an explanation about the upstream
 not provide versioned downloads.

Okay, done. (A watch file will be able to be made when #395439 is fixed.)


I've just uploaded the new package to mentors.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53fad923.3030...@bitmessage.ch

Bug#758918: Made working watch file!

[Riley Baird]

I just found out how to make a watch file that works with
python3-pyelliptic. As it turns out, the maintainer uploads releases to
PyPI, so a watch file can be generated.

I've had to change the version number of the .orig.tar.gz, as I'm using
one made from a git snapshot. (I can't use the given tarball because the
OpenSSL exception was not yet granted in that.)

I've uploaded the version with the watch file to mentors.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53faf30c.50...@bitmessage.ch

Bug#758918: Made working watch file!

[Riley Baird]

Hi,

Ah, I thought that the date referred to the time of download. I've
changed the date to 2014-06-17 and I've uploaded the new package to mentors.

Cheers,

Riley

On 26/08/14 05:55, Eriberto Mota wrote:
 Hi,
 
 The problem is you added an inexistent git commit number as upstream
 version. The commit 7810c7afd8 was registered on 2014-06-17.
 
 Cheers,
 
 Eriberto
 
 
 2014-08-25 5:25 GMT-03:00 Riley Baird
 bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch:
 I just found out how to make a watch file that works with
 python3-pyelliptic. As it turns out, the maintainer uploads releases to
 PyPI, so a watch file can be generated.

 I've had to change the version number of the .orig.tar.gz, as I'm using
 one made from a git snapshot. (I can't use the given tarball because the
 OpenSSL exception was not yet granted in that.)

 I've uploaded the version with the watch file to mentors.
 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53fba31d.7020...@bitmessage.ch

Bug#754441: VCS Created

[Riley Baird]

I've just created a repo on pkg-gnustep. You can find it here:
git+ssh://your_alioth_usern...@scm.alioth.debian.org//git/pkg-gnustep/pkg-gmastermind.app.git

I've also added corresponding Vcs-Git: and Vcs-Browser: fields in d/control.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e9b1ab@bitmessage.ch

Bug#754441: gmastermind.app

[Riley Baird]

 You can add this yourself in the task list, they should be self explanatory.

 Are you talking about this task list:
 http://blends.debian.org/junior/tasks/puzzle ? If so, I don't see
 anywhere that I can edit it. Do I need to be part of the Alioth project
 first?
 
 This is maintained by the Debian Blends team (currently - there is no
 practical need to but there was no request to change this).  I'd happily
 proxy this entry for you.  However, for the moment the package is not
 yet in Debian nor the packaging in any Blends VCS.  I have recommended
 to create a Debian Jr. VCS to do the packaging which has not yet
 happened as far as I know.  Perhaps also Debian Games Git would fit and
 than the information about the package becomes available for the tasks
 page you mentioned above ...

Ah, okay, it would be better to wait until the package is in Debian
before editing the page.

As for a VCS, I've heard a lot about having one. tbh, gmastermind.app
probably won't need one, as it doesn't look like it will be upgraded any
time in the future, but I'm fine either way.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dcb680.7000...@bitmessage.ch

Bug#754441: gmastermind.app

[Riley Baird]

 As for a VCS, I've heard a lot about having one. tbh, gmastermind.app
 probably won't need one, as it doesn't look like it will be upgraded any
 time in the future, but I'm fine either way.
 
 That's no point.  The *packaging* might change over time and if you want
 some help in packaging you can most effectively get it if the packaging
 is in VCS.  I have set one precondition for my Sponsoring of Blends
 effort that the package is maintained in VCS for good reasons.

Oh, okay. I was actually offered a VCS with pkg-gnustep, but I turned it
down because I assumed that I wouldn't need one. Seeing as I'll probably
need a VCS for maintaining this package, I'll try asking them if the
offer is still valid.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dcbef0.4010...@bitmessage.ch

Bug#754441: pkg-gnustep VCS

[Riley Baird]

Hi Yavor,

A while ago, you offered me a VCS with pkg-gnustep's Alioth project, and
I declined because I thought that my package would be too trivial to
need one.

What I didn't know was, that practically all packages are expected to
have a VCS.

Would it still be possible to set up a VCS with pkg-gnustep's Alioth
project?

Yours thankfully,

Riley Baird


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dcc069.2030...@bitmessage.ch

Bug#754441: Copyright Problems Solved

[Riley Baird]

Due to consensus from upstream, and the Debian project, I have uploaded
a new version of the package, with the copyright file modified to
indicate that the entire package is licensed under GPL-2+.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53db5b04.9070...@bitmessage.ch

Bug#754441: gmastermind.app for Debian Jr

[Riley Baird]

Greetings, -jr!

I am trying to find a sponsor for my package, gmastermind.app. I
submitted an RFS to this list a while ago, but in retrospect, I did not
explain the relevance to debian-jr.

Mastermind is a game that encourages logic and critical thinking for
children (and adults) of any age. The rules are not difficult to learn,
but for a surefire winning strategy, both patience and skill are required.

gmastermind.app is lightweight (the .deb is only 23.9kB), so there is no
need to worry about it using too much space.

Specifically, I think that gmastermind.app should be included in the
Recommends field of the junior-puzzle package.

If you are interested, or just want more information, then please do not
hesitate to respond!

Thanks for reading,

Riley Baird


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53db5ff0.6060...@bitmessage.ch

Bug#754441: gmastermind.app for Debian Jr

[Riley Baird]

 You can add this yourself in the task list, they should be self explanatory.

Are you talking about this task list:
http://blends.debian.org/junior/tasks/puzzle ? If so, I don't see
anywhere that I can edit it. Do I need to be part of the Alioth project
first?

 Join the Debian Jr Alioth project. Someone else than me has to approve
 you though, I haven't migrated to my Debian account on Alioth yet. Tell us
 if you don't get access quickly

I've sent through a request.

 I assume that the package uploaded to mentors.d.n today is the current
 one for the RFS

Yes, it is.

 I'll have a look at this within a week. There seem to be quite a lot of good
 review already.

Thanks. Hopefully, all of the problems will have already been ironed out. :)

 In the long run, I encourage you maintain gmastermind.app in the
 Debian Jr team, and, thus, becoming a team member!

Yes, in the long run, that is definitely something that I would like to do!


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53db7e1c.1090...@bitmessage.ch

Bug#754441: GMastermind Relicensing

[Riley Baird]

Hi Riccardo,

I'm glad that you're fine with releasing your contributions under GPL-2+.

I'll send your arguments to debian-legal, and we'll see what they make
of them; you might be right.

Riley

On 24/07/14 07:49, Riccardo Mottola wrote:
 Hi Riley,
 
 the program comes with a COPYING file, which standard to contain the
 license used. In thiscase, it contains the GPL v2 or later.
 
 In other words:
 1) the program headers contain reference to the GPL v2 or later
 2) the COPYING file distirbuted with GMastermind contains the GPL v2 or
 later text
 3) only the readme file contains a reference to the program being
 distributed GPL v2 without the or later clause
 
 To me it is clear that the intent is the program to be under GPLv2 or
 later and that the readme.txt contains a small omission. The source
 files and the COPYING file have priority!
 
 Given this, I already consider all my contributions under  the GPL v2
 or later clause.
 
 Riccardo
 
 On 2014-07-22 09:26:48 +0200 Riley Baird
 bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch wrote:
 
 Hi Riccardo,

 Even if you're not the original author, if you've made any modifications
 to the work, you own copyright on them.

 For example, Linus Torvalds is not the only copyright holder of Linux;
 the other ~5000 contributors all have copyright on it as well. This is
 why the kernel can't be upgraded to GPL-3, even if Linus wants to.

 So, having a statement from you would be helpful. (You are only
 relicensing *your* contributions)

 Also, what do you mean by the COPYING is the full GPL v2 or later?

 Riley
 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d22cb7.9060...@bitmessage.ch

Bug#754441: GMastermind Relicensing

[Riley Baird]

Hi Riccardo,

Even if you're not the original author, if you've made any modifications
to the work, you own copyright on them.

For example, Linus Torvalds is not the only copyright holder of Linux;
the other ~5000 contributors all have copyright on it as well. This is
why the kernel can't be upgraded to GPL-3, even if Linus wants to.

So, having a statement from you would be helpful. (You are only
relicensing *your* contributions)

Also, what do you mean by the COPYING is the full GPL v2 or later?

Riley

On 20/07/14 20:40, Riccardo Mottola wrote:
 Hi Riley,
 
 
 thanks for inquirying. I am not the original author of GMastermind, thus
 I cannot relicense it, if you need that explicit statement, you need
 to ask Marko Riedel. I see you put it in CC, I do not know if that email
 address is current though. We just got permissions to incorporate
 GMastermind in GAP.
 
 I think the original author licensed it under GPLv2+. The README file is
 misleading and probably written in haste. Not only the header files
 explicitely say or later, but also the COPYING is the full GPL v2 or
 later statement.
 The README file says to refer to gpl.txt, this is probably inaccurate
 and COPYING was intended. I would say that the original intentions are
 pretty clear.
 
 Just in the case, I corrected the README file and also updated COPYING
 to the current GPL v2+ file from fsf, it had even the old FSF address.
 Perhaps that statement should be removed totally and just COPYING should
 be included.
 
 Riccardo
 
 Riley Baird wrote:
 Hi,

 I'm currently packaging GMastermind for Debian. In the process, it has
 been discovered that, according to a technical reading of the README,
 GMastermind is licensed under GPL-2 only (i.e. without or, at your
 option, any later version).

 However, according to the headers on the source files, it would appear
 that the intention was to license under GPL-2 or any later version.

 If you are fine with releasing your contributions under GPL-2+, please
 copy the following statement, fill in your name and send it to the email
 addresses below. (If not, then please send a message anyway so we know.)

 -

 I, YOUR NAME, irrevocably give permission to use, redistribute, modify
 and to distribute modified copies of any and all of my contributions to
 the program GMastermind under the terms of the GNU General Public
 License as published by the Free Software Foundation, either version 2
 of the License, or (should anyone choose to do so) any later version.

 No warranty, not even the implied warranties of merchantability or
 fitness for a particular purpose, is given by this license grant.

 ---

 Please send this statement to the following email addresses:
 bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch
 754...@bugs.debian.org
 pkg-gnustep-maintain...@lists.alioth.debian.org
 gap-dev-disc...@nongnu.org

 NOTE: If you don't want to be bothered by licensing issues again, send
 the following statement in instead.

 

 I, YOUR NAME, release my contributions to the program GMastermind
 into the public domain. This applies worldwide.

 In some countries, this may not be legally possible; if so:

 I grant anyone the right to use this my contributions to the program
 GMastermind for any purpose, without any conditions, unless such
 conditions are required by law.

 -

 Thanks in advance,

 Riley Baird

 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ce1238.3020...@bitmessage.ch

Bug#754441: GMastermind Relicensing

[Riley Baird]

Hi,

I'm currently packaging GMastermind for Debian. In the process, it has
been discovered that, according to a technical reading of the README,
GMastermind is licensed under GPL-2 only (i.e. without or, at your
option, any later version).

However, according to the headers on the source files, it would appear
that the intention was to license under GPL-2 or any later version.

If you are fine with releasing your contributions under GPL-2+, please
copy the following statement, fill in your name and send it to the email
addresses below. (If not, then please send a message anyway so we know.)

-

I, YOUR NAME, irrevocably give permission to use, redistribute, modify
and to distribute modified copies of any and all of my contributions to
the program GMastermind under the terms of the GNU General Public
License as published by the Free Software Foundation, either version 2
of the License, or (should anyone choose to do so) any later version.

No warranty, not even the implied warranties of merchantability or
fitness for a particular purpose, is given by this license grant.

---

Please send this statement to the following email addresses:
bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch
754...@bugs.debian.org
pkg-gnustep-maintain...@lists.alioth.debian.org
gap-dev-disc...@nongnu.org

NOTE: If you don't want to be bothered by licensing issues again, send
the following statement in instead.



I, YOUR NAME, release my contributions to the program GMastermind
into the public domain. This applies worldwide.

In some countries, this may not be legally possible; if so:

I grant anyone the right to use this my contributions to the program
GMastermind for any purpose, without any conditions, unless such
conditions are required by law.

-

Thanks in advance,

Riley Baird


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53c38e86.6060...@bitmessage.ch

Bug#754441: RFS: gmastermind.app/0.6-1 [ITP] -- GNUstep based Mastermind (TM) clone

[Riley Baird]

 Well, it could be argued if this little notice in README carries more
 legal weight than the intent expressed in the source files (the notice
 does not follow the recommended form and gpl.txt is missing)...
 
 We (pkg-gnustep) had an inititive 6 or 7 years ago to re-check the
 licenses of all GNUstep packages as the license of the GNUstep core
 libraries was upgraded to LGPLv3+ (the summary is still here:
 https://wiki.debian.org/DebianGNUstep/TODO).  Unsurprisingly, many of
 the supposed GPLv2-only apps were licensed as such unintentionally by
 their authors, or were presumed by us to be GPLv2-only based on
 assumptions very similar to yours.  GMastermind is much more likely to
 be GPL-2+ than GPL-2; I am quite certain about that.  It's best to
 clarify though, so that you could sleep well.

If you're worried about the incompatibility between LGPL3 and GPL2, you
don't have to be. gmastermind.app is only linking to the LGPL3
libraries, so the copyleft doesn't apply to it (because of the linking
exemption).

 To be sure of this, though, I'd have to get confirmation from all of
 the contributors; writing to upstream wouldn't be enough. Should I
 try to do this?
 
 I think it would be enough to contact the GAP folks, they can reach
 the others if necessary.

GAP cannot provide us with legal certainty. In fact, while we need their
confirmation (due to the GNUstep Application Team 2011 copyright),
their confirmation is not enough. I've written to all of the copyright
holders, and if they all agree, then I'll change the license. There's no
reason to postpone putting the package into Debian, though.

 Thanks; no further remarks from me.  Good luck in your sponsor quest.

Thanks; I've fixed the problems that you've described. Now, off to find
a sponsor!


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53c39871.1040...@bitmessage.ch

Bug#754441: RFS: gmastermind.app/0.6-1 [ITP] -- GNUstep based Mastermind (TM) clone

[Riley Baird]

On 14/07/14 19:45, Yavor Doganov wrote:
 Riley Baird wrote:
 If you're worried about the incompatibility between LGPL3 and GPL2,
 you don't have to be. gmastermind.app is only linking to the LGPL3
 libraries, so the copyleft doesn't apply to it (because of the
 linking exemption).
 
 You are very wrong here.  A GPLv2-only program cannot link with a
 LGPLv3 library.  Because of this the license of GNUstep Base and GUI
 was downgraded to LGPLv2.1+.  Unfortunately.
 
 This is also the reason why glibc's license has not been upgraded; it
 would make all GPLv2-only stuff undistributable.

Ah, you're right. The problem isn't the LGPL3; it's the GPL2's
requirement for all libraries to be GPL2-compatible.

Ah well, I guess it's good in the interests of compatibility that
GNUstep's license remained at v2.1 (for all of the other problems that
may remain).


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53c3aba8.6020...@bitmessage.ch

Bug#754441: RFS: gmastermind.app/0.6-1 [ITP] -- GNUstep based Mastermind (TM) clone

[Riley Baird]

 I don't think that this was the author's intention.  There are plenty
 of Info.plist files where GPL 2.0 is stated, but it doesn't mean GPL
 2.0 only.  To be sure, you could clarify with upstream (write to
 gap-dev-disc...@nongnu.org rather than via Savannah's interface).

From a legal point of view, GPL 2.0 does mean GPL 2.0 only, but I agree
that this probably wasn't the author's intention. To be sure of this,
though, I'd have to get confirmation from all of the contributors;
writing to upstream wouldn't be enough. Should I try to do this?

  - You use $(optim) but the conditional to define the variable is
missing.

 Removed
 
 You'd better add the conditional so that the package can be easily
 rebuilt for debugging without source modifications (debug=yes defines
 some debugging macros, it's not only the optimization level).  We
 should probably add this snippet to config.mk instead of duplicating
 it everywhere.

Done

 Hmm.  This line is redundant:
 
   dh_link usr/games/GMastermind usr/games/gmastermind.app
 
 And more importantly, you are not creating the symlink from /usr/share
 to /usr/lib so the app won't be able to find its own resource bundle.
 Also, you must move Resources to a directory named after the app so
 that it is clear that it belongs to this package.
 Something like this (untested):
 
 override_dh_link:
   mv $(d_app)/usr/bin/GMastermind $(d_app)/usr/games
   rm -rf $(d_app)/usr/bin
   mv $(d_app)$(GNUSTEP_SYSTEM_APPS)/*.app/Resources \
 $(d_app)/usr/share/GNUstep/GMastermind.app
   dh_link /usr/share/GNUstep/GMastermind.app \
 $(GNUSTEP_SYSTEM_APPS)/GMastermind.app/Resources

Done. (I've added some mkdir -p lines in there so that it compiles.)

 gmastermind.app.6:
 Likewise.  The manpage should be named after the binary, and you
 already have GMastermind.6.

 Are you sure? People that have typed `apt-get install gmastermind.app'
 will most likely try `man gmastermind.app' next.
 
 Yes, I am sure.  There is no guarantee that a binary package should
 contain a program of the same name, and never was.  The user is armed
 with dpkg -L and can figure out what to start, configure, or read
 after installation.

Removed

I've just put the new package is on mentors


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53c1c079.2080...@bitmessage.ch

Bug#754441: RFS: gmastermind.app/0.6-1 [ITP] -- GNUstep based Mastermind (TM) clone

[Riley Baird]

On 11/07/14 17:46, Yavor Doganov wrote:
 Thanks for packaging a GNUstep game.  Unfortunately I can't sponsor.

That's okay!

  * License : GPL2
 
 The license is GPL-2+, AFAICS.

*Most* of GMastermind is released under GPL-2+. However, the README
indicates that, as a whole, GMastermind is released under GPL-2 (so, it
would apply to all files without a license header).

Section : gnustep
 
 A more appropriate section would be games.

Done

   * Removed broken, unnecessary menu items
 
 This should not be in the changelog.

Done

Remove libbobjc-4.9-dev and libgcc-4.9-dev -- these are fulfilled
by gnustep-make and are volatile, you should not hardcode them.
You may as well remove gnustep-make as libgnustep-base-dev will
always depend on it.  You only need a versioned dependency on -make
if you require a particular feature.
Likewise, libgnustep-base-dev is fulfilled by libgnustep-gui-dev.

Done

  - Depends:
Remove gnustep-gpbs.  The package is gone so your package will not
be installable.  GNUstep Backend dependencies are volatile too, and
are added automatically via libgnustep-gui's shlibs.  No package
should use them directly, that's asking for trouble and pain
during GNUstep transitions.

Done. Was gnustep-gpbs replaced by another package and should I put that
one as a dependency?

  - You can include /usr/share/GNUstep/debian/config.mk instead of
exporting GNUSTEP_* variables.

Done

  - Please use $(MAKE) instead of make, this ensures that sub-makes
work properly.

Done

  - You use $(optim) but the conditional to define the variable is missing.

Removed

  - Why override_dh_userlocal with no recipe?

The build kept stopping on it, so I decided to override it. However,
I've removed it now and the build completes.

  - Just delete GMastermind.desktop -- it is invalid and in a non-standard
location.

Done

  - You should move Resources to /usr/share/GNUstep and install a
symlink, then the lintian override can be removed.
  - Move the /usr/bin symlink to /usr/games here.

Done

 postinst, postrm:
 Completely unnecessary (and broken), delete them.

Done

 gmastermind.app.6:
 Likewise.  The manpage should be named after the binary, and you
 already have GMastermind.6.

Are you sure? People that have typed `apt-get install gmastermind.app'
will most likely try `man gmastermind.app' next.

 gmastermind.app.menu:
 Could be renamed to menu, and would be nice to have a XPM icon for WMs
 that support icons in menus. This is easily done with imagemagick, but
 there are other ways, of course.  You could also include a .desktop file
 and install it in /usr/share/applications.

Added an .xpm file.

 README.Debian:
 I think it's redundant and contains no useful/important information
 for the user.  There's also a thinko (/usr/bin instead of /usr/games).

Removed

 docs:
 Upstream's README is redundant too, no reason to install it
 (information already present in the package description and
 debian/copyright).

Removed

 copyright:
 The Ustream-Name is GMastermind.

Done

 Take a look at (gs)dh_gnustep.  It is not very capable for apps,
 unfortunately, but will add a gnustep-fhs-layout dependency via
 ${gnustep:Depends}.

Do I need to do that for this package? I'll use it in future packages,
but AFAIK, I think that I have met the FHS requirements for this package.

 Once your package is in Debian, please file a wishlist bug against
 gnustep-games so that we don't forget to add it as a dependency.

Okay, will do.

 You are also welcome to join pkg-gnustep and host your package there,
 if you wish so.

Thanks, but I don't think that gmastermind.app will get enough upstream
updates to justify having an Alioth repo.

I've just uploaded the new package with the changes described above to
mentors.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53c079fb.60...@bitmessage.ch