Re: MeshLab update ready to review/sponsor
Hi Ryan, I have uploaded the package. Please try to add some autopkgtest for the future uploads. Thanks for contribution! Anton On 12/2/20 12:24 AM, Ryan Pavlik wrote: > Hello Debian scientists! > > I have completed the update of the MeshLab package to 2020.09, which was > the latest upstream release before this morning. It is presently in > Salsa, ready for review and sponsorship: > > https://salsa.debian.org/science-team/meshlab > > As is common with this project, upstream shuffled/added some bundled > deps, so the files-excluded list got updated as did the rest of the > copyright file, which was the bulk of the work. On the plus side, the > file now mostly is the same as the output of `cme update > dpkg-copyright`, which should reduce maintenance burden. > > I don't have time this week to look at 2020.12, released today, but it > does make our Files-Excluded work much harder through some build system > modification/re-org. I've opened some discussions with upstream about > these changes, and hopefully they'll revise them so we can have an > easier-to-package 2021.01, and maybe just skip 2020.12 entirely. > > This will fix https://bugs.debian.org/975157 - the lone bug, a FTBFS and > thus serious. > > I'd also like to acknowledge the help of Anton Gladky in getting the > previous 2020.06 release out. > > Thanks for your reviews and sponsorship! > > Ryan Pavlik > > (Apologies for my previous unreadable encrypted email: looks like I > accidentally encrypted the email to myself instead of signing it. I have > reverted my Thunderbird settings.) > OpenPGP_signature Description: OpenPGP digital signature
Re: Advent calendar bug squashing issue (Was: Bug#936609: cblas / gsl hint needed (Was: Bug#936609: Ported ghmm to Python3 but issues with clapack))
Hi Dirk,
thanks for the hint but simply using gsl as is was done in this package
and now it does not build any more. However, maybe I misunderstood you
hint.
Kind regards
Andreas.
On Sat, Dec 05, 2020 at 08:32:33AM -0600, Dirk Eddelbuettel wrote:
>
> On 5 December 2020 at 12:09, Andreas Tille wrote:
> | this issue is something for our advent calendar. Anybody with cblas
> | knowledge?
>
> I am the GNU GSL maintainer, and I at one point also worked a lot with the
> Atlas and other LAPACK/BLAS packages. I think Mo may be wrong here: I did the
> same approach of "oh we can just skip GSL's cblas". I think that is
> wrong. The way the C interface of the GNU GSL works appears to be require GSL
> + GSL CBLAS. That is what every package I know using GSL does -- even though
> that "looks weird and redundant".
>
> >From a quick look at http://ghmm.org it also looks like GLS is purely
> optional and for RNGs only -- just like my RcppZiggurat (upstream) package
> does which just relies on my RcppGSL (upstream) package which just export
> `gsl-config --libs`, and has for years.
>
> So I'd give the GSL defaults here a try.
>
> (That said Mo knows a lot more than I do about BLAS, but I've watched a lot
> of GSL build too over the decades I looked after that package.)
>
> Dirk
>
>
> | Kind regards
> |
> |Andreas.
> |
> | On Mon, Jan 27, 2020 at 10:55:25AM +0100, Andreas Tille wrote:
> | > Hi again,
> | >
> | > with my last mail I wanted to express: H, to stupid to turn
> | > this hint into real code. Any more detailed hint / patch would be
> | > really welcome.
> | >
> | > Kind regards
> | >
> | > Andreas.
> | >
> | > On Mon, Jan 06, 2020 at 12:56:17PM +0100, Andreas Tille wrote:
> | > > Hi Mo,
> | > >
> | > > On Sun, Jan 05, 2020 at 08:19:07AM +, Mo Zhou wrote:
> | > > > GSL provides a set of CBLAS API/ABI, delivered with shared object
> | > > > "libgslcblas.so" and header "gsl_cblas.h". That subset becomes
> | > > > redundant once you include the headers of any standard/compatible
> | > > > (C)BLAS library. That's what the compilation error means.
> | > >
> | > > Seems you want to tell me to not include gsl_cblas.h header. However,
> | > > the code has no hit for
> | > >
> | > >grep -R gsl_cblas
> | > >
> | > > so the header is not included explicitly. So while your hint explains
> | > > the error I need to admit I have no idea yet, how to fix it.
> | > >
> | > > > Make sure that the code only use one CBLAS implementation. In the
> | > > > context of debian, I'd recommend you use the CBLAS ABI from
> libblas-dev,
> | > > > and avoid linking against -lcblas. Link against -lblas instead.
> | > >
> | > > OK, once I'm at the linking step I might come back to this hint.
> | > >
> | > > Kind regards
> | > >
> | > > Andreas.
> | > >
> | > > > On Sun, Jan 05, 2020 at 07:55:05AM +0100, Andreas Tille wrote:
> | > > > > Control: tags -1 help
> | > > > >
> | > > > > Hi,
> | > > > >
> | > > > > I was asking upstream about this issue[1] and an issue about gsl
> usage
> | > > > > is suspected. Any hint how this can be fixed?
> | > > > >
> | > > > > > Finally I have a question about building with lapack. I get:
> | > > > > >
> | > > > > > ...
> | > > > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Wdate-time
> -D_FORTIFY_SOURCE=2 -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -g -O2
> "-fdebug-prefix-map=/build/ghmm-0.9~rc3=." -fstack-protector-strong -
> Wformat -Werror=format-security -I/usr/include
> -I/usr/include/x86_64-linux-gnu -I/usr/include/libxml2 -c rng.c -fPIC -DPIC
> -o .libs/rng.o
> | > > > > > In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
> | > > > > > from matrixop.c:48:
> | > > > > > /usr/include/x86_64-linux-gnu/cblas.h:5:9: error: nested
> redefinition of 'enum CBLAS_ORDER'
> | > > > > > 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102
> };
> | > > > > > | ^~~
> | > > > > > /usr/include/x86_64-linux-gnu/cblas.h:5:9: error: redeclaration
> of 'enum CBLAS_ORDER'
> | > > > > > In file included from /usr/include/gsl/gsl_blas_types.h:28,
> | > > > > > from /usr/include/gsl/gsl_blas.h:29,
> | > > > > > from /usr/include/gsl/gsl_linalg.h:30,
> | > > > > > from matrixop.c:44:
> | > > > > > /usr/include/gsl/gsl_cblas.h:46:6: note: originally defined here
> | > > > > >46 | enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102};
> | > > > > > | ^~~
> | > > > > > In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
> | > > > > > from matrixop.c:48:
> | > > > > > /usr/include/x86_64-linux-gnu/cblas.h:5:22: error: redeclaration
> of enumerator 'CblasRowMajor'
> | > > > > > 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102
> };
>
> | > > > > > | ^
> | > > > > > In file included from
Re: Advent calendar bug squashing issue (Was: Bug#936609: cblas / gsl hint needed (Was: Bug#936609: Ported ghmm to Python3 but issues with clapack))
On 5 December 2020 at 12:09, Andreas Tille wrote:
| this issue is something for our advent calendar. Anybody with cblas
| knowledge?
I am the GNU GSL maintainer, and I at one point also worked a lot with the
Atlas and other LAPACK/BLAS packages. I think Mo may be wrong here: I did the
same approach of "oh we can just skip GSL's cblas". I think that is
wrong. The way the C interface of the GNU GSL works appears to be require GSL
+ GSL CBLAS. That is what every package I know using GSL does -- even though
that "looks weird and redundant".
>From a quick look at http://ghmm.org it also looks like GLS is purely
optional and for RNGs only -- just like my RcppZiggurat (upstream) package
does which just relies on my RcppGSL (upstream) package which just export
`gsl-config --libs`, and has for years.
So I'd give the GSL defaults here a try.
(That said Mo knows a lot more than I do about BLAS, but I've watched a lot
of GSL build too over the decades I looked after that package.)
Dirk
| Kind regards
|
|Andreas.
|
| On Mon, Jan 27, 2020 at 10:55:25AM +0100, Andreas Tille wrote:
| > Hi again,
| >
| > with my last mail I wanted to express: H, to stupid to turn
| > this hint into real code. Any more detailed hint / patch would be
| > really welcome.
| >
| > Kind regards
| >
| > Andreas.
| >
| > On Mon, Jan 06, 2020 at 12:56:17PM +0100, Andreas Tille wrote:
| > > Hi Mo,
| > >
| > > On Sun, Jan 05, 2020 at 08:19:07AM +, Mo Zhou wrote:
| > > > GSL provides a set of CBLAS API/ABI, delivered with shared object
| > > > "libgslcblas.so" and header "gsl_cblas.h". That subset becomes
| > > > redundant once you include the headers of any standard/compatible
| > > > (C)BLAS library. That's what the compilation error means.
| > >
| > > Seems you want to tell me to not include gsl_cblas.h header. However,
| > > the code has no hit for
| > >
| > >grep -R gsl_cblas
| > >
| > > so the header is not included explicitly. So while your hint explains
| > > the error I need to admit I have no idea yet, how to fix it.
| > >
| > > > Make sure that the code only use one CBLAS implementation. In the
| > > > context of debian, I'd recommend you use the CBLAS ABI from libblas-dev,
| > > > and avoid linking against -lcblas. Link against -lblas instead.
| > >
| > > OK, once I'm at the linking step I might come back to this hint.
| > >
| > > Kind regards
| > >
| > > Andreas.
| > >
| > > > On Sun, Jan 05, 2020 at 07:55:05AM +0100, Andreas Tille wrote:
| > > > > Control: tags -1 help
| > > > >
| > > > > Hi,
| > > > >
| > > > > I was asking upstream about this issue[1] and an issue about gsl usage
| > > > > is suspected. Any hint how this can be fixed?
| > > > >
| > > > > > Finally I have a question about building with lapack. I get:
| > > > > >
| > > > > > ...
| > > > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Wdate-time
-D_FORTIFY_SOURCE=2 -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -g -O2
"-fdebug-prefix-map=/build/ghmm-0.9~rc3=." -fstack-protector-strong -
Wformat -Werror=format-security -I/usr/include -I/usr/include/x86_64-linux-gnu
-I/usr/include/libxml2 -c rng.c -fPIC -DPIC -o .libs/rng.o
| > > > > > In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
| > > > > > from matrixop.c:48:
| > > > > > /usr/include/x86_64-linux-gnu/cblas.h:5:9: error: nested
redefinition of 'enum CBLAS_ORDER'
| > > > > > 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102 };
| > > > > > | ^~~
| > > > > > /usr/include/x86_64-linux-gnu/cblas.h:5:9: error: redeclaration of
'enum CBLAS_ORDER'
| > > > > > In file included from /usr/include/gsl/gsl_blas_types.h:28,
| > > > > > from /usr/include/gsl/gsl_blas.h:29,
| > > > > > from /usr/include/gsl/gsl_linalg.h:30,
| > > > > > from matrixop.c:44:
| > > > > > /usr/include/gsl/gsl_cblas.h:46:6: note: originally defined here
| > > > > >46 | enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102};
| > > > > > | ^~~
| > > > > > In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
| > > > > > from matrixop.c:48:
| > > > > > /usr/include/x86_64-linux-gnu/cblas.h:5:22: error: redeclaration of
enumerator 'CblasRowMajor'
| > > > > > 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102 };
| > > > > > | ^
| > > > > > In file included from /usr/include/gsl/gsl_blas_types.h:28,
| > > > > > from /usr/include/gsl/gsl_blas.h:29,
| > > > > > from /usr/include/gsl/gsl_linalg.h:30,
| > > > > > from matrixop.c:44:
| > > > > > /usr/include/gsl/gsl_cblas.h:46:19: note: previous definition of
'CblasRowMajor' was here
| > > > > >46 | enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102};
| > > > > > | ^
| > > > > > In file included from
Advent calendar bug squashing issue (Was: Bug#936609: cblas / gsl hint needed (Was: Bug#936609: Ported ghmm to Python3 but issues with clapack))
Hi folks,
this issue is something for our advent calendar. Anybody with cblas
knowledge?
Kind regards
Andreas.
On Mon, Jan 27, 2020 at 10:55:25AM +0100, Andreas Tille wrote:
> Hi again,
>
> with my last mail I wanted to express: H, to stupid to turn
> this hint into real code. Any more detailed hint / patch would be
> really welcome.
>
> Kind regards
>
> Andreas.
>
> On Mon, Jan 06, 2020 at 12:56:17PM +0100, Andreas Tille wrote:
> > Hi Mo,
> >
> > On Sun, Jan 05, 2020 at 08:19:07AM +, Mo Zhou wrote:
> > > GSL provides a set of CBLAS API/ABI, delivered with shared object
> > > "libgslcblas.so" and header "gsl_cblas.h". That subset becomes
> > > redundant once you include the headers of any standard/compatible
> > > (C)BLAS library. That's what the compilation error means.
> >
> > Seems you want to tell me to not include gsl_cblas.h header. However,
> > the code has no hit for
> >
> >grep -R gsl_cblas
> >
> > so the header is not included explicitly. So while your hint explains
> > the error I need to admit I have no idea yet, how to fix it.
> >
> > > Make sure that the code only use one CBLAS implementation. In the
> > > context of debian, I'd recommend you use the CBLAS ABI from libblas-dev,
> > > and avoid linking against -lcblas. Link against -lblas instead.
> >
> > OK, once I'm at the linking step I might come back to this hint.
> >
> > Kind regards
> >
> > Andreas.
> >
> > > On Sun, Jan 05, 2020 at 07:55:05AM +0100, Andreas Tille wrote:
> > > > Control: tags -1 help
> > > >
> > > > Hi,
> > > >
> > > > I was asking upstream about this issue[1] and an issue about gsl usage
> > > > is suspected. Any hint how this can be fixed?
> > > >
> > > > > Finally I have a question about building with lapack. I get:
> > > > >
> > > > > ...
> > > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Wdate-time
> > > > > -D_FORTIFY_SOURCE=2 -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -g -O2
> > > > > "-fdebug-prefix-map=/build/ghmm-0.9~rc3=." -fstack-protector-strong -
> > > > > Wformat -Werror=format-security -I/usr/include
> > > > > -I/usr/include/x86_64-linux-gnu -I/usr/include/libxml2 -c rng.c
> > > > > -fPIC -DPIC -o .libs/rng.o
> > > > > In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
> > > > > from matrixop.c:48:
> > > > > /usr/include/x86_64-linux-gnu/cblas.h:5:9: error: nested redefinition
> > > > > of 'enum CBLAS_ORDER'
> > > > > 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102 };
> > > > > | ^~~
> > > > > /usr/include/x86_64-linux-gnu/cblas.h:5:9: error: redeclaration of
> > > > > 'enum CBLAS_ORDER'
> > > > > In file included from /usr/include/gsl/gsl_blas_types.h:28,
> > > > > from /usr/include/gsl/gsl_blas.h:29,
> > > > > from /usr/include/gsl/gsl_linalg.h:30,
> > > > > from matrixop.c:44:
> > > > > /usr/include/gsl/gsl_cblas.h:46:6: note: originally defined here
> > > > >46 | enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102};
> > > > > | ^~~
> > > > > In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
> > > > > from matrixop.c:48:
> > > > > /usr/include/x86_64-linux-gnu/cblas.h:5:22: error: redeclaration of
> > > > > enumerator 'CblasRowMajor'
> > > > > 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102 };
> > > > > | ^
> > > > > In file included from /usr/include/gsl/gsl_blas_types.h:28,
> > > > > from /usr/include/gsl/gsl_blas.h:29,
> > > > > from /usr/include/gsl/gsl_linalg.h:30,
> > > > > from matrixop.c:44:
> > > > > /usr/include/gsl/gsl_cblas.h:46:19: note: previous definition of
> > > > > 'CblasRowMajor' was here
> > > > >46 | enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102};
> > > > > | ^
> > > > > In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
> > > > > from matrixop.c:48:
> > > > > /usr/include/x86_64-linux-gnu/cblas.h:5:41: error: redeclaration of
> > > > > enumerator 'CblasColMajor'
> > > > > 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102 };
> > > > > | ^
> > > > >
> > > > >
> > > >
> > > > Kind regards
> > > >
> > > > Andreas.
> > > >
> > > >
> > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936609#19
> > > >
> > > > --
> > > > http://fam-tille.de
> > > >
> > >
> >
> > --
> > http://fam-tille.de
> >
> >
>
> --
> http://fam-tille.de
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
--
http://fam-tille.de
HELP needed for uploading a new debianisation of the Rheolef package
Hi Andreas, I just commit with git a new release 7.1-2 of the debianisation of the rheolef package: it fixes a FTBFS bug #971933 (see d/changelog). The upstream version is unchanged (7.1). Could you please upload it in debian ? Many thanks for your help. Best regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
