Bug#861649: Newer version uploaded

[Tobias Frost]

On Mon, Mar 26, 2018 at 04:40:12PM +0200, Gard Spreemann wrote:
> Hello again,
> 
> A new version has been uploaded to mentors. It contains the following
> changes since last time:
> 
>  - Upstream's CGAL patches were removed from the DFSG sources to
>simplify copyright information. These are not needed for CGAL >>
>4.11, and so the build-deps were updated accordingly.
> 
>  - A small man page for gudhui(1) was added to the gudhui package.
> 
>  - Build-depend on python3-all per
>https://wiki.debian.org/Python/LibraryStyleGuide
> 
>  - Remove trivially satisfiable build-dep version bounds.
> 
>  - The short-name for GPL-3+ was changed from GPL-3.0+.
> 
>  - Lower the recommends deps of libgudhi-examples to suggests.
> 
>  - The copyright information was hopefully rectified; I'd appreciate
>it if you could have a look.

I think that will work out, though the last word will be of the FTP
masters ;-)

>  - Excluded C++ source files from compression. These are in the
>examples package, and it seems reasonable to me that anyone
>installing that package wants the uncompressed example sources.
> 
> 
> Thanks again!

Welcome! I will upload the package ASAP, thanks for your contributions to 
Debian!
> 
>  -- Gard
>  
> 

tobi


signature.asc
Description: PGP signature

Bug#861649: Newer version uploaded

[Gard Spreemann]

Hello again,

A new version has been uploaded to mentors. It contains the following
changes since last time:

 - Upstream's CGAL patches were removed from the DFSG sources to
   simplify copyright information. These are not needed for CGAL >>
   4.11, and so the build-deps were updated accordingly.

 - A small man page for gudhui(1) was added to the gudhui package.

 - Build-depend on python3-all per
   https://wiki.debian.org/Python/LibraryStyleGuide

 - Remove trivially satisfiable build-dep version bounds.

 - The short-name for GPL-3+ was changed from GPL-3.0+.

 - Lower the recommends deps of libgudhi-examples to suggests.

 - The copyright information was hopefully rectified; I'd appreciate
   it if you could have a look.

 - Excluded C++ source files from compression. These are in the
   examples package, and it seems reasonable to me that anyone
   installing that package wants the uncompressed example sources.


Thanks again!


 -- Gard
 

Bug#861649: Newer version uploaded

[Tobias Frost]

On Fri, Mar 23, 2018 at 06:29:33PM +0100, Gard Spreemann wrote:
> On Tuesday 13 March 2018 13:58:07 CET Tobias Frost wrote:
> > On Sun, Mar 11, 2018 at 06:48:10PM +0100, Gard Spreemann wrote:
> > > On Sunday 11 March 2018 00:18:32 CET Gard Spreemann wrote:
> > > > On Wednesday 7 March 2018 19:32:48 CET Tobias Frost wrote:
> > > > > Please review d/copyright. I found at least one undocumented file 
> > > > > which
> > > > > is licensed Apache 2.0 and another one under LGPL3+. Neither are in 
> > > > > d/copyright.
> > > > 
> > > > I'm looking into this, and will get back to you.
> > > > 
> > > 
> > > I've updated the copyright information for the Apache 2.0-licensed
> > > file, as well as another MIT-licensed file with missing coverage.
> > 
> > Thanks!.
> > 
> > Note that some files are claimed copyright just by "20xx INRIA" and
> > "20xx INRIA (France)"
> > As copyright must be verbatim, you need to addtionalyl write this in 
> > d/copyright.
> > Not sure about all those other variants of INRIA: Are they different
> > organisattions (like a subsidiary) of just different writing of the same
> > one? In the first case, you need to have one stanca for every different
> > organisations,
> > (hint: license-reconcile might help here)
> 
> I got in touch with upstream, who says:
> 
> [Begin quote]
> This is a problem we have seen, but it was "too late", everybody
> copy/paste the colleague copyright and just changed the Inria center's
> name...  I have started to change it every where, every time I fix a
> bug, but from what you say, I shall change it once for every files ;-)
> 
> The correct Copyright is "Inria".
> 
> If you want, I can change it everywhere and make a new version if it
> can accelerate the submission.
> [End quote]
> 
> It certainly sounds great if they can fix this upstream, but would a
> statement like this suffice for now?

Thanks for clarify it with upstream!
I guess it will be sufficient to store the email as comment in
d/copyright, but probably less effort would be to just have an addtional
Copyright: stanca for it (as you can combine paragraphs in d/copyright,
it will be only one extra line in the Files: * section)

