Re: Next autoconf problem for today libdisorder

[Andreas Tille]

Hi Christian,

On Mon, Jun 27, 2016 at 11:57:12PM +0200, Christian Seiler wrote:
> 
> Well, autoconf in and by itself doesn't support testing, automake does,
> which fortunately you're also using.
> 
> I've added a very trivial test from the way I understand how the program
> you're using works, and attached an updated patch to this email. (I've
> also updated the autoconf/automake prerequisites, see my last email.)
> It's actually quite trivial: write a shell script that returns
> successfully (exit code 0) or not. (You can run a C program directly if
> it does return 0 or not depending on the test results, but that doesn't
> apply to ropy directly.) My test applies ropy to the COPYING file
> containing the text of the GPL and checks if the result matches the
> expectations. Feel free to extend/change that to your liking, but as a
> basic functionality check I think that is already useful.

Great.  I applied the patch in Git.
 
> Beware though that if "make check" fails, the package build will also
> fail by default.

Yes.  That's what a test is for. :-)

> (I consider that to be a good thing, just something to
> keep in mind.) I did some test builds on amd64, i386, x32, and arm64,
> and the simple test I created succeeds on all of these platforms.

Thanks for the thorough checking!
 
> Well, in general I would consider pkg-config to be good thing for
> libraries, but I'm not sure here, especially if the circle of consumers
> is a very small circle and they don't appear to be using pkg-config so
> far anyway, so it's probably a waste of time here.

Good to know that you have the same feeling as I had.
 
> In your package, that's already the case, so you can just add the header
> to debian/control.

A, well, yes - I simply forgot this.  In my initial question I assumed
something more on the Build-System would be needed.

> Another thing I noticed: your configure.ac checks for a C++
> compiler, which is unnecessary here, as this is a pure C library.
> You can simply drop the C++ checks and save computing resources.
> I've done that in the updated autoconf.patch I've attached (that
> also contains the unit test).

Cool, thanks.
 
> Anyway: in case you want to know more about autoconf/automake etc.
> I would really recommend  in
> addition to the official documentation of that ecosystem ([1],
> [2], [3], [4]).

I know I should know more about these tools but I need to quite rarely
and the good thing on Debian Mentors is that you (obviously) get
brilliant help if needed.  While beeing really great this on the other
hand decreases the motivation to learn everything be heart. ;-)

Thanks a lot for your very verbose and helpful hints

  Andreas.

-- 
http://fam-tille.de

Re: Next autoconf problem for today libdisorder

[Andreas Tille]

Hi Christian,

On Mon, Jun 27, 2016 at 10:41:28PM +0200, Christian Seiler wrote:
> On 06/27/2016 07:49 PM, Christian Seiler wrote:
> > Other comments regarding the package:
> 
> Oh btw. I just noticed that you don't install the manpage for
> the library function in the -dev package (because d-shlibmove
> doesn't care about manpages, and you don't have an .install
> file for that package). Since upstream includes the manpage,
> I would recommend also shipping it.

The manpage is not installed since it has zero bytes.  (I actially
had a debian/manpages file written but removed it afterwards.)

Thanks for the hint anyway

 Andreas.

-- 
http://fam-tille.de

Bug#828700: RFS: twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1 [binNEW] -- Voice over Internet Protocol (VoIP) SIP Phone

[Peter Colberg]

I have pushed two minor commits:

git show-ref --heads
76e884d7cc340d88924a51505521a5c6d7b7f1b3 refs/heads/master
9b3e492fbc6e923b7fddd9a320abfc8eba57eb03 refs/heads/pristine-tar
ef9654f270da62ba87a112e2a9724ca3fe5466a4 refs/heads/upstream

Peter


signature.asc
Description: PGP signature

Bug#827907: RFS: evil/1.2.12-1 ITP

[Sean Whitton]

Hello,

On Mon, Jun 27, 2016 at 05:32:32PM +0300, Dmitry Bogatov wrote:
> 2. In d/copyright, I think you need to specify copyright years for the
> copyright holders.  Just their names is not enough, since on a desert
> island ~60 years from now with no newer versions of evil available for
> download, the code would become public domain :) (well, I guess the
> old version of the code would be public domain on the mainland too)
> 
> Unfortunately, upstream maintains only list of contributors. So seems
> best thing we can do is to count 60 years from last debian upload.

I'm not sure whether this is likely to be acceptable to the ftp-masters
or not.  Perhaps someone more experienced on debian-mentors can chime
in.

> > 3. Any particular reason you are using gz and not xz compression in
> >gbp.conf?  Also, it might be a good idea to check the tarball into
> >git with pristine-tar so that a sponsor has exactly the same one (I
> >generated my own for testing).
> 
> No. Moved to xz.

I still don't see a pristine-tar branch :)

> 4. Please run the test suite.  Since it uses ERT, dh_elpa_test can run
>the tests for you, though you'll probably need to give it some hints.
>See dh_elpa_test(1) for how to do this: basically, raise to compat
>level 10 and then set DH_ELPA_TEST_* env vars.
> 
> Tests want tty on stdin. Added note and disabled tests. Any good
> ideas, how to run them in background?

It's unlikely that the tty issue is the problem: ERT tests are supposed
to be runnable in batch mode.  Although perhaps evil is different.

First, though, we need to fix your dh_elpa_test usage.  You don't need
DH_ELPA_TEST_ERT_EVAL: dh_elpa_test will automatically load that file
because it contains ERT test definitions.  Instead, you need to use
DH_ELPA_TEST_ERT_HELPER to call `evil-test-initialise' as upstream's
Makefile does.

> 5. Please add a d/watch.
> 
> Problem. Mercurial upstream repository, and tarballs are named not
> after version, but after hashes. I fail to extract anything useful
> from this page: [1]
> 
> [1] https://bitbucket.org/lyro/evil/downloads

Ah.  Seems that we're out of luck: uscan can't do Mercurial tags.

> PS. Your email formatting is amazing. Thank you.

Thanks!  Plaintext e-mail is very efficient if you use it right.

On Mon, Jun 27, 2016 at 05:46:58PM +0300, Dmitry Bogatov wrote:
> 
> > The function `evil-mode' doesn't seem to be properly autoloaded.
> > I.e. if I install elpa-evil-mode and then I open Emacs and type M-x,
> > evil-mode is not available.  However, if I type M-x describe-function
> > RET evil-mode RET it works.  Something is going wrong with the
> > autoloading.
> 
> I think I fixed it. Please, check.

It seems it wasn't enough.  If I move my .emacs.d out of the way and
then run it, and M-x evil-mode, I get this:

Error in post-command-hook (evil-repeat-post-hook): (void-function 
evil-repeat-post-hook)
Error in pre-command-hook (evil-repeat-pre-hook): (void-function 
evil-repeat-pre-hook)

Does that happen for you if you move .emacs.d?  I'm actually testing on
Ubuntu 16.04 instead of Debian but it shouldn't be relevant.

-- 
Sean Whitton

Re: Next autoconf problem for today libdisorder

[Christian Seiler]

