Bug#832704: RFS: nixnote2/2.0~beta8+20160727+ds-1 [ITP] -- Open Source Evernote client

[Boyuan Yang]

> I can't sponsor the upload, but I hope the following review is useful to
> you.

Thank you very much for your detailed review. I would like to explain
those problems here for you and anyone who might be interested:

> Since I am not familiar with Java packaging, it would be advisable to
> ask on the Debian java packaging group mailing list for someone to
> review those parts of the package.

OK,  I will take a try.

> Must-fixes
> --
>
> Is the GitHub repo that this package is based on a fork of Nevernote?  I
> think you should change the Homepage: field to point at the GitHub
> repo.  Or are they controlled by the same person?

They are controlled by the same person and actually they are the *same
project*. Actually the author is still using nevernote page on
Sourceforge to distribute pre-built nixnote2 packages.

> Your version number indicates that you are packaging a beta release.
> Generally, only full upstream releases are uploaded to Debian unstable,
> rather than testing releases/release candidates.  Is there some good
> reason for using this version?

Upstream is keeping "beta" string in version for several years and
there is no sign that he/she will make a "non-beta" release in near
future. However the function of nixnote2 is complete and everything
works well now. Personally I think it is suitable for the release.

> The description of the "exclude opencv linking" doesn't explain why
> opencv support is disabled "for now".  Please explain.

In upstream trunk the opencv-related functions are disabled and
removed. The developer intends to make it into a plugin, so I disabled
related builds. What's more, I noticed that Debian is preparing
opencv2-3 transition, so my personal preference is to pack the
opencv-related plugin after the transition is completed.

> Vcs-* should point at your packaging repository, not the upstream git
> repository.

Yes. I am pointing to my packaging repository.

> You should remove the "ignore-branch" and "builder" settings from
> gbp.conf.  Those should only be set in ~/.gbp.conf or /etc/gbp.conf.

Thanks. I will fix it later.

> I can't try building and installing this package because I can't get a
> correct orig tarball.  The version on mentors seems to be out-of-date,
> and the version the watch file downloads conflicts with your
>  repo (which is what I'm looking
> at).  How can I get the correct orig tarball?

Really sorry I did not try to build from mentors. I will look into it
afterwards.

> Suggested improvements
> --
>
> There are a lot of build-dependencies.  It would be nice to run
> `wrap-and-sort -abst`.

Sure I will fix it.

> README.Debian is meant for users, but what you have written in there is
> only really relevant to Debian contributors.  Perhaps rename it to
> README.source, or just remove it.  You could also cite the relevant
> section of policy (and the version of policy in which the section had
> that number).

Thanks, I will try.

> The watch file looks like it will only work for the current version,
> because the repack suffix contains a part of the current version
> string.  Could it be made more general?

Sure. Will be fixed after next upstream release.

> Could you explain why you Recommends: mimetex and Suggests: cups?

Mimetex is used for latex support of evernote notes, as described by the author.
Cups is needed for note printing, but it is totally fine not to
install it if the user do not need to print.

> You're installing README.md but this file contains no useful
> information.  The README.txt file looks more useful.  Does that get
> installed to the help/ dir?  I couldn't tell without building the
> package, sorry!

I did not install README.txt, since this file mainly describes the situation
of source (not the binary). Should I install it anyway?

> I'm not sure you need to override dh_installchangelogs.  It usually
> detects filenames like 'changelog.txt'.  But I might be wrong.
>
> At debhelper compat 9, I think that you could remove a lot of lines from
> your rules file.  For example, you probably don't need these lines:
>
> DPKG_EXPORT_BUILDFLAGS = 1
> include /usr/share/dpkg/default.mk
> include /usr/share/dpkg/buildflags.mk

Thanks for these advices, I will try it out.

Bug#832704: RFS: nixnote2/2.0~beta8+20160727+ds-1 [ITP] -- Open Source Evernote client

[Sean Whitton]

control: tag -1 +moreinfo
control: owner -1 !

Hello,

