Re: adding a new file using (d)quilt
On Thu, 2012-04-12 at 13:06 +0200, Thibaut Paumard wrote: Le 12/04/12 12:50, Gerber van der Graaf a écrit : Hi, for packaging freefoam-user-doc I intend to include the static file UsersGuide.pdf.gz as asymptote is currently broken. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668286) Also, generating the manual pages for the freefoam package does not work for the moment as a2x from asccidoc does currently not work properly. The idea is to include these files statically (for the moment until mentioned packages have been repaired) using (d)quilt. Hi, It's not OK to include a binary file which can't be built automatically. That's called fails to build from source in a sane way. That said, you can't use a diff file to include a binary file. That's why we now use debian.tar.gz rather than .diff.gz. The right solution is to list your file in debian/source/include-binaries, see man dpkg-source. Doesn't this make it a non-free package? I think the right solution is to strip the un-buildable binary out of the upstream source and re-make the .orig.tar.gz with .dfsg in the version. And ask upstream to put the source in the next version. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
On Wed, 2012-02-29 at 11:42 +0100, Julien Cristau wrote: On Mon, Feb 13, 2012 at 15:05:00 -0500, Adam C Powell IV wrote: Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. mumps and hdf5 have now transitioned. For petsc/slepc, they either need to build again on armel and kfreebsd-*, or the out of date binaries on those architectures need to be removed, by filing a bug against the ftp.debian.org pseudo-package. The bug against ftp.debian.org has been filed and closed (661936), but petsc and slepc and their reverse-depends have not transitioned. What more needs to happen? I see a transition page for slepc at http://release.debian.org/transitions/html/slepc.html , does feel++ need to build for any of these other packages to go in? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
On Mon, 2012-03-05 at 22:40 +0100, Julien Cristau wrote: On Mon, Mar 5, 2012 at 16:28:25 -0500, Adam C Powell IV wrote: On Wed, 2012-02-29 at 11:42 +0100, Julien Cristau wrote: On Mon, Feb 13, 2012 at 15:05:00 -0500, Adam C Powell IV wrote: Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. mumps and hdf5 have now transitioned. For petsc/slepc, they either need to build again on armel and kfreebsd-*, or the out of date binaries on those architectures need to be removed, by filing a bug against the ftp.debian.org pseudo-package. The bug against ftp.debian.org has been filed and closed (661936), but petsc and slepc and their reverse-depends have not transitioned. What more needs to happen? I see a transition page for slepc at http://release.debian.org/transitions/html/slepc.html , does feel++ need to build for any of these other packages to go in? The bug you reference seems to be about petsc. slepc has the same issue. Oh dear. Do we need to do this for every reverse-depends package in order for the whole thing to transition? PETSc is the one with the build trouble on these architectures... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
On Mon, 2012-02-27 at 11:15 +0100, Julien Cristau wrote: On Sat, Feb 25, 2012 at 23:51:12 -0500, Adam C Powell IV wrote: That said, the HDF5 transition seems a bit premature. There are some fundamental changes which have broken a couple of its reverse-depends, which is one reason so many packages needed to be removed from testing in order to transition it. I'm sorry but I wasn't going to hold testing hostage of hdf5 for much longer than a month... This is a new regression that happened since January 21 and broke at least med-fichier, with several rdeps of its own. But I understand, it had to go in at some point. In particular, it's impossible to install hdf5-tools and libhdf5-*mpi-dev at the same time, as is required to build a handful of reverse-depends [3]. There's no reason the MPI and non-MPI shared libs should conflict. Well there's no way they can be installed together as long as they ship the same files, this is not a new issue AFAICT... Of course. I'll post a patch hopefully sometime today which resolves the conflict. [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586149 And this bug is almost 2 years old, I don't see that it has anything to do with the recent changes? Because it's the same issue: inability to install multiple versions of the HDF5 libraries simultaneously. Then again, the new issue, the regression, is that hdf5-tools and libhdf5-mpi-dev can't be installed simultaneously, so perhaps this is a different issue. But resolving the shared library conflict fixes this new problem. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
Hello Anton, On Sat, 2012-02-25 at 15:41 +0100, Cyril Brulebois wrote: Hi, Anton Gladky gladky.an...@gmail.com (25/02/2012): is there a chance to get petsc in testing in a near future? gmsh was removed from wheezy because of petsc. as explained by Julien in [1], we had to remove it to let hdf5 go forward. If you need any help to get petsc back into testing, please let us (debian-release) know. 1. http://lists.debian.org/debian-qa-packages/2012/02/msg00221.html I think the first step is to complete the mumps transition [1] for which coinor-ipopt seems to be the main obstacle, with an RC bug [2]. [1] http://release.debian.org/transitions/html/mumps.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659898 When MUMPS goes in, then petsc and slepc go right in, along with elmerfem, and a couple of others. That said, the HDF5 transition seems a bit premature. There are some fundamental changes which have broken a couple of its reverse-depends, which is one reason so many packages needed to be removed from testing in order to transition it. In particular, it's impossible to install hdf5-tools and libhdf5-*mpi-dev at the same time, as is required to build a handful of reverse-depends [3]. There's no reason the MPI and non-MPI shared libs should conflict. [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586149 Sorry I've been MIA for the past week, busy week at work. I'll try to get together patches for 586149 and 659898 so these things can move forward. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
On Tue, 2012-02-14 at 12:15 +0100, Cyril Brulebois wrote: Adam C Powell IV hazel...@debian.org (13/02/2012): Writing in with an update: Thanks. Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. Not quite: http://release.debian.org/transitions/html/hdf5.html http://release.debian.org/transitions/html/mumps.html Thanks, these are a lot more helpful than the Excuses pages! But I don't understand the mumps transition page -- does this mean that coinor-ipopt and freefem++ need binNMUs? Hmm, trying to build coinor-ipopt, the ipopt library builds fine, but the build fails during the doxygen step, which is called even with dpkg-buildpackage -B (just filed bug 659898 on this). I didn't follow very closely, but there was a new hdf5 upload this morning, which should fix a few bugs: http://packages.qa.debian.org/h/hdf5/news/20120214T104759Z.html Okay, thanks! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
Writing in with an update: On Thu, 2012-01-26 at 14:59 +0100, Cyril Brulebois wrote: Adam C Powell IV hazel...@debian.org (26/01/2012): On Tue, 2012-01-24 at 00:51 +0100, Cyril Brulebois wrote: That means one “OK-able” package, one “oops-broken-for-a-long-while” package, and several “unknown-status” packages. To keep everyone as testing candidates until this transition is ready, maybe re-uploading petsc 3.1 would do the trick? (Either with an epoch or with the 3.2-is-really-3.1-like dirty version.) This way, all packages can stay in testing and be updated through unstable w/o having to be entangled? I think we're closer than that, we've been active for the past couple of weeks to make this happen. The only unknown at this point is feel++. Stuff to do looks like: * Upload a new petsc to fix some bugs (me, probably today) * Upload a new slepc with a tiny patch to add a header file (me, probably today) * Upload mpich2 from alioth to fix an RC bug (me, today or tomorrow) * Update to deal.II 7.1.0 (me, within a week) * Patch gmsh to work with petsc/slepc 3.2 (Christophe Trophime with my help, probably within a week) * Update DOLFIN (Johannes Ring, within a week) * Test/update feel++ (?? If nobody else I'll take a stab at it) Only in unstable anyway, so it can migrate later AFAICT. * Remove illuminator from testing (release team) dak rm seems happy with it, so it can be hinted out when the rest is ready. * Close the RC bug against mpi-defaults (which is pointless anyway because it transitioned just before I filed it, I'll do this today) It looks like there's a clear path to success, and this can all happen within a week or two, then we can transition a bunch of stuff at once including HDF5. Otherwise we're stuck trying to do two transitions which will take at least 4 weeks... This looks much better than my previous summary. :) And thanks for the details. Of these packages (and some of their dependencies), hypre transitioned this past weekend. Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. Following later: elmerfem, deal.ii, feel++, dolfin, none of which is in testing now anyway, all are currently broken in some way. A new gmsh was just uploaded, not sure how it will affect things... Needs removal from testing: illuminator I think we're near the finish line... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
On Tue, 2012-01-24 at 00:51 +0100, Cyril Brulebois wrote: Adam C Powell IV hazel...@debian.org (23/01/2012): deal.II detects the PETSc version and acts accordingly, I believe 7.1.0 will work through 3.2. I need to work on upgrading from 7.0.0 to 7.1.0. […] Illuminator has major problems -- the PETSc object on which all of illuminator is based has changed drastically. This will require major upstream surgery, and the new version will not be data-compatible with the old. Since upstream is me, I can tell you I will not have time for the foreseeable future (couple of months at least) to port illuminator to PETSc 3.2. It will need to come out of testing when PETSc transitions. :-( […] Can't speak for the others (dolfin, feel++, gmsh). That means one “OK-able” package, one “oops-broken-for-a-long-while” package, and several “unknown-status” packages. To keep everyone as testing candidates until this transition is ready, maybe re-uploading petsc 3.1 would do the trick? (Either with an epoch or with the 3.2-is-really-3.1-like dirty version.) This way, all packages can stay in testing and be updated through unstable w/o having to be entangled? I think we're closer than that, we've been active for the past couple of weeks to make this happen. The only unknown at this point is feel++. Stuff to do looks like: * Upload a new petsc to fix some bugs (me, probably today) * Upload a new slepc with a tiny patch to add a header file (me, probably today) * Upload mpich2 from alioth to fix an RC bug (me, today or tomorrow) * Update to deal.II 7.1.0 (me, within a week) * Patch gmsh to work with petsc/slepc 3.2 (Christophe Trophime with my help, probably within a week) * Update DOLFIN (Johannes Ring, within a week) * Test/update feel++ (?? If nobody else I'll take a stab at it) * Remove illuminator from testing (release team) * Close the RC bug against mpi-defaults (which is pointless anyway because it transitioned just before I filed it, I'll do this today) It looks like there's a clear path to success, and this can all happen within a week or two, then we can transition a bunch of stuff at once including HDF5. Otherwise we're stuck trying to do two transitions which will take at least 4 weeks... Makes sense? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
Hello Julian, On Sat, 2012-01-21 at 16:49 +0100, Julien Cristau wrote: Hi, it seems there's currently a move from petsc and slepc 3.1 to 3.2 in sid. In addition to the library package names changing, presumably because the new versions are not binary-compatible, the devel package were also renamed, from libpetsc3.1-dev and libslepc3.1-dev to libpetsc3.2-dev and libslepc3.2-dev. Which is a problem, because it means every single reverse dependency would need debian/control changes. Is the new petsc/slepc API really completely incompatible with 3.1, such that all reverse dependencies need source changes to cope with 3.2? If not, what's the reason for changing the -dev package names? If yes, was the change coordinated with the reverse deps so things don't stay broken for too long? I announced it to debian-science a month ago, but didn't coordinate beyond that. :-( Sorry! Is anyone willing to take care of making this happen? I'm working on this for my packages (see below). FWIW the affected packages seem to be: - deal.ii deal.II detects the PETSc version and acts accordingly, I believe 7.1.0 will work through 3.2. I need to work on upgrading from 7.0.0 to 7.1.0. - dolfin - feel++ - gmsh - illuminator Illuminator has major problems -- the PETSc object on which all of illuminator is based has changed drastically. This will require major upstream surgery, and the new version will not be data-compatible with the old. Since upstream is me, I can tell you I will not have time for the foreseeable future (couple of months at least) to port illuminator to PETSc 3.2. It will need to come out of testing when PETSc transitions. :-( - libmesh Should be okay like deal.II, though I haven't touched libMesh in a long time... Can't speak for the others (dolfin, feel++, gmsh). -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: libmed 64 bits (was: Re: Code Aster version NEW11.0.10 uploaded to SVN)
Hello Andrea, On Wed, 2011-12-14 at 20:50 +, Andrea Palazzi wrote: However, the package builds but the executable has a big problems when reading MED files (containing mesh data and results). I'm almost sure that this comes from the use of the flag _MED_USE_SHORT_INT - as a reminder, the process of CA installation from the EDF package builds also the libraries, all with 64bit integers by default ( -fdefault-double-8 -fdefault-integer-8 -fdefault-real-8 ). About this problem, I was wondering if it would be possible to build a libmed64 package beside the ones already built, so that we can use that for CA and solve the problem; other advantages of this approach would be of less effort from upstream and a wider user base to use this configuration - I think I'm the only one using _MED_USE_SHORT_INT. Could this be done somehow? Nobody on this topic? The maintainer of libmed? D'oh! I guess that's me and Aurelien Jarno, the only two who have uploaded. This might require building twice for the normal and libmed64 versions, which will change debian/rules quite a bit. I have a bunch of other stuff to do around the mpi-defaults transition and might not get to this for a week or two, would you (or anyone else) be willing to investigate a patch? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: deal.ii 7.0.0
Hi Nuno et al., I finally found the time to work out how to deal with this giant package which breaks git-import-orig... So I've been able to do some work on this (more inline below). On Sun, 2011-07-31 at 18:35 -0400, Nuno Sucena Almeida wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2011 08:30 AM, Adam C Powell IV wrote: Dear Nuno, A git format patch set would make my life a *lot* easier. But it will be enormous given the size of the repository. Can you post it somewhere on the web for me to download? Hi Adam,Christophe, You can access it at the following urls: git format patch files: http://slug.aeminium.org/software/gfp-deal.ii-7.0.0-slug.tar.xz (5.2M) http://slug.aeminium.org/software/gfp-deal.ii-7.0.0-slug.tar.xz.asc Thanks. I used this patch set because it's more complete than Christophe's -- includes patch forward-porting, other updated files, even satisfying lintian and making the tests work (though I haven't gotten quite that far yet). The result is up on alioth now. I'm going to build it tonight and test it over the weekend (it takes too much memory for too long to interrupt my day for it). Let me know how/if you need the format patch in a different way. This is my first debian package contribution, so please make sure I'm not messing something up :) No, you did a good job with it. One thing to note is that I added a new patch (doc.patch) that fixes a bug with a plain.cc tutorial script generator, solved upstream on the trunk branch. Thanks, saw that, now re-reading your explanation I understand it. In the meanwhile, can you advise on the following: some of the deal.ii functionality which I use, and needed by some of the examples, in particular MPI petsc/slepc library support, require disabling threading ( ./configure --disable-threads). On the other hand some other use cases and examples need thread enabled when running on shared memory machines, which I also use. So my question is what would be the best approach on building thread/non-thread packages for deal.ii ? The libboost package does something similar (libboost , libboost-thread ) I see, that's a problem. What does upstream say about the conflict? I subscribed to the debian-science mailing list, do you want to move this discussion over there? Actually, that's a good idea. Taking it there now. Anyone else with feedback on the package? Thanks again, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: OpenMPI-bin missing on some arches (Was: mrbayes-mpi: uninstallable on mipsen and s390)
On Wed, 2011-06-29 at 23:19 +1000, Drew Parsons wrote:
On Wed, 2011-06-29 at 15:01 +0200, Andreas Tille wrote:
Hi,
Your package is uninstallable on some archs:
mrbayes-mpi/mips unsatisfiable Depends: openmpi-bin
mrbayes-mpi/mipsel unsatisfiable Depends: openmpi-bin
mrbayes-mpi/s390 unsatisfiable Depends: openmpi-bin
I admit I'm not so comfortable with these architectures. Is there any
drop-in replacement for openmpi on these and if yes, what do I need to
specify in debian/{control,rules}? Could any other package with the
same problem serve as an example?
Try mpich2, or better still use mpi-defaults (mpi-defaults-dev).
mpi-defaults is a dummy package that pulls in what we deem to be the
most reliable mpi implementation for the architecture, which on those
arches is mpich2 not openmpi. lam4 is an alternate option, it was
previously the mpi-default but is currently being deprecated in favour
of mpich2.
And you want mpi-default-bin where you would otherwise use openmpi-bin.
Tons of packages use mpi-default-* dependencies, just use debtree or
similar to find them.
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
Re: Proposal: Debian Science mailing lists
On Mon, 2011-06-27 at 17:26 +0200, Sylvestre Ledru wrote: Le mercredi 22 juin 2011 à 10:20 -0400, Adam C Powell IV a écrit : On Tue, 2011-06-21 at 13:29 +1000, Drew Parsons wrote: On Wed, 2011-06-15 at 08:33 -0400, Manjusha Joshi wrote: On Tue, Jun 14, 2011 at 1:13 PM, Brett Viren b...@bnl.gov wrote: Sylvestre Ledru sylves...@debian.org writes: == Proposal == I would like to propose the following: * move all packaging related discussions to debian-science-maintain...@lists.alioth.debian.org * use debian-science@lists.debian.org only for user oriented discussions * make sure that all the commit mails are sent on debian-science-maintainers-comm...@lists.alioth.debian.org [...] FWIW I agree with Drew on this. It's hard to segregate user queries from packaging queries, and many user discussions probably belong on the lists of the individual projects, as Manjusha mentioned this morning. (Indeed, I see a lot of Debian- and Ubuntu-related questions on forums such as FreeCAD and Elmer.) Debian is about packaging software, not generating it, and users who come to Debian lists will probably want to discuss that packaging, not the software itself. You are probably right with this argument... Can the proponents of this proposal please describe what kinds of discussions would belong on debian-science if we decide to make the change? I was more thinking about people exchanging about already packaged software. For example, what is the best software for CFD available into Debian ?, Is there any connector between XX and YY ?, etc. This makes a lot of sense -- comparing, say, CFD software or statistical packages packaged for Debian, is something users might want to discuss without the overhead of all the packaging talk. I've seen similar discussions on CAD packages. But beyond this, such a discussion would probably turn to I like package A better than B, because B doesn't have feature X, to which the reply might be B has feature X upstream, but it's not implemented in the Debian package. After which they'd be politely pushed to the packaging list, and the discussion in the archives would be split between two lists. I could see this happening often. So FWIW I'm not quite convinced. But of course I'll go along with the decision of the majority/consensus -- if I see more packaging discussions on d-s-m than d-s, then I'll start my new threads there. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Proposal: Debian Science mailing lists
On Tue, 2011-06-21 at 13:29 +1000, Drew Parsons wrote: On Wed, 2011-06-15 at 08:33 -0400, Manjusha Joshi wrote: On Tue, Jun 14, 2011 at 1:13 PM, Brett Viren b...@bnl.gov wrote: Sylvestre Ledru sylves...@debian.org writes: == Proposal == I would like to propose the following: * move all packaging related discussions to debian-science-maintain...@lists.alioth.debian.org * use debian-science@lists.debian.org only for user oriented discussions * make sure that all the commit mails are sent on debian-science-maintainers-comm...@lists.alioth.debian.org Benefit is we also get updates about packages and that is really useful for us. As Linux user cannot remain only user, need to do system admin level work also for scientific packages. Second thing is, after making 2 separate list will there be increase in the user level queries? At present there are hardly user related queries. In practice I'm inclined to disagree with the proposal. That is, in one sense it arguably makes sense in principle to keep packing discussions separate from user discussions. But I agree with Manjusha that a) it could be useful to have the user's perspective on packaging questions b) users could potential find it useful to hear what we're up to and what decisions we're making on packages. They will be affected by those decisions. c) I haven't noticed that many user-level discussions anyway. What problem are we trying to solve here? Have user discussions been impeded by packaging discussions? Is it the intention of the proposal to encourage more user discussion by shifting out all packaging discussion? For myself personally, I tend to find it easier to have just the one list to have to think about. Although it's easy enough to set up another email filter just as I already have for debian-science. FWIW I agree with Drew on this. It's hard to segregate user queries from packaging queries, and many user discussions probably belong on the lists of the individual projects, as Manjusha mentioned this morning. (Indeed, I see a lot of Debian- and Ubuntu-related questions on forums such as FreeCAD and Elmer.) Debian is about packaging software, not generating it, and users who come to Debian lists will probably want to discuss that packaging, not the software itself. Can the proponents of this proposal please describe what kinds of discussions would belong on debian-science if we decide to make the change? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Status of salome package
On Tue, 2011-06-14 at 09:21 +0200, Alain Leufroy wrote: Andre, has upstream merged in your new versions of the patches, or do we need to forward-port them all again to send in for merging? Let see the end of this mail, I've pasted the answer of the upstream (in french). Wow, thank you very much Alain! I am glad to see that upstream has accepted so many of these patches. From erwan.a...@cea.fr Mon Apr 4 16:53:09 2011 Date: Mon, 04 Apr 2011 16:53:00 +0200[B From: Erwan ADAM erwan.a...@cea.fr To: alain.leuf...@logilab.fr Cc: BERGEAUD Vincent vincent.berge...@cea.fr, Vincent LEFEBVRE vincent.lefeb...@edf.fr, Nicolas Chauvat n...@logilab.fr, Andre Espaze d...@logilab.fr, al...@logilab.fr Subject: Re: patches Salome 5.14 Bonjour, Votre contribution concernant la compilation des paquets debian de salome 5.1.4 a été analysée, mergée dans la branche V5 et mergée dans la branche V6. Les prochaines versions de salome contiendront donc ces modifications : o 6.3.0 prévue mi mai 2011 o 5.1.6 prévue fin juin 2011 Merci encore, E. Adam PS : Ci-joint l'analyse qui a été faite des patchs # --- The following patches have not been applied because they modify the checks detecting presence of the SALOME modules to find the SALOME modules in Debian-correct directory locations only kernel-debian-dirs.patch gui-debian-dirs.patch geom-debian-dirs.patch med-debian-dirs.patch smesh-debian-dirs.patch visu-debian-dirs.patch The following patches sets format of pictures generated by doxygen to SVG format in order to minimize their size. The patches have not been applied because SVG format is correctly supported since doxygen-1.7.2 while we currently use doxygen-1.6.1. The patches will be applied as soon as we pass to doxygen-1.7.2 (or a later version). kernel-doc-images-svg.patch gui-doc-images-svg.patch geom-doc-images-svg.patch med-doc-images-svg.patch smesh-doc-images-svg.patch visu-doc-images-svg.patch This much is fine, it should not be a problem to maintain the Debian-specific patches and the svg doc patches. kernel-mpi-libs.patch has not been applied as it is Debian-specific. It modifies check_mpi.m4 by adding libmpi++.so, which is a symlink to a concret MPI implementation, to MPI_LIBS variable. We can re-name the debian-specific ones, such as kernel-mpi-libs which should be kernel-debian-mpi-libs. geom-fix-clean.patch has been applied partially; the part removing the code renameing geompyDC.py to geompy.py for the sake of correct documentation generation has been ignored. Another solution for the problem fixed by that patch part has been implemented. med-scotch.patch has been applied partially; a part of the patch unconditionally including mpi.h in tests of the scotch library (check_scotch.m4) has been ignored. The part patching MEDSPLITTER_SCOTCHGraph.cxx has been ignored as it does not work with the current version of the scotch library and unconditionally includes mpi.h. med-safe-include.patch has been applied partially; parts of the patch unconditionally including mpi.h into MEDMEM source files has been ignored. geom-mpich-mpi, smesh-hdf5-needs-mpi.patch and visu-hdf5-needs-mpi.patch have been ignored as they add CHECK_MPI (possibly needed for hdf5) into configure.ac. Another solution has been implemented: CHECK_MPI has been added to check_hdf5.m4 It sounds like upstream has made many of the above patches work for us, and a little bit of work will fix the last few. Merci beaucoup encore Alain, this is terrific news. It will take a little bit of work to forward-port what's left, and I'll try to make some time in the next couple of weeks to make this happen. That said, this will make it much easier to maintain the Debian Salomé package going forward. I am glad that we have a channel to work with upstream on making Debian and its derivatives first-class platforms for running this first-class engineering software suite! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: gmsh and libscotchmetis
On Wed, 2011-06-08 at 20:29 +0200, Andrea Palazzi wrote: Il giorno mer, 08/06/2011 alle 19.59 +0200, Anton Gladky ha scritto: Just a guess, maybe we can contact metis upstream with the question of relicensing it under distributable license? Anton Hi, I've contacted metis upstream to ask permission to place it on debian mirrors, and also asked him to consider a different license: he agreed to put the sources and binaries on debian mirrors, but didn't answer about the relicensing; and since it wasn't the first time he was asked for this, I'm guessing he's not interested in changing the license. Anyway, if someone wants to try, it won't do any harm. I did the same about ten years ago... -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: gmsh and libscotchmetis
Hi Anton, Sounds good, thanks. I notice you also added the interfaces you need for gmsh to Bug 506033, thanks. For Elmer, I noticed that it could do node-wise or element-wise partitioning, and just disabled the element-wise partitioning which used METIS_PartMesh* functions. Is it possible to do something similar for gmsh? -Adam On Tue, 2011-06-07 at 17:46 +0200, Anton Gladky wrote: Thanks for answers, I have uploaded a new version with disabled metis. Anton On Mon, Jun 6, 2011 at 8:28 PM, Adam C Powell IV hazel...@debian.org wrote: Hi Anton, On Sun, 2011-06-05 at 07:29 +0200, Anton Gladky wrote: Hi, all! I am trying to package gmsh 2.5.1~svn version and to fix lintian errors and warnings. But I have a problem with linking against packaged libscotchmetis. The following error appears: Linking CXX executable gmsh /home/dk/gmsh/nv/upl_metis/gmsh-2.5.1~svn9373/Mesh/meshPartition.cpp:527: error: undefined reference to 'METIS_mCPartGraphKway' /home/dk/gmsh/nv/upl_metis/gmsh-2.5.1~svn9373/Mesh/meshPartition.cpp:502: error: undefined reference to 'METIS_mCPartGraphRecursive' collect2: ld returned 1 exit status The scotchmetis compatibility layer is not a complete reimplementation of METIS. Bug 506033 requests addition of PartMesh functions; these may also be missing. I or someone else should probably forward these requests upstream and see if there is some prospect of implementing these functions... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: gmsh and libscotchmetis
Hi Anton, On Sun, 2011-06-05 at 07:29 +0200, Anton Gladky wrote: Hi, all! I am trying to package gmsh 2.5.1~svn version and to fix lintian errors and warnings. But I have a problem with linking against packaged libscotchmetis. The following error appears: Linking CXX executable gmsh /home/dk/gmsh/nv/upl_metis/gmsh-2.5.1~svn9373/Mesh/meshPartition.cpp:527: error: undefined reference to 'METIS_mCPartGraphKway' /home/dk/gmsh/nv/upl_metis/gmsh-2.5.1~svn9373/Mesh/meshPartition.cpp:502: error: undefined reference to 'METIS_mCPartGraphRecursive' collect2: ld returned 1 exit status The scotchmetis compatibility layer is not a complete reimplementation of METIS. Bug 506033 requests addition of PartMesh functions; these may also be missing. I or someone else should probably forward these requests upstream and see if there is some prospect of implementing these functions... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: OCE -- OpenCASCADE Community Edition
On Thu, 2011-05-19 at 16:32 +0200, Sylvestre Ledru wrote: Le jeudi 19 mai 2011 à 10:16 -0400, Adam C Powell IV a écrit : Dear Debian Scientists, The question to Debian is: do we package OCC or OCE? If OCE, do we change the name, or just trust that the changes are minor and fully compatible? If the changes are just minor, then do we just gather the git patches in debian/patches? It is a good news! I think we should package it but we will probably have to change the name to avoid confusion for users... However, we will have to make sure OCE is not diverging from upstream too much.. So I guess this depends on which direction the project takes. My understanding is that this is just for providing issue tracking and bug fixes where upstream has dropped the ball. The most ambitious change people have suggested is to switch from autotools to cmake. And the plan is to incorporate all upstream releases into it. Given all this, I don't see a reason to change the name of the Debian package. Even a build system change leaves the bulk of the code the same, all of the interfaces remain the same, etc., so does the name really need to change? If there are new features or incompatible changes -- even fixes which change the behavior to match the design or documentation -- then that's a different story... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ITP: aster -- Finite Element Analysis (FEA) software for engineering simulations
Hello Andrea, On Tue, 2011-05-10 at 12:58 +0100, Andrea Palazzi wrote: --- Mar 10/5/11, Adam C Powell IV hazel...@debian.org ha scritto: Da: Adam C Powell IV hazel...@debian.org Oggetto: Re: ITP: aster -- Finite Element Analysis (FEA) software for engineering simulations I would like to help in packaging the Code Aster software[1] for Debian. Thanks for your interest in the packaging of Code Aster. However, you should be aware of a license issue with metis-edf: http://glaros.dtc.umn.edu/gkhome/node/686 To unblock, we should consider some uploads in non-free and contrib. How extensive are the differences between metis-edf and metis? Might it be worth porting those differences to Scotch? Or does Code Aster use some features of metis not present in Scotch, like element-wise partitioning (instead of node-wise)? Hi, I know nothing about mesh partitioning, scotch and metis; however here is what Cristophe Trohime said to me when we talked about this a month ago (the quoted text is mine): [...] As far as I understand, it's actually possible to build CA without metis; however some functionalities will not be available (RENUM='METIS' in SOLVEUR), and this can be a rather annoying problem, since metis is the default renumerator; however, if CA can switch automatically to another renum, this may become just a performance issue (and a longer list of failing tests, if METIS is explicitly called). For replacing metis with scotch, the library by itself is already there (libscotchmetis), however what is missing are the executables: see this thread http://www.code-aster.org/forum2/viewtopic.php?id=14417 , where André says In case you succeed to make the tests from liste_internet pass with scotchmetis, I am very interested about your build (because it means that you can supply an alternative to onmetis, kmetis and onmetis.exe). I had the opportunity to discuss that with Mathieu Courtois, a ASTER developper, last year. He tells me that if we choose Scotch instead of metis it will be better to call directly without using any additionnal programs. But my guess is this is a lot of work. The other point is if you want to rewrite (on)metis with scotch you cannot do it easily. They are using some calls to metis which do not exist in scotch. As far as I understand they prefer to stick to metis which is more widespread than scotch. [...] So, if I get it right CA calls metis via an executable (onmetis, konmetis, onmetis.exe). Great, that way there's no derivative work and no copyright violation, as there would be if they linked to libmetis (at least in the FSF interpretation). The difference between metis and metis-edf is (i think) in these executables and in some other modification to make it work with CA - maybe the int32/int64 issue. Those executables are using some library calls that are not implemented in scotch, and EDF doesn't seems interested to replace metis with scotch. Ah, that's what I was afraid of. This is an issue also for Elmer, though Elmer has an option for node-wise partitioning, which Scotch supports, and which I enable by default, so it works out-of-the-box. If an Elmer user switches that off, they get an error message. Thanks for this additional information. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: gmsh FTBFS on some platforms
Hi Anton, On Tue, 2011-04-12 at 23:09 +0200, Anton Gladky wrote: Hi, all gmsh of 2.5.0.dfsg-6 version has the following line in control file[1]: libhdf5-mpi-dev[alpha amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc sparc], As I understand, libhdf5-mpi-dev should be included only on platforms, listed above. But builldd includes this package for all platforms, causing FTBFS on some of them. For example, mips is not listed above, but buildd includes libhdf5-mpi-dev for building [2]: Get:112 http://mirror-ubc.debian.org/debian/ unstable/main libhdf5-mpi-dev mips 1.8.4-patch1-2 [18.3 kB] That's odd. I have nearly the same thing in my petsc build-depends, and it does not get libhdf5-mpi-dev on those arches. The one difference is that my petsc line has a space between libhdf5-mpi-dev and the open bracket: libhdf5-mpi-dev [i386 amd64 lpia ia64 powerpc kfreebsd-i386 kfreebsd-amd64], I have changed libhdf5-mpi-dev on libhdf5-openmpi-dev in build-deps [3]: libhdf5-openmpi-dev[alpha amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc sparc] But I am afraid, that it will cause again FTBFS, because libhdf5-openmpi-dev is not available on all platforms. Yeah, don't do that. We want it to work with mpich2 when that replaces lam on the non-OpenMPI arches. And sparc is not an OpenMPI arch -- at least not according to mpi-default-dev. soapbox Speaking of which, this is holding up the OpenCASCADE 6.5.0 transition, and HDF5 is broken an LAM affecting at least gmsh and petsc (and almost certainly salome when we get our act together on that package), so IMO it would be really helpful to [finally] get some movement on the LAM to MPICH2 change in mpi-defaults. Can we please try to do this sooner rather than later? I notice nobody responded to my last email about this [6], and if we just sit and wait for Godot to fix OpenMPI on the other arches, then wheezy will release with this awful mess still in Debian, as just happened with squeeze. LAM Delenda Est!! /soapbox Can anybody say, what do I do wrong? Why buildd ignores platforms, like described in Debian Policy [4]? The question comes from the bug [5] discussion. I appreciate any help. [1] http://svn.debian.org/wsvn/debian-science/packages/gmsh/tags/2.5.0.dfsg-6/control [2] https://buildd.debian.org/status/fetch.php?pkg=gmsharch=mipsver=2.5.0.dfsg-6stamp=1302030827 [3] http://svn.debian.org/wsvn/debian-science/packages/gmsh/trunk/debian/control [4] http://www.debian.org/doc/debian-policy/ch-relationships.html [5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613056#140 If I were you I'd try it with -mpi-dev and the space, since that works for petsc, and see how the buildds respond. [6] http://lists.debian.org/debian-science/2011/04/msg00023.html -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
binNMU of ScaLAPACK
Hi, I'd like to do a binNMU for ScaLAPACK to get rid of bug 589763. Specifically, whoever uploaded ScaLAPACK appears to have built it with libatlas-base-dev or something similar installed, so libscalapack-mpi1 depends on libatlas3gf-base . But libatlas3gf-base breaks my build of Elmer, which fails on: gfortran -m64 -fPIC -L. -L/usr/lib \ -o ViewFactors ViewFactors.o mpi_stubs.o \ -L. -lelmersolver viewaxis/libviewaxis.a view3d/libview3d.a -lblas -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../.. -lstdc ++ -lm -lgcc_s -lgcc_s /usr/lib64/liblapack.so.3gf: undefined reference to `ATL_scopy' /usr/lib64/liblapack.so.3gf: undefined reference to `ATL_stpsv' and 167 other missing symbols. (I have libatlas3gf-base in Build-Conflicts for this reason, and have to override with -d to get to this.) I thus can't upload Elmer linked to MUMPS -- and thus to ScaLAPACK -- until this is cleared up. ATLAS is nowhere in the ScaLAPACK Build-Depends, and building it with only its Build-Depends leaves it with no ATLAS dependencies, and Elmer + MUMPS builds and runs just fine. So when/how do I do a binNMU ScaLAPACK? It's been 13 days since my bug report. Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: RFH: petsc
On Mon, 2010-07-12 at 18:32 -0400, Adam C Powell IV wrote: On Mon, 2010-07-12 at 23:11 +0200, Johannes Ring wrote: Hi Adam, On Wed, Jul 7, 2010 at 5:51 PM, Adam C Powell IV hazel...@debian.org wrote: Hello, I'm having two problems with PETSc, and need some help. Second, I just uploaded a new version, and although the build process reports that it builds the libraries just fine, they are not installed during the install step -- though on my machine it all works fine. This seems odd to me, as install is just a matter of copying everything: cp -a linux-gnu-c-opt/lib debian/libpetsc3.1-dev/usr/lib/petscdir/3.1/linux-gnu-c-opt/ The linux-gnu-c-opt/lib directory is PETSC_LIB_DIR, but it must be empty, because the corresponding directory in the package is empty. Can someone else try to build it, and let me know what's in the linux-gnu-c-opt/lib directory at the end? I built PETSc in pbuilder and this is the contents in the linux-gnu-c-opt/lib folder: # ls -lh linux-gnu-c-opt/lib/ total 19M -rw-r--r-- 1 root root 13M Jul 12 20:33 libpetsc.a -rwxr-xr-x 1 root root 6.0M Jul 12 20:33 libpetsc.so Thanks very much Johannes. I'm consistently getting: % ls -lh linux-gnu-c-opt/lib/ total 19M -rw-r--r-- 1 hazelsct 1003 13M 2010-07-06 23:39 libpetsc.a lrwxrwxrwx 1 hazelsct 1003 15 2010-07-06 23:39 libpetsc.so - libpetsc.so.3.1* -rwxr-xr-x 1 hazelsct 1003 6.0M 2010-07-06 23:39 libpetsc.so.3.1* The install step should be putting all of these into debian/libpetsc-dev/usr/lib/petscdir/3.1/linux-gnu-c-opt/lib but for some reason the buildds are not getting the libpetsc.a or the .so symlink, let alone the name-versioned lib... Okay, you've given me some ideas, now back to the drawing board. D'oh, I'm an idiot! There's no patch target in PETSc's debian/rules. I'll try that, so the patches actually apply on the buildds. Yup, buildd logs show that the clean target removes all the patches, then it goes ahead and builds without re-applying them. That should also get rid of rpath in environment variables, closing another bug. Fixing that right now and uploading... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: RFH: petsc
On Mon, 2010-07-12 at 23:11 +0200, Johannes Ring wrote: Hi Adam, On Wed, Jul 7, 2010 at 5:51 PM, Adam C Powell IV hazel...@debian.org wrote: Hello, I'm having two problems with PETSc, and need some help. Second, I just uploaded a new version, and although the build process reports that it builds the libraries just fine, they are not installed during the install step -- though on my machine it all works fine. This seems odd to me, as install is just a matter of copying everything: cp -a linux-gnu-c-opt/lib debian/libpetsc3.1-dev/usr/lib/petscdir/3.1/linux-gnu-c-opt/ The linux-gnu-c-opt/lib directory is PETSC_LIB_DIR, but it must be empty, because the corresponding directory in the package is empty. Can someone else try to build it, and let me know what's in the linux-gnu-c-opt/lib directory at the end? I built PETSc in pbuilder and this is the contents in the linux-gnu-c-opt/lib folder: # ls -lh linux-gnu-c-opt/lib/ total 19M -rw-r--r-- 1 root root 13M Jul 12 20:33 libpetsc.a -rwxr-xr-x 1 root root 6.0M Jul 12 20:33 libpetsc.so Thanks very much Johannes. I'm consistently getting: % ls -lh linux-gnu-c-opt/lib/ total 19M -rw-r--r-- 1 hazelsct 1003 13M 2010-07-06 23:39 libpetsc.a lrwxrwxrwx 1 hazelsct 1003 15 2010-07-06 23:39 libpetsc.so - libpetsc.so.3.1* -rwxr-xr-x 1 hazelsct 1003 6.0M 2010-07-06 23:39 libpetsc.so.3.1* The install step should be putting all of these into debian/libpetsc-dev/usr/lib/petscdir/3.1/linux-gnu-c-opt/lib but for some reason the buildds are not getting the libpetsc.a or the .so symlink, let alone the name-versioned lib... Okay, you've given me some ideas, now back to the drawing board. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
RFH: petsc
Hello, I'm having two problems with PETSc, and need some help. First is the HPPA issue (below), for which I just supplied a list of arches for binary packages which includes everything but HPPA. But unlike say openmpi, the HPPA buildd doesn't indicate Not-for-us, but tried to build it. [1] How do I specify that petsc is not for hppa? Or will that change happen automatically following resolution of ftp.debian.org RM bug 588344 (just filed)? [1] https://buildd.debian.org/status/package.php?p=petsc Second, I just uploaded a new version, and although the build process reports that it builds the libraries just fine, they are not installed during the install step -- though on my machine it all works fine. This seems odd to me, as install is just a matter of copying everything: cp -a linux-gnu-c-opt/lib debian/libpetsc3.1-dev/usr/lib/petscdir/3.1/linux-gnu-c-opt/ The linux-gnu-c-opt/lib directory is PETSC_LIB_DIR, but it must be empty, because the corresponding directory in the package is empty. Can someone else try to build it, and let me know what's in the linux-gnu-c-opt/lib directory at the end? Thanks, Adam On Tue, 2010-07-06 at 08:46 -0400, Adam C Powell IV wrote: On Mon, 2010-07-05 at 20:24 +0200, Christophe Prud'homme wrote: what are your plans regarding the build issue of petsc3.1 on hppa ? I have no idea on how to resolve this issue. It seems to be a low-level problem with python, and there was a suggestion that certain kernels worked and others didn't. And it sometimes builds, sometimes does not -- when the problem first showed up, it built approximately once out of every three attempts, but the last several attempts have all failed. So it's a complex HPPA-only issue which seems like a lot more trouble to solve than it's worth. at the moment this issue blocks slepc and life from reaching testing Should I change the build-depends to petsc 3.0 on hppa ? or are you planning an upload the next few days ? The best way forward I know of is to make this a non-hppa package, which all of its derivatives would be as well. The problem exists on petsc 3.0 as well, whose hppa version needs to be removed from the archive. I need to take care of one other issue, and should be able to upload this later this week. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: plans for petsc3.1 on hppa
Hi Christophe, On Mon, 2010-07-05 at 20:24 +0200, Christophe Prud'homme wrote: what are your plans regarding the build issue of petsc3.1 on hppa ? I have no idea on how to resolve this issue. It seems to be a low-level problem with python, and there was a suggestion that certain kernels worked and others didn't. And it sometimes builds, sometimes does not -- when the problem first showed up, it built approximately once out of every three attempts, but the last several attempts have all failed. So it's a complex HPPA-only issue which seems like a lot more trouble to solve than it's worth. at the moment this issue blocks slepc and life from reaching testing Should I change the build-depends to petsc 3.0 on hppa ? or are you planning an upload the next few days ? The best way forward I know of is to make this a non-hppa package, which all of its derivatives would be as well. The problem exists on petsc 3.0 as well, whose hppa version needs to be removed from the archive. I need to take care of one other issue, and should be able to upload this later this week. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: how to do science with amd64 lenny
On Thu, 2010-06-17 at 13:04 -0400, Lennart Sorensen wrote: On Thu, Jun 17, 2010 at 06:05:05PM +0200, Francesco Pietra wrote: Hello: For computational chemistry on the stable amd64 I needed yesterday MPICH2. As the deb package is only in testing, I compiled MPICH2 for stable, but the parallelized program needs python2.6, only available in testing. I doubt I am able enough to compile python. I can't move to testing because I am not allowed to do that not only for the risk of testing distributions for computational work but also because older key computational package do not run on testing. Question: would installing python2.6 on lenny from unstable be safe enough by using apt-pinning? I have no system expert here. I would be responsible for damage to the software. Otherwise, do you know a distribution of linux that overcomes such problems by making some key recent packages available for their stable version? I could suggest to move to that because of recurring problems for us. I would consider moving python2.6 likely more risky than simply moving to testing entirely. No distribution can provide recent packages for stable releases because then it isn't stable anymore. Too many other dependancies end up having to be pulled in in many cases. Either you want stable, or you want current. You can not have both. Ubuntu gets around this by a much more rapid release cycle than Debian. It has had Python 2.6 since Karmic last Fall, and Lucid (current stable) has mpich2 (Karmic may have as well). Do your legacy apps run on new Ubuntu releases? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
If mpi-default-dev points to lam, then why is OpenMPI installed in the system? Just use mpi-default-dev and libhdf5-mpi-dev and they should be consistent. If they're not, then HDF5 needs a bin NMU. Likewise with boost, that should be built using mpi-default-dev, right? Are you suggesting that mpi-default-dev should conflict with every non-default mpi-dev package on a given architecture, to make certain that nobody has it installed when building such packages? [Separate issue: if there's openmpi on Sparc, why is it not the mpi-default?] -Adam On Thu, 2010-06-10 at 07:02 +0200, Christophe Prud'homme wrote: All, if openmpi is installed on sparc, it takes priority over lam ! (it has priority 40 and lam 30) here is the result of mpic++ -showme:compile on smetana.debian.org -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi -pthread and link mpic++ -showme:link -pthread -L/usr/lib/openmpi/lib -lmpi_cxx -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export-dynamic -lnsl -lutil -lm -ldl so even though mpi-default-dev point to lam, if openmpi gets also installed it is in practice the default implementation on sparc ! To my opinion this is a bug in the mpi system. Adam ? Others ? There are 3 choices for the alternative mpi (providing /usr/include/mpi). SelectionPath Priority Status * 0/usr/lib/openmpi/include 40auto mode 1/usr/include/lam 30manual mode 2/usr/lib/mpich/include 10manual mode 3/usr/lib/openmpi/include 40manual mode On Wed, Jun 9, 2010 at 8:53 PM, Christophe Prud'homme prudh...@debian.org wrote: I tried, without success so far, to help cmake(FindMPI.cmake) find the proper mpi implementation. It still finds openmpi which breaks linkage with boost::mpi Best regards C. On Wed, Jun 9, 2010 at 12:08 PM, Adam C Powell IV hazel...@debian.org wrote: On Mon, 2010-06-07 at 02:25 -0500, Steve M. Robbins wrote: On Mon, Jun 07, 2010 at 09:02:41AM +0200, Christophe Prud'homme wrote: On my side life depends solely on mpi-default-dev, it seems that some other package don't (e.g. hdf5), isn't it a problem ? Yes, something like that is likely the problem. Note that libhdf5-mpi-dev is supposed to alleviate that problem as it depends on the default MPI version. Installing that package should not pull in any non-default MPI packages, IMHO. Adam: any comment? Indeed, that's the idea: Build-Depend on libhdf5-mpi-dev and mpi-default-dev and you should have a consistent MPI implementation across both. That said, the LAM HDF5 implementation seems to be missing a couple of libraries, such that for example PETSc doesn't build on architectures where LAM is the default. I disabled PETSc HDF5 support on those arches, but haven't investigated further. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
Hi Christophe, On Fri, 2010-06-11 at 23:48 +0200, Christophe Prud'homme wrote: Hi Adam, thanks for your answer ! On Fri, Jun 11, 2010 at 8:05 PM, Adam C Powell IV hazel...@debian.org wrote: If mpi-default-dev points to lam, then why is OpenMPI installed in the system? Just use mpi-default-dev and libhdf5-mpi-dev and they should be consistent. If they're not, then HDF5 needs a bin NMU. I am not depending on hdf5, it gets installed due to another build-depends (I am not sure which one) It sounds like the bug is here. When this is found and fixed, everything should work with the MPI defaults. I of course use mpi-default-dev which points to lam unfortunately openmpi gets installed too and has higher priority than lam and all the defaults point to openm pi mpic++, incluce, libs... Likewise with boost, that should be built using mpi-default-dev, right? boost is also build-depending on mpi-default-dev I believe neither life or boost are at fault but rather mpi-default* which has an inconsistent behavior on sparc Are you suggesting that mpi-default-dev should conflict with every non-default mpi-dev package on a given architecture, to make certain that nobody has it installed when building such packages? no I suggest that if lam is the default implementation then it should be the default if openmpi is installed it becomes the default log on smetana.debian.org and do ' dchroot unstable' and check for yourself. I believe you. But the alternatives mechanism isn't going to work in this way, so we'd need some other way to create the default links. [Separate issue: if there's openmpi on Sparc, why is it not the mpi-default?] good question. Here's bug #2. The mpi-defaults package is only there to provide LAM as a backup to openmpi on the arches where it doesn't work. Where it works, it should be the default. I fixed the problem by enforcing lam I set the MPI_COMPILER to mpic++.lam explicitely rather than mpic++ which points to the openmpi one also there is a mpicxx for openmpi but none for lam . So the alternatives are not consistent should I fill a bug on mpi-default* ? I don't think it needs a separate mpicxx, that's just the openmpi name for the same thing (they point to the same binary in openmpi). IIRC mpic++ should be a link pointing to the default implementation, is that not the case? I don't have time to file these bugs now, but will try to get to it over the weekend. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
On Mon, 2010-06-07 at 02:25 -0500, Steve M. Robbins wrote: On Mon, Jun 07, 2010 at 09:02:41AM +0200, Christophe Prud'homme wrote: On my side life depends solely on mpi-default-dev, it seems that some other package don't (e.g. hdf5), isn't it a problem ? Yes, something like that is likely the problem. Note that libhdf5-mpi-dev is supposed to alleviate that problem as it depends on the default MPI version. Installing that package should not pull in any non-default MPI packages, IMHO. Adam: any comment? Indeed, that's the idea: Build-Depend on libhdf5-mpi-dev and mpi-default-dev and you should have a consistent MPI implementation across both. That said, the LAM HDF5 implementation seems to be missing a couple of libraries, such that for example PETSc doesn't build on architectures where LAM is the default. I disabled PETSc HDF5 support on those arches, but haven't investigated further. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: petsc3.1 using lam instead of openmpi ? incompatilbity with boost::mpi...
Hi Christophe, On Thu, 2010-05-27 at 12:35 +0200, Christophe Prud'homme wrote: Adam, I certainly missed some emails but the recent petsc3.1 upload compiled with lam (and not the default openmi) provoked a massive breakage on my side: slepc and life (which uses also slepc). Oh no! That's my fault, I was testing a couple of packages to fix build issues with LAM, and must have left the alternative pointing to it. Sorry about that. I managed to recompile life without slepc but I also use boost mpi compiled (build-depending on) with mpi-default-dev (as well as life) and combining code linked with lam and openmpi generates a nice segfault is there a place explaining the situation and how to fix my software ? I read the discussions on mpi and the move to mpich2 and openmpi but did not find guidelines I'll fix and re-upload now. But the file $PETSCDIR/conf/base is no longer part of PETSc as of 3.1, so change base to variables in the reverse-depends and you should get what you need. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: petsc3.1 using lam instead of openmpi ? incompatilbity with boost::mpi...
On Thu, 2010-05-27 at 08:31 -0400, Adam C Powell IV wrote: Hi Christophe, On Thu, 2010-05-27 at 12:35 +0200, Christophe Prud'homme wrote: I managed to recompile life without slepc but I also use boost mpi compiled (build-depending on) with mpi-default-dev (as well as life) and combining code linked with lam and openmpi generates a nice segfault is there a place explaining the situation and how to fix my software ? I read the discussions on mpi and the move to mpich2 and openmpi but did not find guidelines I'll fix and re-upload now. But the file $PETSCDIR/conf/base is no longer part of PETSc as of 3.1, so change base to variables in the reverse-depends and you should get what you need. On second thought, I'll put a compatibility link from base to variables to make reverse-depends just work. Apologies again for the LAM issue! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Debian Science related blog post (about Debian usage @ EDF)
Hi Stefano, On Thu, 2010-05-27 at 14:27 +0200, Carsten Aulbert wrote: On Thursday 27 May 2010 14:12:09 Stefano Zacchiroli wrote: The post is at http://upsilon.cc/~zack/blog/posts/2010/05/Debian-based_scientific_computin g_at_EDF/ and kudos your work, so it's probably appropriate to mention it here :) Nice post and I can put a big tick behind any of the items, Debian is just great although I'm not understanding why they need calibre instead of pure Debian. I'm definitely interested in sharing knowledge with you/them/anyone. I agree, great post. I can understand the need for calibre -- when you make custom changes, even compile flag optimizations for a given cluster or CPU sub-arch, you want a place to keep the binary packages where they're easy to install. It's also good for custom backporting and phased upgrades, it's the same reason many people have backport repositories. Related to that, I'm now collecting some feedback about other users of Debian in scientific computing / cluster environments. What would be the most appropriate venue to have people interested in that topic discuss together? Would this list be appropriate or should I rather request a new list, e.g. debian-...@lists.d.o, to replace the (long dead it seems) debian-beow...@lists.d.o mailing list? debian-hpc sounds nice, but I fear that it will eventually die as well as the group of people is very, very small. But at least I think it's worth a try. I agree about the small group, and there are a lot of people here on debian-science who use clusters (myself included). I've been in indirect contact with some people at EDF, and my impression is that they don't interface much with mainstream Debian because it's hard. Not that Debian is difficult per se, but it's not easy to both maintain a production environment which is in between stable and unstable, and also keep an eye on unstable and push packages and patches to it. There's a culture shift needed to see the long-term benefit to direct participation in a project like this, not unlike that of the Linux kernel, where organizations similarly have internal trees with occasional -- and often unpleasant -- contact with the always-on-the-bleeding-edge community. I think we're pleasant people here at debian-science, but still it's hard. Just an outside impression. Thanks again for visiting them and for your blog post. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Reproducibility
On Fri, 2010-04-30 at 14:18 +0200, Andreas Tille wrote: I can confirm that this is actually the reason why at Sanger Institute (even if there are three DDs working) plain Debian (and specifically the Debian Med packages) is not used. FYI, I uploaded a new version of the Med packages on Monday which I believe passes all of the tests (at least André Espaze got them all to pass when he tried the package a while ago). -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Question on Salome package organization
On Tue, 2010-04-27 at 09:36 +0200, Nicolas Chauvat wrote: On Mon, Apr 26, 2010 at 11:07:18PM +0200, Sylvestre Ledru wrote: Well done for this packaging! Yep, nice job. Thanks. One more argument: we could plug Aster into Salome thanks to pylotage. If we are lucky, it could even make it for Squeeze! +1, let's try to get it into squeeze. It will mean more users and developers, even though the packaging changes completely for squeeze+1. Done! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Question on Salome package organization
Greetings again, salome 5.1.3-6 is up at http://lyre.mit.edu/~powell/salome/ . The package is big and ugly and kludgey, but I've tested it a bit and confirmed that it runs from the menu. I built it with -sa and closed the ITP bug in the changelog, so it should be ready for its first upload. The question is: should I upload it? Here are the arguments as I see them. For uploading: * It seems to work (run), and thus can meet users' needs * Quicker reply from ftp-masters on copyright and other uploading issues * Broader testing, especially if it gets into squeeze * Possibly more devs interested in helping with debugging and package development * Use of the BTS to track issues * It will take a lot of work to fix some of the issues below, let's work on them together Against uploading: * The package is buggy! In particular, module loading requires .so files, so one needs to install about 100 MiB worth of -dev packages in order to run it * Package layout is not finalized, as demonstrated below * Shared library versioning isn't even finalized... In short, I think this package is about where OpenCASCADE and OpenOffice were when first uploaded: crude and simple packaging of a very useful piece of software, with plans for big packaging changes. I'd like to go ahead and upload in about 24 hours unless anyone has a strong objection. -Adam On Thu, 2010-04-22 at 19:23 -0400, Adam C Powell IV wrote: Hello André and list, On Thu, 2010-04-22 at 15:04 +0200, Andre Espaze wrote: Dear list, Now that salome-5.1.3-5 is running, I started a documentation on its content and finally found a question on Debian package organization. ... The current package organization is a legacy system from back when I first started to package version 3.2.6. It's really not very good. :-) I am aware of my ignorance on Debian package policy, Debian package policy doesn't require any particular organization, it just indicates what should be in shared lib, python, etc. packages. but I would suggest such kind of organization: - salome-core (the usual pre and post processings) - salome-core-dev (its development files) - salome-advance (the advanced uses) - salome-advance-dev (its development files) - salome-dev (every module for the Salome developer with development files) - salome-doc (the actual documentation) I like this organization. It's something like the transition we did for Open CASCADE a couple of years ago, led by Jason Kraftcheck and Denis Barbier. [1] [1] http://lists.debian.org/debian-science/2008/01/msg00013.html I have a few suggestions: * There are a lot of [T|t]est* binaries in the salome package. It would be good to separate these out into salome-core-test etc. packages so one doesn't need to install them along with the main binaries. * The shared libraries should go in their own packages, such as libsalome-core etc. Because their interface changes with every version, they should probably change from the 0.0.0 version designation to using the libtool -release flag with the package version, e.g. libGLViewer-5.1.3.so . * I think there should be a package called plain salome with the core functionality which people expect to have when they think of Salomé. * The documentation also desparately needs to break up! I suggest salome-doc for the non-built docs, and salome-user-doc and salome-dev-doc for the docs made with make -C [MODULE]/doc usr_docs and dev_docs respectively. * As for implementation, instead of SALOME_MODULES, perhaps we can have SALOME_CORE_MODULES, etc., and install them with DESTDIR= $(CURDIR)/debian/salome-core or -advanced etc., and then move around the shared libs, header files, symlinks, and python files from there. Another solution would be to provide a package for every Salome module but it seems to be confusing because of the modules number. Moreover the package creations is going to become inconvenient while producing very little improvement to the user. Who is going to create a mesh without using the GUI but only through a CORBA service (thus installing only salome-kernel and salome-smesh)? The same scenario can be repeated to others modules as well. I agree this would not be a helpful solution. In conclusion, is it worth to wonder about a new Salome package organization? Definitely! Thanks for the suggestion. It will all take a lot of work, and should probably happen after the initial package goes into unstable, but it will make people's lives much easier in the post-squeeze release. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open
Re: MPI implementations in squeeze
tags 563705 +patch thanks Hi and apologies for the long delay... On Fri, 2010-02-26 at 14:55 -0500, Adam C Powell IV wrote: On Fri, 2010-02-26 at 20:22 +0100, Lucas Nussbaum wrote: On 26/02/10 at 10:46 -0500, Adam C Powell IV wrote: On Thu, 2010-02-25 at 20:49 +0100, Lucas Nussbaum wrote: On 25/02/10 at 14:22 -0500, Adam C Powell IV wrote: On Thu, 2010-02-25 at 18:10 +0100, Lucas Nussbaum wrote: There is not much progress so far with respect to changing mpi-defaults to use MPICH2 instead of LAM on the architectures where Open MPI is not available yet. This needs a round of binNMUs. Marc Brockschmidt said he will look at the request to debian-release in the next few days, so this might resolve soon as well. Something to consider: this will break a lot of packages which use FORTRAN until 563705 is fixed, and then that will require mods to packages. I understand that bug as: if mpich2 or openmpi don't do the right thing when calling mpif77/mpif90, then symlinks are needed. Is there a proof that either of them doesn't do the right thing? Wouldn't it be more appropriate to fix them to do the right thing? (Those are honest questions -- I don't know anything about fortran) As discussed before (including in the bug), when there are mixed FORTRAN and C++ symbols, it's not clear whether to use mpif77/90 or mpic++. Also, it's a big convenience: a lot of packages make multiple executables and/or libraries, some of which use MPI and some don't. Pointing them to -lmpi -lmpi++ -lmpif77 for the MPI execs/lib directories seems easier than telling them to use mpicc and friends for some targets and gcc for others. I'm not sure I buy that, since mpicc friends also hide include paths, which are not handled with alternatives currently. Are you sure? % update-alternatives --display mpi mpi - auto mode link currently points to /usr/lib/openmpi/include /usr/lib/openmpi/include - priority 40 slave libmpi++.so: /usr/lib/openmpi/lib/libmpi_cxx.so [And a bunch of other slaves] It sounds more like a way to break packages by getting them linked with the wrong version of MPI. Do you know of packages doing that already? I've used this in most of my packages: petsc, hypre, libmesh, the new netgen and med-fichier under development (pending togl and updated hdf5 respectively), and salomé under development. Why would this break packages, if they just build-depend on mpi-default-dev? If the mpicc/mpif77 etc. alternatives work, why not the includes and libs as well? OK. Since it's harmless anyway, could you prepare and test patches for openmpi and mpich2? Since it would be a slave alternative, it doesn't require any alternatives transition. Will do, thanks. I'll also need to patch (at least my) packages which use this, will get to that in short order. Short order turned out to be somewhat long order, but here are the patches for mpich2 and openmpi. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ --- mpich2-1.2.1/debian/libmpich2-dev.postinst~ 2010-02-28 08:04:31.0 -0500 +++ mpich2-1.2.1/debian/libmpich2-dev.postinst 2010-03-09 10:56:08.0 -0500 @@ -19,6 +19,8 @@ --install /usr/include/mpi mpi /usr/include/mpich2 40 \ --slave /usr/lib/libmpi.so libmpi.so /usr/lib/libmpich.so \ --slave /usr/lib/libmpi++.so libmpi++.so /usr/lib/libmpichcxx.so \ + --slave /usr/lib/libmpif77.so libmpif77.so /usr/lib/libfmpich.so \ + --slave /usr/lib/libmpif90.so libmpif90.so /usr/lib/libmpichf90.so \ --slave /usr/bin/mpicc mpicc /usr/bin/mpicc.mpich2 \ --slave /usr/bin/mpic++ mpic++ /usr/bin/mpic++.mpich2 \ --slave /usr/bin/mpicxx mpicxx /usr/bin/mpicxx.mpich2 \ --- mpich2-1.2.1/debian/changelog~ 2010-02-28 08:04:31.0 -0500 +++ mpich2-1.2.1/debian/changelog 2010-03-09 11:04:13.0 -0500 @@ -1,3 +1,11 @@ +mpich2 (1.2.1-3) UNRELEASED; urgency=low + + [Adam C. Powell, IV] + * Added slave alternatives symlinks for MPI FORTRAN libraries +(closes: #563705). + + -- Adam C. Powell, IV hazel...@debian.org Tue, 09 Mar 2010 11:04:13 -0500 + mpich2 (1.2.1-2) unstable; urgency=low * Remove bashism in postinst introduced in 1.2.1-1. (fixes piuparts failure) --- openmpi-1.4.1/debian/libopenmpi-dev.postinst~ 2010-02-28 08:04:26.0 -0500 +++ openmpi-1.4.1/debian/libopenmpi-dev.postinst 2010-03-09 08:16:16.0 -0500 @@ -6,6 +6,8 @@ --install /usr/include/mpi mpi /usr/lib/openmpi/include 40 \ --slave /usr/lib/libmpi.so libmpi.so /usr/lib/openmpi/lib/libmpi.so \ --slave /usr/lib/libmpi++.so libmpi++.so /usr/lib/openmpi/lib/libmpi_cxx.so \ + --slave /usr/lib/libmpif77.so
Re: MPI implementations in squeeze
On Thu, 2010-02-25 at 20:49 +0100, Lucas Nussbaum wrote: On 25/02/10 at 14:22 -0500, Adam C Powell IV wrote: On Thu, 2010-02-25 at 18:10 +0100, Lucas Nussbaum wrote: There is not much progress so far with respect to changing mpi-defaults to use MPICH2 instead of LAM on the architectures where Open MPI is not available yet. This needs a round of binNMUs. Marc Brockschmidt said he will look at the request to debian-release in the next few days, so this might resolve soon as well. Something to consider: this will break a lot of packages which use FORTRAN until 563705 is fixed, and then that will require mods to packages. I understand that bug as: if mpich2 or openmpi don't do the right thing when calling mpif77/mpif90, then symlinks are needed. Is there a proof that either of them doesn't do the right thing? Wouldn't it be more appropriate to fix them to do the right thing? (Those are honest questions -- I don't know anything about fortran) As discussed before (including in the bug), when there are mixed FORTRAN and C++ symbols, it's not clear whether to use mpif77/90 or mpic++. Also, it's a big convenience: a lot of packages make multiple executables and/or libraries, some of which use MPI and some don't. Pointing them to -lmpi -lmpi++ -lmpif77 for the MPI execs/lib directories seems easier than telling them to use mpicc and friends for some targets and gcc for others. I'm not sure I buy that, since mpicc friends also hide include paths, which are not handled with alternatives currently. Are you sure? % update-alternatives --display mpi mpi - auto mode link currently points to /usr/lib/openmpi/include /usr/lib/openmpi/include - priority 40 slave libmpi++.so: /usr/lib/openmpi/lib/libmpi_cxx.so [And a bunch of other slaves] It sounds more like a way to break packages by getting them linked with the wrong version of MPI. Do you know of packages doing that already? I've used this in most of my packages: petsc, hypre, libmesh, the new netgen and med-fichier under development (pending togl and updated hdf5 respectively), and salomé under development. Why would this break packages, if they just build-depend on mpi-default-dev? If the mpicc/mpif77 etc. alternatives work, why not the includes and libs as well? And for something like med-fichier, wouldn't CC=mpicc and friends unnecessarily link a lot of non-MPI executables and libs to MPI libraries, causing memory bloat? Finally, are you sure mpif77 c++-object.o c-object.o f77-object.o -o executable will bring in all of the necessary libraries? I've never tried it, but I'd want to make sure it works for at least OpenMPI and MPICH2 before committing to use it. And we have libmpi.so and libmpi++.so symlinks, why not libmpif77.so? :) Well, maybe it might be a better idea to drop those links ;) Fair enough. :-) -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Bug#563705: MPI implementations in squeeze
On Fri, 2010-02-26 at 11:21 +0100, Sylvestre Ledru wrote: Le vendredi 26 février 2010 à 09:54 +, Alastair McKinstry a écrit : Perhaps using pkg-config (an mpi.pc file) would be a better solution to this; it is more standard: the mpicc, etc. approach isn't very scalable, you can't wrap every complex library. Use mpi.pc to point to where includes, etc. are, and alternatives to change the mpi.pc between versions. You can then, if necessary, use dependencies and conflicts within the pkg-config mechanism if need be, which aren't available if you use mixed mpicc / gcc within Makefiles. The problem with .pc is that a lambda user will consider that it is provided by OpenMPI or MPICH2 and expect to find it on other distributions. Causing pkg-config to be useless... I'm pretty sure OpenMPI upstream would welcome such a contribution, and I'd be surprised if MPICH2 upstream didn't as well, so I don't think that should limit us. Long-term this is my favorite solution, as other upstreams would likely also welcome patches to their configuration systems to use pkg-config to detect MPI, and if they don't, it's not that hard to maintain those patches. If we commit to this I'd gladly drop the other library and header alternatives symlinks -- with one constraint: pkg-config would need to point to libraries in /usr/lib so libtool doesn't add -rpath /usr/lib/openmpi/lib . -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: MPI implementations in squeeze
On Thu, 2010-02-25 at 18:10 +0100, Lucas Nussbaum wrote: There is not much progress so far with respect to changing mpi-defaults to use MPICH2 instead of LAM on the architectures where Open MPI is not available yet. This needs a round of binNMUs. Marc Brockschmidt said he will look at the request to debian-release in the next few days, so this might resolve soon as well. Something to consider: this will break a lot of packages which use FORTRAN until 563705 is fixed, and then that will require mods to packages. I understand that bug as: if mpich2 or openmpi don't do the right thing when calling mpif77/mpif90, then symlinks are needed. Is there a proof that either of them doesn't do the right thing? Wouldn't it be more appropriate to fix them to do the right thing? (Those are honest questions -- I don't know anything about fortran) As discussed before (including in the bug), when there are mixed FORTRAN and C++ symbols, it's not clear whether to use mpif77/90 or mpic++. Also, it's a big convenience: a lot of packages make multiple executables and/or libraries, some of which use MPI and some don't. Pointing them to -lmpi -lmpi++ -lmpif77 for the MPI execs/lib directories seems easier than telling them to use mpicc and friends for some targets and gcc for others. And we have libmpi.so and libmpi++.so symlinks, why not libmpif77.so? :) -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Salomé rules file and make wildcards
Hi, I've been beating my head on $(wildcard...) in a rules file for nearly a week now, and can't make any sense of it. The rules file is attached, and lines 192-193 both have identical $(wildcard...) in them (copied roughly from my babel package, where it works). When I run git-buildpackage, it always breaks on 193, with $(wildcard...) evaluating to nothing, though it works in 192, so the build ends with: rm -f debian/tmp/usr/bin/*.csh echo wildcard /home/hazelsct/repositories/salome/debian/tmp/usr/lib/python2.5/*-packages/salome/ wildcard /home/hazelsct/repositories/salome/debian/tmp/usr/lib/python2.5/site-packages/salome/ mv debian/tmp/usr/bin/*.py mv: target `debian/tmp/usr/bin/waitNS.py' is not a directory make: *** [install-stamp] Error 1 So the echo command in line 192 gets the wildcard right, but the mv command in 193 gets it wrong, even though they're identical. Even worse, when I run debian/rules install again, lines 192-193 both get it right, and it moves the .py files over. So with git-buildpackage, make is just not in the mood to evaluate the wildcard when I need it to, but it does it right in every other situation. This is also true in Ubuntu Karmic, with Python 2.6 as the default, for which it should evaluate to dist-packages, and does in the echo but not the mv. Any ideas on what might be causing this mysterious behavior? Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ #!/usr/bin/make -f # Made with the aid of debmake, by Christoph Lameter, # based on the sample debian/rules file for GNU hello by Ian Jackson. package=salome SALOME_VERSION=5.1.3 # Support multiple makes at once ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NJOBS := $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) else NJOBS := 1 endif # These are the modules which require build_configure to build. They are # ordered by priority and then dependency: KERNEL through NETGENPLUGIN are # core; COMPONENT, RANDOMIZER and SIERPINSKY are optional # modules; later LIGHT and PYLIGHT are alternate non-CORBA interface shells; # HELLO through PYCALCULATOR are module examples; HXX2SALOME # and XDATA are module development tools. In terms of dependency, KERNEL and # HXX2SALOME are at the bottom, GUI depends on KERNEL, GEOM and MED also depend # on GUI, VISU on MED and GUI, SMESH on GEOM MED and GUI, etc. # Notes: # - MULTIPR requires med-fichier add-ons still under development. # - XDATA is not a normal module, it needs special treatment. # - BLSURFPLUGIN, GHS3D[PRL]PLUGIN and HexoticPLUGIN require non-free # libraries, and will not be part of the Debian package. SALOME_MODULES = KERNEL_SRC_$(SALOME_VERSION) \ GUI_SRC_$(SALOME_VERSION) \ GEOM_SRC_$(SALOME_VERSION) \ MED_SRC_$(SALOME_VERSION) \ VISU_SRC_$(SALOME_VERSION) \ SMESH_SRC_$(SALOME_VERSION) \ NETGENPLUGIN_SRC_$(SALOME_VERSION) \ COMPONENT_SRC_$(SALOME_VERSION) \ RANDOMIZER_SRC_$(SALOME_VERSION) \ SIERPINSKY_SRC_$(SALOME_VERSION) \ HELLO_SRC_$(SALOME_VERSION) \ PYHELLO_SRC_$(SALOME_VERSION) \ CALCULATOR_SRC_$(SALOME_VERSION) \ PYCALCULATOR_SRC_$(SALOME_VERSION) \ HXX2SALOME_SRC_$(SALOME_VERSION) # LIGHT_SRC_$(SALOME_VERSION) \ PYLIGHT_SRC_$(SALOME_VERSION) \ YACS_SRC_$(SALOME_VERSION) \ MULTIPR_SRC_$(SALOME_VERSION) \ XDATA_SRC_$(SALOME_VERSION) \ BLSURFPLUGIN_SRC_$(SALOME_VERSION) \ GHS3DPLUGIN_SRC_$(SALOME_VERSION) \ GHS3DPRLPLUGIN_SRC_$(SALOME_VERSION) \ HexoticPLUGIN_SRC_$(SALOME_VERSION) clean: dh_testdir for skipdir in GEOM_SRC_$(SALOME_VERSION)/src/PARTITION KERNEL_SRC_$(SALOME_VERSION)/DEPRECATED; do \ mv $$skipdir/Makefile.in $$skipdir/Makefile.skip; \ done for salomodule in $(SALOME_MODULES); do \ if [ -e $$salomodule/Makefile ]; then \ $(MAKE) -C $$salomodule maintainer-clean; \ fi; \ rm -f `find $$salomodule -name Makefile.in -print`; \ done if [ -e XDATA_SRC_$(SALOME_VERSION)/Makefile ]; then \ make -C XDATA_SRC_$(SALOME_VERSION) maintainer-clean; \ fi for skipdir in GEOM_SRC_$(SALOME_VERSION)/src/PARTITION KERNEL_SRC_$(SALOME_VERSION)/DEPRECATED; do \ mv $$skipdir/Makefile.skip $$skipdir/Makefile.in; \ done # Remove new .in files rm -f KERNEL_SRC_$(SALOME_VERSION)/bin/runSalome.in \ KERNEL_SRC_$(SALOME_VERSION)/bin/appliskel/env.d/envProducts.sh.in # Restore obsolete files for obsoletefile in `find . -name \*.obs -print`; do \ mv -f $$obsoletefile `echo $$obsoletefile | sed s/.obs//`; \ done rm -f *-stamp dh_clean configure-stamp: dh_testdir # Move aside obsolete files for obsoletefile in KERNEL_SRC_$(SALOME_VERSION)/bin/runSalome \ KERNEL_SRC_$(SALOME_VERSION)/bin/appliskel/env.d/envProducts.sh \ XDATA_SRC_$(SALOME_VERSION)/aclocal.m4 \ XDATA_SRC_$(SALOME_VERSION)/configure \ `find XDATA_SRC_$(SALOME_VERSION) -name Makefile.in -print`; do \ if [ ! -e $$obsoletefile.obs ]; then \ mv $$obsoletefile
Re: Merge of pkg-scicomp into the Debian Science Team
On Wed, 2010-02-10 at 10:56 -0600, Steve M. Robbins wrote: On Wed, Feb 10, 2010 at 09:14:05AM +0100, Andreas Tille wrote: I think it is rather the workflow you have to change which is sometimes much harder. You have to remember to change the Vcs fields in the control files of your packages, upload to a different Vcs, When you say different Vcs, you do mean simply a different subversion or git URL, right? I just want to make sure there is no plan to move all pkg-scicomp SVN packages to git or vice-versa. Conversely, are there tools to migrate SVN history to a git repository? I've come to like git, and would like to migrate my packages. Then again, with team maintenance, it's hard to tell exactly which those are... Will negotiate with other maintainers on each package. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: BLAS/LAPACK implementations
On Mon, 2010-02-08 at 14:44 +0100, Sylvestre Ledru wrote: Hello Adam, Le lundi 08 février 2010 à 08:39 -0500, Adam C Powell IV a écrit : Hello, Some time ago, the netlib and ATLAS implementations of BLAS and LAPACK were ABI-compatible, and used alternatives symlinks to access their different libraries with the same ABI. I didn't know that. That I don't know when it happened, but at some point they diverged, and now the netlib packages have libblas-3gf.so and liblapackgf-3.so, and ATLAS has libblas-3.so and liblapack-3.so. I know that ATLAS has its own API as well, but it was nice back in the day to be able to build to the netlib API, and then swap them back at forth at runtime using update-alternatives. Are you sure ? That API is supposed to be the BLAS one. Of course, I meant that I think ATLAS has its own additional calls, as well as the standard netlib BLAS API. Sorry I wasn't clear. Are they no longer ABI-compatible? Is it possible to get back to the old state of things? As far as I know, they are probably compatible but we would have to dig deeper to make sure of that. I would be happy to put this behavior back, especially since this would fix the first point described here: http://lists.alioth.debian.org/pipermail/pkg-scicomp-devel/2009-October/004582.html Makes sense. Will reply separately to Axel's post... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Salomé packaging
Sorry, forgot to mention a couple of things yesterday. First, the package doesn't build in current unstable, because HDF5 transitioned and MED didn't transition with it. I may be able to help with MED to resolve this, but not until next week. (It builds fine in my unstable chroot updated a few days ago, but that machine doesn't have enough disk space to build the whole thing.) On Mon, 2010-01-25 at 11:45 -0500, Adam C Powell IV wrote: Now for one problem. The VISU module doesn't completely compile, because of a symbol/prototype incompatibility within its CONVERTER library. I don't know quite enough C++ to fix this, can someone help? Second, the log with this build failure is in http://lyre.mit.edu/~powell/salome/salome_5.1.3-3_amd64.build - search for *** . The relevant files are VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.cxx and .hxx. I don't understand why TGetFieldData in the prototype with the vtkDataSet* argument works for both TGetPointData and TGetCellData but the one with the VISU::TFieldList* argument doesn't... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Salomé packaging
Hello again, I now have 10 modules enabled, and have made all but one of the patches upstream-friendly, though I've only uploaded the -3 source package to http://lyre.mit.edu/~powell/salome/ at the moment. Nicolas, can you do me a favor and try to push some of the patches upstream? You can find them in the salome_5.1.3-3.debian.tar.gz file, in the debian/patches directory; I can send them to you individually if you prefer. The patches fall into in several categories, and are separated out by module: * *-safe-include: Eliminate extern C blocks where they are unnecessary -- and even harmful, as they break building with OpenMPI. See the patch head for details. * *-cleanup: Fixes for compiler bugs which break the build with recent compilers. * *-hdf5-needs-mpi: The HDF5 header and library files need MPI in order to work, so this includes the MPI -I and -L flags in with those of HDF5, and puts MPI checks before HDF5 ones. * *-mpich-mpi: Replace MPICH checks with MPI checks, as I've made it compatible with OpenMPI. * *-use-gui-check: Use check_GUI.m4 in the GUI module directory, instead of the rewritten version of that file in several other module directories. * *-build-in-tree: Debian requires that the whole package build first, then install. These patches make this possible. These patches will not only make it easier to maintain the package, but will assist anyone building Salomé on Debian/Ubuntu in the future. And all of them should preserve the ability to build as before, let me know if that is not the case. Other specific patches: * kernel-remove-mpi-undefs: Not sure why these undefs are there, they break OpenMPI compatibility. * kernel-occ-includes: Search for OpenCASCADE header files both in the default location when building OCC from source and also in the Debian/Ubuntu package location. * hxx2solame-destdir: Use DESTDIR for install. * med-scotch: Search for Scotch files both in the default location when building Scotch from source and also in the Debian/Ubuntu package location. * med-missing-libs: Add the MED libraries to the mprint_version link command. * visu-flags-typo: Fix incorrect automake flags variable. * kernel-mpi-libs: This is the one which should *not* go upstream, as it tests for the Debian-specific MPI alternative symlink lib names. Now for one problem. The VISU module doesn't completely compile, because of a symbol/prototype incompatibility within its CONVERTER library. I don't know quite enough C++ to fix this, can someone help? Before upload, I think this needs a few more modules, a full copyright audit, and at least a working GUI shell. I've only done the audit for the first two modules (KERNEL and HXX2SALOME), and haven't tried running the shell yet... Cheers, Adam On Sun, 2010-01-10 at 17:53 -0500, Adam C Powell IV wrote: On Sun, 2010-01-10 at 23:28 +0100, Nicolas Chauvat wrote: Hi, As part of the OpenHPC project[1], Logilab commited itself to package Salomé for Debian. We had seen the great work you have done and are glad that you are resuming it. Wow, thank you for this terrific news! Have you started to forward-port the old patches to a new package, or are you using a different approach? A correction: most of my work on this was two years ago, not three. André Espaze has been developing a connector between Salomé and Code_Aster for the past few months. He is about to continue his work with the packaging of Salomé. He will have the help of Pierre-Yves David. We also have a Debian developer on the team, Alexandre Fayolle, but he will not have a lot of time for this particular project in the upcoming months. Okay. Let me know how I can best fit in with your plans for this project. I am cc'ing every person involved to make sure everyone can get in touch easily. Is debian-science the best place to discuss this topic or should we take the discussion off-list? I think this list is pretty good as long as we are talking about generalities, as I think some of the people on the list will have good suggestions. When we start to get into the details of patches and the package, maybe it will make sense to go off-list. Hopefully, the fact that we have been working with upstream for years will help us get this work done more easily. This is terrific. My patches are Debian-specific, and need some work to make them fit the needs of both upstream and Debian. This gives me hope that doing that work will help to actually get the patches into the upstream source! This is the best news I've heard in a long time. Thanks again, I look forward to working with you. Regards, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http
Salomé packaging
Greetings, For those interested, I'm re-doing the Salomé .deb I started three years ago. Salomé is a finite element pre-post processing framework, with a lot of other things in there as well. Though some things have improved between version 3.2.6 and 5.1.3, many have not, so although this likely won't take 100+ hours like the last one did, it's taking more effort than I can give to it. I've got five modules configuring, compiling and installing, but will not be able to work on it for the next couple of weeks. rantAmong other things, it needs major updates for modern compilers, for OpenMPI, and for new versions of other packages. It amazes me that upstream can get it to build at all, but then, they seem to only build to certain particular narrow (and old) platforms/targets, and don't accept outside patches (never looked at the 50+ I generated last time), so it is not surprising that this is the result./rant Because I can't do the whole package, I'm putting up the progress I've made thus far at http://lyre.mit.edu/~powell/salome/ for others to work on. The -2 .dsc and .debian.tar.gz files are there, the rest will follow later today. I'm reluctant to put it in git until an audit turns up the non-free and other troublesome files, to avoid having to change the upstream branch and dfsg tarball too many times. (I've only audited the first two modules thus far, which seem dfsg-clean.) Speaking of which, random -legal question: one directory has a .sxw, a .pdf and a .ps. The .pdf and ps files are clearly generated from the sxw. Does a .dfsg tarball have to remove the .pdf and .ps files, and somehow re-generate them from the .sxw, or can it just leave them in? Is there a way to script OO.o to generate a .pdf from a .sxw? Note: the files whose debian/patches/series entries are commented are old patches from 3.2.6 which I haven't backported. They're there to provide some guidance into how to fix problems related to those I fixed back then. The uncommented patches are new, and many of them are ready to go to upstream. A few others need only to be made more general before going upstream, e.g. test for files in dependency packages both where upstream installs them and where Debian installs them, etc. To summarize, I need help with the following: * Copyright audit of the tree * Getting the other modules to configure, compile and install * Making patches upstream-compatible, and sending them to upstream Hopefully in a month or two we'll have both a good Salomé package in Debian, and a more enlightened upstream! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Salomé packaging
On Sun, 2010-01-10 at 23:28 +0100, Nicolas Chauvat wrote: Hi, On Sun, Jan 10, 2010 at 02:29:03PM -0500, Adam C Powell IV wrote: For those interested, I'm re-doing the Salomé .deb I started three years ... Because I can't do the whole package, I'm putting up the progress I've ... To summarize, I need help with the following: * ... * Getting the other modules to configure, compile and install * Making patches upstream-compatible, and sending them to upstream As part of the OpenHPC project[1], Logilab commited itself to package Salomé for Debian. We had seen the great work you have done and are glad that you are resuming it. Wow, thank you for this terrific news! Have you started to forward-port the old patches to a new package, or are you using a different approach? A correction: most of my work on this was two years ago, not three. André Espaze has been developing a connector between Salomé and Code_Aster for the past few months. He is about to continue his work with the packaging of Salomé. He will have the help of Pierre-Yves David. We also have a Debian developer on the team, Alexandre Fayolle, but he will not have a lot of time for this particular project in the upcoming months. Okay. Let me know how I can best fit in with your plans for this project. I am cc'ing every person involved to make sure everyone can get in touch easily. Is debian-science the best place to discuss this topic or should we take the discussion off-list? I think this list is pretty good as long as we are talking about generalities, as I think some of the people on the list will have good suggestions. When we start to get into the details of patches and the package, maybe it will make sense to go off-list. Hopefully, the fact that we have been working with upstream for years will help us get this work done more easily. This is terrific. My patches are Debian-specific, and need some work to make them fit the needs of both upstream and Debian. This gives me hope that doing that work will help to actually get the patches into the upstream source! This is the best news I've heard in a long time. Thanks again, I look forward to working with you. Regards, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: MPI implementations in squeeze
On Tue, 2009-11-10 at 16:27 +0100, Michael Banck wrote: On Tue, Nov 10, 2009 at 09:19:11AM -0500, Adam C Powell IV wrote: On Mon, 2009-11-09 at 16:47 -0800, Nicholas Breen wrote: * is it too late in the release cycle to propose this as a release goal? should squeeze+1 be the target instead? squeeze+2? I think it's too late for squeeze, but squeeze+1 should definitely be doable. How many packages are affected? I think your previous email best answered that question. Squeeze freeze is several months away still. I am not sure about release-goal freeze, but even then, it could be considered an inofficial release goal among debian-science at least. Oh, right. For some reason my mental calendar still has late '09 as the release goal date. I'm all for it then, at least unofficially. The other issue would be rebuilding all of the mpi-defaults packages at least on lam architectures when/if we decide to switch to mpich2. Count my vote in support of such a switch, which might be worth as much as $0.03-.04 since I wrote the original mpi-defaults. :-) -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: MPI implementations in squeeze
I generally agree, just a quick nit-pick/clarification: On Tue, 2009-11-10 at 20:56 +0100, Manuel Prinz wrote: * Alternatives need to be fixed. Besides what the bugs that Nicholas referenced say, there are two other issues with those: First, the priorities do not match the reality (Open MPI being the default / recommended implementation to use), and second, that mpi.so is also in the alternatives, which is wrong in every respect and has bother me for a very long time now. The implementations are not ABI-compatible in any way, and we really need to get rid of that. The .so alternatives symlinks only require that the libraries be API-compatible, which they are (or if not, it's a bug, since they're supposed to follow the MPI standard). That's why these links, and plain .so links in general, are in the -dev packages, not the shlib packages. It should be possible to compile any MPI program's source code against any implementation by linking -lmpi -lmpi++ etc. Then the resulting binary, shlib etc. includes the soname specific to the library it linked with, e.g. libopen-rte.so.0 . So if it's in a Debian package, the resulting binary depends on the ABI-correct library package, e.g. libopenmpi1 . If this still doesn't make sense, the libtool online documentation is pretty clear. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#549238: ITP: elmerdoc -- Elmer FEA documentation
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-science@lists.debian.org Package name: elmer-doc Version: 2009.09.22 Author: CSC – IT Center for Science, Finland License: CC-BY-ND 3.0 URL: http://www.csc.fi/elmer/ Description: Documentation for Elmer finite element analysis package Elmer is an open source mutiphysics simulation package developed by CSC in collaboration with Finnish universities, research institutes and industry. It includes physical models of fluid dynamics, structural mechanics, electromagnetics, heat transfer and acoustics, for example. These are described by partial differential equations which Elmer solves by the Finite Element Method (FEM). This non-free package will contain the PDF documentation files for Elmer which are available under the Creative Commons Attribution-No Derivative Works 3.0 License. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: OpenMPI transition
On Mon, 2009-06-01 at 19:00 -0400, Adam C Powell IV wrote: Hi, Last week OpenMPI transitioned to a new shared library package, reflecting an ABI change to version 1.3.x (which wasn't reflected in the shared lib package name of 1.3-2). From what I can see, it looks like there are at least three things holding up this transition: the alpha build of openmpi, the hppa build of petsc, and the alpha upload of suitesparse (built last week). There may of course be others I'm not seeing. It doesn't look like there's been any attempt to build openmpi, which is odd, because the alpha buildd has built a bunch of other stuff. The alpha upload of suitesparse is also odd: it seemed to build just fine last Wednesday, but is just sitting there without upload. HPPA and petsc is two issues: the first two attempts failed due to a stochastic failure to make a file (succeeded in one out of three tries, very odd, bug 529485), the next three due to failed Java dependencies. The Java deps are not working in petsc now, so I could just disable them by removing the babel-1.2.0 build-dep. But that would impose another ten-day delay on this transition. So the question is: should I make this change in PETSc in the hopes that it will un-stick stuff as soon as the alpha buildd gets its act together, or leave it, and ... hope that other intervention from on high makes the transition go through in less than ten days? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: OpenMPI transition
On Tue, 2009-06-16 at 20:10 +0200, Luk Claes wrote: Adam C Powell IV wrote: On Mon, 2009-06-01 at 19:00 -0400, Adam C Powell IV wrote: Hi, Last week OpenMPI transitioned to a new shared library package, reflecting an ABI change to version 1.3.x (which wasn't reflected in the shared lib package name of 1.3-2). From what I can see, it looks like there are at least three things holding up this transition: the alpha build of openmpi, the hppa build of petsc, and the alpha upload of suitesparse (built last week). There may of course be others I'm not seeing. There are quite some others [1]. Ah, never knew about that, thanks! It doesn't look like there's been any attempt to build openmpi, which is odd, because the alpha buildd has built a bunch of other stuff. The alpha upload of suitesparse is also odd: it seemed to build just fine last Wednesday, but is just sitting there without upload. openmpi given back and suitesparse scheduled for upload Good, thank you. HPPA and petsc is two issues: the first two attempts failed due to a stochastic failure to make a file (succeeded in one out of three tries, very odd, bug 529485), the next three due to failed Java dependencies. The Java deps are not working in petsc now, so I could just disable them by removing the babel-1.2.0 build-dep. But that would impose another ten-day delay on this transition. Please upload a fix with urgency medium. Just did, thanks again! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Visualising multi-variable higher-degree polynomials?
On Sat, 2009-06-06 at 21:35 -0400, Christopher Olah wrote: Thanks for your responses! David Joyner Wrote: http://www.sagemath.org/doc/reference/sage/plot/plot3d/implicit_plot3d.html sage's implicit plots seem perfect. Thanks! Kapil Hari Paranjape Wrote: Such plots are (in general) a (rather difficult) problem in real algebraic geometry so it is unlikely that you will have a generic algorithm that Just Works! Couldn't you just use a 3D scalar field with only boolean values (check if each point matches)? I'd been planning to write such a program if I couldn't find a suitable solution... I don't think you want boolean. I think you want to express it in terms of f(x,y) or f(x,y,z) = 0. In your example: y^4 + y^3 - x^2 - 3x - z - z^8 = f(x,y,z) = 0 Then calculate the value of f(x,y,z) with scalar (not boolean) values on a grid and plot its zero contour. With a decent grid, linear interpolation on the edges of cells with points above and below it give you a set of intercepts which form a good approximation of the surface. There are numerous packages which can do this, in parallel too. POVray is one, and I implemented it in Illuminator in not too many lines if you want some source code (using PETSc objects). For more accuracy, use Newton's method instead of linear interpolation to find the root on each edge. Then bisect the edges of your new surface to make more points, and refine each of those along the function gradient to the nearest root, and repeat the edge division. I don't know of any package specifically designed for that though. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
OpenMPI transition
Hi, Last week OpenMPI transitioned to a new shared library package, reflecting an ABI change to version 1.3.x (which wasn't reflected in the shared lib package name of 1.3-2). I went to rebuild my spooles package, only to find that there is already a rebuild versioned 2.2-6+b1. However, superlu has not been rebuilt, and is a reverse-depends for a bunch of my packages. Was the spooles rebuild automatic, or someone's binNMU? Should I do a binNMU for superlu, or wait for that to happen somehow automatically? What about my other reverse-depends? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: OpenMPI transition
On Tue, 2009-06-02 at 09:52 +0200, Manuel Prinz wrote: Am Montag, den 01.06.2009, 19:00 -0400 schrieb Adam C Powell IV: Last week OpenMPI transitioned to a new shared library package, reflecting an ABI change to version 1.3.x (which wasn't reflected in the shared lib package name of 1.3-2). I went to rebuild my spooles package, only to find that there is already a rebuild versioned 2.2-6+b1. However, superlu has not been rebuilt, and is a reverse-depends for a bunch of my packages. Was the spooles rebuild automatic, or someone's binNMU? Should I do a binNMU for superlu, or wait for that to happen somehow automatically? What about my other reverse-depends? The rebuilds were done by the release team, it's a regular transition they know about. As it seems, I missed communicating it to the maintainers of dependant packages. Sorry for that! :( No problem, thanks very much! I'm sorry if some software became uninstallable! We're trying to sort it out ASAP. No problem. Transitions are never easy. Thanks for all of your hard work! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
New mpi-defaults BLACS and ScaLAPACK call for testing
Hello, I've just finished re-doing the blacs and scalapack packages using mpi-defaults. The results are in http://lyre.mit.edu/~powell/mumps/ (since I'm using them for my not-yet-finished MUMPS package). They are NMUs approved by the maintainer to close bugs 491028 and 491105. If you maintain reverse-depends, please adjust and test. I've run the package self-tests with mpirun -np 4 test test.out (yes I still use tcsh), and most pass, though some segfault right away (BLACS c shared, x*gemr), and others infinite loop and have to be killed... All results are in: http://lyre.mit.edu/~powell/mumps/tests/ I'll wait a week and if the packages are good will upload. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Recent ARPACK package
On Sun, 2008-11-23 at 16:24 +0100, Daniel Leidert wrote: Hi Adam, I CCed you, because this information might be of some importance to you. Am Donnerstag, den 06.11.2008, 19:30 -0500 schrieb Adam C Powell IV: Where can I get a recent ARPACK package? I know it's been removed from main, but thought it should go into non-free soon, as it's been about three months. Following [1][2] the Rice-BSD license has been modified and now it seems, that it is just a normal BSD 3-clause license. So ARPACK could go back to main. [1] http://bugs.debian.org/491794 (last message still missing) [2] http://www.caam.rice.edu/software/ARPACK/RiceBSD.txt Thanks! I had already heard about this, and plan an upload today. This also means that my Elmer package can go into main (after ARPACK lands). Yay! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ITP: mpi-defaults -- Meta-packages depending on appropriate MPI -dev and -bin packages for each platform
Hi again, and sorry for causing accidental posts to
[EMAIL PROTECTED] -- I don't know how to do X-Debbugs-CC in
Evolution.
On Thu, 2008-11-20 at 12:35 +0100, Ondrej Certik wrote:
On Thu, Nov 20, 2008 at 11:14 AM, Manuel Prinz [EMAIL PROTECTED] wrote:
Am Mittwoch, den 19.11.2008, 09:05 -0600 schrieb Dirk Eddelbuettel:
I think we should put either debian or mpi first. How about
mpi-default-{dev,bin}
or even
mpi-debian-default-{dev,bin}
to make it even clearer that it is just 'us' (ie Debian) defining a default
for us, rather misconstruing that more than two decades (I'm guessing) of
competing mpi implementations have ended ? ;-)
Good guessing. But I'm confident we can solve that problem in one way or
another in a shorter time frame.
Comments ?
Well, why not debian-default-mpi-{bin,dev}? ;)
Seriously, I do not care that much. A name is a name. If we're lucky,
the package might be gone by release of Squeeze.
I like Dirk's suggestion more:
mpi-default-{dev,bin}
But as you said, a name is just a name.
I like this suggestion, and have just posted the new package for comment
in the alioth debian-science repository:
git://git.debian.org/git/debian-science/packages/mpi-defaults.git
http://git.debian.org/?p=debian-science/packages/mpi-defaults.git;a=summary
It uses the PETSc system, which Build-Depends on an arch-dependent MPI
implementation, then rules uses readlink to determine which one is the
default alternative, and sets substvars appropriately, whether openmpi,
lam, or mpich*. That way, if we want to change the defaults, we just
need to change the Build-Depends in control. In many other ways it
follows the example of java-common.
Also, I made it GPL 2+, and made the copyright in the model of
java-common.
Feedback anyone?
Cheers,
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
Re: ITP: mpi-defaults -- Meta-packages depending on appropriate MPI -dev and -bin packages for each platform
On Thu, 2008-11-20 at 16:48 +0100, Manuel Prinz wrote: Am Donnerstag, den 20.11.2008, 09:45 -0500 schrieb Adam C Powell IV: Feedback anyone? I was just wondering why you depend on debhelper = 3, while compat is set to 5. Souldn't you depend on = 5 then? Not sure. My reasoning was that it doesn't require any capabilities of debhelper 3. But I think you're right, that's inconsistent and should be changed. All other things look good, though I did not test it yet. Thanks for your work! No problem, it was quite simple. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
ITP: mpi-defaults -- Meta-packages depending on appropriate MPI -dev and -bin packages for each platform
Package: wnpp Severity: wishlist Package name: mpi-defaults Version: 0.1 Author: Debian Science Team [EMAIL PROTECTED] License: Undetermined This new source package will produce two binary meta-packages: default-mpi-dev and default-mpi-bin which depend on libopenmpi-dev and openmpi-bin respectively on the platforms where they are available, and lam4-dev and lam-runtime on the others. A third default-mpi-dbg might also depend on libopenmpi-dbg, though there is no corresponding lam package. Background: http://lists.debian.org/debian-science/2008/10/msg00097.html -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: building package with different libs
On Tue, 2008-11-18 at 23:06 +0100, Manuel Prinz wrote: [ Sorry for the long email! I wanted to express my view and as a non-native speaker, it's not always easy to be precise. Hope you don't mind. ] No problem at all! Am Dienstag, den 18.11.2008, 08:05 -0500 schrieb Adam C Powell IV: On Sat, 2008-11-15 at 21:04 -0600, Dirk Eddelbuettel wrote: On 14 November 2008 at 23:12, Steve M. Robbins wrote: | While reading this thread, however, I had an idle thought. Could we | prepare an mpi-default-dev or sensible-mpi-dev package for us to | build-depend on? This would be something like the gcc-defaults | package and simply depend on the appropriate -dev pacakges (OpenMPI on | some architectures, LAM on the rest). | | The idea is to put the messy details about which architectures support | OpenMPI and which use LAM in one place. Sounds good to me, and I am cc'ing the pkg-openmpi list. I won't have spare cycles to work on it, but it strikes as a fundamentally sound suggestion. I'm all set to make this happen. Manuel, you mentioned getting OpenMPI to work on all arches as your top priority; what's your expected timeframe? I know, when it's ready or real soon now. But if this will happen in plenty of time for packages to transition before squeeze, then there's no point in doing mpi-defaults. It's hard to say at the moment because I do not have all the details yet. Personally, I'd like to have support on all arches before the release of Squeeze, I hope around summer next year, though this might be a bit optimistic. I'm currently in the process of getting details about what is and what needs to be done; not just with getting OpenMPI to build on all arches, but how we can handle the other open issues with mixing different MPI implementations. What we have so far: We have an untested patch to make OpenMPI build on MIPS. It did not apply to the current upstream version and I lately tried to update it to the current upstream release. I asked for feedback but did not get any so far. (I guess I'll try to build OpenMPI on a MIPS as soon as I have some spare cycles.) We also have a patch that makes use of libatomic-ops on currently unsupported architectures. It is not well tested and may have some itches we need to scratch but it may be enough to get OpenMPI to run on all arches. Thanks to everyone involved in providing patches and solutions so far! It is very much appreciated. So, the honest answer is: I do not have a clue. As said, I'm working on it and it is one of the most important things in my Debian work at the moment. But we heavily rely on the porters, need testing and need to get all MPI maintainers together to sort some other issues out. This takes time. Nevertheless, I'm optimistic that we can sort this out before Squeeze, including the transitions. Okay. I spent a good while this Spring trying to get libatomic-ops to work, and at this point it doesn't work *anywhere*, and I don't know enough assembly to make it work. And that's on the best-case arches, i386 and amd64, which are missing just one or two primitives each. ARM, Sparc and others are nowhere near there, and I don't recall seeing anything for s390. Congratulations on the MIPS patch! I wish you well on the others. But won't be chomping at the bit (sorry, English term like a horse biting the metal bar in its mouth waiting to jump out and start the race)... I do not oppose to an mpi-default-dev package, I thought of that myself as well. Nevertheless, I also think we can sort that out in time and live with the situation as is until then. I will not stop anyone from implementing it, though. It might assist developers a lot and is surely a Good Thing. But it's just a part of the problem. I also think that a huge part of the problem is that MPI maintainers did not talk to each other so far; at least such efforts are not known to me. OpenMPI did not see much love in Debian for quite some time and we just started to get it back on track. We now have a well working team (Thanks, dudes!) and that's why I'm optimistic that we can now do the next steps and join the efforts of everyone involved in MPI maintainance in Debian. Okay, I've prepared an ITP and will send it in, and upload, if we decide to go that route. I would suggest that I collect some more information, write it up and we discuss things then, so we can agree which road is the best to take. (I do not know where the appropriate place for that is, though.) I can't promise anything but hope to have that finished within the next two weeks. Does this sound acceptable? Sounds good to me. And while we're at it, it may also make sense to try to come to a consensus of our MPI 'preferences' within Debian. I.e. which one should be the default and own the 'highest' alternatives level. Good point. I'm happy to change mpich to below the priority of OpenMPI, maybe
Re: [Elmerdiscussion] Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
Hello again, On Thu, 2008-11-13 at 15:10 -0500, Adam C Powell IV wrote: On Thu, 2008-11-13 at 08:05 -0500, Adam C Powell IV wrote: [snip] Thank you. I'm afraid I'm already well-enough along that the only issue remaining is finding Scotch functions corresponding to METIS_MeshPartNodes and METIS_MeshPartDual. I'm in contact with upstream, which is helping with this (off-list). I've posted my first two versions 5.4.1-1 and 5.4.1.dfsg-1 at http://lyre.mit.edu/~powell/elmer/ . The former includes the full source, and works (as far as I can tell), but doesn't have the versioned shared library. The latter omits mathlibs, umfpack and elmergrid/src/metis, and has a complete copyright file for what's left, but ElmerGrid linking fails because of the missing Metis functions as mentioned. I've just posted .dfsg-2 which is DFSG-compliant (doesn't include metis) and includes a working -- but not complete -- ElmerGrid. That is, ElmerGrid can't do METIS-style partitioning using the MeshDual and MeshNodal methods because Scotch doesn't support them, though it can do the other three METIS partition styles. I also reversed the order of the rpath and shlibs patches, so the attached shlib patch should be acceptable for upstream adoption. I built it also for 32-bit. They're up in my Debian Lenny repository at opennovation.org. I'm building Ubuntu Hardy 64- and 32-bit as well. I have not patched it to work with Debian's UMFPACK. If I need it, I'll take care of that; otherwise I'll wait for the next Elmer release. The only two ways to get around this are: * Get the ARPACK people to drop the non-free requirements of their license (see http://bugs.debian.org/491794 ). * Change the license of Elmer either to something like LGPL or to grant an explicit GPL exception to link with ARPACK (and maybe Metis?). Both of these are, of course, beyond the scope of this maintainer... :-( This is still needed before I can upload to Debian. Somehow Francesco's post didn't get to the Elmer list, so I'll point out that the FSF's linking exception example is at: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs Note that there are different texts for GPLv2 and v3; Elmer is I believe currently under v2. Also, this applies to the elmergrid directory re Metis and fem directory re ARPACK. These copyright notices typically go in the AUTHORS file. Share and enjoy, and please let me know if there are any errors. Cheers, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ --- elmerfem-5.4.1/fem/src/Makefile.am~ 2008-11-10 17:07:18.0 -0500 +++ elmerfem-5.4.1/fem/src/Makefile.am 2008-11-10 17:06:59.0 -0500 @@ -79,7 +79,8 @@ libelmersolver$(SHL_EXT): $(SOLVEROBJS) binio/libbinio.a $(RM) $@ - $(SH_LD2) $(RPATH_ELMER) $(SH_LDFLAGS) $(B64FLAGS) $(LDFLAGS) -o $@ $(SOLVEROBJS) $(SOLVER_LIBS) -L. -Lbinio -lbinio + $(SH_LD2) $(RPATH_ELMER) $(SH_LDFLAGS) $(B64FLAGS) $(LDFLAGS) -Wl,-soname,libelmersolver-5.4.1.so -o libelmersolver-5.4.1.so $(SOLVEROBJS) $(SOLVER_LIBS) -L. -Lbinio -lbinio + ln -s libelmersolver-5.4.1.so $@ .$(OBJEXT).$(SHLEXT): @@ -186,7 +186,7 @@ $(CP) ElmerSolver$(EXEEXT) $(DESTDIR)$(prefix)/bin $(CP) ViewFactors$(EXEEXT) $(DESTDIR)$(prefix)/bin $(CP) GebhardtFactors$(EXEEXT) $(DESTDIR)$(prefix)/bin - $(CP) libelmersolver$(SHL_EXT) $(DESTDIR)$(prefix)/lib + $(CP) -a libelmersolver*$(SHL_EXT) $(DESTDIR)$(prefix)/lib $(CP) elmerf90 elmerf90-nosh elmerld $(DESTDIR)$(prefix)/bin if USE_MPI $(CP) ElmerSolver_mpi$(EXEEXT) $(DESTDIR)$(prefix)/bin signature.asc Description: This is a digitally signed message part
Re: building package with different libs
On Fri, 2008-11-14 at 23:12 -0600, Steve M. Robbins wrote: Howdy, On Thu, Oct 30, 2008 at 07:48:19PM -0400, Adam C Powell IV wrote: [Copying -beowulf as there's likely some interest there as well.] On Thu, 2008-10-30 at 15:21 +0100, Manuel Prinz wrote: When building against OpenMPI, there are a few choices: 1. Do not build packages using OpenMPI on the unsupported arches. 2. Build against OpenMPI on the supported ones, fall back to LAM on the unsupported ones. [ ... ] As for -lam where there's no openmpi, I only know of petsc and babel. I have subsequently adopted this approach for minc, which uses MPI via hdf5. I will likely adopt it for boost, too, unless someone has a better idea. And ARPACK as well... While reading this thread, however, I had an idle thought. Could we prepare an mpi-default-dev or sensible-mpi-dev package for us to build-depend on? This would be something like the gcc-defaults package and simply depend on the appropriate -dev pacakges (OpenMPI on some architectures, LAM on the rest). The idea is to put the messy details about which architectures support OpenMPI and which use LAM in one place. That's a terrific idea. Build-Depends are not a big problem in terms of LAM vs. OpenMPI, because one can use architecture-dependent lists. But for dependencies of the -dev package (libpetsc-dev etc.), things are more tricky; you either need to make a substvar, or use things like type-handling's not+mipsel etc. Having an mpi-default-dev would make things a lot easier and clearer in both cases. Thanks! I can go ahead and take care of this later this week unless someone doesn't think it's a good idea. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
On Fri, 2008-11-14 at 21:50 +0100, Francesco Poli wrote: On Fri, 14 Nov 2008 08:57:40 -0500 Adam C Powell IV wrote: [...] On Thu, 2008-11-13 at 23:49 +0200, Mikko Lyly wrote: [...] Indeed, you're fine as far as your distribution is concerned; as far as I can tell no GPL code in the fem directory written by others which is linked to ARPACK. As the Elmer copyright holder, you just need to abide by the ARPACK license, and can do whatever you want with the Elmer code. But if Debian redistributes it, and the code changes hands, the owner of the Elmer copyright can in theory restrict Debian from distributing it. [...] LGPL for Elmer is unfortunately not possible at the moment, but an GLP exception might be taken under consideration. How would you like to see the exception be documented for being compatible with Debian policies? I'm afraid I don't have enough experience with this to give good advice here. Can someone on debian-legal perhaps provide an example of a copyright statement which provides such an GPL exception? Hi Adam, hi everyone else! Hi Francesco! [I am keeping you and the other addresses in Cc:, since you asked to be Cc:ed in the past and I suppose the other people are not subscribed to debian-legal] Thanks, no need for me since I subscribe to debian-science. If I understand correctly, the issue is that Elmer, which is distributed under the terms of the GNU GPL, links against ARPACK, which is available under GPL-incompatible and non-free terms. The distributability issue may be solved with a GPL exception granted from Elmer copyright holders, as long as no other purely GPL'ed code is included in or linked with Elmer. That is to say, *each* copyright holder of GPL'ed code included in or linked with Elmer must agree with the GPL exception. To clarify: each copyright holder of GPL'ed code in the binary/binaries which link with ARPACK needs to agree. As mentioned, my review of the fem directory showed that CSC owns the copyright to all of the code in question (ElmerSolver, libelmersolver, all of the equation plugins). Assuming that all such copyright holders agree, the canonical example GPL linking exception is detailed at http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs Thanks, I was not aware of this. On the other hand, I think you (Adam) are aware that this solution would force Elmer to be placed in the contrib Debian archive (rather than in main), Yup, my pre-upload package is already in contrib. with the additional inconvenience that ARPACK has now been removed from Debian: http://bugs.debian.org/497900 I re-uploaded it into non-free a couple of days ago. I would recommend getting in touch with ARPACK upstream maintainers and persuading them to relicense ARPACK under DFSG-free and GPL-compatible terms (a 3-clause BSD license would be an optimal suggestion). Indeed, will do. I hope this helps. Disclaimers: IANAL, TINLA, IANADD, TINASOTODP. It helps a lot! Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
On Thu, 2008-11-13 at 08:05 -0500, Adam C Powell IV wrote: On Thu, 2008-11-13 at 09:55 +, Antonio Amorim wrote: Dear Colleagues, I have previously created a debian package for Elmer that does not claim to fulfill the official debian policies but might be useful to trigger the debian work. The package is available as source and for the amd64 architecture. It is available form the repositories: deb http://mirror.sim.ul.pt/debian-paipix etch main contrib non-free where one can replace deb by deb-src and etch by lenny or sid. In the backport to etch, I also backported libqt4 that is available from the same repository. The packages are elmerfem and elmerfem-doc. All packages are build under pbuilder so the dependencies should be Ok. Thank you. I'm afraid I'm already well-enough along that the only issue remaining is finding Scotch functions corresponding to METIS_MeshPartNodes and METIS_MeshPartDual. I'm in contact with upstream, which is helping with this (off-list). I've posted my first two versions 5.4.1-1 and 5.4.1.dfsg-1 at http://lyre.mit.edu/~powell/elmer/ . The former includes the full source, and works (as far as I can tell), but doesn't have the versioned shared library. The latter omits mathlibs, umfpack and elmergrid/src/metis, and has a complete copyright file for what's left, but ElmerGrid linking fails because of the missing Metis functions as mentioned. Both are supposedly in section contrib. The first should really be non-free because of the inclusion of Metis. I'm afraid I realized *after* putting a lot of time into this that neither one is acceptable to Debian, because Debian considers ARPACK to be non-free, and will almost certainly refuse to distribute a GPL program linked to a non-free library. The only two ways to get around this are: * Get the ARPACK people to drop the non-free requirements of their license (see http://bugs.debian.org/491794 ). * Change the license of Elmer either to something like LGPL or to grant an explicit GPL exception to link with ARPACK (and maybe Metis?). Both of these are, of course, beyond the scope of this maintainer... :-( In the meantime, feel free to enjoy and add to these two packages. I'd welcome any patches to improve them. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Recent ARPACK package
On Mon, 2008-11-10 at 18:10 +0100, Daniel Leidert wrote: Am Montag, den 10.11.2008, 10:05 -0500 schrieb Adam C Powell IV: On Thu, 2008-11-06 at 22:21 -0500, Adam C Powell IV wrote: On Fri, 2008-11-07 at 03:29 +0100, Daniel Leidert wrote: Am Donnerstag, den 06.11.2008, 19:30 -0500 schrieb Adam C Powell IV: Where can I get a recent ARPACK package? I know it's been removed from main, but thought it should go into non-free soon, as it's been about three months. http://svn.debian.org/wsvn/pkg-scicomp/arpack/trunk/?rev=0sc=0 Just needs to be adjusted for non-free. Great, thanks. (Should have looked there...) Anyone mind if I adjust and upload? One other thing: why is the ARPACK tree unpacked in the root and a separate directory? The debian/rules file has no references to the ARPACK directory. Can I just wipe it out? Think so. But you should check, if it is maybe cleaner to remove the copy in the root directory and use the stuff in ARPACK, because this package is a compilation of ARPACK and PARPACK. But some time has passed since I touched the package, so you need to check this carefully. Thanks. There are actually some differences, like second in ARPACK is arscnd in root. There are a lot of diffs vs. upstream, where can I get your .orig.tar.gz or a procedure for making it from upstream tarballs? Some patches (quilt) are applied to both copies of ARPACK and some changes are not done via patch system (IIRC - just compare the copies in the root path and in ARPACK/). IMHO this situation should/could be improved too. Neither debian/rules nor any Makefile references ARPACK, but you're right, a couple of patches apply to that directory. Like second is changed to secnd2 in ARPACK but not root, and noetime applies to ARPACK but not root. I'll try to figure it out and make it work. But I really need the .orig.tar.gz which is not on any of the mirrors since it's been removed. Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
ITP: Elmer -- Finite element software for multiphysics problems
Package: wnpp Severity: wishlist Package name: elmerfem Version: 5.4.1 Author: CSC -- IT Center for Science Ltd (Finnish Ministry of Education) License: GPL URL: http://www.csc.fi/elmer/ Elmer is an open source mutiphysics simulation package developed by CSC in collaboration with Finnish universities, research institutes and industry. It includes physical models of fluid dynamics, structural mechanics, electromagnetics, heat transfer and acoustics, for example. These are described by partial differential equations which Elmer solves by the Finite Element Method (FEM). Elmer uses METIS (or its free counterpart Scotch) for mesh partitioning, and (P)ARPACK, UMFPACK, BLAS/LAPACK and hypre to solve the sparse linear systems resulting from FEM discretization. It includes pre- and post-processors, and several examples illustrating simulation of various physical phenomena. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ITP: Elmer -- Finite element software for multiphysics problems
On Mon, 2008-11-10 at 22:18 +0100, Thomas Weber wrote: Hi, I don't have anything to say about Elmer, but ... On Mon, Nov 10, 2008 at 02:01:52PM -0500, Adam C Powell IV wrote: Elmer uses METIS (or its free counterpart Scotch) for mesh partitioning, do you have some experience with using Scotch? Is it a drop-in replacement for METIS? Every code I've tried seems to build with Scotch instead of METIS, just use -lscotchmetis -lscotch -lscotcherr and you should be all set. As for running, I have tried libMesh, which works, but is very slow. Then again, using METIS with it is probably also very slow, I didn't try it. So in my experience, it is fully compatible. The deal.II authors modified an aclocal.m4 patch I sent them to look for METIS, and if absent, then look for Scotch. It's in their SVN now, and I'll dig it out when I get some time. It might be helpful to have this m4 file in libscotch-dev at some point... Cheers, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Recent ARPACK package
On Mon, 2008-11-10 at 22:10 +0100, Daniel Leidert wrote: Am Montag, den 10.11.2008, 13:03 -0500 schrieb Adam C Powell IV: On Mon, 2008-11-10 at 18:10 +0100, Daniel Leidert wrote: Am Montag, den 10.11.2008, 10:05 -0500 schrieb Adam C Powell IV: [..] One other thing: why is the ARPACK tree unpacked in the root and a separate directory? The debian/rules file has no references to the ARPACK directory. Can I just wipe it out? Think so. But you should check, if it is maybe cleaner to remove the copy in the root directory and use the stuff in ARPACK, because this package is a compilation of ARPACK and PARPACK. But some time has passed since I touched the package, so you need to check this carefully. Thanks. There are actually some differences, like second in ARPACK is arscnd in root. There are a lot of diffs vs. upstream, where can I get your .orig.tar.gz or a procedure for making it from upstream tarballs? Not my :) I just helped getting it into some better shape. The upstream sources should be here: http://www.caam.rice.edu/software/ARPACK/download.html. But Christophe Prud'homme AFAIK put them together. Thanks. I had downloaded upstream, including the patches, and found that the files in pkg-scicomp differs significantly from them (including a TON of whitespace difference), that's why I was asking about this. Christophe, how did you make the .orig.tar.gz from the upstream tarballs? [..] Neither debian/rules nor any Makefile references ARPACK, but you're right, a couple of patches apply to that directory. Like second is changed to secnd2 in ARPACK but not root, Correct, but it is not applied. and noetime applies to ARPACK but not root. This one applies to both and is necessary to compile with gfortran. Okay, thanks for the clarification. I'll try to figure it out and make it work. But I really need the .orig.tar.gz which is not on any of the mirrors since it's been removed. Ubuntu still has it: http://packages.ubuntu.com/search?keywords=libarpack2 Ah, very good! Will use this. But it still suffers from the problem above (difference vs. upstream). Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Recent ARPACK package
Hello, Where can I get a recent ARPACK package? I know it's been removed from main, but thought it should go into non-free soon, as it's been about three months. Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: tasks overview wishlist: Canonical citing reference
Hi Andreas, You replied to a message more than a week old, and missed an option which came up last week, see below. On Sat, 2008-10-18 at 16:33 +0200, Andreas Tille wrote: On Fri, 10 Oct 2008, Manuel Prinz wrote: Sure. So, to summarize, we have the following options: 1. The references are added to the long description 2. The references are added to Packages via a new X-* field 3. The references are added to debian/copyright 4. The references are supplied in a file under ./debian and installed in a common location (via debhelper or other methods) 1. in an already widely-used bibliographic format 2. in a RFC822 format that is converted to other formats on installation To me, only 4) is an option, and I prefer to go the 4.1 route. 5. The package maintainer includes reference file(s) where (s)he sees fit, with an index pointing to them and indicating their format in the .doc-base file. Thanks for sumarizing these options. My opinion about these options is not that strong. I admit I can understand your motivation for your preference. I do not really want to use this as an argument but I would just want to note that your prefered choice is the option that makes the implementation on the tasks page the hardest amongst all the options. I do not see this as an unresolvable problem but it delays the implementation the most. Option 5 doesn't delay implementation at all, and allows later versions of doc-base parsers to build any number of centralized reference indices by aggregating the packages' reference files. Is there a reason you didn't consider it? Do you think one of 1-4 is better? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: tasks overview wishlist: Canonical citing reference
On Thu, 2008-10-16 at 15:17 +0200, Michael Banck wrote: On Thu, Oct 16, 2008 at 10:40:26AM +0900, Charles Plessy wrote: - Prepare files named 'reference' of 'citation' in the source package. Did you mean 'reference' *or* 'citation'? As I argued elsewhere, I think both are quite different, and both files have their merit. Also, what format are you now talking about? For the references file, bibtex format sounds fine, but as elsewhere discussed, it makes less sense for the citation file. Further, would it be possible to have a boilerplate comment at the top which would get ignored by the doc-base stuff, but would be useful for the users browsing /usr/share/doc/package? Something like For more information regarding this package, see the following publications: bibtex. I think the For more information can go in the .doc-base file abstract, and most bibliographic metadata formats including BibTeX have a comment field where a package maintainer can put this information as well. If we think bibtex is too unclear for some users, we could also include a free-form reference in the comments above the bibtex data. I agree, it would help a lot of users to have a free form reference, as well as a clickable link. But should developers need to put this redundant information in the package, or should we rely on future doc-base front-ends (dhelp, dwww, etc.) to do it? I'd prefer the latter, as there's less for the developer to update -- it's less likely that the dev will update one format and not the others, particularly if someone adopts the package. Also, what other open formats do people use for citations? Is there a format which OpenOffice can use? (I've found bibliographies in OOo to be a real pain, so I just do them in latex/bibtex even if collaborators want the main paper/proposal to be in OOo.) I do *not* think we should have Debian tools parse EndNote etc. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: tasks overview wishlist: Canonical citing reference
On Thu, 2008-10-16 at 21:36 +0200, Manuel Prinz wrote: Am Donnerstag, den 16.10.2008, 17:41 +0200 schrieb Michael Banck: The problem I have with doc-base is that it is underused and not very accessible. At least that is my impression of it as somebody who doesn't care a lot about it from a packager's POV. I probably should care more, though. I know lots of long-term Debian users who are not even aware of doc-base at all... I do share your POV here. Really? But doc-base is so cool! It's yet another Debian invention (predates scrollkeeper by several years) which makes life a ton easier for users, like apt and debconf. So anyway, I'd really like to have something usable for users in /usr/share/doc/package and not just some meta-data stream that's marked up reasonably somewhere else. Maybe it's best to have a seperate citation.bib and references.bib file with just the bibtex data? This is IMHO the solution to go for. Adam's idea is quite good as well, and as I see it, they're complementary in that we could use doc-base for now and use the data (better: the .doc-base files) to generate the citations.bib and references.bib out of those entries via a script. My idea was actually to have the citations.bib and/or references.bib in /usr/share/doc/package as you say, and have the .doc-base file include something like: Format: BibTeX Files: /usr/share/doc/package/*.bib Is there an advantage to having the BibTeX data right in the .doc-base file? I can't see one, and I think it might confuse .doc-base parsers. So I think we agree about this. Advantages: * It uses (and perhaps reinforces) the doc-base index system, which IMO is one of Debian's under-appreciated strengths. * It's backward-compatible with old versions of debhelper, dhelp/dwww, etc. which will just ignore that section of .doc-base. * There's a user-visible place for .bib files, which is wherever the maintainer feels is the best place for them, we don't need to wait for a script to be available to generate it. * Metadata are in one place, which is the .bib files, not duplicated in .doc-base and .bib files and plain formats and HTML and control, so the maintainer only has to change or update things once. * It doesn't bloat Packages or control. * It's future-expandable, as new versions of dhelp etc. can use the .doc-base and .bib files to generate a whole host of new user- friendly files, from a master .bib file or other reference manager files, to a plain text reference list, to an HTML index with links to the DOIs. * Scrollkeeper might follow Debian's leadership (again) and make use of such metadata. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: tasks overview wishlist: Canonical citing reference
On Thu, 2008-10-16 at 22:52 +0200, Michael Banck wrote: On Thu, Oct 16, 2008 at 04:41:45PM -0400, Adam C Powell IV wrote: My idea was actually to have the citations.bib and/or references.bib in /usr/share/doc/package as you say, and have the .doc-base file include something like: Format: BibTeX Files: /usr/share/doc/package/*.bib Isn't this going to need changes to doc-base and/or dhelp, or do they understand the above already? They don't, but they'll ignore a format they don't recognize. I'm proposing this as a change which new versions of dhelp/dwww will be able to parse, and which won't break old ones. Is there an advantage to having the BibTeX data right in the .doc-base file? I can't see one, and I think it might confuse .doc-base parsers. Ok. So I think we agree about this. Advantages: * It uses (and perhaps reinforces) the doc-base index system, which IMO is one of Debian's under-appreciated strengths. * It's backward-compatible with old versions of debhelper, dhelp/dwww, etc. which will just ignore that section of .doc-base. * There's a user-visible place for .bib files, which is wherever the maintainer feels is the best place for them, we don't need to wait for a script to be available to generate it. * Metadata are in one place, which is the .bib files, not duplicated in .doc-base and .bib files and plain formats and HTML and control, so the maintainer only has to change or update things once. * It doesn't bloat Packages or control. * It's future-expandable, as new versions of dhelp etc. can use the .doc-base and .bib files to generate a whole host of new user- friendly files, from a master .bib file or other reference manager files, to a plain text reference list, to an HTML index with links to the DOIs. * Scrollkeeper might follow Debian's leadership (again) and make use of such metadata. While I think this doc-base integration is fine and nice, I still think having the data in free-form in addition is worthwhile. What do you mean by free-form? Plain text or HTML? That leads to the same data in two places problem... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: tasks overview wishlist: Canonical citing reference
On Sun, 2008-10-12 at 14:20 +0200, Michael Banck wrote:
On Wed, Oct 08, 2008 at 08:19:25AM +0200, Andreas Tille wrote:
The format of /usr/doc/package/references could be a popular one, for
instance BibTeX, if it allows cross references to other systems like
DOI, PubMed, ...)
I would strongly vote for RFC822 format (as debian/control, Packages
and Sources file). There are tools inside Debian to work on this
format (I'm using these in my scripts) and conversion to any other
format like BibTeX would be easy.
First off, I think citation would be a better name than references,
at least for the canonical reference to cite when using that package.
That said, those citations are usually (or at least often) *not*
bibliographical references to some published article, but are in the
rought form PACKAGE VERSION AUTHORS (INSTITUTION) YEAR, so rather
free-form.
I agree. BibTeX and similar systems are much more structured metadata
formats, and it is *much* easier to convert from those to text than the
other way around (which is impossible in the general case).
Another matter are the article references explaining the package and/or
giving more information; for those, bibtex entries probably make a lot
of sense. On the other hand, we could just have it be a list of URLs,
either to http://dx.doi.org/DOI or
http://www.ncbi.nlm.nih.gov/pubmed/PMID or similar. This would be a
very compact form for a X-References in debian/control. If we settle on
a debian/references (next to a debian/scitation), Quoting the title of
the papers in ASCII transcription(?) (and possibly the author names),
followed by the URL and maybe the bibtex data.
Additionally, we could settle on some standard introduction text, like
$PACKAGE should be cited as follows: for debian/citation and
Additional information for $PACKAGE can be found in the following
publications for debian/references.
The Description is obviously the wrong place for this, it bloats
Packages etc. And adding a new dh_addcitation would be a lot of work,
moving us to squeeze+1.
So why not just adapt the existing doc-base format, adding a new BibTeX
files field? The description of which citation to use when (canonical
article(s) for different parts of the package, background theory,
related stuff) can just go in the doc-base abstract.
This way, all the package needs to have is a doc-base file, which is
backward compatible (older versions of dhelp etc. will just ignore these
BibTeX files) and somewhat future-proof. With this info, a future dhelp
might create a centralized /usr/share/doc-base/references.bib file which
merges all of them, so a .tex paper need only include this file to have
access to all of the citations. And doi = {10.1234/my_article} can
just be a field in the .bib file, which a .bib browser can convert to an
HTML link.
Do we need any more metadata than this? Is there anything you can
envision a dh_addcitation doing beyond this? For some reason is the
doc-base file not an appropriate place to put it?
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
Re: tasks overview wishlist: Canonical citing reference
On Wed, 2008-10-15 at 09:27 +0900, Charles Plessy wrote:
Le Tue, Oct 14, 2008 at 09:47:40AM -0400, Adam C Powell IV a écrit :
why not just adapt the existing doc-base format, adding a new BibTeX
files field? The description of which citation to use when (canonical
article(s) for different parts of the package, background theory,
related stuff) can just go in the doc-base abstract.
Hello Adam,
let me rephrase to see if I understood completely.
Let a package foo, that contains the program foo that was published
by Bar in the Fooomics journal.
The Debian source package would contain a file named
foo-reference.doc-base in its debian directory. foo-reference.doc-base
would contain something like this:
Document: foo-reference
Title: Bibliographic information for foo
Section: Bibliography
Format: BibTeX
@book{foo-debian,
title = Foo for the masses,
author = Bar,
publisher = Foomics journal,
year = 2029
doi = 3.14159/foo_article
}
Users would first have to go to /usr/shar/doc-base by themselves, then some
time later we would update doc-base to generate something from the Format:
BibTeX entry, and in a third step we would implement a central bibliography
that can be easily used by reference managers and LaTeX articles.
Does it reflect your proposition ?
That's pretty much it, though I figured it would point to one or more
separate .bib files instead of having the entry inside the doc-base
file. It seems like it has the best of both worlds: use current files
and infrastructure, but allow expansion to a centralized citation list
as soon as squeeze.
What do you think?
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
Re: [OT] tasks overview wishlist: Canonical citing reference
On Tue, 2008-10-07 at 23:55 +0200, Bernhard R. Link wrote: * Michael Banck [EMAIL PROTECTED] [081007 22:53]: Also, having this would sense a clear signal to upstream authors that we consider proper citing important and that enforcing citations in copyright licensing is not the best thing to do. I think the better signal to send is that enforced citation is considered not academical behaviour as it is simply citation trolling. I my eyes it is equivalent of paying people to cite you. (Or rather eqauivalent to harrassing people to make them cite you). I disagree. Papers are required to provide full details on the methods they use which affect the results, whether an instrument or piece of software. That provides transparency and verification. For example, if someone package A version B.C to solve equation Y, and someone else gets a different solution, and a third person later finds a bug in that version, it is essential to have the software and version in the papers in order to sort out who is write. The citation provides the canonical reference to the software. To address another side of this, the relevant currency in academia is credit and not money, and nobody is paying or harassing anyone to use a piece of software. If you don't want to cite it, use a different tool, or re-implement it. But using software without citing it is like not citing an algorithm or experimental method. There might be things where software can actually be used as academical contribution to some paper, but all examples I've yet seen were just ridicilously broad. Neighter your calculator nor your typewriter belonged in the citations (though sometimes might have been added as kind of joke, like people trying to award PHDs to their desktop computer), not does the equivalent in software. Citations have an academic purpose, they are not something to collect to make your resume look better... That's a completely different situation. One doesn't need to cite the make and model of computer, as long as computers can be trusted to do math properly -- the Pentium fdiv bug being the only counterexample I know of in the past 30 years or so. Until scientific software is as reliable and robust as arithmetic in silicon (or the libm for that matter), we'll need to cite it properly. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
PHP documentation
Hi, I'm in the process of adding a libmesh-doc binary package to libmesh, but doxygen generates all of its docs in .php files. file:// links fail to open these because the browser (Iceweasel) doesn't know what .php is. I know nothing about PHP, so I figured Suggesting dwww and libapache*-mod-php5 would do the trick, but it didn't. (dwww created .php?type=html files with no formatting, and again Iceweasel doesn't know what to do if I strip the ?type=html (the links of course don't have this), because Apache is neither interpreting the PHP nor presenting the right mime type. For the PHP-ignorant, is there a simple set of packages I can Suggest to make a bunch of .php files display properly? Or a *very* brief howto I can insert into the libmesh-doc Description? Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Presentation of Debian Science/Octave/Scilab/Scicomp, roundtable on free software
Hi Christophe, Sorry I didn't reply sooner, didn't read down far enough... Let me first say I really appreciate your efforts to work with EDF to open their software -- and perhaps the process for writing it. The crown jewels of Code_Aster, Code_Saturne and Salomé with the MECA modules are truly outstanding packages representing the state of the art in many ways, and an enormous contribution to the Open Source community. On Thu, 2008-10-02 at 10:27 +0200, Christophe Prud'homme wrote: [snip] Adam, could you send me an update on Salomé: hours of work, amount changes that were done, number of people involved in the packaging, communication with upstream...) ? Salomé might provide some good examples of what should not be done in such platforms. I will be cautious about criticism though: I want the discussion to be constructive. I'm afraid I wasn't accurately keeping track of my hours while working on Salomé, but that work spanned about sex weeks of sort-of full time work between January and April, of which about 40-50% was focused work on Salomé (i.e. not waiting for builds, reading LWN, working on other packages, doing other client work, etc.), hence something over 100 hours. There are 48 patches named debian/patch-*, which you can see at: http://lyre.mit.edu/~powell/salome/ (see -7.diff.gz). The main people working with me were Thomas Girard on the omniORB 4.1 port, Dirk Eddelbuettel on OpenMPI integration, Alexandre Fayolle on build testing and bug reporting, hmm -- I know I'm leaving people out. Though there were a lot of off-line replies, the bulk of the emails are in three threads starting at: http://lists.debian.org/debian-science/2008/01/msg4.html , http://lists.debian.org/debian-science/2008/01/msg00017.html and http://lists.debian.org/debian-science/2008/08/msg00072.html . As for upstream communication, I tried both [EMAIL PROTECTED] and [EMAIL PROTECTED] as well as the web forms of both Salomé and OpenCASCADE, with no replies. When I complained loudly on the Salomé forum, Adam Erwan replied in April. Sylvestre Ledru was very helpful in establishing contact with people like Vincent Lefebvre, Aimery Assire, who recently sent me a very long and detailed update on the technical and legal status of Salomé in reply to the attached, and Hughes Prisker, who a week ago suggested I wait until a planned early 2009 release before continuing packaging efforts. More than anything else, what has frustrated me until recently was the lack of information. First there was no way to contact upstream, then no forum for sending patches, or even any indication of whether they cared about patches. Then between the March binary-only release of 3.2.9 and the past couple of weeks, it was unclear whether there would be future source releases at all. I think I have some answers to these, which can be summarized as: upstream develops this, tests it extensively, and then throws releases over the wall to the public after internal development has long since moved on. The development process is closed, and due to client interactions upstream has no plan to open that process. So we should work with what we get, and not think about whether upstream is interested in patches. The EDF/OCC developers have every right to do things this way. But I think they would be pleasantly surprised at how many people would jump at the opportunity to participate in testing and development, making the code at least more portable and robust, and possibly adding significant new features. And binary-only releases for an ostensibly open source product are very confusing and frustrating. I wish you well in your presentation, and look forward to hearing about the outcome of your meetings. Thank you again! Regards, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ ---BeginMessage--- Bonjour Messieurs, (M. Erwan, merci pour ton message au Salomé forum de 10 Avril.) J'ai travaillé sur un package de Salomé pour Debian GNU/Linux (et Ubuntu aussi). On peut le télécharger au http://lyre.mit.edu/~powell/salome/ . Mais comme j'ai ecrit au Salomé forum, maintenant c'est impossible de packager le version courant, parce que le source code n'est pas disponsible. Comment peut-on obtenir le source code de version 3.2.9 ou plus nouveau? Le Salomé-MECA 3.2.9 était disponsible onze semaines avant, et c'est logiciel libre, n'est-ce pas? Par ailleurs, j'ai ecrit 47 patches pour nouveaux bibliothèques (VTK 5, omniORB 4.1, etc.) et autres choses pour Salomé version 3.2.6. Peut être quelques patches ne sont pas utiles maintenant, mais dans l'avenir, a qui doit-on envoyer les patches? (Si vous voulons les voir, ce sont dans les fichiers avec fin .diff.gz au URL au-dessus.) J'attend le version 3.2.9 ou plus nouveau source avant de travailler plus sur le package. [Pardon, je ne peut pas ecrire bien français.] Cordialement,
Re: Bug#457075: Status of Salomé packaging
On Thu, 2008-08-21 at 22:28 +0200, Christophe Prud'homme wrote: To follow Ondrej comment, I have been in contact with some people close to the Salome project. With almost the same ones we are going to have a similar project to build a recently funded open platform (OPUS) for uncertainty quantification in simulations possibly based on openturns (in the NEW queue). I will be extra careful that Salome's mess doesn't happen again. I also try at each meeting to bring forth Debian's (Adam's and others) huge efforts to bring Salome to its users. Thank you very much Christophe. It would be terrific to have a cooperative partner in the Salomé upstream developers. I think they share our goal of broadening the use of this amazing project by making it much easier to install and use in Debian and derivative distros, and I look forward to being a part of a future vibrant Salomé user/developer community. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Package categories
On Sat, 2008-08-02 at 19:28 +0100, Chris Walker wrote: Adam C Powell IV [EMAIL PROTECTED] writes: On Fri, 2008-08-01 at 11:02 +0100, Chris Walker wrote: And http://www.opennovation.org/ provides a much better categorisation of engineering type packages than I did. Categories there are: Partial Differential Equation (PDE) Solvers General Finite Element Analysis (FEA) Computational Fluid Dynamics (CFD) Electromagnetism and Optics Software for Phase Field simulations Boundary Element Method (BEM) Pre- and post-processing frameworks and tools Computer-Aided Design (CAD) Multi-body dynamics Integrated Computational Materials Engineering (ICME) (Ab initio and Molecular dynamics codes listed here) As the owner/maintainer of opennovation.org, I'm struggling with this categorization, and welcome input. For example: * Is libMesh FEA or CFD? It is a general FEA lib, but its examples and development point toward CFD -- not to mention that its authors are the CFD group at UT Austin. Saturne is clearly CFD and Aster is clearly mechanics/heat (as are CacluliX and Impact), so why should Aster, CalculiX and Impact be in general FEA? I've got as far as bending a beam using FEA, so take this with some pinches of salt. Would listing all the programs in one PDE solvers in one category, but having ticks for CFD, mechanics, etc solve the problem - these would correspond naturally to tags. Eg: CFD | Mechancics | Integrated pre/post | x | x | | Prog1 x | | x | Prog 2 Excellent idea. Makes for a big table though, once you start listing all of the interesting capabilities. I have the beginnings of such a beast (going through a transition) at: http://www.opennovation.org/fea.html (Posting this here will motivate me to work on finishing it. :-) * Should libraries be treated differently from standalone codes? Or is input file vs. short program which calls the library functions merely a semantics issue? Aster calls its python scripts input files where FiPy calls the exact same thing programs which call its functions. * How about standalone FEA codes like Aster, vs. an integrated pre- post- and solver like OpenFOAM? If you like the idea above, then have an Integrated pre/post solver tick. You could then have a separated pre/post processor. Knowing which pre/post processor works with which codes will also help. Indeed! These are some of the reasons I think keywords or tags are more appropriate than categories. But keywords/tags don't lend themselves to well-organized websites... If there is an obvious set of tags, can you suggest them here. Okay, here's a start: * PDE-solver * finite-elements * boundary-elements * finite-differences * integrated-mesher * integrated-visualization * fluid-dynamics * solid-mechanics * heat-mass-transfer * radiation * electromagnetics * multi-domain * multi-thread * MPI * PVM * works-with [Salomé | gmsh | VTK ...] This list can grow arbitrarily if we let it. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Package categories
On Fri, 2008-08-01 at 11:02 +0100, Chris Walker wrote: Adam C Powell IV [EMAIL PROTECTED] writes: On Thu, 2008-07-24 at 13:44 +0100, Chris Walker wrote: Christophe Prud'homme [EMAIL PROTECTED] writes: Salome to my knowledge Salome does not provide a fe code ! AFAICT from http://www.salome-platform.org/home/presentation/overview/ while salome doesn't perform FEA calculations, it can be used to create meshes and display results from FEA - which is why I suggested it in that category. It wouldn't however fit in a numerical methods category. Indeed: Salomé proper doesn't include a solver, but it does just about everything else (meshing, MED file editing, post-processing). And Salomé-MECA adds modules to set up and monitor/control a complex Aster run, so in a sense it is a complete FEA front end. And http://www.opennovation.org/ provides a much better categorisation of engineering type packages than I did. Categories there are: Partial Differential Equation (PDE) Solvers General Finite Element Analysis (FEA) Computational Fluid Dynamics (CFD) Electromagnetism and Optics Software for Phase Field simulations Boundary Element Method (BEM) Pre- and post-processing frameworks and tools Computer-Aided Design (CAD) Multi-body dynamics Integrated Computational Materials Engineering (ICME) (Ab initio and Molecular dynamics codes listed here) As the owner/maintainer of opennovation.org, I'm struggling with this categorization, and welcome input. For example: * Is libMesh FEA or CFD? It is a general FEA lib, but its examples and development point toward CFD -- not to mention that its authors are the CFD group at UT Austin. Saturne is clearly CFD and Aster is clearly mechanics/heat (as are CacluliX and Impact), so why should Aster, CalculiX and Impact be in general FEA? * Should libraries be treated differently from standalone codes? Or is input file vs. short program which calls the library functions merely a semantics issue? Aster calls its python scripts input files where FiPy calls the exact same thing programs which call its functions. * How about standalone FEA codes like Aster, vs. an integrated pre- post- and solver like OpenFOAM? These are some of the reasons I think keywords or tags are more appropriate than categories. But keywords/tags don't lend themselves to well-organized websites... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Package categories
On Thu, 2008-07-24 at 13:44 +0100, Chris Walker wrote: Christophe Prud'homme [EMAIL PROTECTED] writes: Salome to my knowledge Salome does not provide a fe code ! AFAICT from http://www.salome-platform.org/home/presentation/overview/ while salome doesn't perform FEA calculations, it can be used to create meshes and display results from FEA - which is why I suggested it in that category. It wouldn't however fit in a numerical methods category. Indeed: Salomé proper doesn't include a solver, but it does just about everything else (meshing, MED file editing, post-processing). And Salomé-MECA adds modules to set up and monitor/control a complex Aster run, so in a sense it is a complete FEA front end. Unfortunately, Salomé recent source code is not available, and most of -MECA source has never been released. :-( However, Sylvestre is in close contact with developers, and it looks like there will be progress by the end of the year. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Package categories
On Sun, 2008-06-29 at 13:55 +0100, Chris Walker wrote: It would be nice to see science packages better categorised. I guess this is ultimately best done using debtags. For example http://cdd.alioth.debian.org/science/tasks/physics.php lists packages to do Finite element analysis, optical simulation, xray absorption spectroscopy, ab inito quantum mechanics and computer algebra. I propose to post to this list or the wiki a list of potential subcategories along with packages that would go in them, and see where we go from there. Comments? Rather than subcategories, I would prefer keywords, because many packages cover multiple subcategories. But then, debtags are more keyword than (sub)category in this sense. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: About free-form database
On Mon, 2008-06-09 at 15:29 +, Dirk Eddelbuettel wrote: This is a debian-user question. Learn to use 'apt-cache search' -- there must be at least a hundred packages in Debian for what you describe, from note taking to mind mappming to personal wikis. Don't abuse debian-science because you think of yourself as a scientist. I don't agree that this constitutes abuse of debian-science. This list is for discussion of tools for scientific development, and a couple of long threads have dealt with typesetting tools suited for science. If typesetting is on-topic, why not data management? That said, I'll echo the recommendation to use apt-cache search. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
OpenCASCADE ACCEPTED!
On Tue, 2008-05-13 at 14:57 -0400, Adam C Powell IV wrote: On Mon, 2008-05-12 at 16:51 -0400, Adam C Powell IV wrote: On Mon, 2008-05-12 at 22:11 +0200, Denis Barbier wrote: On Wed, 07 May 2008 12:27:08 -0400, Adam C Powell IV [EMAIL PROTECTED] wrote: Greetings, I've (finally) begun the arduous task of auditing the copyright(s)/ license(s) in OpenCASCADE. Based on the number of files and directories, this is bound to take a ton of time, so I'd appreciate some help! I've also solicited help on the OpenCASCADE forum, where I've been discussing this with the Gentoo packagers. Hi Adam, I worked with Aurélien Jarno on an Opencascade Debian package a couple of years ago, here is the debian/copyright file that I did write after a full license audit of OpenCascade 6.1, I later checked files newly added to 6.2 and did not find any new problem. Hope this helps. Wow, thanks very much, this helps tremendously! I will reformat this in the proposed copyright format, and hope to have something uploadable (to non-free) soon! Given that this cuts an enormous amount of time off package development, I will convert the .tar.bz2 file to .tar.gz for -8, in order to target this to lenny. I'm uploading 6.2-2 to http://lyre.mit.edu/~powell/opencascade/ . I consider this a beta test before uploading -3 to NEW, so please look it over and try it out! The copyright and README.Debian.html files should be complete now. My last to-do before -3 will be to add -release flags to LDFLAGS in Makefile.?m to do library versioning, which will get rid of the biggest remaining lintian warning. (After that, only missing man pages remain.) I also want to split the package using Jason Kraftcheck's scripts, but won't have time for a while; perhaps it'll get done by the time Debian rejects this version. :-) Big thanks to Denis Barbier for the old copyright file, and to him and Aurélien Jarno for actually doing the audit! We just may see OpenCASCADE in lenny... And after three weeks in the NEW queue, OpenCASCADE was ACCEPTED this morning into unstable! Yay! However, Denis pointed out a couple of significant flaws in the packaging, such as a lot of missing files and the need to put /usr/share files of the shlib package into a version-specific location. Denis, can you file a bug or two on this? If anyone else has an application which uses OpenCASCADE, please help to test the package so it will be as robust and bug-free possible for the lenny release. I think I will postpone re-splitting the package and ripping out the non-free parts (which would put the package in main) until after lenny, as uploading such changes would require another trip through the NEW queue with even more scrutiny. Not to mention that I haven't had time for this in the five months since Jason proposed it, and that isn't likely to change in the next couple of weeks. (But I would gladly accept patches!) Thanks again to everyone who contributed so much to making this happen! Regards, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: OpenCASCADE ACCEPTED!
On Mon, 2008-06-09 at 19:01 -0500, Jordi Gutiérrez Hermoso wrote: On 09/06/2008, Adam C Powell IV [EMAIL PROTECTED] wrote: And after three weeks in the NEW queue, OpenCASCADE was ACCEPTED this morning into unstable! Yay! Awesome! Good job! This means it will make it into lenny? Very good news! I think I will postpone re-splitting the package and ripping out the non-free parts I admit I haven't really been following the discussion which got very technical, but now that it looks like I (er, we) have more software readily available, I got curious. From the webpage, it looks like a very powerful suite for numerical work, and I already see some things I could use it for. Indeed, it's beautiful! However, I am a strong believer in software freedom, especially, *especially*, when it comes to scientific software (highest priority for free software, in my opinion). I tried to understand right now exactly why OpenCASCADE is non-free, and the restriction seems to be about the method which modifications have to be published. Is this correct? There also seems to be a plainly proprietary component in it? There are two reasons. First, there is a non-free component, the triangle software which is part of libTKMesh.so, which has a number of non-free aspects to its license. But that's small and not hard to remove. The second reason is that although the OCTPL seems to be a free license, upstream's interpretation of it is not. The paragraph starting with In short on http://www.opencascade.org/occ/license/ introduces the non-free requirement that one send all modifications to them, which is nowhere in the license itself. As mentioned, I'm going to try to rip out triangle and get the rest into main for lenny+1. I see this happen so frequently, by developers who seem to misunderstand the nature or motive of free software, particularly the GPL, and want to fix it, often producing non-free results.[1] Have you spoken to upstream about a possible relicensing? I think upstream seldom chooses to change licensing terms, but a polite request might still be in order. I couldn't easily track down in the discussion if you had already done so or not, and what upstream responded. I have tried to contact them, to no avail. A couple of years ago Denis Barbier and Aurelien Jarno tried to package OCC, and contacted upstream, but didn't get any encouraging words in their replies. For details, see http://lists.debian.org/debian-legal/2007/12/msg00066.html for details. Congrats on the packaging, Thanks! - Jordi G. H. [1] I myself am sometimes a slight perpetrator of this too. I would like to create a license which forbids military use of my software, but I err on the side of the many free lawyers and their often lauded law-fu used in the making of the GPL, so I choose not to add such a restriction. Not that I think my software is particularly useful for the military, but if there is anything I could do to hinder professional murderers worldwide, I would do it. I guess you're probably not alone. Then again, some military labs contribute quite a bit to free software, e.g. the DARPAnet - Internet. Off-topic though... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: OpenCASCADE ACCEPTED!
On Mon, 2008-06-09 at 20:46 -0500, Jordi Gutiérrez Hermoso wrote: On 09/06/2008, Adam C Powell IV [EMAIL PROTECTED] wrote: The second reason is that although the OCTPL seems to be a free license, upstream's interpretation of it is not. The paragraph starting with In short on http://www.opencascade.org/occ/license/ introduces the non-free requirement that one send all modifications to them, which is nowhere in the license itself. Now, this part is downright bizarre. Further proof that tampering with good things like the GPL comes from people who are confused with its intent and purpose. It is odd, isn't it? IMO, the requirement of a distinct patch makes this license more like the QPL than the LGPL which they claim. As an aside, now that FreeCAD is fully LGPL (as of a couple of weeks ago, not sure that the change has entered a release yet), it can legally link to both OCC and QPL-licensed Qt, as can Salomé. I hope that this doesn't mean that once you remove the triangle software (Delaunay triangulation, is it, or something harder to reimplement?), that upstream's confusion about their own license won't stop it from trickling down to main. We'll see in a few months... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Bug#464400: OpenCASCADE copyright/license audit
On Mon, 2008-05-12 at 16:51 -0400, Adam C Powell IV wrote: On Mon, 2008-05-12 at 22:11 +0200, Denis Barbier wrote: On Wed, 07 May 2008 12:27:08 -0400, Adam C Powell IV [EMAIL PROTECTED] wrote: Greetings, I've (finally) begun the arduous task of auditing the copyright(s)/ license(s) in OpenCASCADE. Based on the number of files and directories, this is bound to take a ton of time, so I'd appreciate some help! I've also solicited help on the OpenCASCADE forum, where I've been discussing this with the Gentoo packagers. Hi Adam, I worked with Aurélien Jarno on an Opencascade Debian package a couple of years ago, here is the debian/copyright file that I did write after a full license audit of OpenCascade 6.1, I later checked files newly added to 6.2 and did not find any new problem. Hope this helps. Wow, thanks very much, this helps tremendously! I will reformat this in the proposed copyright format, and hope to have something uploadable (to non-free) soon! Given that this cuts an enormous amount of time off package development, I will convert the .tar.bz2 file to .tar.gz for -8, in order to target this to lenny. I'm uploading 6.2-2 to http://lyre.mit.edu/~powell/opencascade/ . I consider this a beta test before uploading -3 to NEW, so please look it over and try it out! The copyright and README.Debian.html files should be complete now. My last to-do before -3 will be to add -release flags to LDFLAGS in Makefile.?m to do library versioning, which will get rid of the biggest remaining lintian warning. (After that, only missing man pages remain.) I also want to split the package using Jason Kraftcheck's scripts, but won't have time for a while; perhaps it'll get done by the time Debian rejects this version. :-) Big thanks to Denis Barbier for the old copyright file, and to him and Aurélien Jarno for actually doing the audit! We just may see OpenCASCADE in lenny... Cheers, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Bug#464400: OpenCASCADE copyright/license audit
On Mon, 2008-05-12 at 22:11 +0200, Denis Barbier wrote: On Wed, 07 May 2008 12:27:08 -0400, Adam C Powell IV [EMAIL PROTECTED] wrote: Greetings, I've (finally) begun the arduous task of auditing the copyright(s)/ license(s) in OpenCASCADE. Based on the number of files and directories, this is bound to take a ton of time, so I'd appreciate some help! I've also solicited help on the OpenCASCADE forum, where I've been discussing this with the Gentoo packagers. Hi Adam, I worked with Aurélien Jarno on an Opencascade Debian package a couple of years ago, here is the debian/copyright file that I did write after a full license audit of OpenCascade 6.1, I later checked files newly added to 6.2 and did not find any new problem. Hope this helps. Wow, thanks very much, this helps tremendously! I will reformat this in the proposed copyright format, and hope to have something uploadable (to non-free) soon! Given that this cuts an enormous amount of time off package development, I will convert the .tar.bz2 file to .tar.gz for -8, in order to target this to lenny. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: OpenCASCADE copyright/license audit
On Thu, 2008-05-08 at 15:35 +0200, Teemu Ikonen wrote: On Wed, May 7, 2008 at 6:27 PM, Adam C Powell IV [EMAIL PROTECTED] wrote: I've put a brief start (6 of the 536 directories in ros/src) in: http://www.opennovation.org/audits/opencascade-6.2.txt and will update it as I and others work through this. But before proceeding further, my big question is: does this need any more information than it has? Obviously the debian/copyright file will need the full text of all of the licenses, but that's another matter. May I suggest using the machine readable copyright format described at http://wiki.debian.org/Proposals/CopyrightFormat from the start? Since the audit is going to be a huge task, it would be good to document it in as formal way as possible. I made a partial conversion of the current audit (files, copyright and license sections only) to this format. You can find it attached to this mail. Terrific, this is exactly why I sent this so early. I think we can probably simplify the file a bit by grouping a bunch of directories together with similar copyrights and licenses. Ah, Match order will make this a lot easier, for the final copyright file. Is there no way to distinguish other/free licenses from other/non-free? I'll propose this... I'll change the copyright file to this format for my next upload. Also, I built a new package based on the OpenBSD .tar.bz2 sources. This includes the audit file as debian/audit.txt and I'd like to make it the basis of future packages. One little hitch: as a Format 3.0 source package, I don't think it can be uploaded before the lenny release (because stable has to be able to unpack unstable sources). At least it works well here with the dpkg from lenny. Looking at the size of the source package and the potential problems with missing licenses etc. I don't think the upload to the archive will happen very soon :) Indeed! This .tar.bz2 is about half the size of my original .tar.gz, and has about 20-30% fewer files, which is a good thing. There are separate FreeBSD tarballs for Java and other pieces of OCC, and gentoo is using them for their packages too. By the way, speaking of size, would anyone mind if I drop the static libs from the -dev package? They are enormous, they double the build time and more than double the storage requirement, and I don't think they are so important. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
OpenCASCADE copyright/license audit
Greetings, I've (finally) begun the arduous task of auditing the copyright(s)/ license(s) in OpenCASCADE. Based on the number of files and directories, this is bound to take a ton of time, so I'd appreciate some help! I've also solicited help on the OpenCASCADE forum, where I've been discussing this with the Gentoo packagers. I've put a brief start (6 of the 536 directories in ros/src) in: http://www.opennovation.org/audits/opencascade-6.2.txt and will update it as I and others work through this. But before proceeding further, my big question is: does this need any more information than it has? Obviously the debian/copyright file will need the full text of all of the licenses, but that's another matter. Also, I built a new package based on the OpenBSD .tar.bz2 sources. This includes the audit file as debian/audit.txt and I'd like to make it the basis of future packages. One little hitch: as a Format 3.0 source package, I don't think it can be uploaded before the lenny release (because stable has to be able to unpack unstable sources). Cheers, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Choose between TeXmacs and Auctex
On Tue, 2008-04-22 at 18:47 +0200, Rafa Rodríguez Galván wrote: Hello. I agree with the previous e-mails and I think that the combination of LaTeX + emacs is, in the long term, the best choice. 1. Formula editing is very efficient, I can even carry out my deduction lively (and embedding CAS session, e.g. maxima). I am a regular user of scientific free software, especially Octave and Maxima. In addition to specific modes for these programs, Emacs allows you to embed them, using it's own buffer. You can also edit a Maxima or Octave script and send the contents of the buffer (or a region, current line, etc.) to the embedded session, that will display the results. Really? Does it work with, say, cxref as well? I love cxref's latex documentation extraction from source code, and the ability to put equations right there next to the lines that implement them. But I have longed for an environment which would do latex syntax highlighting right in a .c file comment -- not to mention a preview! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#464400: opencascade packages
On Mon, 2008-04-21 at 15:09 +0200, Leopold Palomo-Avellaneda wrote: A Dilluns 21 Abril 2008, Adam C Powell IV va escriure: On Fri, 2008-04-18 at 21:25 +0200, Teemu Ikonen wrote: On Thu, Apr 17, 2008 at 8:23 PM, Adam C Powell IV [EMAIL PROTECTED] wrote: I haven't had much time for this recently, but my todo list consists of: * Switch to the tarball used by FreeBSD (and soon Gentoo) at: ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/thierry/ * Conduct a thorough license/copyright audit of the tarball to make sure we have everything documented in the copyright file. * Upload to non-free, will probably take several iterations to get in. * Separate out the non-free bits. * Upload to main with non-free parts in separate package, again will probably take several iterations. * Use Jason Kraftcheck's scripts to separate it into a few packages, and re-upload. Sounds like a good plan in general, but will the FreeBDS tarball stay up to date with the upstream version? Well, maybe it's too early to worry about that. I have followed this thread with a lot of interest. I don't think the OpenCascade was free in the way to put it in debian, so to me it's a bit I don't know in a polite words ... unpolite touch my b.. /unpolite than you spend a lot of hours in package some huge soft to nonfree. Well, I know, they have their rights. But this kind of half-license half-open half-nonfree are more problematic (and close) than open (free) and feasible. As I see it, the license itself is free (can you find any non-free parts?). But right now a small handful of non-free bits, such as triangle, will prevent it from entering main. It will take some time to disentangle these bits, so why not first upload to non-free, then when we have time to disentangle it, then put the free majority in main? Howeber, as all in this life has a lot of buts: - if we have opencascade, another great free soft that use OpenCascade could be inside. - if we have opencascade, maybe they want to relax their license I don't know... just my feelings in this. We can try to begin a campain to ask to OpenCascade about a change in their licences but this is utopia. Right, we can't count on a license change, though it doesn't hurt to ask. And having it in non-free can be good as well, as you mention. Yes, but I can't guarantee I can spend much time on opencascade. I'm interested in free tools for 3D CAD, and as a first step I would like to be able to display a 3D models from IGES files. Apparently FreeCAD ( http://juergen-riegel.net/FreeCAD/Docu/index.php?title=Main_Page ) can do this, but it needs Opencascade to compile. FreeCad seems a great soft. I have tested the deb package (with opencascade inside. It would be nice to have a deb package ... at least in contrib. The FreeCAD libraries can go into contrib, but the main GPL app cannot -- unless Debian concludes that the OpenCASCADE license is GPL-compatible! At this point, I don't see why they wouldn't, but it's hard to tell. This is an issue for Salomé as well: it is LGPL, but it links with GPL Qt, so it can't go into Debian unless the OCC license is GPL-compatible and OCC will need to be in main. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#464400: opencascade packages
On Mon, 2008-04-21 at 19:43 +0200, Leopold Palomo Avellaneda wrote:
A Dilluns 21 Abril 2008, Adam C Powell IV va escriure:
On Mon, 2008-04-21 at 15:09 +0200, Leopold Palomo-Avellaneda wrote:
A Dilluns 21 Abril 2008, Adam C Powell IV va escriure:
On Fri, 2008-04-18 at 21:25 +0200, Teemu Ikonen wrote:
On Thu, Apr 17, 2008 at 8:23 PM, Adam C Powell IV
[EMAIL PROTECTED]
wrote:
I haven't had much time for this recently, but my todo list
consists of:
* Switch to the tarball used by FreeBSD (and soon Gentoo) at:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/thierry/ *
Conduct a thorough license/copyright audit of the tarball to make
sure we have everything documented in the copyright file. * Upload
to non-free, will probably take several iterations to get in. *
Separate out the non-free bits.
* Upload to main with non-free parts in separate package,
again will probably take several iterations.
* Use Jason Kraftcheck's scripts to separate it into a few
packages, and re-upload.
Sounds like a good plan in general, but will the FreeBDS tarball stay
up to date with the upstream version? Well, maybe it's too early to
worry about that.
I have followed this thread with a lot of interest. I don't think the
OpenCascade was free in the way to put it in debian, so to me it's a bit
I don't know in a polite words ...
unpolite
touch my b..
/unpolite
than you spend a lot of hours in package some huge soft to nonfree. Well,
I know, they have their rights. But this kind of half-license half-open
half-nonfree are more problematic (and close) than open (free) and
feasible.
As I see it, the license itself is free (can you find any non-free
parts?).
yes, it's non free at least in 2006 when I asked it to debian-legal and I
interchanged some private mails with Aurelien Jarno.
Really? Can you point me to a URL? I discussed it on debian-legal last
Fall (including Aurelien) and the conclusion was opposite: free license,
but upstream interprets it as non-free.
http://lists.debian.org/debian-legal/2007/12/msg00066.html
But right now a small handful of non-free bits, such as
triangle, will prevent it from entering main.
tetgen?
Like I said, a handful. :-)
It will take some time to
disentangle these bits, so why not first upload to non-free, then when
we have time to disentangle it, then put the free majority in main?
of course. But I don't think that it could be in main.
Howeber, as all in this life has a lot of buts:
- if we have opencascade, another great free soft that use OpenCascade
could be inside.
- if we have opencascade, maybe they want to relax their license
I don't know... just my feelings in this. We can try to begin a campain
to ask to OpenCascade about a change in their licences but this is
utopia.
Right, we can't count on a license change, though it doesn't hurt to
ask. And having it in non-free can be good as well, as you mention.
I asked in 2006 and I could ask again.
Do you know people there? If so, then please do ask! And you could
point out that their interpretation clause saying that people must send
changes upstream would make it GPL-incompatible, let alone non-free.
And that this would make FreeCAD and Salomé illegal.
Yes, but I can't guarantee I can spend much time on opencascade. I'm
interested in free tools for 3D CAD, and as a first step I would like
to be able to display a 3D models from IGES files. Apparently FreeCAD
( http://juergen-riegel.net/FreeCAD/Docu/index.php?title=Main_Page )
can do this, but it needs Opencascade to compile.
FreeCad seems a great soft. I have tested the deb package (with
opencascade inside. It would be nice to have a deb package ... at least
in contrib.
The FreeCAD libraries can go into contrib, but the main GPL app cannot
-- unless Debian concludes that the OpenCASCADE license is
GPL-compatible! At this point, I don't see why they wouldn't, but it's
hard to tell.
?
it's gpl is public the discussion? It's just curiosity.
See above.
This is an issue for Salomé as well: it is LGPL, but it links with GPL
Qt, so it can't go into Debian unless the OCC license is GPL-compatible
and OCC will need to be in main.
It's a mistake a soft that links against GPL library is GPL. It couldn't be
LGPL.
Well, it can be LGPL as long as the GPL library is optional. In the
case of Salomé, it has multiple components which interact using CORBA,
and it's possible that some might link with Qt and others with
proprietary code.
Unfortunately, there are binaries in Salomé which link with both Qt and
OCC (i.e. within a single component), so they must either assume that
OCC is GPL-compatible, or just ignore the licensing issues.
I discussed this a bit
Re: Bug#464400: opencascade packages
On Fri, 2008-04-18 at 21:25 +0200, Teemu Ikonen wrote: On Thu, Apr 17, 2008 at 8:23 PM, Adam C Powell IV [EMAIL PROTECTED] wrote: I haven't had much time for this recently, but my todo list consists of: * Switch to the tarball used by FreeBSD (and soon Gentoo) at: ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/thierry/ * Conduct a thorough license/copyright audit of the tarball to make sure we have everything documented in the copyright file. * Upload to non-free, will probably take several iterations to get in. * Separate out the non-free bits. * Upload to main with non-free parts in separate package, again will probably take several iterations. * Use Jason Kraftcheck's scripts to separate it into a few packages, and re-upload. Sounds like a good plan in general, but will the FreeBDS tarball stay up to date with the upstream version? Well, maybe it's too early to worry about that. Apparently they've kept up with the last few releases, so it seems a good bet they'll keep on. Are you interested in helping with any of the above? Yes, but I can't guarantee I can spend much time on opencascade. I'm interested in free tools for 3D CAD, and as a first step I would like to be able to display a 3D models from IGES files. Apparently FreeCAD ( http://juergen-riegel.net/FreeCAD/Docu/index.php?title=Main_Page ) can do this, but it needs Opencascade to compile. If you get a repository in Alioth (I prefer git or bzr, but can work with other systems as well), I can try to do something. Okay, I'll post to the bug and debian-science when a repository is available. In the meantime, feel free to use the package on lyre. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#464400: opencascade packages
On Thu, 2008-04-17 at 18:56 +0200, Teemu Ikonen wrote: Adam C Powell IV [EMAIL PROTECTED] wrote: I am packaging OpenCASCADE, a powerful computer-aided engineering (CAE) ... The current package is at http://lyre.mit.edu/~powell/opencascade/ . Hi, Has there been any progress on getting these packages to the archive lately? Is the licensing situation still unclear? Thank you for inquiring. The licensing situation is unclear, but that's something for Debian to worry about after upload, I don't think I'll get a straight answer before that. I haven't had much time for this recently, but my todo list consists of: * Switch to the tarball used by FreeBSD (and soon Gentoo) at: ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/thierry/ * Conduct a thorough license/copyright audit of the tarball to make sure we have everything documented in the copyright file. * Upload to non-free, will probably take several iterations to get in. * Separate out the non-free bits. * Upload to main with non-free parts in separate package, again will probably take several iterations. * Use Jason Kraftcheck's scripts to separate it into a few packages, and re-upload. Are you interested in helping with any of the above? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
Greetings, The problem is much earlier, in the GUI module: sip4 4.7.4 is failing. See Debian bug 469850 and http://www.riverbankcomputing.com/pipermail/pyqt/2008-March/01.html I have some time to work on it this evening to prepare a small test case for that list. From there, thanks to Thomas' help, it should be straightforward to complete the omniORB 4.1.x port. -Adam On Tue, 2008-04-01 at 10:53 -0700, Darko P. wrote: Dear Adam, Thomas, and list, I try to compile Salome on my system (32-bit Intel Core2, Kubuntu 7.10 (gutsy)) but get the same error as Thomas (ld cannot find -lSMESHimpl). How is the workaround? As it seemes, you proceeded further. Thanks and best regards, Dan Adam C Powell IV wrote: I am willing to help you with this, and tried to compile Salomé on my system but got blocked before the step you reached. When compiling NETGENPlugin, I get: /usr/bin/ld: cannot find -lSMESHimpl I have regenerated and installed OpenCASCADE 6.2.0-7 and recompiled hdf5 1.6.5-5.2 with your patch for OpenMPI on top of it. Do you know what's wrong in my local installation? Wow, thanks for putting in the hard work to help with this!! Actually, if you look at your log, it failed well before getting to that point, so it didn't build the SMESH library. I need to get the build to actually stop when it fails during the for ... $(MAKE) ... done loop in rules... Thank you again, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
On Thu, 2008-03-06 at 09:28 -0500, Adam C Powell IV wrote: Okay, I've made it build as far as I can, into a number of similar corrections in the SUPERV module. However, there's a sip/Qt error in the GUI module: /usr/bin/sip -t WS_X11 -t Qt_3_3_8b -x Qt_STYLE_INTERLACE -x Qt_STYLE_WINDOWSXP -x Qt_ASSISTANTCLIENT -s .cc -c . -I /usr/share/sip/qt/qt SALOME_PYQT_GUI.sip sip: QPixmap has not been defined I added the following Build-Depends: python-qt-dev sip4 python-sip4-dev libvtk5-qt3-dev . I don't have time to finish this just now, will get back to it and post an updated patch/package later today. Just put -6 at the usual place http://lyre.mit.edu/public_html/salome/ and filed bug 496850 against sip4 (after confirming it wouldn't build on my testing machine as it used to, so it's not a build-dep problem). -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
On Fri, 2008-03-07 at 09:08 -0500, Adam C Powell IV wrote: On Thu, 2008-03-06 at 09:28 -0500, Adam C Powell IV wrote: Okay, I've made it build as far as I can, into a number of similar corrections in the SUPERV module. However, there's a sip/Qt error in the GUI module: /usr/bin/sip -t WS_X11 -t Qt_3_3_8b -x Qt_STYLE_INTERLACE -x Qt_STYLE_WINDOWSXP -x Qt_ASSISTANTCLIENT -s .cc -c . -I /usr/share/sip/qt/qt SALOME_PYQT_GUI.sip sip: QPixmap has not been defined I added the following Build-Depends: python-qt-dev sip4 python-sip4-dev libvtk5-qt3-dev . I don't have time to finish this just now, will get back to it and post an updated patch/package later today. Just put -6 at the usual place http://lyre.mit.edu/public_html/salome/ D'oh! http://lyre.mit.edu/~powell/salome/ -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