On 06/27/2016 10:49 PM, Andreas Tille wrote:
> On Mon, Jun 27, 2016 at 07:49:53PM +0200, Christian Seiler wrote:
>>  - you build tool/ropy, but you never use it? Neither in the test suite
>>(dh_auto_test doesn't do anything) nor do you package that - why?
> 
> Since I wanted to get things working somehow first.  I've now reated a
> libdisorder-tools package (will write a ropy.1 as well). If you could
> help with a sensible test suite - I have no idea how to get this working
> with autoconf.

Well, autoconf in and by itself doesn't support testing, automake does,
which fortunately you're also using.

I've added a very trivial test from the way I understand how the program
you're using works, and attached an updated patch to this email. (I've
also updated the autoconf/automake prerequisites, see my last email.)
It's actually quite trivial: write a shell script that returns
successfully (exit code 0) or not. (You can run a C program directly if
it does return 0 or not depending on the test results, but that doesn't
apply to ropy directly.) My test applies ropy to the COPYING file
containing the text of the GPL and checks if the result matches the
expectations. Feel free to extend/change that to your liking, but as a
basic functionality check I think that is already useful.

Note that adding it to automake will automatically have "make check"
available and then dh_auto_test will call that (unless DEB_BUILD_OPTIONS
contains nocheck), so it's automatically integrated into the package
build without additional things for you to do.

You can also use more complicated test harnesses like TAP or DejaGNU,
but that would be overkill here IMHO.

Appropriate documentation:
https://www.gnu.org/software/automake/manual/html_node/Tests.html
(+ subpages of that)

Beware though that if "make check" fails, the package build will also
fail by default. (I consider that to be a good thing, just something to
keep in mind.) I did some test builds on amd64, i386, x32, and arm64,
and the simple test I created succeeds on all of these platforms.

>>  - you could consider installing a pkg-config file for the library,
>>as it requires linking against -lm. While this works automatically
>>with the shared library, this is not the case for the static
>>library, where you explicitly have to add -lm after libdisorder.a
>>when linking against it
> 
> I have no specific reason not to use pkg-config.  If you recommend this
> I'd happily apply a patch.

Well, in general I would consider pkg-config to be good thing for
libraries, but I'm not sure here, especially if the circle of consumers
is a very small circle and they don't appear to be using pkg-config so
far anyway, so it's probably a waste of time here.

>>  - you install everything into the proper multiarch locations, but
>>libdisorder0 and libdisorder-dev are not Multi-Arch: same, even
>>though they easily could be
> 
> How?

Well, simply add 'Multi-Arch: same' to both packages. M-A: same implies
that the same package can be installed for multiple architectures at
the same time, so you have to take care that 

 - architecture-specific stuff is installed in /usr/lib/$triplet
   (or /usr/include/$triplet for include files that are different on
   different architectures)
 - the rest (e.g. generic includes that are non-architecture dependent
   and hence in /usr/include directly) is identical regardless of the
   architecture a package is built for

In your package, that's already the case, so you can just add the header
to debian/control. (Don't add it to the new -tools package you created
though, because that's not M-A: same.)

Relevant documentation:

https://wiki.ubuntu.com/MultiarchSpec
https://wiki.debian.org/Multiarch

>>  - you don't build the test program (although it doesn't serve as
>>a unit test, because it will never fail unless /dev/urandom is
>>not accessible, so there's no actual check whether the routine
>>works as expected or not - so I don't think that's a problem
>>really, just wanted to make you aware of it)
> 
> Well, upstream provides a test and I would like to run it - if I would
> know how to do this.  Any patch is welcome.

I've looked at the upstream test binary btw., and it's an endless
loop that processes /dev/urandom - not something you want as a unit
test. But see above for something that is a useful unit test.

>>  - this is more of an upstream issue (i.e. not related to your
>>packaging): the library uses global state and is non-reentrant;
>>which is actually not a great thing for a shared library to be
> 
> I guess upstream is MIA since a long time.
>  
>>Unfortunately, improving that would require breaking both API
>>and ABI, so I'm not suggesting to you to do so, but I would
>>maybe talk with upstream about improving that in the future.
> 
> I can forward this but my guess is that upstream will not change
> anything.  It would also spoil my primary goal for the libraries that
> are using libdi

Re: Next autoconf problem for today libdisorder

[Andreas Tille]

Hi Christian,

On Mon, Jun 27, 2016 at 07:49:53PM +0200, Christian Seiler wrote:
> However, I think you're making your life far more complicated than it
> needs to be:

Yep - as I said my knowledge here is limited.
 
> I've attached an updated version of your autoconf patch that does just
> his.

Thanks a lot.  That was very helpful.
 