Thanks for packaging this.  Org-mode >> Evernote but enabling people to
use the latter on Debian might be a useful gateway drug ... and a lot of
people say that Org-mode is the gateway drug for Emacs proper ;)

I can't sponsor the upload, but I hope the following review is useful to
you.  I've split it into two sections: things that I would consider
must-fixes before an upload to Debian, and suggested improvements.  The
latter aren't strictly necessary, but they would help demonstrate to a
potential sponsor that you are committed to maintaining this package in
Debian.

Since I am not familiar with Java packaging, it would be advisable to
ask on the Debian java packaging group mailing list for someone to
review those parts of the package.

Must-fixes
--

Is the GitHub repo that this package is based on a fork of Nevernote?  I
think you should change the Homepage: field to point at the GitHub
repo.  Or are they controlled by the same person?

Your version number indicates that you are packaging a beta release.
Generally, only full upstream releases are uploaded to Debian unstable,
rather than testing releases/release candidates.  Is there some good
reason for using this version?

The description of the "exclude opencv linking" doesn't explain why
opencv support is disabled "for now".  Please explain.

Vcs-* should point at your packaging repository, not the upstream git
repository.

You should remove the "ignore-branch" and "builder" settings from
gbp.conf.  Those should only be set in ~/.gbp.conf or /etc/gbp.conf.

I can't try building and installing this package because I can't get a
correct orig tarball.  The version on mentors seems to be out-of-date,
and the version the watch file downloads conflicts with your
 repo (which is what I'm looking
at).  How can I get the correct orig tarball?

Suggested improvements
--

There are a lot of build-dependencies.  It would be nice to run
`wrap-and-sort -abst`.

README.Debian is meant for users, but what you have written in there is
only really relevant to Debian contributors.  Perhaps rename it to
README.source, or just remove it.  You could also cite the relevant
section of policy (and the version of policy in which the section had
that number).

The watch file looks like it will only work for the current version,
because the repack suffix contains a part of the current version
string.  Could it be made more general?

Could you explain why you Recommends: mimetex and Suggests: cups?

You're installing README.md but this file contains no useful
information.  The README.txt file looks more useful.  Does that get
installed to the help/ dir?  I couldn't tell without building the
package, sorry!

I'm not sure you need to override dh_installchangelogs.  It usually
detects filenames like 'changelog.txt'.  But I might be wrong.

At debhelper compat 9, I think that you could remove a lot of lines from
your rules file.  For example, you probably don't need these lines:

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/default.mk
include /usr/share/dpkg/buildflags.mk

Since I couldn't actually build the package, that's all for now!

--
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#833288: would FTBFS now with cython 0.24.1 MACS2/IO/PeakIO.pyx:632:49: Cannot assign type 'float' to 'int'

[Jakub Wilk]

* Andreas Tille , 2016-08-10, 09:54:
I've checked MACS2/IO/PeakIO.pyx and I think the typing of the function 
call should be fine - so probably the problem is somewhere else - but 
where?


https://github.com/cython/cython/issues/551

--
Jakub Wilk

Bug#833909: RFS: xml-security-c/1.7.3-3~bpo7+1 [BPO]

[Ferenc Wágner]

Gianfranco Costamagna  writes:

> the library has been renamed and conflicting with the non-v5 version, because
> of the libstdc++ transition.
>
> backporting to jessie and wheezy (where the transition didn't happen), means
> you have to revert that change, because otherwise the package will be 
> uninstallable
> with all of the reverse dependencies, because of:
>
> Package: libxml-security-c17v5
> Conflicts:
>  libxml-security-c17,
> Replaces:
>  libxml-security-c17,
>
> in this case, oldstable has the library with a different soname (c16),
> so I'm not sure if the rename is worth the effort or not, please ask
> on -mentors, -devel or wherever you find more appropriate.

It'd probably make sense to start with a jessie backport, where this
change is necessary, then branch off the wheezy backport from that, and
do the PKG_INSTALLDIR change only.

> also, can the new patch be added to the package in unstable too?
> -  * [aba87f7] New patch 
> Remove-PKG_INSTALLDIR-to-build-with-older-pkg-config.patch

In principle it could, but it was added in the latest revision with the
very purpose of getting it tested before upstreaming.
-- 
Feri

Bug#833909: RFS: xml-security-c/1.7.3-3~bpo7+1 [BPO]

[Etienne Dysli-Metref]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thank you very much for your review Gianfranco. :)