> > Speaking about external sources... I see that there is also cpython in
> > the source. As cpython is packaged, can it be also removed via
> > Files-Exluded (as you said, you're repacking already, so we can reduce
> > the size of the source package even more)
> 
> Maybe I misunderstood, but I can't see a bundled cpython. Did you mean
> the cython subdirectory? It just contains .pyx sources to be compiled
> with cython.

thanks for explaining! I thought those are cython source, I did not
realize that it is only used by cython. -> disregard my comment...

> > Older stuff already mentioned, but still not fixed:
> >   - many versioned build dependencies are already satisfied since
> >   oldstable. As thus those old version constraint can be removed,
> >   especially as this is a new package.
> 
> I've fixed this now (but haven't made a new upload).
> 
> 
> Thanks a lot for your help. I'll upload a new version (also having a
> new dependency that has become necessary after a change to sid's
> Python package) when I hear back from you about the copyright question
> above.

\o/ 
Looking forward for the upload!

--
tobi

> 
>  Best,
>  Gard
> 

Bug#861649: Newer version uploaded

[Gard Spreemann]

On Tuesday 13 March 2018 13:58:07 CET Tobias Frost wrote:
> On Sun, Mar 11, 2018 at 06:48:10PM +0100, Gard Spreemann wrote:
> > On Sunday 11 March 2018 00:18:32 CET Gard Spreemann wrote:
> > > On Wednesday 7 March 2018 19:32:48 CET Tobias Frost wrote:
> > > > Please review d/copyright. I found at least one undocumented file which
> > > > is licensed Apache 2.0 and another one under LGPL3+. Neither are in 
> > > > d/copyright.
> > > 
> > > I'm looking into this, and will get back to you.
> > > 
> > 
> > I've updated the copyright information for the Apache 2.0-licensed
> > file, as well as another MIT-licensed file with missing coverage.
> 
> Thanks!.
> 
> Note that some files are claimed copyright just by "20xx INRIA" and
> "20xx INRIA (France)"
> As copyright must be verbatim, you need to addtionalyl write this in 
> d/copyright.
> Not sure about all those other variants of INRIA: Are they different
> organisattions (like a subsidiary) of just different writing of the same
> one? In the first case, you need to have one stanca for every different
> organisations,
> (hint: license-reconcile might help here)

I got in touch with upstream, who says:

[Begin quote]
This is a problem we have seen, but it was "too late", everybody
copy/paste the colleague copyright and just changed the Inria center's
name...  I have started to change it every where, every time I fix a
bug, but from what you say, I shall change it once for every files ;-)

The correct Copyright is "Inria".

If you want, I can change it everywhere and make a new version if it
can accelerate the submission.
[End quote]

It certainly sounds great if they can fix this upstream, but would a
statement like this suffice for now?
 
> Speaking about external sources... I see that there is also cpython in
> the source. As cpython is packaged, can it be also removed via
> Files-Exluded (as you said, you're repacking already, so we can reduce
> the size of the source package even more)

Maybe I misunderstood, but I can't see a bundled cpython. Did you mean
the cython subdirectory? It just contains .pyx sources to be compiled
with cython.

> Older stuff already mentioned, but still not fixed:
>   - many versioned build dependencies are already satisfied since
>   oldstable. As thus those old version constraint can be removed,
>   especially as this is a new package.

I've fixed this now (but haven't made a new upload).


Thanks a lot for your help. I'll upload a new version (also having a
new dependency that has become necessary after a change to sid's
Python package) when I hear back from you about the copyright question
above.


 Best,
 Gard

Bug#861649: Newer version uploaded

[Tobias Frost]

Control: tags -1 moreinfo

On Sun, Mar 11, 2018 at 06:48:10PM +0100, Gard Spreemann wrote:
> On Sunday 11 March 2018 00:18:32 CET Gard Spreemann wrote:
> > On Wednesday 7 March 2018 19:32:48 CET Tobias Frost wrote:
> > > Please review d/copyright. I found at least one undocumented file which
> > > is licensed Apache 2.0 and another one under LGPL3+. Neither are in 
> > > d/copyright.
> > 
> > I'm looking into this, and will get back to you.
> > 
> 
> I've updated the copyright information for the Apache 2.0-licensed
> file, as well as another MIT-licensed file with missing coverage.

Thanks!.

Note that some files are claimed copyright just by "20xx INRIA" and
"20xx INRIA (France)"
As copyright must be verbatim, you need to addtionalyl write this in 
d/copyright.
Not sure about all those other variants of INRIA: Are they different
organisattions (like a subsidiary) of just different writing of the same
one? In the first case, you need to have one stanca for every different
organisations,
(hint: license-reconcile might help here)