> Other comments regarding the package:
> 
>  - if you use autoconf/automake, you don't need to use d-moveshlibs
>for multiarch, dh_auto_configure / dh_auto_build / dh_auto_install
>will do all the heavy lifting for you (just create proper .install
>files for the packages, and use /usr/lib/*/filename to select the
>proper file names) That's a matter of taste, of course.

I agree that its not necessary to copy files around.  However, I like
d-shlibs to ensure that debian/control is properly designed.
 
>  - you build tool/ropy, but you never use it? Neither in the test suite
>(dh_auto_test doesn't do anything) nor do you package that - why?

Since I wanted to get things working somehow first.  I've now reated a
libdisorder-tools package (will write a ropy.1 as well). If you could
help with a sensible test suite - I have no idea how to get this working
with autoconf.
 
>  - you don't provide a symbols file for your library. Not required,
>but it's good practice to provide one (I've attached one based on
>your current package, save it as debian/libdisorder0.symbols, dh
>will take care of the rest)

Thanks a lot for this as well.
 
>  - why hardening only +bindnow? The package builds with +all in the
>hardening options just fine?

Cut-n-pasto.  Fixed now, thanks for the hint.
 
>  - Have you actually tested this with automake 1.6 and autoconf
>2.57? (they are ancient!) If not I'd recommend using autoconf 2.64
>and automake 1.11 as the minimal required versions for each (just
>to be on the safe side, even though it won't have any effect on
>Debian's package build)

Fixed.
 
>  - you could consider installing a pkg-config file for the library,
>as it requires linking against -lm. While this works automatically
>with the shared library, this is not the case for the static
>library, where you explicitly have to add -lm after libdisorder.a
>when linking against it

I have no specific reason not to use pkg-config.  If you recommend this
I'd happily apply a patch.

>  - I would recommend maybe sending the build system changes upstream,
>so that other people can also profit from this?

Sure.  Once it works I'll propose it upstream.
 
>  - you install everything into the proper multiarch locations, but
>libdisorder0 and libdisorder-dev are not Multi-Arch: same, even
>though they easily could be

How?
 
>  - you don't build the test program (although it doesn't serve as
>a unit test, because it will never fail unless /dev/urandom is
>not accessible, so there's no actual check whether the routine
>works as expected or not - so I don't think that's a problem
>really, just wanted to make you aware of it)

Well, upstream provides a test and I would like to run it - if I would
know how to do this.  Any patch is welcome.
 
>  - this is more of an upstream issue (i.e. not related to your
>packaging): the library uses global state and is non-reentrant;
>which is actually not a great thing for a shared library to be

I guess upstream is MIA since a long time.
 
>Unfortunately, improving that would require breaking both API
>and ABI, so I'm not suggesting to you to do so, but I would
>maybe talk with upstream about improving that in the future.

I can forward this but my guess is that upstream will not change
anything.  It would also spoil my primary goal for the libraries that
are using libdisorder.

Thanks a lot for your great help

 Andreas.
 
> [1] https://www.gnu.org/software/automake/manual/libtool.html#LT_005fINIT

> Author: Andreas Tille 
> Last-Update: Wed, 22 Jun 2016 16:27:46 +0200
> Description: Add autoconf stuff to enable simple library creation
> 
> --- /dev/null
> +++ b/Makefile.am
> @@ -0,0 +1,12 @@
> +lib_LTLIBRARIES  = libdisorder.la
> +libdisorder_la_SOURCES = src/disorder.c
> +libdisorder_la_LDFLAGS = -version-info @LIB_VERSION@
> +libdisorder_la_CPPFLAGS = -Iinclude
> +libdisorder_la_LIBADD = -lm
> +
> +bin_PROGRAMS = ropy
> +ropy_SOURCES = tool/ropy.c
> +ropy_LDADD = libdisorder.la
> +
> +include_HEADERS = include/disorder.h
> +man_MANS = man/shannon_H.3
> --- /dev/null
> +++ b/configure.ac
> @@ -0,0 +1,62 @@
> +#   -*- Autoconf -*-
> +# Process this file with autoconf to produce a configure script.
> +
> +AC_INIT(disorder, 0.0.2, mich...@freshdefense.net)
> +AC_CONFIG_HEADERS([config.h])
> +
> +AC_PREREQ(2.57)
> +
> +#Directory that contains install-sh and other auxiliary files
> +AC_CONFIG_AUX_DIR([config])
> +
> +
> +#Accordi

Bug#828792: RFS: yamllint/1.3.0-1

[Adrien Vergé]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "yamllint"

* Package name: yamllint
  Version : 1.3.0-1
  Upstream Author : Adrien Vergé 
* URL : https://github.com/adrienverge/yamllint
* License : GPL-3+
  Section : devel

It builds this binary package:

  yamllint   - Linter for YAML files

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

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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/y/yamllint/yamllint_1.3.0-1.dsc

Changes since the last upload:

  * Allow disabling yamllint checks using comments
  * Detect user config using `os.path.expanduser()`
  * Update standards version to 3.9.8

Regards,
 Adrien Vergé

Re: Next autoconf problem for today libdisorder

[Christian Seiler]

On 06/27/2016 07:49 PM, Christian Seiler wrote:
> Other comments regarding the package:

Oh btw. I just noticed that you don't install the manpage for
the library function in the -dev package (because d-shlibmove
doesn't care about manpages, and you don't have an .install
file for that package). Since upstream includes the manpage,
I would recommend also shipping it.

Regards,
Christian

Bug#824967: RFS: budgie-desktop/10.2.5-1 [ITP]

[foss.freedom]

Hi all,

  I've updated a new version today of my package budgie-desktop - this
tidies the vcs-browser and git fields in the control file.

Does anyone have anytime to have a look-see and maybe sponsor the package
please?

thanks

David

On 31 May 2016 at 20:14, foss.freedom  wrote:

> Many thanks Paul for the additional review comments.  I've included the
> changes below in a revised package.
>
> Important Note.  I've contacted the maintainer of the budgie-desktop
> package on a couple of issues that was raised.
>
> He has decided to consolidate all the issues raised under one umbrella
> issue:
>
>  - https://github.com/solus-project/budgie-desktop/issues/465
>
> He has graciously (albeit time-limited) offered Debian a minor point
> release that can address any packaging issue or issues.  Two caveats - the
> issue or issues must not be distro specific and he is expecting a
> consolidated list of points to consider - "let's get a complete action plan
> here so I can get my development time back. i.e. kick things into gear."
>
> Whilst I know you do not wish to sponsor this package - do you know of
> someone who can?  I'm keen to get one list together to to keep the
> maintainer positively engaged.  I cannot go back now to the maintainer with
> individual points over a period of time.
>
> On Fri, 2016-05-27 at 20:17 +0100, foss.freedom wrote:
>
> > > Looking on the mentors / mypackages webpage it says that the watch
> > > file I've included does not work.  This is very strange because I ran
> > > a uscan and it correctly downloaded the upstream release file:
>
> > The version we use on mentors is older so that might be the issue.
> > I expect if you use version=3 in the watch file it will work there.
>
> version=3 has been used now and you are quite correct - mentors website no
> longer complains :)
>
> > > In summary - users are requested to upgrade.  Moving forward, the
> > > maintainer intends to branch the project at the next major release
> > > and will backport stuff where necessary (e.g. critical issues).  This
> > > will be very useful for Debian to identify issues to include in
> > > updates.
>
> > Sounds good, please refer to the dev ref for security/stable uploads:
>
> >
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> 
> >
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security
> 
>
> Thanks for this - I'll use this info for maintenance of the package moving
> forward in the future.
>
> > I suggest dropping the version number from the Upstream-Name field,
> > since version numbers are usually not in the name of upstream projects.
>
> This has now been corrected.
>
> > > I asked this upstream:
> https://github.com/solus-project/budgie-desktop/issues/448
>
> > Nice response :(
>
> > It doesn't sound like they understood what I was trying to say.
>
> > Perhaps the first paragraph of our upstream guide is more clear:
>
> > https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source
> 
>
>
> > > In the debian/clean I've removed the build artifacts that upstream
> > > have recommended here https://github.com/solus-project/budgie-
> > > desktop/issues/446#issuecomment-221378660
>
> > There was no need to remove those because autoreconf will automatically
> > overwrite them. The other generated files need to be removed though.
>
> I've removed the clean part of the debian/rules as requested.  With
> regards to the build artifacts and other possible package changes, the
> maintainer has pointed us to this:
> https://github.com/solus-project/budgie-desktop/blob/master/README.md#reporting-issues--project-integration
>
> Basically, if we change the upstream release package in anyway without the
> explicit consent of the maintainer and a problem that is reported that is
> found to be because of that change we will lose support.  "Don't make other
> users suffer because you failed to follow our established build and release
> processes. Use standard methods, and we all benefit."
>
>
> > Thanks for the info. I suggest this course of action in parallel to
> > finding a sponsor for budgie-desktop:
>
> > For each of natray and gvc:
>
> > First, get the embedded code copies documented according to this:
>
> > https://wiki.debian.org/EmbeddedCodeCopies
> 
>
> I looked at that link  - are you asking me to file bug reports to debian
> with the following body text?
>
> "Source: natray
> Severity: normal
> Usertags: embed"
>
> or
>
> "Source: gvc
> Severity: normal
> Usertags: embed"
>
>
> > Second, find out where they are developed and talk with upstream about
> > making these stable projects that are released and can be used as
> > shared libraries by each of the projects using them.
>
> The

Re: Next autoconf problem for today libdisorder

[Christian Seiler]

(resending because I got the mailing list address wrong, sorry)

On 06/27/2016 05:00 PM, Andreas Tille wrote:
> ftpmaster spotted in two of my packages a code copy of libdisorder[1]
> which better should be packaged separately.  Since I'd like to create
> dynamic and static library (upstream Makefile only creates static) I
> intended to add autoconf - but today I just proved that my skills are
> quite limited here.

You have a toplevel Makefile.am that defines a library (libdisorder)
but sets no source files, so automake/make assuems that libdisorder.c
has to be there. The sub-level Makefile.ams are never found because
you don't set SUBDIRS.

However, I think you're making your life far more complicated than it
needs to be:

1) alter configure.ac to have automake enable the option subdir-objects
   and don't generate the subdirectory Makefiles, only the top-level
   one

2) put everything in a top-level Makefile.am (makes your life so much
   easier)

3) don't bother to drop upstream's src/Makefile (if you don't use a
   src/Makefile.am, there'll be no conflict)

4) actually reference libtool in configure.ac via LT_INIT/LT_PREREQ,
   AC_PROG_LIBTOOL/AM_PROG_LIBTOOL are the old, deprecated names of
   LT_INIT (see [1])

I've attached an updated version of your autoconf patch that does just
his.

Other comments regarding the package:

 - if you use autoconf/automake, you don't need to use d-moveshlibs
   for multiarch, dh_auto_configure / dh_auto_build / dh_auto_install
   will do all the heavy lifting for you (just create proper .install
   files for the packages, and use /usr/lib/*/filename to select the
   proper file names) That's a matter of taste, of course.

 - you build tool/ropy, but you never use it? Neither in the test suite
   (dh_auto_test doesn't do anything) nor do you package that - why?

 - you don't provide a symbols file for your library. Not required,
   but it's good practice to provide one (I've attached one based on
   your current package, save it as debian/libdisorder0.symbols, dh
   will take care of the rest)

 - why hardening only +bindnow? The package builds with +all in the
   hardening options just fine?

 - Have you actually tested this with automake 1.6 and autoconf
   2.57? (they are ancient!) If not I'd recommend using autoconf 2.64
   and automake 1.11 as the minimal required versions for each (just
   to be on the safe side, even though it won't have any effect on
   Debian's package build)

 - you could consider installing a pkg-config file for the library,
   as it requires linking against -lm. While this works automatically
   with the shared library, this is not the case for the static
   library, where you explicitly have to add -lm after libdisorder.a
   when linking against it

 - I would recommend maybe sending the build system changes upstream,
   so that other people can also profit from this?

 - you install everything into the proper multiarch locations, but
   libdisorder0 and libdisorder-dev are not Multi-Arch: same, even
   though they easily could be

 - you don't build the test program (although it doesn't serve as
   a unit test, because it will never fail unless /dev/urandom is
   not accessible, so there's no actual check whether the routine
   works as expected or not - so I don't think that's a problem
   really, just wanted to make you aware of it)

 - this is more of an upstream issue (i.e. not related to your
   packaging): the library uses global state and is non-reentrant;
   which is actually not a great thing for a shared library to be

   Unfortunately, improving that would require breaking both API
   and ABI, so I'm not suggesting to you to do so, but I would
   maybe talk with upstream about improving that in the future.