On 10/08/16 11:31, Gianfranco Costamagna wrote:
> 1) really? what about don't care to wheezy anymore?

What do you mean? Should backports only be done for jessie now?

Here is the backstory: we (SWITCH) are providing Shibboleth packages
for Debian and Ubuntu to members of our community (universities and
high schools in Switzerland). We chose to support wheezy, jessie,
precise, trusty and xenial as you can see in our Shibboleth Service
Provider installation guide [1]. To this end, I'm already packaging
for all five distributions so why not have Debian benefit from it by
contributing backports at the same time? Also, I want our packages to
be closer to Debian's to 1) avoid version conflicts 2) reduce the
repackaging needed on our end.

[1] https://www.switch.ch/aai/guides/sp/installation/

> Did you get in touch with the maintainers? they seems active, one
> of them is a DM, and might be able to upload it for you if needed

Yes, I'm in touch with Ferenc Wágner. He wasn't able to upload that
package yesterday evening.

> 2)
> 
> this looks wrong to me. the library has been renamed and
> conflicting with the non-v5 version, because of the libstdc++
> transition.
> 
> backporting to jessie and wheezy (where the transition didn't
> happen), means you have to revert that change, because otherwise
> the package will be uninstallable with all of the reverse
> dependencies, because of: Package: libxml-security-c17v5
> 
> Conflicts: libxml-security-c17, Replaces: libxml-security-c17,

Oh good catch! I'll revert the names to c17.

> 3)
> 
> also, can the new patch be added to the package in unstable too? -
> * [aba87f7] New patch
> Remove-PKG_INSTALLDIR-to-build-with-older-pkg-config.patch
> 
> is it a breaking and non-compatible with new pkg-config change?

I'll defer to Ferenc on that one.

> 4) dpkg-source: warning: failed to verify signature on
> /tmp/xml-security-c_1.7.3-3~bpo7+1.dsc
> 
> dpkg-source: error: file /tmp/xml-security-c_1.7.3.orig.tar.gz has
> size 909320 instead of expected 897454
> 
> please use the right orig tarball, thanks.

Will do at the next upload.

Should I increment the bpo revision for the next upload (bpo7+2)?

Cheers,
   Etienne
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXqwk3AAoJEDtvu5hdVFPu1foQAJ3IYdbeUfC469j5hIY6kATu
6yec4wIr9T4bnuG5jlsbiEThZFdGjMG30Oy82qyyoYvCq5Y3Wf/XycGRSm4yQj8V
jz0Mc67pfUvoHDGTEuo/hq3OBod7iWIYp/O2AL1fhxC3OtYs/E6brMVIlSg9EySp
lSETydFiyUzYXMbqQhxXO0fUn3Q7hovEluzcFNOEPVSiCe9WH4Zcl1MXXRpq4dv1
ZJdFyB4m4gjClYTTEzHphZANrzpSB+aPtJNabOeI1gGyTOYgFOXcYqP1BzqwEEA1
uFA8zQbGlkWERJWu9zr9G/sGiiV1cbFn9SG/BH/Xr9Y49TGALotqDxP8XE19c7Q5
YULxhc8AFRWZkxvGgktzfcm8gDIi5kk1PSE5dvFUEwFqHtZA9QBkoZEJ4BhfgAKa
U3+qYPDYFkdo0nJ+cGNz8GQkTy/4aVhO2V8wvc5r9rS+AbD3Z5Bll20sKMT/JacA
RSe5ih2qqtFXipxYGYgT/FbO4YCoAzaenG37PyiSAGILL9rM/eDjB+LHldMiUqvo
TlWfhIr5L5bI8Tz9USdDkm3olaW2Ju4+OWNxr8Hvj1YZ3s3ZU8zVB+J8FwWuehiE
TInzXCt7fhbF+ub/jDul8Mgn/G+OKkIiHg9h8pmjJ4pXAshZlCIYRArr+4hFxKcR
PfJY+Cror7LT894JUHhm
=32aN
-END PGP SIGNATURE-