> It turns out that the swaths of LGPL3+-licensed files were CGAL
> patches carried by upstream to support CGAL << 4.11. Since CGAL 4.11.1
> is in buster, and there's already a lot of DFSG modifications to the
> upstream source in my package, I simply added deletion of these
> patches in the DFSG modifications and bumped the CGAL version
> requirements accordingly. I verified that the patches are only used
> when CGAL << 4.11 is detected. Is this satisfactory?

Yes, this will work.
Speaking about external sources... I see that there is also cpython in
the source. As cpython is packaged, can it be also removed via
Files-Exluded (as you said, you're repacking already, so we can reduce
the size of the source package even more)

> A new version has been uploaded to mentors:
> 
>  https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_2.1.0+dfsg-1.dsc


Older stuff already mentioned, but still not fixed:
  - many versioned build dependencies are already satisfied since
  oldstable. As thus those old version constraint can be removed,
  especially as this is a new package.

Many thanks for putting doxygen generation into build-indep!

> 
> Thanks again!
> 
>  -- Gard


Ok, otherwise package is ready... So please fix the last bits,
especially the copyright remarks, and then it will be ready.

--
tobi

Bug#861649: Newer version uploaded

[Tobias Frost]

On Sun, Mar 11, 2018 at 12:18:32AM +0100, Gard Spreemann wrote:
> On Wednesday 7 March 2018 19:32:48 CET Tobias Frost wrote:
> > But the lintian stuff I complained about is not completly fixed, there
> > is even a new tag: 
> > I: gudhi source: quilt-patch-missing-description no-external-doc-
> > resources.patch
> > 
> > Please run lintian after every build! Best, include it into pbuilder or
> > like! Remember "some sponsors are evil and pedantic [1] when running
> > lintian.
> > 
> > [1]  https://nthykier.wordpress.com/2012/02/23/some-sponsors-are-evil-a
> > nd-pedantic/
> 
> Ah, I'm sorry; I had accidentally run lintian too unpedantically and
> with an older version. I've adopted your suggested routine now. Thanks
> a lot!
> 
> Some comments/questions on other lintian messages follow.
> 
> > I: gudhi source: binary-control-field-duplicates-source field "section"
> > in package gudhui
> 
> Since there's nothing inherent about one of the binary packages being
> in the same section as the source, I think it should be OK to keep
> this as is. Does that seem OK?

You do not need to specify it for binaries when it is in the same section as the
source. So all "section: math" of the binary packages could go. 
But as it is only "informational" you can decide yourself whether you
want to keep ti

> > P: gudhi source: file-contains-trailing-whitespace debian/control (line
> > 110)
> 
> Fixed.
> 
> > P: gudhi source: package-uses-old-debhelper-compat-version 10
> 
> Fixed.
> 
> > I: gudhi source: quilt-patch-missing-description no-external-doc-
> > resources.patch
> 
> Fixed.
> 
> > W: gudhi source: unnecessary-testsuite-autopkgtest-field
> 
> Fixed.
> 
> > I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist-
> > packages/gudhi.cpython-36m-x86_64-linux-gnu.so ment meant
> > I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist-
> > packages/gudhi.cpython-36m-x86_64-linux-gnu.so preambule preamble
> > I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist-
> > packages/gudhi.cpython-36m-x86_64-linux-gnu.so choosen chosen
> 
> I'd prefer to consider these upstream bugs. I can report them, but I
> guess it's OK to leave these minor things unpatched?

Again a personal style thing... I usually make a patch for upstream,
asking to merge it and as then I'd already have the patch then I
also apply it to the Debian package. 
But It's ok just to send the patch upstream asking to merge it.

> > W: libgudhi-examples: lib-recommends-documentation recommends:
> > libgudhi-doc
> 
> I think this is a false report; libgudhi-examples is in fact not a
> library package.

Ok; IMHO it shouls be only a "Suggest" (not "Recommend") here.

> 
> > I: libgudhi-doc: possible-documentation-but-no-doc-base-registration
> 
> Fixed.
> 
> > I: gudhui: spelling-error-in-binary usr/bin/gudhui preambule preamble
> 
> See above.
> 
> > P: gudhui: no-upstream-changelog
> 
> Upstream doesn't supply one.

yepp, no need to fix that.

> > W: gudhui: binary-without-manpage usr/bin/gudhui
> 
> This is a GUI tool without an upstream manpage. Should I make a stub
> one?

We usually try to have manpages for every binary. So it would be great
if you could make a manpage for it.