Regards,
Christian

[1] https://www.gnu.org/software/automake/manual/libtool.html#LT_005fINIT
Author: Andreas Tille 
Last-Update: Wed, 22 Jun 2016 16:27:46 +0200
Description: Add autoconf stuff to enable simple library creation

--- /dev/null
+++ b/Makefile.am
@@ -0,0 +1,12 @@
+lib_LTLIBRARIES  = libdisorder.la
+libdisorder_la_SOURCES = src/disorder.c
+libdisorder_la_LDFLAGS = -version-info @LIB_VERSION@
+libdisorder_la_CPPFLAGS = -Iinclude
+libdisorder_la_LIBADD = -lm
+
+bin_PROGRAMS = ropy
+ropy_SOURCES = tool/ropy.c
+ropy_LDADD = libdisorder.la
+
+include_HEADERS = include/disorder.h
+man_MANS = man/shannon_H.3
--- /dev/null
+++ b/configure.ac
@@ -0,0 +1,62 @@
+#   -*- Autoconf -*-
+# Process this file with autoconf to produce a configure script.
+
+AC_INIT(disorder, 0.0.2, mich...@freshdefense.net)
+AC_CONFIG_HEADERS([config.h])
+
+AC_PREREQ(2.57)
+
+#	Directory that contains install-sh and other auxiliary files
+AC_CONFIG_AUX_DIR([config])
+
+
+#	According to (http://www.mail-archive.com/autoconf@gnu.org/msg14232.html)
+#		this macro should be after AC_INIT but before AM_INIT_AUTOMAKE
+#

Bug#826266: RFS: dvtm/0.15-1~bpo8+1 ITP

[Gianfranco Costamagna]

Hi
>1) mentors removes the packages too soon or policies are ilogic!
>2) seems uploaded to ftp package polls but not found? sponsored !?


3) the bug is closed, so the package is sponsored, you need to wait until it 
shows
up on debian systems.

yes, there is a hole in which the package isn't available. It has a duration of 
some minutes.


the package is available here
https://packages.debian.org/source/stable-backports/dvtm

G.

Bug#828104: RFS: sollya/5.0+ds-1 [ITP] -- library for safe floating-point code development

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Gianfranco, thanks for your review.

On 27/06/16 12:52, Gianfranco Costamagna wrote:
> control: owner -1 ! control: tags -1 moreinf
> 
>> I am looking for sponsorship for the Debian package sollya [1], an
> 
> quick look:
> 
> 
> 1) Suggests: libsollya-dev (=${binary:Version}), sollya-doc (=
> ${source:Version})
> 
> so, the main sollya package is not using the library?

Indeed. I was surprised as well. It appears that the provided library
is a wrapping library but not a core library.

> 
> 2) Depends: ${shlibs:Depends}, libgmp-dev, libmpfr-dev, libmpfi-dev,
> libfplll-dev, libxml2-dev, ${misc:Depends}
> 
> 
> why libsollya5 has a dependency on the -dev packages? I would expect
> the dev package to pull them in, not the library itself

This is a mistake of mine: the *-dev was meant to the libsollya-dev package:
I have just corrected it.

> 
> 3) many circular suggestions between packages, this looks wrong to
> me.

I have just attempted to break the circles of suggestions by introducing 
Enhances fields.


> 
> 4) debian GPL-3, * is CeCILL-C
> 
> this makes difficult to forward patches upstream

What do you suggest ?


> 
> 5) COPYING mentions GPL-3

Sorry I do not get your point here.
My first reaction was: they are free to do so.

> 
> 6) can you please double check again the multiarch tags?

I think it is ok: where could there exist an issue ?




> 
> cheers,
> 
> Gianfranco
> 

Cheers,
Jerome


- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJXcVQIAAoJED+SGaZ/NsaLGicgAL+MfToWvUnY1aloKyU6nD96
W4ZSih/EePUr65KpYfMxpd3Cm2xf2IXRHZuVO/tKpjfq5UCuQqMwFq2ZKW0iuKVz
xpuwOT8BByzLsk/P5Z3onyECdVMZgY33SIy6/5HDAmTdjunqG6GqoXemHgw/LFee
3Qeh0EvMbCuiwvAs7Ds2K07cb4UVUie0pdvrA+uLsQTJ1Cg78Qk5SIX/cvy1c0Ss
0wrSlGD9EKq4gZToArZh3KqFzrzpYGOwfO07w0KYNfYryFdJfn4NuzYzfxLmOm+d
LWfL5T3EAhLNS2TfkiQegEzXo7pz2mI/uWiyuVwAqIimyQmvr17TsLHNnHRskREl
HZpz787YNkAkaqKyk/Yn/zOZOVzs07nq8Lz7iyL3A0kPT6rLXKuXblqwaU48mn61
tj5ewelKp5sSu12TXiq6YWDr0ksUVvQcLNfOCDcRpYDKyPr6cx4hu0E+Hx/Bl73W
p4oKoqJw0suQxU+lOY+cxms7pw/4W72ivX4CMP924LlYPovdMwNc5lZzsiQgAZ+t
iego7jbLdc5/SM4GujS/eMYKqnlVTTyXZV6hOaRl4GMLgU7qYVd4pIZacZRjLWkK
SR/3JYLqsktlo3ls3jN53Lze9H2YPsC1GRFuM7uzqaRwG9EeXdE5nUpiNYHnEz9x
vK1oSF0uXOOLQym3chNHr9rVjwHbzZcqRpN9An9N9tmrikjAVhgvhmXxDeQq1tX7
3KwcErAMI5sCS9p8oTECQPYu34io7xWw3PHueRz6OcOEvRqF0ebzBc9DVYam4Ur7
7su8mVdmqUzPrSo90X+CJ2YRWfzW0i/xHCCAXWdMGFCaHEILy8AfgcX3krZOHHwL
FFbi6BkVmIBNS8kGErd/XG2KjBpYdiam2LzLCs4U8cTrtJE511qIlhiqwLQUV0cs
6K/em5Vrxnkr1C6ldzyRNHxiQpY2juGw/T9axi/WUQyIvL6eER3zL2aMWAwxONut
G1eqX6lOthvkO+vY+rmZCPE+/79ymmLRGIxTd5jazNfyFJLljQwGXHwBm1TEtCRW
7/gz/pqimd/Nk/bMhO3xjTh0p+XLrhISQzwa5YbALSLQBz2kJXvkYybGYV2Eefs6
MsvoR49U9R6gT3BNJYOtPk53VBa5S7EDotPS6QZ7IjE9n+Uy71w85VSVYNXj7Qpi
38aU+TDnAWM7DgCss/q8gOObCitV4NUBvW6ohGh0G/blfqmtg+kZVtVXzAQ/1pjg
aWqOTloGsHPDnIfQfG0DJlaHQw5ugbV+gN90/NIn3WXeGmryiBp9MrHX52O2sHjx
P/ZOcmbWquUptMObO5gjEK/dHvghFwhjwMfFDet71vqwSIUivjflr4w3bsEcrk8=
=GQBc
-END PGP SIGNATURE-

Next autoconf problem for today libdisorder

[Andreas Tille]

Hi folks,

ftpmaster spotted in two of my packages a code copy of libdisorder[1]
which better should be packaged separately.  Since I'd like to create
dynamic and static library (upstream Makefile only creates static) I
intended to add autoconf - but today I just proved that my skills are
quite limited here.

I wonder whether some kind soul could check my quilt patches in Git[2].
Currently it ends up in

...
make[1]: Entering directory '/build/libdisorder-0.0.2'
make  all-am
make[2]: Entering directory '/build/libdisorder-0.0.2'
make[2]: *** No rule to make target 'libdisorder.c', needed by 
'libdisorder_la-libdisorder.lo'.  Stop.
...


I probably failed in following upstream logich to distribute one file
per directory - but I did not wanted to change upstream directory
layout.

Thanks a lot for any help

  Andreas.

[1] https://github.com/locasto/libdisorder
[2] https://anonscm.debian.org/git/debian-med/libdisorder.git

