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 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 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-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 (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 (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 (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 (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 wrote: > > > > Sylvestre Ledru 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 wrote: > > Sylvestre Ledru 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 > To: alain.leuf...@logilab.fr > Cc: BERGEAUD Vincent , Vincent LEFEBVRE > , Nicolas Chauvat , Andre Espaze > , 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: Status of salome package
Hi Andrea, On Fri, 2011-06-10 at 21:46 +0200, Andrea Palazzi wrote: > Hi, > > what's the status of Salome package? In debian there's a package with > version 5.1.3, now version 6.3.0 is almost ready to come out... is there > any chance to have it packaged for Debian? Here's the full history. I packaged version 3.2.6 way back in 2008, and tried to send my patches for upstream consideration, but got nowhere, so I figured it wasn't worth the effort to port several dozen patches for every new upstream release. A year ago I re-started the effort with the 5.1.3 package, with the understanding that upstream would merge many of those patches. Others such as Denis Barbier, Andre Espaze, and Gerber Van de Graaf, Christophe Trophime and Alain Leufroy contributed a lot, and the package made a lot of progress. Andre Espaze did the hard work of porting the patches to newer upstream versions (at least 5.1.4), and I believe sent them upstream for merging. 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? Fortunately upstream now uses an open git server, so we can port patches to that in order to help upstream merge them. There are some patches which are debian-specific (*-debian-*.patch), and a few which upstream does not want to merge but I think most of those can be worked around. I'd be glad to help with re-starting this packaging effort... -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 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
OCE -- OpenCASCADE Community Edition
Dear Debian Scientists, Denis Barbier has brought to my attention the OpenCASCADE Community Edition, or OCE, a project intended to bring together all of the community-generated patches, track bugs, and maybe try some new things. It's discussed at http://www.opencascade.org/org/forum/thread_20111/ which I just mostly read through. I think there are still slightly divergent opinions on whether it should be a fork or just a bugfix repository of use to both upstream and the community. The project is hosted at https://github.com/tpaviot/oce/ which is limited to the /ros directory. It has had 67 commits in the past month, which compares to 7.6 bug fixes/month for upstream between the 6.3.0 and 6.5.0 releases. 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? Denis and I feel that changing to OCE is the right way to go forward. But we would like to get feedback from other users and reverse-dependency user/developers before proceeding. What do you think? -Adam LAM Delenda Est!! As soon as I get time to patch mpich2 for Lucas... -- 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 ha scritto: > > > Da: Adam C Powell IV > > 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: ITP: aster -- Finite Element Analysis (FEA) software for engineering simulations
On Wed, 2011-05-04 at 10:36 +0200, Sylvestre Ledru wrote: > Hello, > > > I would like to help in packaging the Code Aster software[1] for Debian. > Thanks for your interest in the packaging of Code Aster. > You are more than welcome to help. If it is not the case now, you could > join the Debian Science team and start to update the SVN repository. I > will be happy to upload your changes. > 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)? -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: Updating mpi-defaults
On Fri, 2011-04-15 at 11:21 -0500, Steve M. Robbins wrote: > On Wed, Apr 13, 2011 at 08:49:52AM -0400, Adam C Powell IV wrote: > > > > > 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!! > > > > I agree with you that we should switch from LAM to MPICH2 in > mpi-defaults now. In fact, bug #555653 requesting this change > was marked confirmed and pending over a year ago! > > This message is reaching all the listed maintainers of mpi-defaults. > I'd suggest one of you go ahead and make the upload! (If you prefer, > I can do it) And here's another reason to switch: MPICH2 builds on HURD, LAM doesn't, so the entire MPI reverse-depends chain is held up on HURD until we make this change. Remind me, what are the reasons to wait? > > [6] http://lists.debian.org/debian-science/2011/04/msg00023.html LAM Delenda Est!! -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. 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!! > 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=gmsh&arch=mips&ver=2.5.0.dfsg-6&stamp=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
Re: updating mpi-defaults (decommissioning lam)
Greetings, On Sun, 2011-04-10 at 17:13 +1000, Drew Parsons wrote: > On Sat, 2011-04-09 at 14:12 +0200, Manuel Prinz wrote: > > On Fri, Apr 08, 2011 at 10:54:47AM +1000, Drew Parsons wrote: > > > I'm happy to leave bug #575259 untouched if you suspect the patch might > > > be unreliable. I just want lam gone so packages can autobuild. I have > > > no substantial preference between openmpi and mpich2, unless mpich2 > > > should give the same build problems that lam did. > > > > I do not think it is reliable and needs further testing. I'll give a short > > summary of what is going on in this direction and we should discuss how to > > proceed: > > > > - I'm currently packaging Open MPI 1.5 and am working with upstream to > >add support for currently unsupported architectures. It's looking quite > >good so openmpi will build on at least armel and mips(el), maybe others > >or even all architectures. > > - I'd prefer to fix mpi-defautls once we have both openmpi and mpich2 build > >on all architectures, so that we can go for one. (I'm not really in favor > >for one or the other.) I disagree with waiting. We've been waiting for better openmpi arch support for a very, very long time. I tried to work on it a couple of years ago using libatomic-ops, to no avail. LAM is causing packages to FTBFS *now* (PETSc with HDF5 support and gmsh to name two). FWIW, my "vote" would be to go ahead and replace LAM with MPICH2 on the non-OpenMPI arches now, and remove LAM and MPICH1 from the archive. Or if we decide MPICH2 is better than OpenMPI, default to that everywhere. Either way, let's get rid of LAM and MPICH1, and switch mpi-defaults, sooner rather than later. > Judging by the build logs at > https://buildd.debian.org/pkg.cgi?pkg=mpich2, mpich2 is already building > on all architectures. Will be nice to have openmpi available everywhere > too though (not that people will be setting up mpi jobs across their > armel smartphones, but it's the principle of the matter... :) ). Actually, giving large computers and data centers the flexibility to switch between x86[_64]-compatible and ARM or MIPS cores is a real issue in terms of power usage -- one where Debian's mostly-seamless multi-architecture support is a major benefit. > - Using update-alternatives in the MPI packages to replace a library did > >always bother me and I think this is broken. We should consider modifying > >the packages in a way so that mpi-defaults would provide libmpi.so. I did > >not check how a migration path would look like, though. I somewhat agree. Update-alternatives often breaks down because one package provides a link which others don't, etc., leaving one with stranded links or missing links. On the other hand, it's a pain to have to remove and later reinstall, say, OpenMPI -- and all of its rdeps -- just to test building something with, say, MPICH2, so to the extent the alternatives system works it can be quite helpful. On Sun, 2011-04-10 at 14:32 +0200, Lucas Nussbaum wrote: > On 10/04/11 at 17:13 +1000, Drew Parsons wrote: > > A related side question: what are the current pros/cons of openmpi vs > > mpich2, aside from architecture support? > > The market share for openmpi is currently larger than the one of > mpich2, so defaulting to openmpi sounds like a better idea if it can > work on all architectures. This is a small detail relative to getting rid of LAM, but if you're talking about popcon, that's likely because OpenMPI is the default on the post popular arches (amd64, i386, powerpc, ia64, kfreebsd-*), so most people who install MPI-related software will get it. You have to do quite a bit more work to use MPICH2 on those arches. Or are you talking about the broader world beyond Debian (and Ubuntu)? If so, I'd love to hear more... -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 > > 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 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: Science Track Wiki Page
On Sat, 2010-05-01 at 19:51 +0200, Michael Banck wrote: > Hi, > > I started a wiki page on the Science track, collecting the talk > submissions so far (note that official submission deadline is the end of > today UTC-time): > > http://wiki.debconf.org/wiki/DebConf10/TrackScience > > Please add events if I forgot some, or you are going to submit one. Just wondering, is there a tentative schedule for these events somewhere (particularly the round-table)? I'll likely only be able to get to New York for one or two days, and would like to plan travel etc. 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: 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 ?
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 > 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 ?
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 > 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 > 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 ?
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: 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: 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: 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: 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: RFS: latexila
On Thu, 2010-04-29 at 00:45 +0900, Norbert Preining wrote: > On Mi, 28 Apr 2010, Tanguy Ortolo wrote: > > Should I increase the Debian version number of my package before I > > upload a new revision? > > No, you *should* not, because nothing has been uploaded. Just tell > me when you have uploaded a newer version to mentors, please again > with the dget line ;-) Interesting, I always advise people to bump the Debian version as soon as they've distributed it at all anywhere, to avoid confusion by any who might have downloaded it. You can always use -v to specify from which revision to include bug-closings. Is there "official" guidance on this issue anywhere? -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 13:58 -0400, Adam C Powell IV wrote: > On Tue, 2010-04-27 at 09:36 +0200, Nicolas Chauvat wrote: > > > 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! Sorry, bunch of errors on my part, should have -7 on lyre and uploaded by the end of today. -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 w
Re: Question on Salome package organization
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 source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
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.s
Re: MPI implementations in squeeze
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. -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é rules file and make wildcards
On Wed, 2010-02-24 at 21:02 -0500, Aaron M. Ucko wrote: > Adam C Powell IV writes: > > > 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, > > In general, using $(wildcard ...) differs in two ways from using shell > wildcards directly (which I would recommend simply doing here): > > - make expands it before running *any* commands; that allows its use > in some contexts (particularly target lists), but backfires here > because there won't necessarily be a *-packages directory when make > starts. > > - When there are no matches, it expands to nothing, which is not > default shell behavior (but available with bash's shopt nullglob). > > Your observations are consistent with that; in particular, your echo > statement lists site-packages only because you fed the shell an > unquoted wildcard. After a couple of tries, I think I get it: the wildcard is expanded before any of the target is run, and at that point, there's no directory. Okay, in that case I'll just use the unquoted wildcard, and not the $(wildcard...). And it works! Thank you very much for the explanation, it's a funny beast and just RTFM didn't quite get me 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: 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 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: 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 $$obso
Re: Salomé packaging
Hello Andre, No problem regarding the reply time. It takes a while to come up to speed on git, quilt, and the complicated Debian packaging system. I've made a lot of progress in getting salome to build and clean itself properly, so some things should be much easier. The only thing not building properly at this point is VISU, there's a C++ problem mentioned earlier which I don't know how to resolve. On Wed, 2010-02-17 at 11:37 +0100, Andre Espaze wrote: > Hi Adam, > > Thank you very much for your fast reply. I am sorry for not being as > responsive, I am new to Debian packaging and I am also discovering git. > > > > I have succeeded to build most of the Salomé modules with the > > > version 5.1.3-3 that you uploaded at http://lyre.mit.edu/~powell/salome/ > > > however I wanted to discuss the following problems: > > > > > > - the configure step in 'debian/rules' needs to add VTKSUFFIX="-5.4" > > > else vtk is not found and many components do not build. > > > > Indeed, I built -3 before VTK 5.4 was in unstable. I am using > > --with-vtk-version=5.4 which seems to do the same thing. > Yes but I have a slight preference for VTKSUFFIX because it avoids such > warning in the configure step:: > > WARNING: unrecognized options: --with-vtk-version > > when the module does not deal with VTK. Good point. I have just made that change, thanks. > Anyway I would like to discuss > the configure step in the following ticket: > http://www.python-science.org/ticket/1405 You make a good point about different features needed for different modules. But I think the loop is helpful because it is easy to change or fix variables which apply to all of the modules, and cuts down on the size of the rules file. It needs to do the documentation separately for each module because not all modules have documentation; I'd like to keep from having to do that in the configure-stamp target. That said, if you can produce a patch which does this without making things too long (for example by having a COMMON_CONFIGURE_OPTIONS makefile variable for options needed by all modules), I will likely adopt it. [Skipping resolved issues...] > > I'm impressed that it actually runs -- hadn't tried to run it yet! > Yes, it runs, with very few modules (only KERNEL and GUI from now) > but that is already a nice start. Great, let's see how we can make the other modules work... > > > How to you plan to collaborate on the package building? I would suggest > > > to use the project http://www.python-science.org/project/salome-packaging > > > because I can be efficiently organized on such a platform. Would you > > > like to add a git or mercurial repository on which we will share the > > > package source code? > > > > It is already on the Debian Science git repository at > > http://git.debian.org/git/debian-science/packages/salome.git/ . > Thank you, I built Salomé again from that repo. My tickets are > there: > http://www.python-science.org/project/salome-packaging/0.1 > and we can discuss the specific details off list. Sounds good. Thanks for your help! -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 Andre, On Thu, 2010-02-11 at 17:32 +0100, Andre Espaze wrote: > Hi Adam, > > I am André Espaze, the Logilab's employee supposed to help you in the > Salomé packaging for Debian. First I wanted to thank you for the great > work that you did on the current package. Then I would like to let you > know my progress on the testing part. Great, thanks for following up on this. > I have succeeded to build most of the Salomé modules with the > version 5.1.3-3 that you uploaded at http://lyre.mit.edu/~powell/salome/ > however I wanted to discuss the following problems: > > - the configure step in 'debian/rules' needs to add VTKSUFFIX="-5.4" > else vtk is not found and many components do not build. Indeed, I built -3 before VTK 5.4 was in unstable. I am using --with-vtk-version=5.4 which seems to do the same thing. > - it lacks the omniorb4-nameserver package in the dependency list > else the KERNEL component does not find the omniNames command. Okay, the salome binary package needs to depend on this, right? I don't think it needs to be in Build-Depends. > - as you said, the med 2.3.5 library needs to be built manually > with hdf5-1.8.4 but the main problem is that tests do not pass > in that case. There are patches to hdf5 (bug 510057) and med (bug 566828, fix is in the git repository) to build these two using the default MPI implementation, e.g. OpenMPI on most arches, LAM on others (soon MPICH2, which will require further changes to the current HDF5 package...). The HDF5 team is a bit slow to adopt patches, but hopefully plans for a March freeze will get this done, so MED-MPI and Salomé can get in. > - it seems to lack the 'config.h' file in the libopencascade-* > packages. Else do you know where that file could be? I fear that > some components (like GEOM) really need it. Denis replied to this. I didn't notice any problems building GEOM, are there run-time issues which could result from missing this file? > - the GEOM module crashes when trying to add a geometrical object I see. Could this be related to the OCC config.h issue? I don't see how... I'm impressed that it actually runs -- hadn't tried to run it yet! > You can find all the steps that I did, more details and also more problems > at: http://www.python-science.org/ticket/1383 Thanks, I'll look over this. > How to you plan to collaborate on the package building? I would suggest > to use the project http://www.python-science.org/project/salome-packaging > because I can be efficiently organized on such a platform. Would you > like to add a git or mercurial repository on which we will share the > package source code? It is already on the Debian Science git repository at http://git.debian.org/git/debian-science/packages/salome.git/ . I'm trying to get it to work with git/quilt, as right now a couple of the "clean" targets are a bit too aggressive -- they remove a lot that shouldn't be removed. > I am looking forward to work with you, I am as well! Thanks for the 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: 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 15:18 +0100, Axel Freyn wrote: > Hello Adam, > On Mon, Feb 08, 2010 at 08:39:50AM -0500, Adam C Powell IV wrote: > > 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 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. > If I remember correctly, that renaming was due to the compiler-update > from g77 to gfortran (which are NOT ABI-compatible!): Packages whose > names end with "gf" are supposed to be compiled and linked with > gfortran, while the older ones use g77. As this was a release goal for > Lenny, it should be finished by now - and also atlas should use now > gfortran, thus being again ABI-compatible with BLAS. That much I got... > > 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 they no longer ABI-compatible? Is it possible to get back to the > > old state of things? > Did you try to install the package "libatlas3gf-base"? Last time I checked > it on my machine (squeeze), it was no problem to switch between netlib > and atlas withour recompiling: just changing LD_LIBRARY_PATH to link to > the netlib-versions did the trick. And I have > /usr/lib/atlas/libblas.so.3gf which belongs to the package > "libatlas3gf-base". I have that package installed. I think I understand. So whereas there used to be an /etc/alternatives mechanism for selecting between netlib and ATLAS libraries, now one must use LD_LIBRARY_PATH. Makes sense. So the alternatives symlinks I mentioned above are now useless? Or do they need updating so they're at least consistent? Perhaps they should both link from libblas.so.3gf? -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
BLAS/LAPACK implementations
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 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 they no longer ABI-compatible? Is it possible to get back to the old state of things? -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 >
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
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. Among 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. 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: [Pkg-scicomp-devel] Bug#563705: MPI: Add Fortran library symlink(s)
On Mon, 2010-01-04 at 20:21 +0100, Lucas Nussbaum wrote: > On 04/01/10 at 13:25 -0500, Adam C Powell IV wrote: > > I propose libmpif77.so and libmpif90.so slaves to the mpi alternatives > > symlink which link to libfmpich.so, libmpi_f77.so, libmpi_f90.so etc. > > Isn't it more appropriate to use mpif77/mpif90 (which are managed using > alternatives) to compile, instead of specifying the library to link to > manually? This should work for Fortran (and probably C) objects. But if they are mixed Fortran/C++/C, will all mpif77/mpif90 implementations inspect the object files and properly link to all of the necessary language libraries? I'm pretty sure they don't, which is why many packages have MPI_LIBS make variables to include them. If you're sure that all mpif77/mpiCC/etc. implementations do this right, then feel free to close this bug. -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#563705: MPI: Add Fortran library symlink(s)
Source: openmpi,mpich2,lam,mpich Severity: wishlist X-Debbugs-CC: debian-science@lists.debian.org Greetings, There are mpi alternative slaves for libmpi.so and libmpi++.so which are convenient for C and C++ development. But a lot of MPI code is in Fortran (77 or 90), for which there are no such symlinks. This requires packages to use various methods to determine which MPI implementation is installed by mpi-default-dev in order to figure out how to link to the Fortran lib. I propose libmpif77.so and libmpif90.so slaves to the mpi alternatives symlink which link to libfmpich.so, libmpi_f77.so, libmpi_f90.so 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: 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
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
Here are my opinions for what they're worth... On Mon, 2009-11-09 at 16:47 -0800, Nicholas Breen wrote: > There's been some preliminary discussion before about dropping the latter two > [1], though legacy support is an issue as well [2]. Currently, the MPI > situation is fairly messy: 18 source packages depend on mpi-default-dev > (OpenMPI or LAM, depending on architecture), but another 18 depend on various > permutations of the implementations directly [3], with no particular > consistency. The concerns you raise are the motivation for mpi-defaults. And IMO 50% voluntary transition there with no particular push or strong impetus is pretty good progress. > >From a package maintainer standpoint, I'd like to see us start reducing the > number of implementations to build client packages against, even if we > maintain > all the MPI implementations themselves (perhaps moving them to the 'oldlibs' > section). What I'm wondering is: > > * in mpi-defaults, should MPICH2 replace LAM for architectures not supported >by OpenMPI? I think that would make a lot of sense since LAM is end-of-life. > * should we start filing wishlist bugs asking packagers not to build against >MPICH (1) and LAM? I've done this for packages I care about, and posted patches, and done NMUs (with maintainer approval). So I'd say go for it. > * 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. > This is orthogonal to solving #552429, which will need action before the > squeeze release in any case. Indeed. And while we're at it, given the popularity of fortran, we need a consistent fortran library alternatives link as a slave of mpi... Will add that to the bug. -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: hi team!
On Fri, 2009-09-25 at 10:31 +0200, Sylvestre Ledru wrote: > Hello Andrea, > > Le vendredi 25 septembre 2009 à 08:01 +, Andrea Neroni a écrit : > > Hi, > > I'm graduated in physic and actually a student for the Master of > > science, Debian user from some years. Recently I decided to spend some > > of my free time > > to collaborate with Debian. > > I would want to join the Debian Science Team because some packages are > > useful in my studies and everywhere developer recommend to join a team > > to start contribution. > > Since I'm new to this I need a bit of help for improving my knowledge > > of the Debian distribution and packaging/mantaining the system. > > > > How can I collaborate with you? > There are different ways of doing it. > > The main one is to upload and maintain new packages in the archive. > You can also help us by fixing some bugs and participate to the > maintenance of the packages you are using. Simpler than uploading and maintaining packages is just testing them, and filing bugs where appropriate, or making "wishlist" suggestions. A lot of people just use packages, find something wrong, and gripe to themselves without notifying the package maintainer. And there is always a need for better documentation, so if you find something difficult, try to think of a way to explain it so the next person has an easier time, and send it to the package maintainer. -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: 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: MPICH2 packaging
Hello Pavan, The best starting point for the mpich package is: http://packages.qa.debian.org/m/mpich.html . There you can get the .diff.gz file (labeled ".diff" under Source package), which has all of the "control" files in the debian/ directory, and subscribe to receive emails about package changes. For more information about Debian packages, the best starting point is probably http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html . -Adam On Mon, 2009-06-15 at 22:19 -0500, Pavan Balaji wrote: > Thanks Adam. Btw, can you send me the control files for MPICH-1? I can > try to modify them to work with MPICH2 (I don't know much about debian > binary package creation, but am somewhat familiar with spec files, so a > link to get me started on this would be useful as well). > > All: If anyone is interested in maintaining MPICH2 for Debian, please > let me know. We'd like to work closely with you to make sure MPICH2 is > well supported for Debian. > > Thanks, > > -- Pavan > > On 06/15/2009 05:32 PM, Adam C Powell IV wrote: > > Hello Pavan, > > > > Thank you for the inquiry. I've somewhat left MPICH for now (focusing > > on OpenMPI, which I don't maintain but use), and assigned its > > maintenance to the Debian Scientific Computing team. But I think there > > are others very interested in MPICH2, and am copying the debian-science > > list to gauge interest. > > > > -Adam > > > > On Mon, 2009-06-15 at 16:28 -0500, Pavan Balaji wrote: > >> Hello, > >> > >> I'm one of the MPICH2 developers at Argonne National Laboratory. I > >> noticed that you were the package maintainer for MPICH-1 for Debian. As > >> you might know, most of our current effort is towards MPICH2. We just > >> released v1.1 a few days ago > >> (http://www.mcs.anl.gov/research/projects/mpich2). > >> > >> We wanted to see if we can help get MPICH2 packaged into Debian. Since > >> you have been maintaining MPICH-1, I thought I should just check with > >> you first to see if you can help us with this. > >> > >> Please let us know. > >> > >> Thanks, > >> > >> -- Pavan -- 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: MPICH2 packaging
Hello Pavan, Thank you for the inquiry. I've somewhat left MPICH for now (focusing on OpenMPI, which I don't maintain but use), and assigned its maintenance to the Debian Scientific Computing team. But I think there are others very interested in MPICH2, and am copying the debian-science list to gauge interest. -Adam On Mon, 2009-06-15 at 16:28 -0500, Pavan Balaji wrote: > Hello, > > I'm one of the MPICH2 developers at Argonne National Laboratory. I > noticed that you were the package maintainer for MPICH-1 for Debian. As > you might know, most of our current effort is towards MPICH2. We just > released v1.1 a few days ago > (http://www.mcs.anl.gov/research/projects/mpich2). > > We wanted to see if we can help get MPICH2 packaged into Debian. Since > you have been maintaining MPICH-1, I thought I should just check with > you first to see if you can help us with this. > > Please let us know. > > Thanks, > > -- Pavan > -- 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
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
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: Bug#521918: pbuilder --build --binary-arch invokes 'build' target
On Mon, 2009-05-11 at 15:11 +0200, Filippo Rusconi wrote: > On Mon, May 11, 2009 at 02:11:18PM +0200, Julien Cristau wrote: > > > > On Mon, May 11, 2009 at 13:46:30 +0200, Lionel Elie Mamane wrote: > > > > > No, policy is very clear on that: if you call the "build" target, you > > > _must_ satisfy Build-Depends-Indep and Build-Conflicts-Indep: > > > > > And policy is clearly not followed by any actual practice on this point. > > So that's as much a bug in policy as anything else (#374029). > > > > Cheers, > > Julien > > Well, but then, why have new packagers trained by studying the Policy? > > Look at my own situation (which must not be a rare one, I suppose): > I've worked to make a Debian package of the software I develop [0] > with the idea that the Debian Policy had to be implemented in the > package making. > > That software recently entered Debian through NEW and almost > immediately after that I got a FTBFS bug report [2]: pbuilder called > debian/rules build without installing the required > > Build-Depends-Indep: texlive-latex-extra, texlive-latex-recommended, > texlive-fonts-recommended > > which of course failed because pdflatex was not found on the system > and thus could not build the LaTeX docs of the software. I don't understand. I maintain a bunch of packages with tex in Build-Depends-Indep, and autobuilders never have a problem with them. Why are they calling the build target, and not build-arch? -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 >& .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
[Fwd: opencascade_6.3.0.dfsg.1-1_amd64.changes ACCEPTED]
OPEN CASCADE IS IN DEBIAN MAIN!! Now others like Elmer and Salomé will be eligible, and without issue when LGPL Qt 4.5 goes into unstable (it's currently in experimental). Open CASCADE should be QPL-compatible, but Qt 4.4 is GPL and no longer QPL, so that doesn't currently work. FreeCAD is also a candidate, though because it links to the GPL Coin3D lib, that will require Debian to accept the Open CASCADE license as GPL-compatible... At this point I don't see a reason why they wouldn't. And there was much rejoicing! Cheers, Adam Forwarded Message > From: Debian Installer > To: Adam C. Powell, IV , Debian Science > Maintainers > Subject: opencascade_6.3.0.dfsg.1-1_amd64.changes ACCEPTED > Date: Sat, 07 Mar 2009 15:49:57 + > [snip] > Announcing to debian-devel-chan...@lists.debian.org > Closing bugs: 487116 491912 494715 496668 501128 501352 > > > Thank you for your contribution to Debian. -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#505224: RFP: freecad -- An extensible CAx program (alpha)
On Wed, 2009-02-18 at 17:18 +0100, Teemu Ikonen wrote: > On Tue, Feb 17, 2009 at 9:18 PM, Denis Barbier wrote: > > On 2009/2/10, Adam C Powell IV wrote: > > [...] > >> Robert, I owe you an answer on why the OCTPL is GPL-incompatible. > >> IANAL, TINLA, TINASOTODP, etc. but here goes: > >> * 4. para 4: "If you distribute or sublicense the Software (as > >>modified by You or on Your behalf as the case may be), You cause > >>such Software to be licensed as a whole, at no charge, to all > >>third parties..." The GPL does not require "at no charge", and > >>even expressly allows charging for software, so this is an > >>additional restriction beyond the GPL. > > > > GPL 2, section 2.b) > >You must cause any work that you distribute or publish, that in > >whole or in part contains or is derived from the Program or any > >part thereof, to be licensed as a whole at no charge to all third > >parties under the terms of this License. > > > >> * 4. para 5: "You document all Your Modifications, indicate the > >>date of each such Modifications, designate the version of the > >>Software You used..." None of this is required by the GPL, so > >>all of these are additional restrictions. > > > > GPL 2, section 2.a) > >You must cause the modified files to carry prominent notices > >stating that you changed the files and the date of any change. > > > > To me, OCTPL 6.3 (as found in OpenCascade sources, not the one > > at the website, which is outdated IIRC) is identical to LGPL 2.1, they > > paraphrased it, and I believe that OCTPL 6.3 is compatible with GPL. Thanks Denis, I stand corrected. > Interesting. I assume this would mean that works combining GPL and > OCTPL code (such as FreeCAD) would be acceptable to Debian main? IANAL, TINLA, etc. but I assume so. > Would it make sense to send a note about the GPL compatibility of > OCTPL and its similarity to LGPL to the FTP-master? Maybe this would > get OpenCascade out of the NEW queue, it's been sitting there 4 months > already. I don't think so. Last I corresponded with them, their last remaining concern was about whether the Matra Datavision copyright notices could be assumed to have transferred to Open Cascade SAS. That was six weeks ago... Hopefully the lenny release will let them get back to NEW queue processing. -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#505224: RFP: freecad -- An extensible CAx program (alpha)
On Tue, 2009-02-03 at 14:10 +, Chris Walker wrote: > On Tue, Feb 03, 2009 at 02:37:31PM +0100, Robert Millan wrote: > > On Tue, Feb 03, 2009 at 11:42:07AM +, Chris Walker wrote: > > > Robert Millan writes: > > > > > > > Package: wnpp > > > > Severity: wishlist > > > > Owner: Robert Millan > > > > > > > > * Package name: freecad > > > > > > > > > I've added this package to the the engineering metapackage in > > > debian-science. It should appear at > > > http://cdd.alioth.debian.org/science/tasks/engineering.html when the > > > cron job next runs. > > > > > > As you have prepared a preliminary package, I've treated this as an > > > ITP and put you down as responsible for the package. I can easily > > > remove you if you wish. > > > > > > For those reading on Debian-science, more details of the package below. > > > > Hi, > > > > There are long-standing license issues, which are being worked on by Adam > > Powell and others at the moment. > > Oh right - good luck. The issue here is that FreeCAD links to Coin3D which is GPL, and to Open CASCADE which is OCTPL [1] and is not GPL-compatible. The Coin3D developers refuse to make a GPL exception for Open CASCADE [2]. And I have never been able to reach anyone at Open CASCADE for any purpose (was the maintainer of the Debian package), except indirectly via the Forum. [1] http://www.opencascade.org/occ/license/ [2] https://jira.sim.no/browse/COINSUPPORT-425 So unless they separate the Coin3D and Open CASCADE linkages into independent binaries, FreeCAD will unfortunately not be distributable for the foreseeable future. :-( Robert, I owe you an answer on why the OCTPL is GPL-incompatible. IANAL, TINLA, TINASOTODP, etc. but here goes: * 4. para 4: "If you distribute or sublicense the Software (as modified by You or on Your behalf as the case may be), You cause such Software to be licensed as a whole, at no charge, to all third parties..." The GPL does not require "at no charge", and even expressly allows charging for software, so this is an additional restriction beyond the GPL. * 4. para 5: "You document all Your Modifications, indicate the date of each such Modifications, designate the version of the Software You used..." None of this is required by the GPL, so all of these are additional restrictions. The additional restrictions in this license make a derivative work (e.g. a GPL binary linked to this library, or the LGPL FreeCAD binary linked to the GPL Coin3D library and OCC) a violation of the GPL. The copyright holder of the GPL code can sue for copyright infringement, which usually just means "stop distributing the infringing product". > > Also, the package is maintained outside of > > the debian archives by Teemu Ikonen. My preliminar work only served to > > incorporate some improvements in Teemu's tree. Please leave this as RFP. > > OK. > > Should I list Teemu Ikonen instead of/as well as you as the person > responsible? Why not just list Debian Science Maintainers as maintainer? -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 09:45 -0500, Adam C Powell IV wrote:
> On Thu, 2008-11-20 at 12:35 +0100, Ondrej Certik wrote:
> > On Thu, Nov 20, 2008 at 11:14 AM, Manuel Prinz
> 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.
This was just accepted! Yay! I'm now wishist bugging all of my
packages to use it, and will start uploading with hypre tonight.
-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
arpack: unfreeze request
Greetings, arpack was removed from lenny and sid because of non-free clauses in its license, see bug 491794 for details. Note this bug was filed after the freeze. It is an important scientific computation package for parallel linear system analysis which is in etch. Recently upstream changed its license so it is DFSG-free. I built and uploaded it with minimal changes, and it is now in unstable. I think that because arpack is in etch and is used by many prominent programs, such as the Elmer finite element multiphysics package, it should really be part of the lenny release. Furthermore, this would "reward" upstream for changing the license at the request of Debian maintainers. Therefore please un-freeze arpack so it can transition into testing and release with lenny. [Please either include debian-science in replies, or CC me, as I'm not subscribed to debian-release.] 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: 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
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
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
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 thin
Re: building package with different libs
On Sat, 2008-11-15 at 21:04 -0600, Dirk Eddelbuettel wrote: > On 14 November 2008 at 23:12, 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. > > [ For r-cran-rmpi, I also fall back to using LAM where Open MPI is > missing. Perusing NEW today, I saw that Adam falls back to MPICH for the new > Arpack. May be a better fall-back, but I personally have used LAM and no > MPICH before Open MPI. I guess at some point we need to consolidate out MPI > efforts. ] > > | 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. > | > | 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. > 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 the same as lam? And within mpich, ch_p4 is the "default" but should be below ch_p4mpd (if you install mpd then you're probably running the daemons); I'll put ch_shmem between 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: [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
Hello Mikko, And let me thank you and CSC for being a model upstream partner in the effort to make a high-quality Debian package for such a wonderful piece of software. Your responsiveness, openness to patches, and willingness to discuss license issues have all been far above and beyond any other similar organization that I have worked with. On Thu, 2008-11-13 at 23:49 +0200, Mikko Lyly wrote: > Hello Adam, > > First of all, thank you for your effort, it is greatly appreciated. > > >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... :-( > > I do understand the problem, but could you please elaborate the Debian > point of view? > > I think we are good wrt the licence of Arpack (we reproduce the > copyright notice in the documentaion, at least, as required by Arpack > license for binary distributions, as well as for source). 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. The reason is that, at least under the FSF and Debian interpretation, linking GPL code with libraries with more restrictions creates a derived work which violates the terms of the GPL. Debian is very particular about making sure we are always "in the clear" about any potential copyright issue. > 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? 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/ 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: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
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). > As can be seen in the debian/rules file I add to modify the usual > configure --prefix=/usr > because, even if one installs using > make install DESTDIR=... > many files tend to be sent to /usr/lib. etc. > This means that I had to patch some configure files. The patch files are > in the debian directory, alldough the patches have already been applied. Yup, upstream is happy with all of my patches except the one which gets rid of rpath, so that should be the only one I need to maintain going forward. > I have used the version 5.4.1 of elmer but the ElemerGUI > ElemerGUIlogger and elmergrid was picked form the trunk svn. > > The configure files are tuned by the authors with the -m64 compilation > flag. I have made the package only available for the amd64 > architectures. Migrating to different architectures and even to i386 > means patching more the configure system and has to be checked with the > authors. Ah, I didn't notice this, thanks for the heads-up. I'll make sure to take care of this before uploading. > Lots of room for improvement as you can see but I hope it can be used as > a seed . Great, thanks again! > PS: I have also backported gmsh to etch and also created a getdb package > in the same repository. > Regarding getdb, I have succeeded with the etch backport but lenny and > sid are failing due to lapack3. In the case of lenny and sid I am using > lapack-dev and I get > /tmp/buildd/getdp-1.2.1/Arpack/second.f:29: undefined reference to `etime_ > Does anybody have an idea? Use the Debian ARPACK package. They've removed it from all of the mirrors, but I just uploaded a new one to NEW and you can get it at: http://lyre.mit.edu/~powell/arpack/ . 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: Elmer -- Finite element software for multiphysics problems
On Mon, 2008-11-10 at 16:32 -0500, Adam C Powell IV wrote: > 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 it turns out, only -lmetis is needed from Scotch 5.0.6 onward (in Debian). However, it looks like Scotch only implements a small subset of the METIS interface. It's enough for libMesh and deal.II, but Elmer needs a couple of functions it doesn't provide (METIS_PartMeshNodal and METIS_PartMeshDual). 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
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
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: 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=0&sc=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