> > Please review d/copyright. I found at least one undocumented file which
> > is licensed Apache 2.0 and another one under LGPL3+. Neither are in 
> > d/copyright.
> 
> I'm looking into this, and will get back to you.

OK.

> 
>  Best,
>  Gard
>  
> 
> 
> 
> 

Bug#861649: Newer version uploaded

[Gard Spreemann]

On Sunday 11 March 2018 00:18:32 CET Gard Spreemann wrote:
> On Wednesday 7 March 2018 19:32:48 CET Tobias Frost wrote:
> > Please review d/copyright. I found at least one undocumented file which
> > is licensed Apache 2.0 and another one under LGPL3+. Neither are in 
> > d/copyright.
> 
> I'm looking into this, and will get back to you.
> 

I've updated the copyright information for the Apache 2.0-licensed
file, as well as another MIT-licensed file with missing coverage.

It turns out that the swaths of LGPL3+-licensed files were CGAL
patches carried by upstream to support CGAL << 4.11. Since CGAL 4.11.1
is in buster, and there's already a lot of DFSG modifications to the
upstream source in my package, I simply added deletion of these
patches in the DFSG modifications and bumped the CGAL version
requirements accordingly. I verified that the patches are only used
when CGAL << 4.11 is detected. Is this satisfactory?

A new version has been uploaded to mentors:

 https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_2.1.0+dfsg-1.dsc
 

Thanks again!

 -- Gard

Bug#861649: Newer version uploaded

[Gard Spreemann]

On Wednesday 7 March 2018 19:32:48 CET Tobias Frost wrote:
> But the lintian stuff I complained about is not completly fixed, there
> is even a new tag: 
> I: gudhi source: quilt-patch-missing-description no-external-doc-
> resources.patch
> 
> Please run lintian after every build! Best, include it into pbuilder or
> like! Remember "some sponsors are evil and pedantic [1] when running
> lintian.
> 
> [1]  https://nthykier.wordpress.com/2012/02/23/some-sponsors-are-evil-a
> nd-pedantic/

Ah, I'm sorry; I had accidentally run lintian too unpedantically and
with an older version. I've adopted your suggested routine now. Thanks
a lot!

Some comments/questions on other lintian messages follow.

> I: gudhi source: binary-control-field-duplicates-source field "section"
> in package gudhui

Since there's nothing inherent about one of the binary packages being
in the same section as the source, I think it should be OK to keep
this as is. Does that seem OK?

> P: gudhi source: file-contains-trailing-whitespace debian/control (line
> 110)

Fixed.

> P: gudhi source: package-uses-old-debhelper-compat-version 10

Fixed.

> I: gudhi source: quilt-patch-missing-description no-external-doc-
> resources.patch

Fixed.

> W: gudhi source: unnecessary-testsuite-autopkgtest-field

Fixed.

> I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist-
> packages/gudhi.cpython-36m-x86_64-linux-gnu.so ment meant
> I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist-
> packages/gudhi.cpython-36m-x86_64-linux-gnu.so preambule preamble
> I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist-
> packages/gudhi.cpython-36m-x86_64-linux-gnu.so choosen chosen

I'd prefer to consider these upstream bugs. I can report them, but I
guess it's OK to leave these minor things unpatched?

> W: libgudhi-examples: lib-recommends-documentation recommends:
> libgudhi-doc

I think this is a false report; libgudhi-examples is in fact not a
library package.

> I: libgudhi-doc: possible-documentation-but-no-doc-base-registration

Fixed.

> I: gudhui: spelling-error-in-binary usr/bin/gudhui preambule preamble

See above.

> P: gudhui: no-upstream-changelog

Upstream doesn't supply one.

> W: gudhui: binary-without-manpage usr/bin/gudhui

This is a GUI tool without an upstream manpage. Should I make a stub
one?

> Please review d/copyright. I found at least one undocumented file which
> is licensed Apache 2.0 and another one under LGPL3+. Neither are in 
> d/copyright.

I'm looking into this, and will get back to you.


 Best,
 Gard
 

Bug#861649: Newer version uploaded

[Tobias Frost]

Control: tags -1 moreinfo

On Tue, 06 Mar 2018 16:24:53 +0100 Gard Spreemann  
> Upstream provided a patch that fixes this. I've updated
> 
>  https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_2.1.0+dfsg
-1.dsc

Thanks!

But the lintian stuff I complained about is not completly fixed, there
is even a new tag: 
I: gudhi source: quilt-patch-missing-description no-external-doc-
resources.patch

