Re: Trilinos packages
On Thu, Mar 27, 2014 at 10:58:02PM +0100, Nico Schlömer wrote: As for the prefixing of the libraries with trilinos_, I'd rather refrain from it for the moment. The arguments I can see for this i see. perhaps it would be helpful to dig out the the referenced 'discussion with the ftpmaster' for the exact reasoning. anyway the debian-policy [1] just states that If you have several shared libraries built from the same source tree, you may lump them all together into a single shared library package provided that all of their SONAMEs will always change together. Be aware that this is not normally the case, and if the SONAMEs do not change together, upgrading such a merged shared library package will be unnecessarily difficult because of file conflicts with the old version of the package. When in doubt, always split shared library packages so that each binary package installs a single shared library. . * The Debian package for Trilinos is meant for a researcher to get an application to compile and run with Trilinos to then deploy it on an HPC. If Debian follows a non-default library naming scheme, the user would have to maintain two separate build files for Debian and the cluster (which will typically host a customized Trilinos installation). * The new Trilinos package includes many more subpackages than the old one did. Maintaining a Debian patch that changes all library names is possible, but would be a substantial effort. * The old README brings up that prefixing avoids conflicts. While it it remains possible that another library by the same name appears in Debian, that has not been the case as long as Trilinos in Debian existed and isn't the case now. * The old README brings up that it would be easier to identify trilinos libraries. While that is true, a user of Trilinos typically has a very good idea of what libraries he or she plans to use. i tend to agree. but lets have a look at the proposed split library packages variant... the control file will will blow up, but only once. the next hurdle will be installing the files into the right packages. it should be rather possible to do this half-way automatically... i'm starting to like the idea of splitting up the package. it will cause a lot of packages, but no extra headaches. That said, I do see the benefit of prefixing the libraries with trilinos_. I would suggest that I file a bug report upstream, talk to some of the developers, and see if we can incorporate that change in Trilinos itself. We would probably have to wait for a major release, but I think this coming fall they are bumping the major release number. from the perspective of a trilinos developer, all library packages are packages on their own, and the naming scheme looks fine to me. just because we (may) want to lump them together into one binary package doesnt justify a change, imo. ideally those patches should be included in your package at alioth (whether or not they have been accepted upstream). Really? Why? i was assuming that the patches make sense. some of them apparently are build system related. so why not? hth, regards felix -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
yes. the old trilinos debian source package had a libname.patch and a soname.patch, these fix the names for a monolithic package. i suggest to import these (or just rebase your work on top of that). I already incorporated a fix for proper so-naming upstream a while ago, so that should be fixed. As for the prefixing of the libraries with trilinos_, I'd rather refrain from it for the moment. The arguments I can see for this * The Debian package for Trilinos is meant for a researcher to get an application to compile and run with Trilinos to then deploy it on an HPC. If Debian follows a non-default library naming scheme, the user would have to maintain two separate build files for Debian and the cluster (which will typically host a customized Trilinos installation). * The new Trilinos package includes many more subpackages than the old one did. Maintaining a Debian patch that changes all library names is possible, but would be a substantial effort. * The old README brings up that prefixing avoids conflicts. While it it remains possible that another library by the same name appears in Debian, that has not been the case as long as Trilinos in Debian existed and isn't the case now. * The old README brings up that it would be easier to identify trilinos libraries. While that is true, a user of Trilinos typically has a very good idea of what libraries he or she plans to use. That said, I do see the benefit of prefixing the libraries with trilinos_. I would suggest that I file a bug report upstream, talk to some of the developers, and see if we can incorporate that change in Trilinos itself. We would probably have to wait for a major release, but I think this coming fall they are bumping the major release number. ideally those patches should be included in your package at alioth (whether or not they have been accepted upstream). Really? Why? is there a specific reason to maintain a second and different repository for ubuntu? Not particularly. I just have Trilinos built on a nightly basis on launchpad to make sure upcoming changes won't bite us; it also serves me well as a test bed for changes in debian/. Cheers, Nico On Wed, Mar 26, 2014 at 5:03 PM, Felix Salfelder fe...@salfelder.org wrote: On Wed, Mar 26, 2014 at 10:22:23AM +0100, Nico Schlömer wrote: I would suggest to first go with a monolithic package and split it up at a later point. yes. the old trilinos debian source package had a libname.patch and a soname.patch, these fix the names for a monolithic package. i suggest to import these (or just rebase your work on top of that). also, theres a note on renaming in README.Debian. and a changelog that would be nice to have. README.Debian [..] Debian Trilinos libraries renaming == Following a discussion with ftpmaster, the Trilinos libraries have been renamed to be less generic. They all use the same prefix now : libtrilinos_ . That should also help tremendously with - avoiding conflicts with other libraries/packages - identifying available trilinos libraries [..] In the course of packaging Trilinos for Debian, I have identified quite a number of bugs in Trilinos for which I maintain a little zoo of patches, https://github.com/nschloe/trilinos-ubuntu/tree/master/patches. Some of those have already made it upstream, and we'll have to see if we can get in more of those before the next release freeze. ideally those patches should be included in your package at alioth (whether or not they have been accepted upstream). is there a specific reason to maintain a second and different repository for ubuntu? regards felix -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
i suspect that the clean way would be (binary) packages for each library the trilinos source package contains. I fully agree. Trilinos is structurally similar to Boost which does provide a sophisticated install structure. Unfortunately, the Trilinos build system is flawed in certain places that make it difficult to take an automated approach to that. One example is that the interdependencies of the subpackages aren't presented in a machine-readable form. Although, I'm submitting patches to Trilinos to address these issues, I would suggest to first go with a monolithic package and split it up at a later point. In the course of packaging Trilinos for Debian, I have identified quite a number of bugs in Trilinos for which I maintain a little zoo of patches, https://github.com/nschloe/trilinos-ubuntu/tree/master/patches. Some of those have already made it upstream, and we'll have to see if we can get in more of those before the next release freeze. I'll keep you all posted. Cheers, Nico On Tue, Mar 18, 2014 at 12:56 PM, Felix Salfelder fe...@salfelder.org wrote: On Tue, Mar 18, 2014 at 12:15:49PM +0100, Nico Schlömer wrote: A quick poll on the Trilinos package naming: Right now, we have libtrilinos, which triggers a package-name-doesnt-match-sonames warning since none of the Trilinos libraries is called libtrilinos.* (rather libepetra.*, libbelos.*, ...). This is similar to the libboost package which doesn't contain a library by the name libboost.* either. i suspect that the clean way would be (binary) packages for each library the trilinos source package contains. and maybe have a trilinos-dev metapackage that depends on all the lib*-dev packages. this will add up to some copy and paste work, and end up with a lot of packages... i don't know if it's worth the effort. fwiw, theres another source package that creates a heap of libraries. it is the old trilinos package [1]. here, all sonames are prefixed by libtrilinos_. looks like an alternative... On the other hand, a software very similar to Trilinos, PETSc, goes by the Debian name petsc. i cannot find a (binary) package called petsc. but there is (e.g.) libpetsc3.4.2, and it contains libpetsc.so.4.3.2. unkike trilinos, the petsc source package creates just one shared library. and afaics its soname matches the package name. hth felix [1] https://packages.debian.org/squeeze/amd64/libtrilinos/filelist -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
On Wed, Mar 26, 2014 at 10:22:23AM +0100, Nico Schlömer wrote: I would suggest to first go with a monolithic package and split it up at a later point. yes. the old trilinos debian source package had a libname.patch and a soname.patch, these fix the names for a monolithic package. i suggest to import these (or just rebase your work on top of that). also, theres a note on renaming in README.Debian. and a changelog that would be nice to have. README.Debian [..] Debian Trilinos libraries renaming == Following a discussion with ftpmaster, the Trilinos libraries have been renamed to be less generic. They all use the same prefix now : libtrilinos_ . That should also help tremendously with - avoiding conflicts with other libraries/packages - identifying available trilinos libraries [..] In the course of packaging Trilinos for Debian, I have identified quite a number of bugs in Trilinos for which I maintain a little zoo of patches, https://github.com/nschloe/trilinos-ubuntu/tree/master/patches. Some of those have already made it upstream, and we'll have to see if we can get in more of those before the next release freeze. ideally those patches should be included in your package at alioth (whether or not they have been accepted upstream). is there a specific reason to maintain a second and different repository for ubuntu? regards felix -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
On Tue, Mar 18, 2014 at 12:15:49PM +0100, Nico Schlömer wrote: A quick poll on the Trilinos package naming: Right now, we have libtrilinos, which triggers a package-name-doesnt-match-sonames warning since none of the Trilinos libraries is called libtrilinos.* (rather libepetra.*, libbelos.*, ...). This is similar to the libboost package which doesn't contain a library by the name libboost.* either. i suspect that the clean way would be (binary) packages for each library the trilinos source package contains. and maybe have a trilinos-dev metapackage that depends on all the lib*-dev packages. this will add up to some copy and paste work, and end up with a lot of packages... i don't know if it's worth the effort. fwiw, theres another source package that creates a heap of libraries. it is the old trilinos package [1]. here, all sonames are prefixed by libtrilinos_. looks like an alternative... On the other hand, a software very similar to Trilinos, PETSc, goes by the Debian name petsc. i cannot find a (binary) package called petsc. but there is (e.g.) libpetsc3.4.2, and it contains libpetsc.so.4.3.2. unkike trilinos, the petsc source package creates just one shared library. and afaics its soname matches the package name. hth felix [1] https://packages.debian.org/squeeze/amd64/libtrilinos/filelist -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
Hi Nico, I have built locally your package. But if you run lintian over .changes file, it gives a lot of errors and warnings. Please, deal with them. Thanks Anton 2014-03-10 16:35 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: Did you repack it? Nope. For creating the printine-tar branch, I used the --git-pristine-tar option as described on https://wiki.debian.org/PackagingWithGit#pristine-tar. --Nico On Mon, Mar 10, 2014 at 4:30 PM, Anton Gladky gl...@debian.org wrote: 2014-03-10 16:25 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: It seems, the checksum of tarball on the website and in pristine-tar branch is not the same. So what to do about this? Did you repack it? Anton -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
Strange, libparmetis-dev should be in jessie, cf. https://packages.debian.org/jessie/libparmetis-dev. --Nico On Mon, Mar 10, 2014 at 10:22 AM, Felix Salfelder fe...@salfelder.org wrote: On Sat, Mar 08, 2014 at 12:39:57AM +0100, Nico Schlömer wrote: 1) Set VCS=fields 2) Standards-Version is 3.9.5 now 3) Use DEP-3 for patches (Description, Author, Last-Updates is enough) 4) Remove some unnecessary comments from debian/rules. It should be as short as possible. Leave only necessary notes. 5) Check 3rd-party files and add them to debian/copyright (if they are). Done and done; I pushed the changes to alioth. tried to build (dpkg-buildpackage -rfakeroot -b) on a machine close to testing. [..] dpkg-checkbuilddeps: Unmet build dependencies: libparmetis-dev [..] apt-get install libparmetis-dev says Package libparmetis-dev is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: libscotchparmetis-dev:i386 libscotchparmetis-dev:armel libscotchparmetis-dev E: Package 'libparmetis-dev' has no installation candidate installing libscotchparmetis-dev does not help. dpkg-buildpackage -rfakeroot -b -d yields [..] Could not find the ParMETIS headers include directory! Please manually set ParMETIS_INCLUDE_DIRS and/or ParMETIS_LIBRARY_DIRS or [..] i don't know what libscotchparmetis is, does it replaces libparmetis for trilinos? in that case it should be easy to fix... thanks felix -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
On Mon, Mar 10, 2014 at 10:52:19AM +0100, Nico Schlömer wrote: Strange, libparmetis-dev should be in jessie, cf. https://packages.debian.org/jessie/libparmetis-dev. indeed it is, and i missed that. curiously, parmetis is non-free, and that is why i missed it. from my understanding (to some extent?) trilinos is free, so it might make sense to not use/link\ against libparmetis. doesn't the build dependency render your package non-free? particularly, there is gplv3 licensed software around (xyce) that build depends on trilinos. i'm no license or dfsg expert, anyhow, this doesn't look very clean to me.. thanks felix -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
I see that ParMETIS is free for educational purposes only http://glaros.dtc.umn.edu/gkhome/metis/parmetis/download, so requiring it as a dependency makes Trilinos installable for edu-only as well. ParMETIS is optional to Trilinos so I might as well removed it without major repercussions. Are there general Debian guidelines for such situations? What's your opinion on this? --Nico On Mon, Mar 10, 2014 at 11:23 AM, Felix Salfelder fe...@salfelder.org wrote: On Mon, Mar 10, 2014 at 10:52:19AM +0100, Nico Schlömer wrote: Strange, libparmetis-dev should be in jessie, cf. https://packages.debian.org/jessie/libparmetis-dev. indeed it is, and i missed that. curiously, parmetis is non-free, and that is why i missed it. from my understanding (to some extent?) trilinos is free, so it might make sense to not use/link\ against libparmetis. doesn't the build dependency render your package non-free? particularly, there is gplv3 licensed software around (xyce) that build depends on trilinos. i'm no license or dfsg expert, anyhow, this doesn't look very clean to me.. thanks felix -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
I checked all other dependencies manually and found that libparmetis-dev was the only thing from non-free. I removed it from the list; please retry building. --Nico On Mon, Mar 10, 2014 at 12:27 PM, Nico Schlömer nico.schloe...@gmail.com wrote: my recommendation is to disable parmetis in trilinos and defer the problem until anybody actually requires it. Sure, why not. how many (license) problems are left without parmetis? Not sure. If you build without parmetis (remove the dependency from debian/control and debian/rules), does the builder still complain? --Nico On Mon, Mar 10, 2014 at 11:59 AM, Felix Salfelder fe...@salfelder.org wrote: On Mon, Mar 10, 2014 at 11:33:26AM +0100, Nico Schlömer wrote: Are there general Debian guidelines for such situations? i'm sorry i don't know or care. i'm not even sure in which way non-free is (not) a part of debian. What's your opinion on this? imo it's best to avoid trouble (here: non-free packages). my recommendation is to disable parmetis in trilinos and defer the problem until anybody actually requires it. if that is you, hopefully somebody else will step in and help. how many (license) problems are left without parmetis? regards felix -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
Hi Nico, is it possible to have working debian/watch? It seems, the checksum of tarball on the website and in pristine-tar branch is not the same. Anton 2014-03-10 13:51 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: I checked all other dependencies manually and found that libparmetis-dev was the only thing from non-free. I removed it from the list; please retry building. --Nico On Mon, Mar 10, 2014 at 12:27 PM, Nico Schlömer nico.schloe...@gmail.com wrote: my recommendation is to disable parmetis in trilinos and defer the problem until anybody actually requires it. Sure, why not. how many (license) problems are left without parmetis? Not sure. If you build without parmetis (remove the dependency from debian/control and debian/rules), does the builder still complain? --Nico On Mon, Mar 10, 2014 at 11:59 AM, Felix Salfelder fe...@salfelder.org wrote: On Mon, Mar 10, 2014 at 11:33:26AM +0100, Nico Schlömer wrote: Are there general Debian guidelines for such situations? i'm sorry i don't know or care. i'm not even sure in which way non-free is (not) a part of debian. What's your opinion on this? imo it's best to avoid trouble (here: non-free packages). my recommendation is to disable parmetis in trilinos and defer the problem until anybody actually requires it. if that is you, hopefully somebody else will step in and help. how many (license) problems are left without parmetis? regards felix -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
On Mon, Mar 10, 2014 at 01:51:24PM +0100, Nico Schlömer wrote: I checked all other dependencies manually and found that libparmetis-dev was the only thing from non-free. I removed it from the list; please retry building. the build succeeded without the ENABLE_ParMETIS switch (takes forever..). there's something wrong with dh_python. this is possibly a problem on my side, but i don't have time to investigate right now. [..] dh binary --with python2 dh_python2 W: dh_python2:437: public extension linked with libpython2.7: _Amesos.so W: dh_python2:437: public extension linked with libpython2.7: _Anasazi.so W: dh_python2:437: public extension linked with libpython2.7: _AztecOO.so W: dh_python2:437: public extension linked with libpython2.7: _Epetra.so W: dh_python2:437: public extension linked with libpython2.7: _EpetraExt.so W: dh_python2:437: public extension linked with libpython2.7: _Galeri.so W: dh_python2:437: public extension linked with libpython2.7: _IFPACK.so W: dh_python2:437: public extension linked with libpython2.7: _Komplex.so W: dh_python2:437: public extension linked with libpython2.7: _ML.so W: dh_python2:437: public extension linked with libpython2.7: _Pliris.so W: dh_python2:437: public extension linked with libpython2.7: _Teuchos.so W: dh_python2:437: public extension linked with libpython2.7: _TriUtils.so W: dh_python2:437: public extension linked with libpython2.7: _Abstract.so W: dh_python2:437: public extension linked with libpython2.7: _Solver.so W: dh_python2:437: public extension linked with libpython2.7: _StatusTest.so W: dh_python2:437: public extension linked with libpython2.7: ___init__.so W: dh_python2:437: public extension linked with libpython2.7: _Interface.so W: dh_python2:437: public extension linked with libpython2.7: ___init__.so W: dh_python2:437: public extension linked with libpython2.7: _NestedEpetra.so W: dh_python2:437: public extension linked with libpython2.7: ___init__.so E: dh_python2:145: extension for python2.6 is missing. Build extensions for all supported Python versions (`pyversions -vr`) or adjust X-Python-Version field or pass --no-guessing-versions to dh_python2 thanks felix -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
Hi Nico, is it possible to have working debian/watch? Not right now. Sandia currently doesn't do public ftp reads. They are in the process of switching to their new site trilinos.org right now, and I already requested a public ftp list to be added alongside. Once this is done, I'll adapt debian/watch. It seems, the checksum of tarball on the website and in pristine-tar branch is not the same. So what to do about this? --Nico On Mon, Mar 10, 2014 at 2:20 PM, Anton Gladky gl...@debian.org wrote: Hi Nico, is it possible to have working debian/watch? It seems, the checksum of tarball on the website and in pristine-tar branch is not the same. Anton 2014-03-10 13:51 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: I checked all other dependencies manually and found that libparmetis-dev was the only thing from non-free. I removed it from the list; please retry building. --Nico On Mon, Mar 10, 2014 at 12:27 PM, Nico Schlömer nico.schloe...@gmail.com wrote: my recommendation is to disable parmetis in trilinos and defer the problem until anybody actually requires it. Sure, why not. how many (license) problems are left without parmetis? Not sure. If you build without parmetis (remove the dependency from debian/control and debian/rules), does the builder still complain? --Nico On Mon, Mar 10, 2014 at 11:59 AM, Felix Salfelder fe...@salfelder.org wrote: On Mon, Mar 10, 2014 at 11:33:26AM +0100, Nico Schlömer wrote: Are there general Debian guidelines for such situations? i'm sorry i don't know or care. i'm not even sure in which way non-free is (not) a part of debian. What's your opinion on this? imo it's best to avoid trouble (here: non-free packages). my recommendation is to disable parmetis in trilinos and defer the problem until anybody actually requires it. if that is you, hopefully somebody else will step in and help. how many (license) problems are left without parmetis? regards felix -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
E: dh_python2:145: extension for python2.6 is missing. Build extensions for all supported Python versions (`pyversions -vr`) or adjust X-Python-Version field or pass --no-guessing-versions to dh_python2 I added override_dh_python2: dh_python2 --no-guessing-versions to debian/rules. This should fix your error, please retry. --Nico On Mon, Mar 10, 2014 at 3:02 PM, Felix Salfelder fe...@salfelder.org wrote: On Mon, Mar 10, 2014 at 01:51:24PM +0100, Nico Schlömer wrote: I checked all other dependencies manually and found that libparmetis-dev was the only thing from non-free. I removed it from the list; please retry building. the build succeeded without the ENABLE_ParMETIS switch (takes forever..). there's something wrong with dh_python. this is possibly a problem on my side, but i don't have time to investigate right now. [..] dh binary --with python2 dh_python2 W: dh_python2:437: public extension linked with libpython2.7: _Amesos.so W: dh_python2:437: public extension linked with libpython2.7: _Anasazi.so W: dh_python2:437: public extension linked with libpython2.7: _AztecOO.so W: dh_python2:437: public extension linked with libpython2.7: _Epetra.so W: dh_python2:437: public extension linked with libpython2.7: _EpetraExt.so W: dh_python2:437: public extension linked with libpython2.7: _Galeri.so W: dh_python2:437: public extension linked with libpython2.7: _IFPACK.so W: dh_python2:437: public extension linked with libpython2.7: _Komplex.so W: dh_python2:437: public extension linked with libpython2.7: _ML.so W: dh_python2:437: public extension linked with libpython2.7: _Pliris.so W: dh_python2:437: public extension linked with libpython2.7: _Teuchos.so W: dh_python2:437: public extension linked with libpython2.7: _TriUtils.so W: dh_python2:437: public extension linked with libpython2.7: _Abstract.so W: dh_python2:437: public extension linked with libpython2.7: _Solver.so W: dh_python2:437: public extension linked with libpython2.7: _StatusTest.so W: dh_python2:437: public extension linked with libpython2.7: ___init__.so W: dh_python2:437: public extension linked with libpython2.7: _Interface.so W: dh_python2:437: public extension linked with libpython2.7: ___init__.so W: dh_python2:437: public extension linked with libpython2.7: _NestedEpetra.so W: dh_python2:437: public extension linked with libpython2.7: ___init__.so E: dh_python2:145: extension for python2.6 is missing. Build extensions for all supported Python versions (`pyversions -vr`) or adjust X-Python-Version field or pass --no-guessing-versions to dh_python2 thanks felix -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
Did you repack it? Nope. For creating the printine-tar branch, I used the --git-pristine-tar option as described on https://wiki.debian.org/PackagingWithGit#pristine-tar. --Nico On Mon, Mar 10, 2014 at 4:30 PM, Anton Gladky gl...@debian.org wrote: 2014-03-10 16:25 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: It seems, the checksum of tarball on the website and in pristine-tar branch is not the same. So what to do about this? Did you repack it? Anton -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
On Fri, 2014-03-07 at 11:21 +0100, Nico Schlömer wrote: Hi all, I've noticed that Trilinos for Debian is dead now for a while http://packages.qa.debian.org/t/trilinos.html, and I'd like to help reviving it. I already have stable https://launchpad.net/~nschloe/+archive/trilinos/+packages and nightly https://launchpad.net/~nschloe/+archive/trilinos-nightly/+packages builds for Ubuntu going which I actively maintain, so I guess it wouldn't be too much of a leap. I'm not too familiar with the Debian community and infrastructure though, so I'll need some assistance. I'm also trying to rebuild trilinos based on your changes in debian/rules. As mentionned in an earlier email latest trilinos FTBS with gcc 4.8 (sacado module is broken). What I suggest is to share our work using the vcs on Debian Science svn. If you are more confortable with git we may move to Debian Science git repository. Best C. Cheers, Nico -- Christophe TROPHIME Research Engineer LNCMI CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE CNRS Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
As mentionned in an earlier email latest trilinos FTBS with gcc 4.8 (sacado module is broken). I've got all my work at https://github.com/nschloe/trilinos-ubuntu. In the debian.trusty/rules, you'll find comments about the Sacado issue with a link to the bug report on Trilinos. If you are more confortable with git we may move to Debian Science git repository. Git would be great. --Nico On Fri, Mar 7, 2014 at 11:36 AM, trophime christophe.troph...@lncmi.cnrs.fr wrote: On Fri, 2014-03-07 at 11:21 +0100, Nico Schlömer wrote: Hi all, I've noticed that Trilinos for Debian is dead now for a while http://packages.qa.debian.org/t/trilinos.html, and I'd like to help reviving it. I already have stable https://launchpad.net/~nschloe/+archive/trilinos/+packages and nightly https://launchpad.net/~nschloe/+archive/trilinos-nightly/+packages builds for Ubuntu going which I actively maintain, so I guess it wouldn't be too much of a leap. I'm not too familiar with the Debian community and infrastructure though, so I'll need some assistance. I'm also trying to rebuild trilinos based on your changes in debian/rules. As mentionned in an earlier email latest trilinos FTBS with gcc 4.8 (sacado module is broken). What I suggest is to share our work using the vcs on Debian Science svn. If you are more confortable with git we may move to Debian Science git repository. Best C. Cheers, Nico -- Christophe TROPHIME Research Engineer LNCMI CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE CNRS Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
Hi Anton, thanks for the links. I've now signed up and go through the package instructions. Small hints/questions about http://debian-science.alioth.debian.org/debian-science-policy.html: * The policy advises to use DM-Upload-Allowed, http://lintian.debian.org/tags/dm-upload-allowed-is-obsolete.html advises against. Which is the current policy? * The copyright format hint should point to http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ instead of the draft. * The Git link could be updated to http://git-scm.com/. I've otherwise adapted the package accordingly and I'm now waiting for debian-science membership approval I guess. Cheers, Nico On Fri, Mar 7, 2014 at 11:42 AM, Anton Gladky gl...@debian.org wrote: Hi Nico, we discussed it a year ago [1] and we keep our promise. Please, follow the procedure according Deb-Sci policy [2], create repo and ping me. [1] http://lists.alioth.debian.org/pipermail/debian-science-maintainers/2013-April/017553.html [2] http://debian-science.alioth.debian.org/debian-science-policy.html Regards Anton 2014-03-07 11:21 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: Hi all, I've noticed that Trilinos for Debian is dead now for a while http://packages.qa.debian.org/t/trilinos.html, and I'd like to help reviving it. I already have stable https://launchpad.net/~nschloe/+archive/trilinos/+packages and nightly https://launchpad.net/~nschloe/+archive/trilinos-nightly/+packages builds for Ubuntu going which I actively maintain, so I guess it wouldn't be too much of a leap. I'm not too familiar with the Debian community and infrastructure though, so I'll need some assistance. Cheers, Nico -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
Hi Nico, we need to update our Policy. Please, follow new rules. Anton -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
Did you push pristine-tar and upstream branches? Anton 2014-03-07 17:28 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: Alright. I've now pushed the contents of the ./debian/ folder to alioth:/git/debian-science/packages//trilinos.git from where it can be reviewed. Will someone open a bug about the new package? Do I need to file na official ITP? Cheers, Nico On Fri, Mar 7, 2014 at 2:48 PM, Anton Gladky gl...@debian.org wrote: Hi Nico, we need to update our Policy. Please, follow new rules. Anton -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Trilinos packages
1) Set VCS=fields 2) Standards-Version is 3.9.5 now 3) Use DEP-3 for patches (Description, Author, Last-Updates is enough) 4) Remove some unnecessary comments from debian/rules. It should be as short as possible. Leave only necessary notes. 5) Check 3rd-party files and add them to debian/copyright (if they are). Done and done; I pushed the changes to alioth. --Nico On Fri, Mar 7, 2014 at 10:38 PM, Anton Gladky gl...@debian.org wrote: Please, do the following: 1) Set VCS=fields 2) Standards-Version is 3.9.5 now 3) Use DEP-3 for patches (Description, Author, Last-Updates is enough) 4) Remove some unnecessary comments from debian/rules. It should be as short as possible. Leave only necessary notes. 5) Check 3rd-party files and add them to debian/copyright (if they are). But the package looks fine! Though I did not build it yet. Please, check your .changes file with lintian. I will upload it shortly. Anton 2014-03-07 22:20 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: I hadn't, but I now found https://wiki.debian.org/PackagingWithGit which I now followed. upstream and pristine-tar are now in place. --Nico On Fri, Mar 7, 2014 at 6:40 PM, Anton Gladky gl...@debian.org wrote: Did you push pristine-tar and upstream branches? Anton 2014-03-07 17:28 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: Alright. I've now pushed the contents of the ./debian/ folder to alioth:/git/debian-science/packages//trilinos.git from where it can be reviewed. Will someone open a bug about the new package? Do I need to file na official ITP? Cheers, Nico On Fri, Mar 7, 2014 at 2:48 PM, Anton Gladky gl...@debian.org wrote: Hi Nico, we need to update our Policy. Please, follow new rules. Anton -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