Re: Bug#833288: would FTBFS now with cython 0.24.1 MACS2/IO/PeakIO.pyx:632:49: Cannot assign type 'float' to 'int'

[Gianfranco Costamagna]

Hi,

>I've checked MACS2/IO/PeakIO.pyx and I think the typing of the function
>call should be fine - so probably the problem is somewhere else - but
>where?

I don't have the answer, but upstream seems to be aware of a new bug report
https://github.com/taoliu/MACS/issues/140

what I'm really not sure is:
why cython Developers and Maintainers are opening RC bugs against packages
using it, without a proper transition, and with a cython RC buggy package?

cython is not built on s390x because of testsuite failures
File 
"/«PKGBUILDDIR»/build/work-dir/run/c/int_float_builtins_as_casts_T400/int_float_builtins_as_casts_T400.so",
 line ?, in int_float_builtins_as_casts_T400.__test__.long_double_to_float_int 
(line 195)
Failed example:
long_double_to_float_int(4)
Expected:
4.0
Got:


0.0
some errors in casting double/float types sounds maybe related to your issue.

So, at the end, I would open an RC against cython (FTBFS on s390x), wait for it 
to be fixed,
and then start looking at reverse-dependencies, with a particular eye on cython 
regressions,

specially when the failures looks strange like this one

Hope this helps,

G.

Bug#833909: RFS: xml-security-c/1.7.3-3~bpo7+1 [BPO]

[Gianfranco Costamagna]

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


>to wheezy-backports-sloppy as a first step to backporting other



1) really? what about don't care to wheezy anymore?
Did you get in touch with the maintainers? they seems active, one of them
is a DM, and might be able to upload it for you if needed

>libxml-security-c-dev - C++ library for XML Digital Signatures
>(development)
>libxml-security-c17v5 - C++ library for XML Digital Signatures (runtime)
>xml-security-c-utils - C++ library for XML Digital Signatures (utilities
>)


2)

this looks wrong to me.
the library has been renamed and conflicting with the non-v5 version, because
of the libstdc++ transition.

backporting to jessie and wheezy (where the transition didn't happen), means
you have to revert that change, because otherwise the package will be 
uninstallable
with all of the reverse dependencies, because of:
Package: libxml-security-c17v5

Conflicts:
libxml-security-c17,
Replaces:
libxml-security-c17,


in this case, oldstable has the library with a different soname (c16), so
I'm not sure if the rename is worth the effort or not, please ask on -mentors, 
-devel
or wherever you find more appropriate.

(I would call it c17 without the v5, to avoid bad installations with apt-pinned 
packages from
Stretch, avoiding runtime failures and segfaults, but I have no strong opinion)


3)

also, can the new patch be added to the package in unstable too?
-  * [aba87f7] New patch 
Remove-PKG_INSTALLDIR-to-build-with-older-pkg-config.patch


is it a breaking and non-compatible with new pkg-config change?
4)
dpkg-source: warning: failed to verify signature on 
/tmp/xml-security-c_1.7.3-3~bpo7+1.dsc

dpkg-source: error: file /tmp/xml-security-c_1.7.3.orig.tar.gz has size 909320 
instead of expected 897454


please use the right orig tarball, thanks.


it should be all for now.

cheers,

G.

Bug#833909: RFS: xml-security-c/1.7.3-3~bpo7+1 [BPO]

[Etienne Dysli-Metref]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my backport of package "xml-security-c"
to wheezy-backports-sloppy as a first step to backporting other
Shibboleth packages to wheezy and jessie (see
https://qa.debian.org/developer.php?email=pkg-shibboleth-devel%40lists.a
lioth.debian.org
for a list of Shib packages).