Please run lintian after every build! Best, include it into pbuilder or
like! Remember "some sponsors are evil and pedantic [1] when running
lintian. 

[1]  https://nthykier.wordpress.com/2012/02/23/some-sponsors-are-evil-a
nd-pedantic/

Those linitian messages should be fixed before an upload:
(As at least partially already asked for in earlier reviews)

N: Starting on group gudhi/2.1.0+dfsg-1
N: Unpacking packages in group gudhi/2.1.0+dfsg-1
N: 
N: Processing changes file gudhi (version 2.1.0+dfsg-1, arch source
amd64 all) ...
N: 
N: Processing source package gudhi (version 2.1.0+dfsg-1, arch source)
...
I: gudhi source: binary-control-field-duplicates-source field "section"
in package gudhui
P: gudhi source: file-contains-trailing-whitespace debian/control (line
110)
P: gudhi source: package-uses-old-debhelper-compat-version 10
I: gudhi source: quilt-patch-missing-description no-external-doc-
resources.patch
W: gudhi source: unnecessary-testsuite-autopkgtest-field
N: 
N: Processing binary package python3-gudhi (version 2.1.0+dfsg-1, arch
amd64) ...
I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist-
packages/gudhi.cpython-36m-x86_64-linux-gnu.so ment meant
I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist-
packages/gudhi.cpython-36m-x86_64-linux-gnu.so preambule preamble
I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist-
packages/gudhi.cpython-36m-x86_64-linux-gnu.so choosen chosen
N: 
N: Processing binary package libgudhi-examples (version 2.1.0+dfsg-1,
arch all) ...
W: libgudhi-examples: lib-recommends-documentation recommends:
libgudhi-doc
N: 
N: Processing binary package libgudhi-doc (version 2.1.0+dfsg-1, arch
all) ...
I: libgudhi-doc: possible-documentation-but-no-doc-base-registration
N: 
N: Processing binary package libgudhi-dev (version 2.1.0+dfsg-1, arch
all) ...
N: 
N: Processing binary package python3-gudhi-dbgsym (version 2.1.0+dfsg-
1, arch amd64) ...
N: 
N: Processing binary package gudhui (version 2.1.0+dfsg-1, arch amd64)
...
I: gudhui: spelling-error-in-binary usr/bin/gudhui preambule preamble
P: gudhui: no-upstream-changelog
W: gudhui: binary-without-manpage usr/bin/gudhui

 
Please review d/copyright. I found at least one undocumented file which
is licensed Apache 2.0 and another one under LGPL3+. Neither are in 
d/copyright.

Again, remove moreinfo when ready.

--

tobi

Bug#861649: Newer version uploaded

[Gard Spreemann]

On Wednesday 28 February 2018 22:26:58 CET Tobias Frost wrote:
> But there are tons of lintian warnings "privacy-break-generic", just
> one example: Not checked, but maybe some template for the doc
> generation has a link to this site?
> 
> W: libgudhi-doc: privacy-breach-generic
> […]

Upstream provided a patch that fixes this. I've updated

 https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_2.1.0+dfsg-1.dsc


 Best regards,
 Gard Spreemann

Bug#861649: Newer version uploaded

[Gard Spreemann]

On Wednesday, 28 February 2018 22:26:58 CET Tobias Frost wrote:
> Ok, it builds now.
> But there are tons of lintian warnings "privacy-break-generic", just
> one example: Not checked, but maybe some template for the doc
> generation has a link to this site?
> 
> […]
> 
> There are other lintian warnings as well; just a friendly reminder to
> alwyays run linitian. Better, include it in your build process so that
> it is automatically executed...

Very good point! Thanks a lot for pointing this out! I'll see if I can
patch the docs to avoid this; if not, I'll avoid building a
documentation package alltogether.

Are there other aspects of the package you feel should be improved?


 Best,
 Gard

Bug#861649: Newer version uploaded

[Tobias Frost]

Control: tags -1 moreinfo

On Mon, 05 Feb 2018 11:07:40 +0100 Gard Spreemann  wrote:
> Control: tags -1 - moreinfo
> 
> On Tuesday 26 December 2017 21:58:36 CET Tobias Frost wrote:
> > I was checking your RFS, but I cannot get it compiled...
> > Please check and then remove the moreinfo tag again...
> 
> Hello again,
> 
> Upstream has now released GUDHI 2.1.0 which is compatible with the
> CGAL version in sid.
> 
> If you have a chance to take a look, version 2.1.0-1 of the package
> can be obtained from
> 
>  https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_2.1.0+dfsg
-1.dsc
> 

