[Pkg-octave-devel] fw: gfortran transition release goal proposal
Paul Brossier
piem at piem.org
Sun Jul 22 23:16:48 UTC 2007
On Sun, Jul 22, 2007 at 01:19:14AM +0300, Riku Voipio wrote:
> Hi,
>
> The proposal to transition from the outdated g77 to gfortran did
> not result any comments. Which rises the suspicion that the maintainers
> of affected packages are not reading debian-release or debian-toolchain.
>
> If you have suggestions, critique, or you are busy but accept NMU'ing
> your packages for gfortran transition.. please speak now.
>
> Some of the packages gfortran transition affects are also affected by
> the long double transition. This includes atleast the following fortran
> packages:
>
> lam, atlas3, fftw3, hdf5, mpich1.0, petsc, pdl
>
> Therefor, I think it would make sense to start g77 -> gfortran
> transition promptly, to avoid transitioning same packages twice.
>
Hi all,
fftw3 changed to gfortran in the last upload, after a discussion on the
BTS with Warren Turkal and upstream Steven Johnson (see #392301).
I will prepare uploads for the long double issue and for fftw2. I might
need sponsoring as my new key is waiting to get into the ring.
Am I wrong assuming {k6,k7,p4}fftwgel are not affected as they are i386
only?
thanks, piem
> --
> "rm -rf" only sounds scary if you don't have backups
> Old-Return-Path: <nchip at kos.to>
> Date: Thu, 5 Jul 2007 17:17:42 +0300
> From: Riku Voipio <riku.voipio at iki.fi>
> To: debian-release at lists.debian.org
> Cc: debian-toolchain at lists.debian.org
> Subject: gfortran transition release goal proposal
> Resent-Message-ID: <HnNYQD.A.4FH.v2PjGB at murphy>
> Resent-From: debian-toolchain at lists.debian.org
> List-Id: <debian-toolchain.lists.debian.org>
> Resent-Sender: debian-toolchain-request at lists.debian.org
> Resent-Date: Thu, 5 Jul 2007 14:18:23 +0000 (UTC)
>
> G77 to Gfortran Transition
>
> We would like to present the G77 to gfortran transition as a Lenny
> release goal. The Debian developers responsible for the transition
> are Riku Voipio <riku.voipio at iki.fi> (fortran application and library
> packages) and Mathias Klose <doko at debian.org> (toolchain packages).
>
> * Why do we need one
>
> Upstream did release the last version of the g77 frontend with
> GCC-3.4. gfortran 4.2 is now considered a viable replacement for g77.
> However, code must not link at the same time against -lg2c and
> -lgfortran. To allow partial upgrades we need to rename all library
> packages built with g77 and linked against g2c when they are rebuilt
> with gfortran.
>
>
> Once the transition is completed, we are able to remove GCC-3.4 from
> the distribution (gpc needing an update for GCC-4.1 as well).
>
> * Actions
>
> If your package build-depends on g77, you need to adjust your
> build-depends from g77 to gfortran. If you build-depend on a library
> package containing a shared library linked against libg2c, wait until
> all of these libraries are rebuilt with gfortran. Tighten the
> build-depends on those lib*-dev packages to the first version built
> with gfortran.
>
> If your package provides a library that exports fortran functionality,
> it needs to be renamed. The recommended suffix for the new package
> name is "gf". If your package is affected by also by the long double
> transition, you can choose whichever suffix for your library.
>
> For example, lapack3 is now:
>
> Package: lapack3
> Binary: lapack3, lapack3-test, lapack3-dev, lapack3-pic, lapack3-doc
> Build-Depends: debhelper (>= 4), g77, refblas3-dev
>
> should become:
>
> Package: lapack3
> Binary: lapack3gf, lapack3-test, lapack3-dev, lapack3-pic, lapack3-doc
> Build-Depends: debhelper (>= 4), gfortran, refblas3-dev (>= <first version built with gfortran)
>
> * Caveats
>
> Some of the command line options supported by g77 have been dropped. You
> can usally just drop them.
>
> On ia32 and amd64, you might need to use the -ffloat-store option for
> gfortran to achieve identical behaviour with floating points. This was
> at least the case for refblas3.
>
> * Affected packages
>
> For the trivial packages, which build-depend on g77 but do not use or
> provide fortran libs, replace g77 with gfortran in build-depends and
> upload.
>
> Aurelien Jarno <aurel32 at debian.org>
>
> * med-fichier
>
> Steinar H. Gunderson <sesse at debian.org>
>
> * pvm (g77 only used for example code.)
>
> Radovan Garabik <garabik at melkor.dnp.fmph.uniba.sk> (MIA)
>
> * zivot
>
> Kurt Roeckx <kurt at roeckx.be>
>
> * libtool
>
> James R. Van Zandt <jrv at debian.org>
>
> * minpack
> * multimix
>
> Chris Lawrence <lawrencc at debian.org>
>
> * r-noncran-lindsey
>
> Justin Pryzby <justinpryzby at users.sf.net>
>
> * saods9
>
> The main knot to open is refblas3 -> lapack3 -> atlas3. It expands
> with scalapack, octave, netcdf, mpich and lam.. Then, a bunch of python
> packages, python-numpy, python-numeric etc need these as well. The actual
> details of upload order are still under work.
>
> Camm Maguire <camm at enhanced.com>
>
> * refblas3
> * lapack3
> * lam
> * atlas3
>
> Adam C. Powell, IV <hazelsct at debian.org>
>
> * mpich
> * petsc
>
> Debian Scientific Computing Team <pkg-scicomp-devel at lists.alioth.debian.org>
>
> * ufsparse
>
> Kevin B. McCarty <kmccarty at debian.org>
>
> * cernlib
> * geant321
> * mclibs
> * mn-fit
> * paw
>
> Paul Brossier <piem at debian.org>
>
> * fftw
> * fftw3
> * k7fftwgel
> * k6fftwgel
> * p4fftwgel
>
> Warren Turkal <wt at penguintechs.org>
>
> * netcdf
>
> Debian Octave Group <pkg-octave-devel at lists.alioth.debian.org>
>
> * octave2.9
> * octave2.1
>
> "Leaf" packages, that can be uploaded as soon as all their
> dependencies have been transitioned.
>
> Christophe Prud'homme <prudhomm at mit.edu>
>
> * arpack
>
> Daniel Baumann <daniel.baumann at panthera-systems.net>
>
> * lush
>
> Michael Banck <mbanck at debian.org>
>
> * mpqc
> * psicode
>
> Adam C. Powell, IV <hazelsct at debian.org>
>
> * pysparse
>
> Matthias Klose <doko at debian.org>
>
> * python-numarray
> * python-numeric
>
> Konstantinos Margaritis <markos at debian.org>
>
> * blitz++
>
> Debian Scipy Team <deb-scipy-devel at lists.alioth.debian.org>
>
> * python-numpy
> * python-scipy
>
> Hamish Moffatt <hamish at debian.org>
>
> * wsjt
>
> Debian QA Group <packages at qa.debian.org>
>
> * tela
> * libextutils-f77-perl
>
> Henning Glawe <glaweh at debian.org>
>
> * pdl
>
> Muammar El Khatib <muammarelkhatib at gmail.com>
>
> * blacs-pvm
> * blacs-mpi
> * scalapack
>
> Nicholas Breen <nbreen at ofb.net>
>
> * gromacs
>
> Mark Hymers <mhy at debian.org>
>
> * kst
>
> * Risks
>
> - MIA or inactive maintaintainers
>
> React with timely NMU's
>
> - Slow NEW que
>
> Renames require visit in NEW. run packages via experimental first
> to avoid breaking sid for long times?
>
> - Upstream support
>
> gfortran-4.2 upstream seems enthusiastic about letting g77 to it's
> rest, so good support is expected. Individual fortran software might
> be quite old upstreams can be inactive.
>
> - gfortran-4.2 on ports
>
> There is a risk that both gfortran upstream finds it uninteresting
> to fix bugs in strange ports, while porters remain uninterested in
> fortran. It needs to be shown to people that major parts of debian
> still have dependencies to fortran packages.
>
> * Feedback and Further discussion
>
> In case we have missed something, you have some sugestions or other
> feedback for the release goal proposal, please use the
> debian-toolchain at lists.debian.org list.
>
> --
> "rm -rf" only sounds scary if you don't have backups
>
>
> --
> To UNSUBSCRIBE, email to debian-toolchain-REQUEST at lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org
More information about the Pkg-octave-devel
mailing list