-- 
http://fam-tille.de

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> The function `evil-mode' doesn't seem to be properly autoloaded.
> I.e. if I install elpa-evil-mode and then I open Emacs and type M-x,
> evil-mode is not available.  However, if I type M-x describe-function
> RET evil-mode RET it works.  Something is going wrong with the
> autoloading.

I think I fixed it. Please, check.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

1. How about using the source package name "emacs-evil"?  I've been
   doing this for my packages where upstream's name is a very generic
   word (e.g. emacs-buttercup), but maybe evil is a significant enough
   package that it can just be "evil", I'm not sure.  Your judgement.

Renamed as evil-el

2. In d/copyright, I think you need to specify copyright years for the
   copyright holders.  Just their names is not enough, since on a desert
   island ~60 years from now with no newer versions of evil available
   for download, the code would become public domain :)  (well, I guess
   the old version of the code would be public domain on the mainland too)

Unfortunately, upstream maintains only list of contributors. So seems
best thing we can do is to count 60 years from last debian upload.

3. Any particular reason you are using gz and not xz compression in
   gbp.conf?  Also, it might be a good idea to check the tarball into
   git with pristine-tar so that a sponsor has exactly the same one (I
   generated my own for testing).

No. Moved to xz.

4. Please run the test suite.  Since it uses ERT, dh_elpa_test can run
   the tests for you, though you'll probably need to give it some hints.
   See dh_elpa_test(1) for how to do this: basically, raise to compat
   level 10 and then set DH_ELPA_TEST_* env vars.

Tests want tty on stdin. Added note and disabled tests. Any good
ideas, how to run them in background?

5. Please add a d/watch.

Problem. Mercurial upstream repository, and tarballs are named not
after version, but after hashes. I fail to extract anything useful
from this page: [1]

[1] https://bitbucket.org/lyro/evil/downloads

PS. Your email formatting is amazing. Thank you.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#826266: RFS: dvtm/0.15-1~bpo8+1 ITP

[PICCORO McKAY Lenz]

the problem its that seems here are two situations:

1) mentors removes the packages too soon or policies are ilogic!
2) seems uploaded to ftp package polls but not found? sponsored !?

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2016-06-03 15:03 GMT-04:00 Gianfranco Costamagna <
costamagnagianfra...@yahoo.it>:

> control: owner -1 !
> control: tags -1 moreinfo
>
> Hi,
> >
> http://mentors.debian.net/debian/pool/main/d/dvtm/dvtm_0.15-1~bpo8+1.dsc
>
>
>
> 404
>
> G.
>
>

Bug#828024: RFS: libretro-beetle-wswan [ITP]

[Gianfranco Costamagna]

Hi
> this package are market as done! but the package are still not in
> debian package !


or use incoming.debian.org :)

G.

Re: Help needed for autoreconf hmmer

[Andreas Tille]

Hi Jakub,

On Mon, Jun 27, 2016 at 03:35:04PM +0200, Jakub Wilk wrote:
> AUTOHEADER=true dh_autoreconf

Thanks - works perfectly

 Andreas.

-- 
http://fam-tille.de

Bug#820644: RFS: libretro-snes9x [ITP]

[PICCORO McKAY Lenz]

2016-06-13 21:37 GMT-04:00 Sérgio Benjamim :

> Hey,
> This libretro package needs a frontend to work, like RetroArch, Phoenix
> [1], Gnome Games [2] or ZMZ [3].
> I think "Provides: snes9x" is not the case, with snes9x or snes9x-gtk the
> user expects a standalone program.
>
that libretro core of snes9x does not provide snes9x due are not functional
without a fronend as retroarch!

please upload this package ! too many time!

Bug#828024: RFS: libretro-beetle-wswan [ITP]

[James Cowgill]

Hi,

On Mon, 2016-06-27 at 10:00 -0400, PICCORO McKAY Lenz wrote:
> this package are market as done! but the package are still not in
> debian package !
> 
> removed yet from mentors but i cannot retrieve from sid! the dsc file
> are not found!

The package was acccepted into unstable about an hour ago:
 https://tracker.debian.org/news/778708

You'll need to wait a bit for the archive software to update itself and
for all the mirrors to sync. It should appear later today.

James

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

Bug#828024: RFS: libretro-beetle-wswan [ITP]

[PICCORO McKAY Lenz]

this package are market as done! but the package are still not in debian
package !

removed yet from mentors but i cannot retrieve from sid! the dsc file are
not found!

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2016-06-23 20:39 GMT-04:00 Sérgio Benjamim :

> Package: sponsorship-requests
> Severity: wishlist
>
> Hey dear mentors!
>
> I'm looking for a sponsor for my package "libretro-beetle-wswan"
>
> This is the libretro port of Beetle/Mednafen WSWAN module, a
> WonderSwan emulator.
>
> It's a fork of Mednafen to fit better with the libretro API, so it's
> not possible to use the same source code of Mednafen package.
>
>
> * Package name : libretro-beetle-wswan
>   Version  : 0.9.35.1+git20160623
>
>   Upstream Author  : Ryphecha / The RetroArch Team (beetle fork)
>
> * URL  : https://github.com/libretro/beetle-wswan-libretro
> * License  : GPL-2+
>   Programming Lang : C/C++
>   Description  : port of Beetle/Mednafen WSWAN to libretro API
>
>
> It builds those binary packages:
>
> libretro-beetle-wswan - Libretro wrapper for the Beetle WSWAN core
>
>
> To access further information about this package, please visit the
> following URL:
>
> https://mentors.debian.net/package/libretro-beetle-wswan
>
>
> More information about RetroArch and the libretro API can be obtained from
> http://www.libretro.com/index.php/api/
>
> --
> sergio-br2
>
>

Bug#827913: marked as done (RFS: goto-chg/1.6-1 ITP)

[Debian Bug Tracking System]

Your message dated Mon, 27 Jun 2016 13:42:08 + (UTC)
with message-id <613745336.3570296.1467034928990.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#827913: RFS: goto-chg/1.6-1 ITP
has caused the Debian Bug report #827913,
regarding RFS: goto-chg/1.6-1 ITP
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
827913: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827913
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "goto-chg"

* Package name: goto-chg
  Version : 1.6-1
  Upstream Author : David Andersson 
* Url : https://www.emacswiki.org/emacs/goto-chg.el
* Licenses: GPL-2+
  Section : lisp

It builds those binary packages:

elpa-goto-chg -- navigate the point of the most recent edit in the buffer

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

http://mentors.debian.net/package/goto-chg

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

http://mentors.debian.net/debian/pool/main/g/goto-chg/goto-chg_1.6-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/git/pkg-emacsen/pkg/goto-chg.git

More information about goto-chg can be obtained from 
https://www.emacswiki.org/emacs/goto-chg.el

Changes since last upload:

  * Initial release. (Closes: #827910)

Regards,
  Dmitry Bogatov
--- End Message ---
--- Begin Message ---
Hi,



>Ah, my bad. I am really sorry.


no need to be sorry :)

we invented the "canc" key, because people make mistakes ;)
(citation needed.)

Sponsored on deferred/2

Gianfranco--- End Message ---

Bug#827913: RFS: goto-chg/1.6-1 ITP

[Dmitry Bogatov]

> >hash: 73310900c65c7d56fb639868ed574424e9fdbec8
> ERR:
> goto-chg (1.6-1) unstable; urgency=low
> Source: goto-chg-el

Ah, my bad. I am really sorry.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: Help needed for autoreconf hmmer

[Jakub Wilk]

* Andreas Tille , 2016-06-27, 12:41:

  dh_autoreconf
autoheader: warning: missing template: EASEL_COPYRIGHT
autoheader: Use AC_DEFINE([EASEL_COPYRIGHT], [], [Description])


Normally one would fix such errors by adding third argument 
(description) to all instanced of AC_DEFINE(_UNQUOTED) where it was 
missing.


But in this case upstream doesn't seem to be using autoheader at all; 
their header template (easel/esl_config.h.in) looks manually-crafted. So 
you should probably just ask autoreconf not to call autoheader:


AUTOHEADER=true dh_autoreconf 


--
Jakub Wilk

Bug#828687: RFS: no-new-privs/0.0.2 [ITP] -- sets PR_NO_NEW_PRIVS and execute a program

[Gianfranco Costamagna]

control: tags -1 moreinfo

Setting moreinfo, as per previous message.

Gianfranco

Bug#828166: RFS: speedcrunch/0.11-1 [ITA]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo
Hi,


>Thanks for adopting this package.


+1



please try to be more verbose in changelog:
>bump std-version (maybe extract in a new changelog entry)


copyright in machine readable format

d/p/0001: did you forward it upstream?

>override_dh_auto_clean:
> dh_auto_clean
> rm -f speedcrunch.1 speedcrunch.xpm


I usually like more


echo -e "speedcrunch.1\nspeedcrunch.xpm" > debian/clean

other stuff LGTM!

thanks for the nice cleanup :)

also, why do you force buildsystem and builddirectory?


and last thing:
BLD_VERBOSE=1

please export it, we have tools (blhc) scanning build logs for missing flags,
so please make the build verbose (I don't care about DH_VERBOSE)

thanks Sergio for the good review!


G.

Re: Help needed for autoreconf hmmer

[Andreas Tille]

Hi Neutron,

I tried

$ git diff
diff --git a/debian/patches/use_debian_packaged_libdivsufsort.patch 
b/debian/patches/use_debian_packaged_libdivsufsort.patch
index 99ed610..fb3b340 100644
--- a/debian/patches/use_debian_packaged_libdivsufsort.patch
+++ b/debian/patches/use_debian_packaged_libdivsufsort.patch
@@ -20,6 +20,15 @@ Description: Use Debian packaged libdivsufsort
  
  AC_SUBST(EASEL_DATE)
  AC_SUBST(EASEL_COPYRIGHT)
+@@ -105,7 +103,7 @@ AC_DEFINE_UNQUOTED(HMMER_VERSION,   "$HM
+ AC_DEFINE_UNQUOTED(HMMER_URL,   "$HMMER_URL")
+ 
+ AC_DEFINE_UNQUOTED(EASEL_DATE,  "$EASEL_DATE")
+-AC_DEFINE_UNQUOTED(EASEL_COPYRIGHT, "$EASEL_COPYRIGHT")
++AC_DEFINE_UNQUOTED(EASEL_COPYRIGHT, "$EASEL_COPYRIGHT", [Define 
EASEL_COPYRIGHT])
+ AC_DEFINE_UNQUOTED(EASEL_LICENSE,   "$EASEL_LICENSE")
+ AC_DEFINE_UNQUOTED(EASEL_VERSION,   "$EASEL_VERSION")
+ 
 @@ -669,14 +667,12 @@ AC_CONFIG_FILES([profmark/Makefile])
  AC_CONFIG_FILES([src/impl_${impl_choice}/Makefile])
  AC_CONFIG_HEADERS([src/p7_config.h])


but this did not changed anything.

Thanks for your attempt to help

   Andreas.

On Mon, Jun 27, 2016 at 07:43:37PM +0700, Neutron Soutmun wrote:
> s/AC_DEFINE/AC_DEFINE_UNQUOTED/g
> 
> On Mon, Jun 27, 2016 at 7:33 PM, Neutron Soutmun  
> wrote:
> > Sorry for non-sense example
> >
> > It should be,
> >
> > AC_DEFINE([EASEL_COPYRIGHT], "$EASEL_COPYRIGHT", [Define EASEL_COPYRIGHT])
> >
> > Cheers,
> > Neutron Soutmun
> >
> > On Mon, Jun 27, 2016 at 7:29 PM, Neutron Soutmun  
> > wrote:
> >> Hi,
> >>
> >> On Mon, Jun 27, 2016 at 5:41 PM, Andreas Tille  wrote:
> >>
> >>>dh_autoreconf
> >>> autoheader: warning: missing template: EASEL_COPYRIGHT
> >>> autoheader: Use AC_DEFINE([EASEL_COPYRIGHT], [], [Description])
> >>
> >> This is the clue. I do the quick review and found that the lines
> >> AC_DEFINE() and AC_DEFINE_UNQUOTED() that warning with missing
> >> template are missing the second and the third arguments, it should be
> >> something like below
> >>
> >> AC_DEFINE([EASEL_COPYRIGHT], [1], [Define EASEL_COPYRIGHT])
> >>
> >> See: 
> >> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Defining-Symbols.html
> >>
> >> Cheers,
> >> Neutron Soutmun
> 

-- 
http://fam-tille.de

Re: Help needed for autoreconf hmmer

[Neutron Soutmun]

s/AC_DEFINE/AC_DEFINE_UNQUOTED/g

On Mon, Jun 27, 2016 at 7:33 PM, Neutron Soutmun  wrote:
> Sorry for non-sense example
>
> It should be,
>
> AC_DEFINE([EASEL_COPYRIGHT], "$EASEL_COPYRIGHT", [Define EASEL_COPYRIGHT])
>
> Cheers,
> Neutron Soutmun
>
> On Mon, Jun 27, 2016 at 7:29 PM, Neutron Soutmun  
> wrote:
>> Hi,
>>
>> On Mon, Jun 27, 2016 at 5:41 PM, Andreas Tille  wrote:
>>
>>>dh_autoreconf
>>> autoheader: warning: missing template: EASEL_COPYRIGHT
>>> autoheader: Use AC_DEFINE([EASEL_COPYRIGHT], [], [Description])
>>
>> This is the clue. I do the quick review and found that the lines
>> AC_DEFINE() and AC_DEFINE_UNQUOTED() that warning with missing
>> template are missing the second and the third arguments, it should be
>> something like below
>>
>> AC_DEFINE([EASEL_COPYRIGHT], [1], [Define EASEL_COPYRIGHT])
>>
>> See: 
>> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Defining-Symbols.html
>>
>> Cheers,
>> Neutron Soutmun

Bug#827913: RFS: goto-chg/1.6-1 ITP

[Gianfranco Costamagna]

Hi,

>hash: 73310900c65c7d56fb639868ed574424e9fdbec8



ERR:

goto-chg (1.6-1) unstable; urgency=low

Source: goto-chg-el


dpkg-source: error: source package has two conflicting values - goto-chg-el and 
goto-chg

please fix and I'll sponsor :)

thanks


G.

Re: Help needed for autoreconf hmmer

[Neutron Soutmun]

Sorry for non-sense example

It should be,

AC_DEFINE([EASEL_COPYRIGHT], "$EASEL_COPYRIGHT", [Define EASEL_COPYRIGHT])

Cheers,
Neutron Soutmun

On Mon, Jun 27, 2016 at 7:29 PM, Neutron Soutmun  wrote:
> Hi,
>
> On Mon, Jun 27, 2016 at 5:41 PM, Andreas Tille  wrote:
>
>>dh_autoreconf
>> autoheader: warning: missing template: EASEL_COPYRIGHT
>> autoheader: Use AC_DEFINE([EASEL_COPYRIGHT], [], [Description])
>
> This is the clue. I do the quick review and found that the lines
> AC_DEFINE() and AC_DEFINE_UNQUOTED() that warning with missing
> template are missing the second and the third arguments, it should be
> something like below
>
> AC_DEFINE([EASEL_COPYRIGHT], [1], [Define EASEL_COPYRIGHT])
>
> See: 
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Defining-Symbols.html
>
> Cheers,
> Neutron Soutmun

Bug#816396: marked as done (RFS: vizigrep/1.3-1 ITP)

[Debian Bug Tracking System]

Your message dated Mon, 27 Jun 2016 12:32:03 + (UTC)
with message-id <552780687.3496352.1467030723841.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#816396: RFS: vizigrep/1.3-1 ITP
has caused the Debian Bug report #816396,
regarding RFS: vizigrep/1.3-1 ITP
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
816396: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816396
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "vizigrep"

* Package name: vizigrep
  Version : 1.3-1
  Upstream Author : Jason J. Herne 
* URL : https://github.com/hernejj/vizigrep
* License : GPL
  Section : utils

  It builds those binary packages:

vizigrep   - graphical file contents search tool using regular expressions

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

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


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

dget -x 
http://mentors.debian.net/debian/pool/main/v/vizigrep/vizigrep_1.3-1.dsc

  More information about Vizigrep can be obtained from
https://github.com/hernejj/vizigrep.

  Changes since the last upload:

  * Initial Upload of Vizigrep v1.3

  Regards,
   Jason J. Herne
--- End Message ---
--- Begin Message ---
Hi,
changed std-version to 3.9.8, and sponsored on deferred/5 :)
G.




Il Sabato 25 Giugno 2016 13:40, Jason J. Herne  ha scritto:



Gianfranco,

I believe I have satisfied all of your packaging review comments. If you don't 
mind please have another look.
My latest package has been uploaded: https://mentors.debian.net/package/vizigrep

Thank you.


On Mon, Jun 20, 2016 at 1:09 PM, Gianfranco Costamagna 
 wrote:

Hi,
>
>
>>You state "please use the new dh call sequencer (rules)". I'm not sure what 
>>this means exactly. Is there something missing in my rules file?
>
>
>https://sources.debian.net/src/knockpy/3.0.0-1/debian/rules/
>
>the default call should be good enough for most stuff
>
>
>#!/usr/bin/make -f
>
>%:
>dh $@
>
>
>
>in case, just override the specific call
>override_dh_foo:
>do-your-stuff
>dh_foo
>
>
>>licensecheck is complaining about unit test data. I assume I can ignore this? 
>>Or should I change my data and test?
>
>no, as long as the license is listed in debian/copyright
>
>>I assume "check-all-the-things" just runs all of the stuff you've listed 
>>below it? (flawfinder, pep8, pyflakes). Also, I assume that coding style is 
>>decided by the >author and not a reason to reject a package?
>
>
>exactly, this is something that is not strictly needed.
>apt-get install -t experimental check-all-the-things
>>Thanks again for your time.
>
>
>you are welcome,
>
>G.
>
>
>
>On Tue, Apr 5, 2016 at 4:09 PM, Gianfranco Costamagna 
> wrote:
>
>control: owner -1 !
>>control: tags -1 moreinfo
>>
>>hi, lets review:
>>
>>please use the new dh call sequencer (rules)
>>std-version is 3.9.7
>>no need probably to force python as runtime dependency
>>having a setup.py might be better
>>
>>check-all-the-things
>>
>>$ find -type f -iname '*.desktop' -exec desktop-file-validate {} \;
>>
>>$ licensecheck --check=. --recursive --copyright . | grep -F 'with incorrect 
>>FSF address'
>>./ut/test-data/c-source/xpad.c: GPL (v2 or later) (with incorrect FSF address)
>>
>>$ flawfinder -Q -c .
>>
>>$ pep8 --ignore W191 .
>>
>>$ pyflakes3 .
>>
>>$ pyflakes.
>>
>>
>>debian/dirs, please remove and install -d in Makefile.
>>
>>the other stuff LGTM, even if I didn't run lintian and test the package yet.
>>
>>cheers,
>>
>>G.
>>
>>Il Martedì 1 Marzo 2016 15:33, Jason J. Herne  ha scritto:
>>
>>
>>
>>Package: sponsorship-requests
>>Severity: wishlist Dear mentors, I am looking for a sponsor for my package 
>>"vizigrep" * Package name   : vizigrep Version  : 1.3-1 Upstream Author : 
>>Jason J. Herne 
>>* URL : https://github.com/hernejj/vizigrep * License  : GPL 
>>Section  : utils It builds those binary packages: vizigrep  - graphical 
>>file contents search tool using regular expressions To access further 
>>information about this package, please visit the following URL: 
>>http://mentors.debian.net/package/vizigrep Alternatively, one can download 
>>the package with dget using this command: dget -x 
>>http://mentors.debian.net/debian/pool/main/v/vizigrep/vizigrep_1.3-1.dsc More 
>>information about Vizigrep can be obtained from 
>>https://github.com/hernejj/vizigrep. Changes since the last upload: * Initi

Re: Help needed for autoreconf hmmer

[Neutron Soutmun]

Hi,

On Mon, Jun 27, 2016 at 5:41 PM, Andreas Tille  wrote:

>dh_autoreconf
> autoheader: warning: missing template: EASEL_COPYRIGHT
> autoheader: Use AC_DEFINE([EASEL_COPYRIGHT], [], [Description])

This is the clue. I do the quick review and found that the lines
AC_DEFINE() and AC_DEFINE_UNQUOTED() that warning with missing
template are missing the second and the third arguments, it should be
something like below

AC_DEFINE([EASEL_COPYRIGHT], [1], [Define EASEL_COPYRIGHT])

See: 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Defining-Symbols.html

Cheers,
Neutron Soutmun

Bug#828104: RFS: sollya/5.0+ds-1 [ITP] -- library for safe floating-point code development

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinf

>I am looking for sponsorship for the Debian package sollya [1], an

quick look:


1)
Suggests: libsollya-dev (=${binary:Version}), sollya-doc (= ${source:Version})

so, the main sollya package is not using the library?

2)
Depends: ${shlibs:Depends}, libgmp-dev, libmpfr-dev, libmpfi-dev, libfplll-dev, 
libxml2-dev, ${misc:Depends}


why libsollya5 has a dependency on the -dev packages? I would expect the dev 
package to pull
them in, not the library itself

3) many circular suggestions between packages, this looks wrong to me.

4) debian GPL-3, * is CeCILL-C

this makes difficult to forward patches upstream

5) COPYING mentions GPL-3

6) can you please double check again the multiarch tags?

cheers,

Gianfranco

Help needed for autoreconf hmmer

[Andreas Tille]

Hi,

since ftpmaster rejected hmmer[1] due to a missing license statement for
libdivsufsort code I verified that this library is packaged separately
and tried to get rid of this code duplication at all.  Thus I needed to
autoreconfigure but failed:


...
   dh_autoreconf
autoheader: warning: missing template: EASEL_COPYRIGHT
autoheader: Use AC_DEFINE([EASEL_COPYRIGHT], [], [Description])
autoheader: warning: missing template: EASEL_DATE
autoheader: warning: missing template: EASEL_LICENSE
autoheader: warning: missing template: EASEL_VERSION
autoheader: warning: missing template: HAVE_FLUSH_ZERO_MODE
autoheader: warning: missing template: HAVE_GZIP
autoheader: warning: missing template: HAVE_MPI
autoheader: warning: missing template: HAVE_SSE2
autoheader: warning: missing template: HAVE_SSE2_CAST
autoheader: warning: missing template: HAVE_VMX
autoheader: warning: missing template: HMMER_COPYRIGHT
autoheader: warning: missing template: HMMER_DATE
autoheader: warning: missing template: HMMER_LICENSE
autoheader: warning: missing template: HMMER_THREADS
autoheader: warning: missing template: HMMER_URL
autoheader: warning: missing template: HMMER_VERSION
autoheader: warning: missing template: eslDEBUGLEVEL
autoheader: warning: missing template: eslLIBRARY
autoheader: warning: missing template: p7_DEBUGGING
autoheader: warning: missing template: p7_IMPL_DUMMY
autoheader: warning: missing template: p7_IMPL_SSE
autoheader: warning: missing template: p7_IMPL_VMX
autoreconf: /usr/bin/autoheader failed with exit status: 1
dh_autoreconf: autoreconf -f -i returned exit code 1
debian/rules:12: recipe for target 'build' failed
make: *** [build] Error 2
...


I admit my autoconf knowledge is a bit rudementary and I have no idea
what to do next.

Any help would be welcome.

Kind regards

  Andreas.

[1] https://anonscm.debian.org/git/debian-med/hmmer.git

-- 
http://fam-tille.de