Ok, it builds now.
But there are tons of lintian warnings "privacy-break-generic", just
one example: Not checked, but maybe some template for the doc
generation has a link to this site?

W: libgudhi-doc: privacy-breach-generic
usr/share/doc/libgudhi/html/_active__witness_8h_source.html [http://gudhi.gforge.inria.fr/assets/img/home.png";
alt="  gudhi">] (http://gudhi.gforge.inria.fr/assets/img/home
.png) 
W: libgudhi-doc: privacy-breach-generic
usr/share/doc/libgudhi/html/_active__witness_8h_source.html [http://pages.saclay.inria.fr/vin
cent.rouvreau/gudhi/gudhi-doc-
2.0.0/assets/css/styles_feeling_responsive.css" />] (http://pages.sacla
y.inria.fr/vincent.rouvreau/gudhi/gudhi-doc-
2.0.0/assets/css/styles_feeling_responsive.css)

There are other lintian warnings as well; just a friendly reminder to
alwyays run linitian. Better, include it in your build process so that
it is automatically executed...


--
tobi

Bug#861649: Newer version uploaded

[Gard Spreemann]

Control: tags -1 - moreinfo

On Tuesday 26 December 2017 21:58:36 CET Tobias Frost wrote:
> I was checking your RFS, but I cannot get it compiled...
> Please check and then remove the moreinfo tag again...

Hello again,

Upstream has now released GUDHI 2.1.0 which is compatible with the
CGAL version in sid.

If you have a chance to take a look, version 2.1.0-1 of the package
can be obtained from

 https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_2.1.0+dfsg-1.dsc



 Best,
 Gard

Bug#861649: Newer version uploaded

[Gard Spreemann]

On Tuesday 26 December 2017 21:58:36 CET Tobias Frost wrote:
> Hi Gard,
> 
> I was checking your RFS, but I cannot get it compiled...

Hello Tobias, and thanks for your feedback.

Apparently this is a known regression [1] when building with CGAL
4.11. That version entered sid after last time I built GUDHI, so I
hadn't noticed. Upstream says it will fix the problem in its next
release, so I'll wait for that and then reupload.


[1] 
https://lists.gforge.inria.fr/pipermail/gudhi-users/2017-December/97.html


 Best,
 Gard
 

Bug#861649: Newer version uploaded

[Tobias Frost]

Control: tags -1 moreinfo

Hi Gard,

I was checking your RFS, but I cannot get it compiled...
Please check and then remove the moreinfo tag again...

tobi

excerpt from the log:

/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:57:21: error: 'Bare_point' in 'using Gt = class
CGAL::Regular_triangulation_euclidean_traits_3 {aka class
CGAL::Regular_triangulation_euclidean_traits_3}' does not
name a type
 using Point_3 = Gt::Bare_point;
 ^~
/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:58:30: error: 'Weighted_point' in 'using Gt = class
CGAL::Regular_triangulation_euclidean_traits_3 {aka class
CGAL::Regular_triangulation_euclidean_traits_3}' does not
name a type
 using Weighted_point_3 = Gt::Weighted_point;
  ^~
/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp: In function 'int main(int, char* const*)':
/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:107:31: error: 'Point_3' was not declared in this scope
   Gudhi::Points_3D_off_reader off_reader(offInputFile);
   ^~~
/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:107:31: note: suggested alternative:
In file included from /usr/include/CGAL/user_classes.h:42:0,
 from /usr/include/CGAL/Kernel/global_functions_2.h:33,
 from /usr/include/CGAL/Kernel/global_functions.h:31,
 from /usr/include/CGAL/Cartesian/Cartesian_base.h:30,
 from /usr/include/CGAL/Simple_cartesian.h:28,
 from
/usr/include/CGAL/Exact_predicates_inexact_constructions_kernel.h:28,
 from /build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:29:
/usr/include/CGAL/Point_3.h:39:7: note:   'CGAL::Point_3'
 class Point_3 : public R_::Kernel_base::Point_3
   ^~~
/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:107:38: error: template argument 1 is invalid
   Gudhi::Points_3D_off_reader off_reader(offInputFile);
  ^
/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:107:63: error: cannot convert 'std::__cxx11::string {aka
std::__cxx11::basic_string}' to 'int' in initialization
   Gudhi::Points_3D_off_reader off_reader(offInputFile);

Bug#861649: Newer version uploaded

[Ghislain Vaillant]

On 16/10/17 15:39, Gard Spreemann wrote:

On Monday 16 October 2017 11:53:08 CEST Ghislain Vaillant wrote:

On 16/10/17 11:22, Gard Spreemann wrote:

Not relevant since the upload would be to sid anyway, right?