* Package name: xml-security-c
  Version : 1.7.3-3~bpo7+1
  Upstream Author : http://santuario.apache.org/team.html
* URL : http://santuario.apache.org/cindex.html
* License : Apache-2.0
  Section : libs

It builds those binary packages:

libxml-security-c-dev - C++ library for XML Digital Signatures
(development)
libxml-security-c17v5 - C++ library for XML Digital Signatures (runtime)
xml-security-c-utils - C++ library for XML Digital Signatures (utilities
)

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

  https://mentors.debian.net/package/xml-security-c

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

  dget -x
https://mentors.debian.net/debian/pool/main/x/xml-security-c/xml-securit
y-c_1.7.3-3~bpo7+1.dsc

More information about xml-security-c can be obtained from
http://santuario.apache.org/cindex.html.

Changes since the last upload (wheezy 1.6.1-5+deb7u2):

 xml-security-c (1.7.3-3~bpo7+1) wheezy-backports-sloppy; urgency=medium
 .
   [ Etienne Dysli Metref ]
   * Rebuild for wheezy-backports-sloppy.
   * [aba87f7] New patch
Remove-PKG_INSTALLDIR-to-build-with-older-pkg-config.patch
 .
 xml-security-c (1.7.3-3) unstable; urgency=medium
 .
   * [dee8abd] New patch Only-add-found-packages-to-the-pkg-config-
 dependenci.patch
 .
 xml-security-c (1.7.3-2) unstable; urgency=medium
 .
   * [9af4b2f] New patches fixing GCC-6 FTBFS, warnings and typos
 (Closes: #811620)
   * [eb1af76] Update Standards-Version to 3.9.8 (no changes needed)
   * [e742472] Switch to secure VCS URIs
   * [894b638] New patch Use-pkg-config-for-Xerces-OpenSSL-and-NSS-and-
 provid.patch
   * [64c49b7] New patch We-do-not-use-pthreads-threadtest.cpp-is-Window
s-
 onl.patch
   * [a5a8a19] The build system now links with the needed libraries only
 .
 xml-security-c (1.7.3-1) unstable; urgency=medium
 .
   * [df661d6] Check signature in watch file
   * [b78a045] Add debian/gbp.conf enabling pristine-tar
   * [ca9476a] Imported Upstream version 1.7.3
   * [f8b635d] Delete upstreamed patch "Avoid use of PATH_MAX where
possible"
   * [9d2337f] Switch watch file to check for bzip-compressed archives
   * [f95b4ef] The default compressor is xz since jessie
   * [ed19f44] Renaming of the binaries happends via a patch since
4771f62 and
 017dc35
   * [34dd591] Enable all hardening features
   * [893eda7] Remove superfluous dh_clean override
   * [2207b52] Fail package build if any installed file is left out in
the future
   * [62c8d2f] Add myself to Uploaders
   * [4afa12e] Update Standards-Version to 3.9.6 (no changes needed)
   * [d338569] Since 2b8a713 we've got proper patch files
   * [cd68dec] Enable commit ids in gbp dch
   * [71cc459] Add version number to the manual pages
   * [e544a7b] Run wrap-and-sort -ast on the package
   * [cf73c2b] Get rid of patch numbers
   * [0832cf9] New patch
 Avoid-forward-incompatibility-warnings-from-Automake.patch
   * [3099c82] Comment the --as-needed tricks
   * [e26686c] Update debian/copyright
   * [3fad239] Add NOTICE.txt to all binary packages
   * [4eaef76] Incorporate the 1.7.2-3.1 NMU.  Thanks to Julien Cristau.
 .
 xml-security-c (1.7.2-3.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Rename library packages for g++5 ABI transition (closes: 791323).
 .
 xml-security-c (1.7.2-3) unstable; urgency=medium
 .
   * Avoid use of PATH_MAX where possible by using getcwd to allocate th
e
 appropriate size string.  Fixes FTBFS on GNU/Hurd.  Patch from Svan
te
 Signell.  (Closes: #735162)
   * Convert all Debian patches to separate patch files managed via
gbp pq.
   * Update standards version to 3.9.5 (no changes required).
 .
 xml-security-c (1.7.2-2) unstable; urgency=low
 .
   * Upload to unstable.
 .
 xml-security-c (1.7.2-1) experimental; urgency=high
 .
   * New upstream release.
 - The attempted fix to address CVE-2013-2154 introduced the
   possibility of a heap overflow, possibly leading to arbitrary cod
e
   execution, in the processing of malformed XPointer expressions in
   the XML Signature Reference processing code.  Fix that heap
   overflow.  (Closes: #714241, CVE-2013-2210)
 .
 xml-security-c (1.7.1-1) experimental; urgency=high
 .
   * New upstream release.
 - Fix a spoofing vulnerability that allows an attacker to reuse
   existing signatures with arbitrary content.  (CVE-2013-2153)
 - Fix a stack overflow in the processing of malformed XPointer
   expressions in the XML Signature Reference 

Re: Bug#833288: would FTBFS now with cython 0.24.1 MACS2/IO/PeakIO.pyx:632:49: Cannot assign type 'float' to 'int'

[Andreas Tille]

Hi,

I can confirm this bug.

I've checked MACS2/IO/PeakIO.pyx and I think the typing of the function
call should be fine - so probably the problem is somewhere else - but
where?

Any help would be welcome

  Andreas.

On Tue, Aug 02, 2016 at 10:37:50AM -0400, Yaroslav Halchenko wrote:
> Package: macs
> Version: 2.1.1.20160309-1
> Severity: serious
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> 
> I have just uploaded cython 0.24.1 into sid and while testing reverse build
> depends found that macs fails to build.  Here is the log extract:
> 
> building 'MACS2.Signal' extension
> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
> -Wstrict-prototypes -fno-strict-aliasing -g -O2 -fstack-protector-strong 
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> -I/usr/lib/python2.7/dist-packages/numpy/core/include 
> -I/usr/include/python2.7 -c MACS2/Signal.c -o 
> build/temp.linux-x86_64-2.7/MACS2/Signal.o -w -O3 -ffast-math
> x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
> -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall 
> -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g 
> -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
> -Wl,-z,now -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-2.7/MACS2/Signal.o -o 
> /build/macs-2.1.1.20160309/.pybuild/pythonX.Y_2.7/build/MACS2/Signal.so
> cythoning MACS2/IO/PeakIO.pyx to MACS2/IO/PeakIO.c
> 
> Error compiling Cython file:
> 
> ...
> pileup = float(fields[5])
> pscore = float(fields[6])
> fc = float(fields[7])
> qscore = float(fields[8])
> peakname = rstrip(fields[9])
> add(chrom, start, end, summit, qscore, pileup, pscore, fc, qscore,
> ^
> 
> 
> MACS2/IO/PeakIO.pyx:632:49: Cannot assign type 'float' to 'int'
> building 'MACS2.IO.PeakIO' extension
> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
> -Wstrict-prototypes -fno-strict-aliasing -g -O2 -fstack-protector-strong 
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> -I/usr/include/python2.7 -c MACS2/IO/PeakIO.c -o 
> build/temp.linux-x86_64-2.7/MACS2/IO/PeakIO.o -w -O3 -ffast-math
> MACS2/IO/PeakIO.c:1:2: error: #error Do not use this file, it is the result 
> of a failed Cython compilation.
>  #error Do not use this file, it is the result of a failed Cython compilation.
>   ^
> error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
> E: pybuild pybuild:274: build: plugin distutils failed with: exit code=1: 
> /usr/bin/python setup.py build 
> dh_auto_build: pybuild --build -i python{version} -p 2.7 returned exit code 13
> debian/rules:16: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 25
> make[1]: Leaving directory '/build/macs-2.1.1.20160309'
> debian/rules:13: recipe for target 'build' failed
> make: *** [build] Error 2
> 
> 
> cheers!
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), 
> (100, 'unstable-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de