FYI, current version is 4.1.1.


Checked and bumped. Thanks.


   E: python3-gudhi: binary-or-shlib-defines-rpath
   usr/lib/python3/dist-packages/gudhi.cpython-35m-x86_64-linux-gnu.so
   /usr/lib/x86_64-linux-gnu>
I admit I'm on thin ice here, but from
https://wiki.debian.org/RpathIssue I had the impression that the use
of RPATH is OK here since only the python3 executable would be loading
the shared object. Am I correct?


It will import is as a module, no? You should not need rpath for public
extension modules. Look for usage of `runtime_library_dirs` in the
definition of the extension module within setup.py.


I've added a patch to give an empty argument to
runtime_library_dirs. The lintian warning went away, and the Python
extension still works.

Thank you.


These are very simple example programs only used together with the
documentation and their own source code. As such it feels a bit
strange for them to have manpages. I could also remove that binary
package, if you think that is better.


Ask yourself whether these are worth shipping. I suspect the examples
are more useful in source code form than binary.


I've changed the -examples package to just ship sources.


I believe that's wise.


By the way: I'm currently letting dh have its way with whether or not
it compresses the sources, which gives an inconsistent result. Should
I do something about this?


Yes, I'd advise to override dh_compress to exclude the examples from 
compression.



This was actually done on purpose. The examples are really meant to be
used together with the documentation, and as such I don't think the
warning applies here. Please let me know if I'm wrong.


Did you declare libgudhi-examples as a library package instead of misc
or doc by any chance (see Section field in d/control)? Then, the warning
would be accurate. Instead, ship the examples in source code form and
make the package Section: misc.


No problem. Glad to see your packaging work is progressing.

Ghis

Bug#861649: Newer version uploaded

[Gard Spreemann]

On Monday 16 October 2017 11:53:08 CEST Ghislain Vaillant wrote:
> On 16/10/17 11:22, Gard Spreemann wrote:
> > Not relevant since the upload would be to sid anyway, right?
> 
> FYI, current version is 4.1.1.

Checked and bumped. Thanks.

> >   E: python3-gudhi: binary-or-shlib-defines-rpath
> >   usr/lib/python3/dist-packages/gudhi.cpython-35m-x86_64-linux-gnu.so
> >   /usr/lib/x86_64-linux-gnu> 
> > I admit I'm on thin ice here, but from
> > https://wiki.debian.org/RpathIssue I had the impression that the use
> > of RPATH is OK here since only the python3 executable would be loading
> > the shared object. Am I correct?
> 
> It will import is as a module, no? You should not need rpath for public
> extension modules. Look for usage of `runtime_library_dirs` in the
> definition of the extension module within setup.py.

I've added a patch to give an empty argument to
runtime_library_dirs. The lintian warning went away, and the Python
extension still works.

Thank you.

> > These are very simple example programs only used together with the
> > documentation and their own source code. As such it feels a bit
> > strange for them to have manpages. I could also remove that binary
> > package, if you think that is better.
> 
> Ask yourself whether these are worth shipping. I suspect the examples
> are more useful in source code form than binary.

I've changed the -examples package to just ship sources.

By the way: I'm currently letting dh have its way with whether or not
it compresses the sources, which gives an inconsistent result. Should
I do something about this?

> > This was actually done on purpose. The examples are really meant to be
> > used together with the documentation, and as such I don't think the
> > warning applies here. Please let me know if I'm wrong.
> 
> Did you declare libgudhi-examples as a library package instead of misc
> or doc by any chance (see Section field in d/control)? Then, the warning
> would be accurate. Instead, ship the examples in source code form and
> make the package Section: misc.

Done.


Thanks for your help.



 -- Gard

Bug#861649: Newer version uploaded

[Ghislain Vaillant]

On 16/10/17 11:22, Gard Spreemann wrote:

On Saturday 14 October 2017 00:56:11 CEST Adam Borowski wrote:

Before a human review, it'd be good to fix issues found by automated
tools.  In particular, lintian throws a lot.  Please run it on both
source and built packages (lintian gudhi*changes).

"lintian -i" gives a helpful explanation how to fix these problems.


Hello, and thanks a lot for getting back to me.

I *think* I have evaluated all of the lintian errors, but any
suggestions or comments are very welcome:


  W: gudhi source: newer-standards-version 4.0.0 (current is 3.9.8)

Not relevant since the upload would be to sid anyway, right?


FYI, current version is 4.1.1.


  E: python3-gudhi: binary-or-shlib-defines-rpath 
usr/lib/python3/dist-packages/gudhi.cpython-35m-x86_64-linux-gnu.so 
/usr/lib/x86_64-linux-gnu

I admit I'm on thin ice here, but from
https://wiki.debian.org/RpathIssue I had the impression that the use
of RPATH is OK here since only the python3 executable would be loading
the shared object. Am I correct?


It will import is as a module, no? You should not need rpath for public 
extension modules. Look for usage of `runtime_library_dirs` in the 
definition of the extension module within setup.py.

  W: gudhui: binary-without-manpage usr/bin/gudhui

I will work on creating a man page for this.


  W: libgudhi-examples: binary-without-manpage usr/bin/libgudhi-example-*

These are very simple example programs only used together with the
documentation and their own source code. As such it feels a bit
strange for them to have manpages. I could also remove that binary
package, if you think that is better.


Ask yourself whether these are worth shipping. I suspect the examples 
are more useful in source code form than binary.



  W: libgudhi-examples: lib-recommends-documentation recommends: libgudhi-doc

This was actually done on purpose. The examples are really meant to be
used together with the documentation, and as such I don't think the
warning applies here. Please let me know if I'm wrong.


Did you declare libgudhi-examples as a library package instead of misc 
or doc by any chance (see Section field in d/control)? Then, the warning 
would be accurate. Instead, ship the examples in source code form and 
make the package Section: misc.



  W: libgudhi-doc: embedded-javascript-library 
usr/share/doc/libgudhi/html/jquery.js please use libjs-jquery


From #736360 and #736432 I had the impression that this is a

long-standing problem where there is not yet any consensus about how
to proceed. Am I overlooking something?


Indeed, that's a doxygen specific issue. You may leave it like that or 
override for it. It's up to what your future sponsor prefers.


Cheers,
Ghis

Bug#861649: Newer version uploaded

[Gard Spreemann]

On Saturday 14 October 2017 00:56:11 CEST Adam Borowski wrote:
> Before a human review, it'd be good to fix issues found by automated
> tools.  In particular, lintian throws a lot.  Please run it on both
> source and built packages (lintian gudhi*changes).
> 
> "lintian -i" gives a helpful explanation how to fix these problems.

Hello, and thanks a lot for getting back to me.

I *think* I have evaluated all of the lintian errors, but any
suggestions or comments are very welcome:


 W: gudhi source: newer-standards-version 4.0.0 (current is 3.9.8)

Not relevant since the upload would be to sid anyway, right?


 E: python3-gudhi: binary-or-shlib-defines-rpath 
usr/lib/python3/dist-packages/gudhi.cpython-35m-x86_64-linux-gnu.so 
/usr/lib/x86_64-linux-gnu

I admit I'm on thin ice here, but from
https://wiki.debian.org/RpathIssue I had the impression that the use
of RPATH is OK here since only the python3 executable would be loading
the shared object. Am I correct?


 W: gudhui: binary-without-manpage usr/bin/gudhui

I will work on creating a man page for this.


 W: libgudhi-examples: binary-without-manpage usr/bin/libgudhi-example-*

These are very simple example programs only used together with the
documentation and their own source code. As such it feels a bit
strange for them to have manpages. I could also remove that binary
package, if you think that is better.


 W: libgudhi-examples: lib-recommends-documentation recommends: libgudhi-doc

This was actually done on purpose. The examples are really meant to be
used together with the documentation, and as such I don't think the
warning applies here. Please let me know if I'm wrong.


 W: libgudhi-doc: embedded-javascript-library 
usr/share/doc/libgudhi/html/jquery.js please use libjs-jquery

>From #736360 and #736432 I had the impression that this is a
long-standing problem where there is not yet any consensus about how
to proceed. Am I overlooking something?



Again, thanks a lot for your feedback.



 Best regards,
 Gard Spreemann

Bug#861649: Newer version uploaded

[Adam Borowski]

Hi!

On Fri, Oct 13, 2017 at 11:09:41AM +0200, Gard Spreemann wrote:
> The package has now been updated to the latest upstream (2.0.1).
> 
> It can be downloaded by
> 
>  dget -x 
> https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_2.0.1+dfsg-1.dsc

Before a human review, it'd be good to fix issues found by automated tools.
In particular, lintian throws a lot.  Please run it on both source and built
packages (lintian gudhi*changes).

"lintian -i" gives a helpful explanation how to fix these problems.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.

Bug#861649: Newer version uploaded

[Gard Spreemann]

The package has now been updated to the latest upstream (2.0.1).

It can be downloaded by

 dget -x 
https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_2.0.1+dfsg-1.dsc


 Regards,
 Gard Spreemann