Re: dpkg-deb temporary storage directory

[Adam C Powell IV]

On Sat, 2010-03-06 at 18:15 +0100, Cyril Brulebois wrote:
> Adam C Powell IV  (06/03/2010):
> > How can I change the temporary directory where it builds the
> > tarballs? I don't see anything in the manpage or dpkg-deb --help
> > output.
> 
> (Untested)
> 
> It probably honours TMP/TMPDIR environment variables.

Ah yes, a search for "dpkg-deb TMPDIR" turns up bug 247086 where someone
asked to include this in the documentation.  The reply: but it's so
obvious, no need to include it.  Version 1.10.22 claimed to fix it, but
only fixed one part of the bug, the TMPDIR issue remained.

I've been a DD for ten years and didn't think of it, so I can't agree
about the obviousness...  I think I'll open a new bug.

> > [Please CC me in replies.]
> 
> [Done.]

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

dpkg-deb temporary storage directory

[Adam C Powell IV]

Greetings,

I'm working on a package for Salomé, and some of its binaries are really
huge -- way too big, I'll split them up at some point.

But in the meantime, I'm getting the following error and want to avoid
it:

dpkg-deb: building package `salome-doc' in `../salome-doc_5.1.3-5opvk1_all.deb'.
dpkg-deb (subprocess): data: internal gzip error: read(4096) != write(0): No 
space left on device
dpkg-deb: subprocess  from tar -cf returned error exit status 2
dh_builddeb: dpkg-deb returned exit code 2

The partition where I'm building this has 6 gigs of free space, which is
more than enough room, and building within a chroot on that partition
works fine.  So I guess it's trying to build a tarball in a temporary
storage directory, and / has "only" 380 megs free.

How can I change the temporary directory where it builds the tarballs?
I don't see anything in the manpage or dpkg-deb --help output.

[Please CC me in replies.]

-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

[Adam C Powell IV]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-scie...@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: ITP: mpi-defaults -- Meta-packages depending on appropriate MPI -dev and -bin packages for each platform

[Adam C Powell IV]

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

[Adam C Powell IV]

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

[Adam C Powell IV]

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

ITP: Elmer -- Finite element software for multiphysics problems

[Adam C Powell IV]

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

ITP: deal.II -- Finite element library

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

Package name: deal.II
Version: 6.1.0
Author: Wolfgang Bangerth, Ralf Hartmann, Guido Kanschat
License: QPL
URL: http://dealii.org/

deal.II is a C++ class library for parallel solution of partial
differential equations using adaptive finite elements.  It interfaces
with the PETSc suite of parallel solvers and data objects, and METIS (or
its free counterpart Scotch) for mesh partitioning, and can use several
other packages for meshing and results visualization.

-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: MUMPS -- MUltifrontal Massively Parallel sparse direct Solver

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

Package name: mumps
Version: 4.7.3
Author: Patrick Amestoy et al.
License: public domain
URL: http://mumps.enseeiht.fr/
Description: MUltifrontal Massively Parallel sparse direct Solver

MUMPS implements a direct solver for large sparse linear systems, with a
particular focus on symmetric positive definite matrices.  It can
operate on distributed matrices e.g. over a cluster.  It has Fortran and
C interfaces, and can interface with ordering tools such as METIS.

Version 9.3 of Code_Aster (ITP 458812) uses MUMPS, so this package will
play a role in that 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

ITP: Triangle -- Two-dimensional quality mesh generator and Delaunay triangulator

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

Package name: triangle
Version: 1.6
Author: Jonathan Richard Shewchuk <[EMAIL PROTECTED]>
License: non-free (distribution for fee prohibited)
URL: http://www.cs.cmu.edu/~quake/triangle.html
Description: Two-dimensional quality mesh generator and Delaunay triangulator

Triangle is a nice mesh generator which is currently distributed as part
of the Debian opencascade package (as version 1.4).  This is (probably)
the only explicitly non-free part of that package (though Debian has not
registered an official position on the Open Cascade Technology Public
License), so splitting it out would allow the rest of opencascade to go
into contrib.  Splitting it out would also allow other packages to link
directly to it, which is currently difficult in opencascade, as triangle
is buried in libTKMesh.

-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: Re: Arch-dependent Depends

[Adam C Powell IV]

Terrific, I will give that a try, thanks very much!

-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: Arch-dependent Depends

[Adam C Powell IV]

On Sun, 2008-06-22 at 18:31 +0200, Goswin von Brederlow wrote:
> Adam C Powell IV <[EMAIL PROTECTED]> writes:
> 
> > Because hypre upstream doesn't make static libs, and I got tired of
> > making a new patch with every release, libhypre-dev is arch all without
> > static libs.  However, it needs to depend on openmpi on some arches, and
> > lam4-dev on others.  Using the same syntax as Build-Depends doesn't
> > work.
> >
> > Is there a way to do this, or do I need to make libhypre-dev arch any
> > and set the dep using substvars, even though its contents are
> > arch-independent?  I notice that Policy section 7.1 provides for
> > arch-dependent Build-Deps, but there's nothing similar for Depends...
> 
> There is no such syntax so you have to something else.
> 
> As you already said you can make libhypre-dev arch any and you must.

"Must" is a bit strong.  There's nothing in Policy (8.4) stating this;
please correct me if I'm wrong.  And 8.3 uses "usually" regarding
provision of a static library.

The bug filed against the package suggests "libopenmpi-dev | lam4-dev".
Will this be a problem?

> Further you have the choice of creating libhypre-dev-common containing
> the shared files. But only do that if libhypre-dev-common will be
> reasonably large. There is no point in the split for just
> 100K. ftp-master will veto if it is too small.

The package is 141K, and it's *all* shared.  That is, it consists of
header files and .so symlinks.

-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

Arch-dependent Depends

[Adam C Powell IV]

Greetings,

I maintain a set of packages which depend openmpi which is missing on
certain architectures.  To get around the latter problem, I use
arch-dependent Build-Depends to specify openmpi where available and lam
otherwise (though the buildd report for hypre on s390 shows it doesn't
seem to understand this directive).

Because hypre upstream doesn't make static libs, and I got tired of
making a new patch with every release, libhypre-dev is arch all without
static libs.  However, it needs to depend on openmpi on some arches, and
lam4-dev on others.  Using the same syntax as Build-Depends doesn't
work.

Is there a way to do this, or do I need to make libhypre-dev arch any
and set the dep using substvars, even though its contents are
arch-independent?  I notice that Policy section 7.1 provides for
arch-dependent Build-Deps, but there's nothing similar for Depends...

[Please CC me in replies.]

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

RFP: chasm -- C++-Fortran 90 interoperability tool

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

Package name: chasm
Version: 1.3.0
Author: Los Alamos National Laboratory
URL: http://chasm-interop.sourceforge.net/
License: BSD
Description: Chasm-interop is a set of tools that parses C++ and Fortran
90 source files and automatically generates bridging code to provide for
seamless language interoperability

Note: this provides Fortran90 support for Babel, a tool which I am
packaging (bug 464717).  If I get some time to package it, I'll change
this to an ITP, but that probably won't happen for at least a couple of
weeks.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ITP: ASTK -- Code_Aster build/control system and front-end

[Adam C Powell IV]

On Sat, 2008-02-23 at 10:04 +0100, Guus Sliepen wrote:
> On Fri, Feb 22, 2008 at 07:40:45PM -0500, Adam C Powell IV wrote:
> 
> > > It is unclear to me what this software can do. Can I generate finite
> > > element models with it? Or is it just a way to start simulations on a
> > > backend? Can I view models, or meshes, or results of calculations? What
> > > kind of finite elements are supported? If this is a frontend, is the
> > > backend also packaged for Debian?
> > 
> > It's the build system and graphical interface for the aster binary(ies)
> > built in the aster package.
> 
> Ah, so there will be other packages that will Build-Depend on astk?

Not that I know of (possibly homard), but it's possible.  It doesn't
look straightforward to disentangle the build system from the "server"
component that runs the aster FEA binary.

Apologies again for the sloppy ITP bug.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ITP: ASTK -- Code_Aster build/control system and front-end

[Adam C Powell IV]

On Fri, 2008-02-22 at 23:45 +0100, Guus Sliepen wrote:
> On Fri, Feb 22, 2008 at 05:07:20PM -0500, Adam C Powell IV wrote:
> 
> > Package name: astk
> 
> Why is it called astk? I can't find an astk tarball on the
> www.code-aster.org site.

astk is one of the tarballs in the aster-full-src-9.2.0-2.noarch.tar.gz
tarball on the site.  They distribute sixteen .tar.gz tarballs within
that tarball, of which:
  * gmsh, grace, hdf5, med, Numeric, omniORB, omniORBpy, tcl and tk
duplicate existing Debian packages; scotch is in incoming
  * metis-edf is similar to parmetis already in Debian, and to
scotch
  * gibi is non-free (can't find source anywhere)
  * Sylvestre Ledru is working on eficas and homard
  * That leaves astk and aster

There's really no point in distributing this tarball-of-tarballs, so
we're packaging the four unique tarballs from within it as separate
packages.

> > Version: 1.5.5
> > Author: EDF (Electricite de France) R&D
> > License: GPL
> > URL: http://www.code-aster.org/
> > Description: Code_Aster build/control system and front-end
> 
> Don't repeat the name of the package in the short description. Also,
> what is it a system and front end for? That is unclear from the
> description.

Okay, I'll use the short version description in the future.

> > ASTK is a client-server front-end for the Code_Aster finite element
> > software (a.k.a. aster), as well as a build system used by Code_Aster
> > and Homard.
> 
> It is unclear to me what this software can do. Can I generate finite
> element models with it? Or is it just a way to start simulations on a
> backend? Can I view models, or meshes, or results of calculations? What
> kind of finite elements are supported? If this is a frontend, is the
> backend also packaged for Debian?

It's the build system and graphical interface for the aster binary(ies)
built in the aster package.

> What is Homard?

Homard is an adaptive mesher linked with aster.

> > The client is written in Tcl, and the server and build system in
> > python.
> 
> I think it doesn't matter what language these tools are written in, as
> long as they do whay they're supposed to do. So this is not useful
> information for the long description. Use the debtags system instead for
> these kinds of annotations.

Okay.  I wanted to provide extra information.  I will just use the
package short and long descriptions in the future.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: ASTK -- Code_Aster build/control system and front-end

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

Package name: astk
Version: 1.5.5
Author: EDF (Electricite de France) R&D
License: GPL
URL: http://www.code-aster.org/
Description: Code_Aster build/control system and front-end

ASTK is a client-server front-end for the Code_Aster finite element
software (a.k.a. aster), as well as a build system used by Code_Aster
and Homard.  The client is written in Tcl, and the server and build
system in python.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: opencascade -- CAE platform library and scripting engine

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

Package name: opencascade
Version: 6.2.0
Author: Open Cascade SAS (OCC), a French software services company
URL: http://www.opencascade.org/
License: Open CASCADE Technology Public License, includes triangle with 
non-free source
Description: CAE platform library and scripting engine

Greetings,

I am packaging OpenCASCADE, a powerful computer-aided engineering (CAE)
platform library and scripting engine.  It includes computer-aided
design (CAD) and visualization features, as well as some meshing for
analysis.  It also comes with its own scripting engine.

The license appears to be free, though upstream interprets it as
non-free, and the source includes the non-free "triangle" program.  See
http://lists.debian.org/debian-legal/2007/12/msg00066.html for details.

The current package is at http://lyre.mit.edu/~powell/opencascade/ .  I
plan to split the package using Jason Kraftcheck's scripts (see
http://lists.debian.org/debian-science/2008/01/msg00013.html and
http://lists.debian.org/debian-science/2008/01/msg00024.html for
details) before uploading.

This is a build-depend for Salomé which I ITP'd (bug 457075).

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: spooles -- SParse Object Oriented Linear Equations Solver

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

Package name: spooles
Version: 2.2
Author: Cleve Ashcraft et al., Boeing Phantom Works
License: Public Domain
Description: SParse Object Oriented Linear Equations Solver
Homepage: http://www.netlib.org/linalg/spooles/

SPOOLES is a library for solving sparse real and complex linear systems
of equations, written in the C language using object oriented design.
Other packages such as PETSc can be enhanced by spooles, and the Finite
Element software CalculiX requires it.  (I plan to ITP CalculiX soon.)

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: C++/STL linking trouble

[Adam C Powell IV]

On Wed, 2008-01-09 at 10:09 -0500, Adam C Powell IV wrote:
> On Wed, 2008-01-09 at 15:37 +0100, Thomas Girard wrote:
> > On Wed, Jan 09, 2008 at 07:07:30AM -0500, Adam C Powell IV wrote:
> > > I'm having trouble with a new C++ package called Salomé which I can't
> > > get to link to a C++ library in a new package OpenCASCADE.
> > > 
> > > Using nm -C I found that the library libTKernel has:
> > > 4c74 T operator<<(_STL::basic_ostream > > _STL::char_traits >&, TCollection_AsciiString const&)
> > > and the other missing symbols are in that and other OpenCASCADE libs
> > > with s/std/_STL/ .
> > > 
> > > >From Googling around, I've learned that this seems to be a confusion
> > > between the stlport namespace and standard C++ library namespace for the
> > > argument symbols.  So how do I either get Salomé to build in the stlport
> > > namespace, or get OpenCASCADE to not build there?
> > 
> > It seems the libTKernel has changed how STLport std:: namespace (through
> > _STDP_STD_NAME macro) gets expanded. If you have a look at libstlport5.1
> > symbols you should see there are defined in the stlp_std:: namespace.
> > Removing this #define _STDP_STD_NAME _STL from headers used by libTKernel
> > should fix the link failure.
> 
> Thank you for pointing this out.  OpenCASCADE doesn't work with stlport
> 5.1, just 4.6.
> 
> I don't see _STDP_STD_NAME in any of the OpenCASCADE headers...  Should
> I perhaps #define _STDP_STD_NAME std, or #undef it?

I think I found the problem.  I pre-processed two files in question,
TDF_Attribute.cxx in OpenCASCADE and testDS.cxx in Salomé.  I put both
outputs in http://lyre.mit.edu/~powell/salome/

In the former, /usr/include/stlport/stl/_iosfwd.h opens a "namespace
_STL {" then #includes /usr/include/stlport/stl/_iosfwd.h which has:
typedef basic_ostream > ostream; (line 2685)

In the latter, /usr/include/c++/4.2/iosfwd opens a
"namespace std __attribute__ ((__visibility__ ("default"))) {" then
#includes /usr/include/c++/4.2/iosfwd which has:
typedef basic_ostream ostream; (line 6311)

So they lead to different symbols, which breaks linking.  What to do?

I see "using namespace std" in testDS.E (lines 31862 and 3) and
"using namespace _STL" in TDF_Attribute.E (lines 17427 and 23430).
Would changing this in the OpenCASCADE headers override the "namespace
_STL {" and fix the problem?

Otherwise, how does a non-stlport binary link to an stlport library??

Thanks for any help and insights you can provide.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: C++/STL linking trouble

[Adam C Powell IV]

On Wed, 2008-01-09 at 15:37 +0100, Thomas Girard wrote:
> On Wed, Jan 09, 2008 at 07:07:30AM -0500, Adam C Powell IV wrote:
> > Greetings,
> 
> Hello Adam,
> 
> > I'm having trouble with a new C++ package called Salomé which I can't
> > get to link to a C++ library in a new package OpenCASCADE.
> > 
> > Here's the error:
> 
> [...]
> 
> > Using nm -C I found that the library libTKernel has:
> > 4c74 T operator<<(_STL::basic_ostream > _STL::char_traits >&, TCollection_AsciiString const&)
> > and the other missing symbols are in that and other OpenCASCADE libs
> > with s/std/_STL/ .
> > 
> > >From Googling around, I've learned that this seems to be a confusion
> > between the stlport namespace and standard C++ library namespace for the
> > argument symbols.  So how do I either get Salomé to build in the stlport
> > namespace, or get OpenCASCADE to not build there?
> 
> It seems the libTKernel has changed how STLport std:: namespace (through
> _STDP_STD_NAME macro) gets expanded. If you have a look at libstlport5.1
> symbols you should see there are defined in the stlp_std:: namespace.
> Removing this #define _STDP_STD_NAME _STL from headers used by libTKernel
> should fix the link failure.

Thank you for pointing this out.  OpenCASCADE doesn't work with stlport
5.1, just 4.6.

I don't see _STDP_STD_NAME in any of the OpenCASCADE headers...  Should
I perhaps #define _STDP_STD_NAME std, or #undef it?

> I'll answer the omniORB change on the pkg-corba mailing list.

Alexandre Fayolle pointed out that Salomé only supports omniORB 4.0.x,
not 4.1.1.  So to get this to build in unstable, I'll need to port it to
4.1.1. :-(

I'll stick to building in testing for now, and port when I get time.

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/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

C++/STL linking trouble

[Adam C Powell IV]

Greetings,

I'm having trouble with a new C++ package called Salomé which I can't
get to link to a C++ library in a new package OpenCASCADE.

Here's the error:

g++ -m64 -D_OCC64 -g -D_DEBUG_ -Wno-deprecated -Wparentheses -Wreturn-type 
-Wunused -o .libs/testDS testDS-testDS.o  -pthread ./.libs/libSalomeDSImpl.so 
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/HDFPersist/.libs/libSalomeHDFPersist.so
 -L/usr/lib -L/usr/lib/openmpi/lib -L/usr/X11R6/lib64 
../HDFPersist/.libs/libSalomeHDFPersist.so /usr/lib/libTKStdSchema.so 
/usr/lib/libTKPCAF.so /usr/lib/libTKCAF.so /usr/lib/libTKV3d.so 
/usr/lib/libTKMesh.so /usr/lib/libTKV2d.so /usr/lib/libTKService.so -lXt -lX11 
/usr/lib/libTKHLR.so /usr/lib/libTKStdLSchema.so /usr/lib/libTKPLCAF.so 
/usr/lib/libTKLCAF.so /usr/lib/libTKTopAlgo.so /usr/lib/libTKGeomAlgo.so 
/usr/lib/libTKShapeSchema.so /usr/lib/libTKPShape.so /usr/lib/libTKBRep.so 
/usr/lib/libTKGeomBase.so /usr/lib/libTKG3d.so /usr/lib/libPTKernel.so 
/usr/lib/libTKG2d.so /usr/lib/libTKMath.so /usr/lib/libTKCDF.so 
/usr/lib/libTKernel.so -lstlport -lieee /usr/lib/libhdf5.so -lpthread -lz -lXmu 
-lnsl -lm -lrt -ldl -Wl,--rpath -Wl,/usr/lib64/salome -Wl,--rpath -Wl,/usr/lib
testDS-testDS.o: In function `main':
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:64: 
undefined reference to `operator<<(std::basic_ostream >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:66: 
undefined reference to `operator<<(std::basic_ostream >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:69: 
undefined reference to `operator<<(std::basic_ostream >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:71: 
undefined reference to `operator<<(std::basic_ostream >&, TCollection_ExtendedString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:73: 
undefined reference to `operator<<(std::basic_ostream >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:73: 
undefined reference to `operator<<(std::basic_ostream >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:78: 
undefined reference to `operator<<(std::basic_ostream >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:80: 
undefined reference to `operator<<(std::basic_ostream >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:80: 
undefined reference to `operator<<(std::basic_ostream >&, TCollection_AsciiString const&)'
testDS-testDS.o:/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:81:
 more undefined references to `operator<<(std::basic_ostream >&, TCollection_AsciiString const&)' follow
./.libs/libSalomeDSImpl.so: undefined reference to 
`TDF_Attribute::ExtendedDump(std::basic_ostream 
>&, TDF_IDFilter const&, TDF_AttributeIndexedMap&) const'
./.libs/libSalomeDSImpl.so: undefined reference to 
`Standard_Transient::ShallowDump(std::basic_ostream >&) const'
./.libs/libSalomeDSImpl.so: undefined reference to 
`operator<<(std::basic_ostream >&, 
Handle_Standard_Type const&)'
./.libs/libSalomeDSImpl.so: undefined reference to 
`TDF_Attribute::Dump(std::basic_ostream >&) const'
collect2: ld returned 1 exit status
make[2]: *** [testDS] Error 1
make[2]: Leaving directory 
`/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl'

The libraries libTKPCAF, libTCAF, libTKernel etc. are part of the
OpenCASCADE package, which I haven't uploaded yet, but you can get from
http://lyre.mit.edu/~powell/opencascade/ (signed with my key in the
Debian keyring).  -4 is missing a build-dep on libmesa-gl1-dev, -5 will
be up soon.  The package I'm trying to build is Salomé, for which I've
put very preliminary -1 sources in http://lyre.mit.edu/~powell/salome/ .

To make matters worse, the Salomé build doesn't get this far in unstable
because of an incompatibility between omniorb4 4.0.6 and 4.1.1, so to
see the above error you need to build it against omniorb4 4.0.6 which is
in testing.  I've emailed the omniorb4 maintainers to ask for help with
making that part work.  Oh -- and building Salomé at all requires
patches to HDF5 and OpenMPI which I put in bugs 457080 and 459642 and
which the maintainers have agreed to merge.  The necessary HDF5 packages
are in the http://lyre.mit.edu/~powell/hdf5/ , and for OpenMPI, do
"ln -s libmpi_cxx.so /usr/lib/libmpi++.so" and Salomé will configure and
build properly.

Using nm -C I found that the library libTKernel has:
4c74 T operator<<(_STL::basic_ostream 
>&, TCollection_AsciiString const&)
and the other missing symbols are in that and other OpenCASCADE libs
with s/std/_STL/ .

>From Googling around, I've learned that this seems to be a confusion
between the st

Re: ITP: PySparse - a sparse linear algebra extension for Python

[Adam C Powell IV]

On Thu, 2006-11-23 at 13:28 +1100, Andrew Donnellan wrote:
> On 11/20/06, Adam C Powell IV <[EMAIL PROTECTED]> wrote:
> 
> > Second, I may need some advice on the license:
> >
> > Copyright (c) 2001-2003, ETH Zurich and Roman Geus
> > All rights reserved.
> >
> > Redistribution and use in source and binary forms, with or without
> > modification, are permitted provided that the following conditions are
> > met:
> >
> > * Redistributions of source code must retain the above copyright
> >   notice, this list of conditions and the following disclaimer.
> > * Redistributions in binary form must reproduce the above
> >   copyright notice, this list of conditions and the following
> >   disclaimer in the documentation and/or other materials provided
> >   with the distribution.
> > * Neither the name of the ETH Zurich nor the names of its
> >   contributors may be used to endorse or promote products derived
> >   from this software without specific prior written permission.
> >
> > THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> > "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> > LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> > A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> > OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> > SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> > LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> > DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> > THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> > (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> > OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> >
> > I believe this allows redistribution by Debian, but can't tell whether
> > this restricts this package to non-free.
> >
> 
> BSDish AFAICS. OK for main.

Thank you, that's what it looked like to me.  I'll go ahead and upload.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#354674: What on earth?

[Adam C Powell IV]

On Thu, 2006-04-13 at 19:58 -0400, David Nusinow wrote:
> On Thu, Apr 13, 2006 at 07:09:55PM -0400, Adam C Powell IV wrote:
> > *Think* for a moment about the consequences.  This is not a simple
> > rebuild, this is a serious problem.
> 
> I agree and I take full responsibility for the issue. I'm sorry for the
> trouble. I'm fully willing to put back the .la files on request from the
> release team, who I should definitely have coordinated with beforehand.
> Note that I would have done so if I'd realized the magnitude of the
> problem, and not doing so was entirely my error.

Wow.  Thank you.  This would help in the short term, though I suspect
the damage is done and the other packages are "fixing" their "bugs" at
this point.  I agree that the release team should decide.

I hope such problems can be avoided in the future.

Cheers,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#354674: What on earth?

[Adam C Powell IV]

On Thu, 2006-04-13 at 19:12 +0300, Daniel Stone wrote:
> On Thu, Apr 13, 2006 at 11:12:06AM -0400, Adam C Powell IV wrote:
> > Please tell me if I have this right:
> >   * You don't like .la files
> 
> Yes.
> 
> >   * So you're unilaterally removing them from a core package
> > (libxcursor) with dozens of reverse-depends, breaking all of
> > them
> 
> Yes.
> 
> >   * Even though they're a years-old and very well established
> > technology
> 
> .la files?  I wouldn't call them 'very well established'.

Okay, then 'widespread', as is evident from the number of broken
packages.

> >   * Which upstream libtool has not yet decided to eliminate ("It's
> > already under discussion")
> 
> And X.Org upstream are currently seriously discussing whether or not to
> eliminate libtool, at which point you get broken away.  This, believe it
> or not, a) improves portability, and b) makes you immune to further
> changes.

Okay, I misunderstood, s/libtool/Xorg/.  Even so, what "further
changes"?  There are no further changes yet, there are merely
discussions.  This doesn't change that you acted unilaterally.

> >   * And which has not been discussed on debian-devel or any other
> > Debian list as far as I can tell (Google search).
> 
> Yes.

This is the main problem.  In numerous other transitions, from udev/hal
to C++, we had fair warning and could coordinate release schedules.  See
Steve's post.

> > Can you really be serious?
> 
> Yes.
> 
> > For example, if the maintainer of GLib decides (s)he doesn't like the
> > way it handles modules, and upstream *might* at some point change the
> > behavior, is that alone enough justification to change it and break all
> > of its dozens of reverse-depending packages?
> 
> If the dependent packages can be fixed with a rebuild, and the reason is
> solid, rather than, 'I'm bored'?  Yes.

So I'm supposed to rebuild all of the dependencies between my package
and libxcursor, like multiple GNOME and KDE libraries (GNOME in my
case), just to build my package?  And then what?  Upload it?  I can't,
because those intermediate libs are broken in unstable, so it won't
autobuild.

And who's to say the interfaces won't change before the next upload of
those intermediates?  For example, GNOME is in the middle of its
2.12-2.14 transition, with dozens of packages in flight from alioth via
experimental.  It would *really* have helped if you had let them know of
these plans *before* they started uploading 2.14 packages.

Now everybody needs to wait while the maintainers of those packages
build and upload.  In the correct order.  Regardless of other release
plans.  With no notice.

*Think* for a moment about the consequences.  This is not a simple
rebuild, this is a serious problem.

> Is a rebuild really that phenomenally onerous for you?  In the time
> spent arguing this point, tons of packages could've been simply rebuilt.
> I don't see where the problem lies, unless you happen to enjoy random
> flamebait more than actual productive work.

Flamebait?  Well, if you consider discussions on stranding a large
fraction of Debian's 1000 part-time volunteer developers without the
ability to build their packages in unstable to be "random flamebait", I
really can't help you.

Regards,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What on earth?

[Adam C Powell IV]

On Thu, 2006-04-13 at 11:12 -0400, Adam C Powell IV wrote:
> Greetings,
> 
> Please tell me if I have this right:
>   * You don't like .la files
>   * So you're unilaterally removing them from a core package
> (libxcursor) with dozens of reverse-depends, breaking all of
> them
>   * Even though they're a years-old and very well established
> technology
>   * Which upstream libtool has not yet decided to eliminate ("It's
> already under discussion")
>   * And which has not been discussed on debian-devel or any other
> Debian list as far as I can tell (Google search).

Okay, my mistake, the removal of .la files throughout X packages
indicates that this was an X-wide decision, not an isolated developer.
But I still don't see any discussion on Debian lists outside of this one
bug.

"I guess that's why they call it unstable..."

Cheers,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

What on earth?

[Adam C Powell IV]

Greetings,

Please tell me if I have this right:
  * You don't like .la files
  * So you're unilaterally removing them from a core package
(libxcursor) with dozens of reverse-depends, breaking all of
them
  * Even though they're a years-old and very well established
technology
  * Which upstream libtool has not yet decided to eliminate ("It's
already under discussion")
  * And which has not been discussed on debian-devel or any other
Debian list as far as I can tell (Google search).

Can you really be serious?

For example, if the maintainer of GLib decides (s)he doesn't like the
way it handles modules, and upstream *might* at some point change the
behavior, is that alone enough justification to change it and break all
of its dozens of reverse-depending packages?

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: petsc_2.3.0-1_i386.changes REJECTED

[Adam C Powell IV]

On Thu, 2005-12-15 at 15:05 +1000, Anthony Towns wrote:
> On Wed, Dec 14, 2005 at 09:29:11PM -0500, Adam C Powell IV wrote:
> > Did you receive this email or any of this thread?  It's now more than
> > two weeks old, and I'd really like to upload a new PETSc 2.3.0 ASAP.
> 
> So upload it? If you've replied to the REJECT message with appropriate
> reasons why the REJECTion was wrong, that seems the natural thing
> to do?

Well, I don't see how it's "natural" to put something in the queue to
wait another few weeks, but then I had already waited a couple of weeks
since the discussion concluded so it could do no more harm...

Thanks, I'll try again.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: petsc_2.3.0-1_i386.changes REJECTED

[Adam C Powell IV]

Joerg,

Did you receive this email or any of this thread?  It's now more than
two weeks old, and I'd really like to upload a new PETSc 2.3.0 ASAP.  If
you didn't see it, the discussion was on debian-release, archive at
http://lists.debian.org/debian-release/2005/11/msg00107.html , then
Steve Langasek moved it to debian-devel (and I copied debian-beowulf) at
http://lists.debian.org/debian-devel/2005/11/msg00986.html

In particular, can you please reply to:

  * Strong support for versioned -dev packages, and in particular,
the PETSc alternatives system which lets admins choose between
different versions or different builds of the same version
(single/double/complex, with/without parmetis and hypre, gcc/ccc
compilers, mpich/lab MPI implementation, etc.), and PETSC_DIR
which lets user/developers choose between installed versions.
Removing the version from the -dev package would cause all
user/devs a lot of trouble during upgrades -- and the vast
majority of users are devs, 43 have -dev vs. 45 the lib.
  * Inconsistent application of the "no empty packages" rule, a rule
which is not found in policy (or if it is, please show me
where), cf. octave, python(-dev), linux-image-2.6, etc.

As mentioned, I'd be happy to remove petsc-dbg, it's petsc-dev which is
important -- and installed by 39/43 of the users of petsc2.2.0-dev
according to popcon.

Regards,
Adam

On Mon, 2005-11-28 at 15:11 -0500, Adam C Powell IV wrote:
> On Sun, 2005-11-20 at 17:50 -0800, Steve Langasek wrote:
> > On Sun, Nov 20, 2005 at 06:57:36PM -0500, Adam C Powell IV wrote:
> > > > Well, I think the factor there is that we "usually" want users to 
> > > > upgrade to
> > > > the latest kernel automatically, whereas users of petsc usually can't
> > > > auto-upgrade to the new API.
> > 
> > > Okay, then what about octave, another empty package which forced an
> > > incompatible auto-upgrade from octave2.0 to octave2.1, and now to 2.9?
> > 
> > Probably depends on how incompatible the upgrades are.
> 
> I've only worked with octave a bit, but such upgrades have bit me on all
> of the .m files I've written.  I'd say roughly similar backward
> compatibility to PETSc-linked source.  There's a larger user community
> for octave, but that's why I don't put multiple PETSc versions in Debian
> simultaneously.
> 
> > BTW, the other big reason for linux-image-2.6-$flavor metapackages is that
> > they provide a hook for debian-installer, so the installer doesn't have to
> > be futzed with in 5 places every time there's a kernel update.
> 
> Okay, fair enough.
> 
> > > And come to think of it, the python-dev python version consistency
> > > argument doesn't really apply to anyone running a single distribution,
> > > because the "python" version in that distribution is automatically
> > > identical to the "python-dev" version.  The only way this "guarantee" of
> > > the same pythonx.y-dev and python -> pythonx.y actually does anything is
> > > if an admin somehow attempts to shoehorn the woody python with the sarge
> > > python-dev onto the same system, and how likely is that?
> > 
> > So you're suggesting that people who package python tools should be ok with
> > having to update their build-dependencies as part of every python
> > transition, even when nothing else in their package needs to change?  (This
> > also has implications for backports and cross-ports, mind you...)
> 
> No, I'm merely saying that the versioning in the python dep is
> irrelevant because python-dev and python will automatically have the
> same version in every Debian release.
> 
> As for what should be OK, two scenarios: (1) empty upgrade packages are
> good, so people build-dep on python-dev, which depends on python; (2)
> empty upgrade packages are bad, so people build-dep on "python2.3-dev |
> python-dev", the latter of which is a virtual package provided by
> python*-dev.  No need to change the python-dependent package.
> 
> > > Again, the point is that these are all over Debian, and it's
> > > inconsistent to accept all but one.
> > 
> > I don't think anyone has been proposing an inconsistent guideline, here.
> > I'll grant you that these guidelines probably haven't been *applied*
> > consistently in the past, but that's not the same thing.
> 
> Makes sense.  Can someone please write the guideline somewhere,
> preferably in policy, so we can apply it?
> 
> Thanks,
> -Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: petsc_2.3.0-1_i386.changes REJECTED

[Adam C Powell IV]

On Sun, 2005-11-20 at 17:50 -0800, Steve Langasek wrote:
> On Sun, Nov 20, 2005 at 06:57:36PM -0500, Adam C Powell IV wrote:
> > > Well, I think the factor there is that we "usually" want users to upgrade 
> > > to
> > > the latest kernel automatically, whereas users of petsc usually can't
> > > auto-upgrade to the new API.
> 
> > Okay, then what about octave, another empty package which forced an
> > incompatible auto-upgrade from octave2.0 to octave2.1, and now to 2.9?
> 
> Probably depends on how incompatible the upgrades are.

I've only worked with octave a bit, but such upgrades have bit me on all
of the .m files I've written.  I'd say roughly similar backward
compatibility to PETSc-linked source.  There's a larger user community
for octave, but that's why I don't put multiple PETSc versions in Debian
simultaneously.

> BTW, the other big reason for linux-image-2.6-$flavor metapackages is that
> they provide a hook for debian-installer, so the installer doesn't have to
> be futzed with in 5 places every time there's a kernel update.

Okay, fair enough.

> > And come to think of it, the python-dev python version consistency
> > argument doesn't really apply to anyone running a single distribution,
> > because the "python" version in that distribution is automatically
> > identical to the "python-dev" version.  The only way this "guarantee" of
> > the same pythonx.y-dev and python -> pythonx.y actually does anything is
> > if an admin somehow attempts to shoehorn the woody python with the sarge
> > python-dev onto the same system, and how likely is that?
> 
> So you're suggesting that people who package python tools should be ok with
> having to update their build-dependencies as part of every python
> transition, even when nothing else in their package needs to change?  (This
> also has implications for backports and cross-ports, mind you...)

No, I'm merely saying that the versioning in the python dep is
irrelevant because python-dev and python will automatically have the
same version in every Debian release.

As for what should be OK, two scenarios: (1) empty upgrade packages are
good, so people build-dep on python-dev, which depends on python; (2)
empty upgrade packages are bad, so people build-dep on "python2.3-dev |
python-dev", the latter of which is a virtual package provided by
python*-dev.  No need to change the python-dependent package.

> > Again, the point is that these are all over Debian, and it's
> > inconsistent to accept all but one.
> 
> I don't think anyone has been proposing an inconsistent guideline, here.
> I'll grant you that these guidelines probably haven't been *applied*
> consistently in the past, but that's not the same thing.

Makes sense.  Can someone please write the guideline somewhere,
preferably in policy, so we can apply it?

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: petsc_2.3.0-1_i386.changes REJECTED

[Adam C Powell IV]

On Sat, 2005-11-19 at 00:22 -0800, Steve Langasek wrote:
> On Wed, Nov 16, 2005 at 10:53:57AM -0500, Adam C Powell IV wrote:
> > > > > For that matter, why is it important that Debian provide support for
> > > > > coinstallability with older packages that are, evidently, not 
> > > > > important
> > > > > enough themselves to be supported by Debian?
> 
> > > > In contrast, libxml-dev has 731 users and at least one major reverse
> > > > dependency (gnucash), making it much more valuable.  Not to mention just
> > > > one large API change, vs. PETSc's, um, 10 or so since I first uploaded
> > > > it.
> 
> > > Right; it's the API changes that make the idea of an unversioned petsc-dev
> > > package of questionable utility...
> 
> > Fair enough.  It's a convenience, but one which forces a user/developer
> > to upgrade his/her code -- or point to the old version (likely still
> > there because there are no conflicts) until such time becomes available.
> 
> > Hmm.  Perhaps the analogy to linux-image-2.6-SUBARCH is better.  The
> > kernel "API changes" enough to suggest or require some new utilities,
> > and obsolete others.  This *usually* doesn't require users to change
> > things, as there's a big effort to be backward compatible (e.g. ALSA
> > provides an OSS-compatible interface), but not always.
> 
> Well, I think the factor there is that we "usually" want users to upgrade to
> the latest kernel automatically, whereas users of petsc usually can't
> auto-upgrade to the new API.

Okay, then what about octave, another empty package which forced an
incompatible auto-upgrade from octave2.0 to octave2.1, and now to 2.9?

And come to think of it, the python-dev python version consistency
argument doesn't really apply to anyone running a single distribution,
because the "python" version in that distribution is automatically
identical to the "python-dev" version.  The only way this "guarantee" of
the same pythonx.y-dev and python -> pythonx.y actually does anything is
if an admin somehow attempts to shoehorn the woody python with the sarge
python-dev onto the same system, and how likely is that?

Again, the point is that these are all over Debian, and it's
inconsistent to accept all but one.

> > But what about the empty linux-image upgrade convenience packages
> > mentioned above?  If the answer is "Such packages are all bad and should
> > go away", I'm fine with that.
> 
> No, I certainly think that packages like linux-image-2.6-686 should be kept
> around.  And you've also made a case for why it may be useful to keep
> petsc-dev around.  In any case, it's ultimately the ftp team's decision to
> make; it sounds to me like all the arguments have been made at this point.

Thanks again for your feedback and explanations.

Joerg, the ball is in your court:

  * There is broad consensus for versioned -dev packages (e.g.
Thomas Viehmann's precedent, Junichi's libpkg-guide),
particularly for this case where both the Debian alternatives
system and PETSC_DIR mechanism allow users to select between
multiple versions or multiple builds of the same version (LAM,
single precision or complex, -contrib linked vs parmetis and
hypre, -dec with HPaq alpha tools, etc.)
  * There is a very strong consistency argument for keeping
petsc-dev, cf. octave, python-dev, linux-image-2.6-xxx, though
I'll drop petsc-dbg with its six users on popcon if you like.

What's the verdict?

Cheers,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: petsc_2.3.0-1_i386.changes REJECTED

[Adam C Powell IV]

On Tue, 2005-11-15 at 23:03 -0800, Steve Langasek wrote:
> On Tue, Nov 15, 2005 at 05:15:28PM -0500, Adam C Powell IV wrote:
> > On Mon, 2005-11-14 at 23:59 -0800, Steve Langasek wrote:
> 
> > > > I understand that, and the whole proposal.  And it will break a lot of
> > > > things for many of my users, who need to use old versions of the -dev
> > > > packages at the same time -- which is why I do the versioned -dev
> > > > packages and the alternatives system.
> 
> > > *Why* do users need to use old versions of -dev packages at the same time?
> > > How can it be so important to maintain parallel installable versions of
> > > devel packages for a library package that has only *one* 
> > > reverse-dependency
> > > in Debian?
> 
> > Users of PETSc are developers, almost always of some local code of their
> > own, most of the time which links with third-party libs, such as libmesh
> > (not yet in Debian), dolfin (from what I hear may soon be in Debian),
> > etc.  Because PETSc upstream changes its API with every point release, a
> > user's local code -- and these various third-party libs -- often lag
> > behind, such that upgrading a single "libpetsc-dev" package would break
> > all of those builds.
> 
> > On the other hand, upgrading my petsc-dev package requires only a simple
> > "update-alternatives --config" to reinstate the older version as the
> > default, since the newer one doesn't conflict with or replace the older
> > one.
> 
> Ah, I didn't notice the alternatives there.  That's definitely an
> interesting approach to dev packages; though given that only root can run
> update-alternatives, I don't know that this is really much of an advantage
> over just keeping two .debs around and switching between them.

PETSc also provides its own sort of "alternatives" mechanism: a
programmer is required to set PETSC_DIR in order to program with PETSc
at all, and that can be e.g. /usr/lib/petscdir/2.3.0
or /usr/lib/petscdir/2.2.0 etc.  The static libs are there, along with
links to the shlibs, C includes, makefile includes, my own petsc.m4,
various scripts, etc.

I put the real shlibs, and alternatives slaves to the static libs,
in /usr/lib following the FHS.  There are also alternatives slaves for
the C includes dir, petsc.m4, etc.

So a user can either manually set PETSC_DIR to point to a particular
version, or set it to /usr/lib/petsc to use the system default pointed
to by the alternatives symlink.

All of this is documented in README.Debian, which is also at
http://lyre.mit.edu/~powell/petsc/README.Debian

> > > For that matter, why is it important that Debian provide support for
> > > coinstallability with older packages that are, evidently, not important
> > > enough themselves to be supported by Debian?
> 
> > In contrast, libxml-dev has 731 users and at least one major reverse
> > dependency (gnucash), making it much more valuable.  Not to mention just
> > one large API change, vs. PETSc's, um, 10 or so since I first uploaded
> > it.
> 
> Right; it's the API changes that make the idea of an unversioned petsc-dev
> package of questionable utility...

Fair enough.  It's a convenience, but one which forces a user/developer
to upgrade his/her code -- or point to the old version (likely still
there because there are no conflicts) until such time becomes available.

Hmm.  Perhaps the analogy to linux-image-2.6-SUBARCH is better.  The
kernel "API changes" enough to suggest or require some new utilities,
and obsolete others.  This *usually* doesn't require users to change
things, as there's a big effort to be backward compatible (e.g. ALSA
provides an OSS-compatible interface), but not always.

> > > Anyway, the empty petsc-dev package is completely pointless.  It can't be
> > > used sanely as a dependency or build-dependency, because it does *not*
> > > guarantee a constant interface thanks to petsc's FHS-incompatible layout.
> > > I think it would be better if there *were* a single petsc-dev package
> > > containing the header files and library links in FHS locations, making
> > > libpetsc2.2.0-dev unnecessary; but if this is not to be the case for
> > > whatever reason, then petsc-dev ought to be dropped.  In any case, I agree
> > > with Joerg that there ought to only be one -dev package here...
> 
> > So then, we don't need python-dev?
> 
> python-dev provides an interface that packages can build-depend on which
> gives them both /usr/bin/python, and a set of development tools from the
> corresponding version of python.  This is not analogous to petsc-dev

Re: petsc_2.3.0-1_i386.changes REJECTED

[Adam C Powell IV]

On Mon, 2005-11-14 at 23:59 -0800, Steve Langasek wrote:
> [redirecting this to -devel; discussions of ftp team NEW queue policies are
>  off-topic for -release.]

Sorry, my mistake.  I'm adding debian-beowulf because that's where some
of PETSc's users are.

> On Mon, Nov 14, 2005 at 05:13:47PM -0500, Adam C Powell IV wrote:
> 
> > > And thats what I asked for, yes. Drop the version from -dev|-dbg|-doc,
> > > use the shlib system for the rest (which makes packages built against it
> > > depending on the right version) and have fun.
> 
> > I understand that, and the whole proposal.  And it will break a lot of
> > things for many of my users, who need to use old versions of the -dev
> > packages at the same time -- which is why I do the versioned -dev
> > packages and the alternatives system.
> 
> *Why* do users need to use old versions of -dev packages at the same time?
> How can it be so important to maintain parallel installable versions of
> devel packages for a library package that has only *one* reverse-dependency
> in Debian?

Users of PETSc are developers, almost always of some local code of their
own, most of the time which links with third-party libs, such as libmesh
(not yet in Debian), dolfin (from what I hear may soon be in Debian),
etc.  Because PETSc upstream changes its API with every point release, a
user's local code -- and these various third-party libs -- often lag
behind, such that upgrading a single "libpetsc-dev" package would break
all of those builds.

On the other hand, upgrading my petsc-dev package requires only a simple
"update-alternatives --config" to reinstate the older version as the
default, since the newer one doesn't conflict with or replace the older
one.

> For that matter, why is it important that Debian provide support for
> coinstallability with older packages that are, evidently, not important
> enough themselves to be supported by Debian?

Why are multiple versions not worth supporting in Debian?  With just 72
users in popcon, and weighing in at about 140 MiB/distro (woody, sarge
and etch/sid), I don't think it's worth n-tupling the impact on the
mirrors for these few users.

In contrast, libxml-dev has 731 users and at least one major reverse
dependency (gnucash), making it much more valuable.  Not to mention just
one large API change, vs. PETSc's, um, 10 or so since I first uploaded
it.

Why is coinstallability worth supporting?  The package is worth much
more to those few users with this feature than without it, as described
above.  I've had a number of users contact me about old versions, which
are available at a URL in README.Debian, and which might be necessary
for an old version of one of the packages mentioned above, or even some
old code written by a former grad student in a research group.

[The alternatives system can also be used for alternate builds of PETSc,
e.g. vs. the LAM MPI implementation instead of mpich, complex or single-
precision, -contrib version linked against ParMETIS and hypre, etc.  All
of these are build-time options described in README.Debian.  Such
packages have different names and library sonames, so the shlib system
can set package lib dependencies for any resulting binaries.]

> Anyway, the empty petsc-dev package is completely pointless.  It can't be
> used sanely as a dependency or build-dependency, because it does *not*
> guarantee a constant interface thanks to petsc's FHS-incompatible layout.
> I think it would be better if there *were* a single petsc-dev package
> containing the header files and library links in FHS locations, making
> libpetsc2.2.0-dev unnecessary; but if this is not to be the case for
> whatever reason, then petsc-dev ought to be dropped.  In any case, I agree
> with Joerg that there ought to only be one -dev package here...

So then, we don't need python-dev?  According to popcon, 36 people have
petsc-dev installed, 72 libpetsc2.2.0-dev, so roughly half of the PETSc
users find petsc-dev useful.  By comparison, about 3/4 of python2.3-dev
users have python-dev installed, a similar ratio for a package which
serves a similar purpose.

Or will python-dev be rejected next time, or the entire python-defaults
source package?

Thanks for the reply.  I think there's a good case for keeping the
package as it is, and have yet to hear good counter-arguments to the
above which don't apply to other packages.  If python-dev qualifies for
rejection, then I can understand petsc-d[ev|bg] as well.

Please CC me in replies.

Cheers,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: libMesh - a C++ Finite Element Library

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

Greetings,

I am planning to package libMesh [1], a C++ library for parallel finite
element calculations using MPI, PETSc and (Par)Metis (and possibly hypre
via PETSc).  It is actively developed at the University of Texas at
Austin and Hamburg University of Technology, and is copyrighted by the
authors at those institutions and licensed under the LGPL (2.1).

[1] http://libmesh.sourceforge.net/

Because ParMetis (and hypre) is non-free, this will need to go into
contrib.

Cheers,

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: anonymous dupload stopped working

[Adam C Powell IV]

On Tue, 2005-04-05 at 11:16 -0500, Gunnar Wolf wrote:
> Adam C Powell IV dijo [Tue, Apr 05, 2005 at 09:55:53AM -0400]:
> > Greetings,
> > 
> > About two weeks ago (or perhaps earlier, I don't know),
> > anonymous-ftp-master stopped functioning as an upload host.  I think
> > this corresponded to a dupload upgrade (2.6.3 in testing), since the
> > $default_host line was commented reflecting a new dupload.conf.
> > 
> > Has anyone else had this problem?  I can't find anything about it using
> > google.  And I'd like to get some bug fixes uploaded before the freeze.
> 
> Hi,
> 
> I have had this same problem - I will try with dput, as some people
> pointed out it does work. Strange thing is, looking into this specific
> package: 
> 
> http://packages.qa.debian.org/libp/libpdf-api2-perl.html
> 
> It reports that it was successfully uploaded yesterday to unstable. It
> showed the same information some time ago (I did this same upload
> about a week ago).

Interesting...  I just installed and tried dput, and everything seems to
work fine.  So dupload is broken.

The odd thing is, dupload version 2.6.3 is more than a year and a half
old!  So I don't see why it broke just now...

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

anonymous dupload stopped working

[Adam C Powell IV]

Greetings,

About two weeks ago (or perhaps earlier, I don't know),
anonymous-ftp-master stopped functioning as an upload host.  I think
this corresponded to a dupload upgrade (2.6.3 in testing), since the
$default_host line was commented reflecting a new dupload.conf.

Has anyone else had this problem?  I can't find anything about it using
google.  And I'd like to get some bug fixes uploaded before the freeze.

Thanks,

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: hypre high performance preconditioners

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

I intend to package hypre, which is "scalable software for solving
large, sparse linear systems of equations on massively parallel
computers".  It provides high-performance matrix preconditioners toward
that end, and can be linked with other software such as PETSc and
Illuminator for parallel computation of the linear equations, solution,
visualization, etc.  It is written by a team at Lawrence Livermore
National Laboratories.

Unfortunately, the license includes a "No commercialization" clause,
which makes it very much non-free.  I have contacted the upstream
authors to request explicit permission to redistribute it, and also to
ask that they consider relicensing under a free license.  (Incidentally,
the Babel project, also written at LLNL, switched from a similar "no
commercialization" license to LGPL, and my request to them for free
licensing apparently carried some weight in their case to management.)

When I receive this permission, I will upload hypre packaging, with the
contents of both the COPYRIGHT_and_DISCLAIMER file below and their
authorization email in the debian/copyright file.

Upstream COPYRIGHT_and_DISCLAIMER:

NOTICE

This work was produced at the University of California, Lawrence
Livermore National Laboratory (UC LLNL) under contract
no. W-7405-ENG-48 (Contract 48) between the U.S. Department of Energy
(DOE) and The Regents of the University of California (University) for
the operation of UC LLNL. The rights of the Federal Government are
reserved under Contract 48 subject to the restrictions agreed upon by
the DOE and University as allowed under DOE Acquisition Letter 97-1.

DISCLAIMER

This work was prepared as an account of work sponsored by an agency of
the United States Government. Neither the United States Government nor
the University of California nor any of their employees, makes any
warranty, express or implied, or assumes any liability or
responsibility for the accuracy, completeness, or usefulness of any
information, apparatus, product, or process disclosed, or represents
that its use would not infringe privately-owned rights.  Reference
herein to any specific commercial products, process, or service by
trade name, trademark, manufacturer or otherwise does not necessarily
constitute or imply its endorsement, recommendation, or favoring by
the United States Government or the University of California. The
views and opinions of authors expressed herein do not necessarily
state or reflect those of the United States Government or the
University of California, and shall not be used for advertising or
product endorsement purposes.

NOTIFICATION OF COMMERCIAL USE

Commercialization of this product is prohibited without notifying the
Department of Energy (DOE) or Lawrence Livermore National Laboratory
(LLNL).

Regards,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: Proposal: make kernel install easier

[Adam C Powell IV]

On Wed, 2003-08-20 at 14:46, Manoj Srivastava wrote:
On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV <[EMAIL PROTECTED]> said: 

> Greetings, Installing a new kernel package can be a bit of a pain,
> especially for newbies, what with hand-editing lilo.conf or config

Why on earth are you hand editing the lilo.conf file for every
 kernel image? The postinst already manages two symlinks for you that
 can be in the lilo.conf file. 

If you have to hand edit lilo.conf for every kernel image, you
are doing something wrong.

See my reply to Josh Lauricha: kernel-image packages corrupt the
vmlinuz(.old) symlinks when removing a kernel, and switching between
kernels with and without initrd.img is not supported.

For the clever, you can manage any number of symlinks
 automatically for yourselves; the latest kernel-package gives
 an example of creating a set of symlinks for 2.4 kerels, another set
 for 2.5 kernels, and so on.

> files for other bootloaders, from grub

Another bad example. For grub you do not need to muck around
 with symlinks at all, you have update-grub, and again, the
 kernel-package package gives examples on how to use this script.

Then /usr/lib/bootloaders/grub would be very small and easy to write. 
My proposed mechanism would add finer-grained control of boot options
(e.g. "apm=on" for 2.2 kernels but not 2.4) and of menu entry
names/labels, with little additional coding.

> So why not (optionally) automate the process a bit?  Use a directory
> e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf
> files and running the bootloaders.

> For example, quik could have debconf questions: "Manage quik.conf
> using debconf?" and "Install new kernels automatically?" and perhaps
> "Global kernel option defaults" (though perhaps this would be better
> outside of each individual bootloader).  Then each kernel package
> would have a low- to med-priority debconf question asking with what
> options to boot the kernel starting from global defaults.  It could
> also ask whether to make this image top priority in the .conf, and
> what name string to use for this image.  Also, quik could Provide
> virtual package bootloader which kernel-image packages could
> Suggest.

Bloat. You have not yet demonstrated a need that can't be met
 with the current infrastructure (your examples are fraught with an
 ignorance of current practice).

Please forgive me, I had not known that a newer version of quik had just
been uploaded which supports such features, and that's what I use to
boot my one fully-unstable machine (i.e. not just a chroot).

> If there's interest (and no show-stoppers anyone can think of), I'll

Well, too late. There are show stoppers galore (lack of need
 for such bloat being just one of them).

> start writing patches to kernel-package, lilo, maybe even quik :-) --
> that is, unless someone else wants to, e.g. their maintainers.

Secondly, most of this creeping featurism does not belong in
 kernel-package proper, but should be off loaded to the hook scripts.

Now that there are hook scripts, this makes some sense.  But if you
think about it for a few seconds, the "bloat" and "creeping featurism"
of the proposed bootloader scripts is no greater than that required for
hook scripts -- in fact, that's what they are (inspired by e.g.
update-cluster).

> [Please CC me in replies as I'm not subscribed.  And apologies if

In the old days, it was considered rude to ask questions on a
 forum when you were not subscribed.

Then I am glad I do not live "in the old days".

> this has been brought up before; searches on lists.debian.org didn't turn 
up
> anything.]

It has not only been brought up, solutions have been found and
 have been implemented.

Again forgive me, I had not known these solutions had been applied to
aboot, quik, palo, etc.

Thank you for the kind and courteous reply,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: Proposal: make kernel install easier

[Adam C Powell IV]

On Wed, 2003-08-20 at 15:02, Goswin von Brederlow wrote:
Adam C Powell IV <[EMAIL PROTECTED]> writes:

> Greetings,
> 
> Installing a new kernel package can be a bit of a pain, especially for
> newbies, what with hand-editing lilo.conf or config files for other
> bootloaders, from grub to yaboot/quik, aboot, palo, you name it.  Yes,
> the kernel-image postinst runs lilo, but lilo.conf is invariably out of
> date, so this is relatively useless except for upgrades.
> 
> So why not (optionally) automate the process a bit?  Use a directory
> e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf files
> and running the bootloaders.

I believe lilo and grub already have that.

>From /boot/grub/menu.lst

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default optons below

There is also a mechanism in dpkg to install hooks now which is
hopefully already used to run update-grub.

Cool, did not know.  I guess a "hooks" mechanism would be required for
unmodified kernel-image packages...

My proposed system would add user control of menu entry names/labels,
and finer-grained control of boot options (without editing the .conf
files), but these don't seem worth the overhead of such a system.

Is this documented somewhere, or should I just look at the latest lilo
and grub packages to see how to adapt this to other bootloaders?  It
would be nice if this were somewhat uniform (at least to the user)
across loaders and architectures.

Zeen,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: Proposal: make kernel install easier

[Adam C Powell IV]

On Wed, 2003-08-20 at 14:25, Josh Lauricha wrote:
On Wed  10:51, Adam C Powell IV wrote:
> Greetings,
> 
> Installing a new kernel package can be a bit of a pain, especially for
> newbies, what with hand-editing lilo.conf or config files for other
> bootloaders, from grub to yaboot/quik, aboot, palo, you name it.  Yes,
> the kernel-image postinst runs lilo, but lilo.conf is invariably out of
> date, so this is relatively useless except for upgrades.

Don't know about your system, but /vmlinuz and /vmlinuz.old always point
to the correct images and lilo.conf is set to use those by default. So,
whenever I upgrade the kernel this is all taken care of.

Not necessarily.  Ever removed a kernel?  Or tried to switch between
kernels with and without initrd.imgs?  (Or perhaps you don't use the
stock Debian 2.4 kernels...)

Zeen,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Proposal: make kernel install easier

[Adam C Powell IV]

Greetings,

Installing a new kernel package can be a bit of a pain, especially for
newbies, what with hand-editing lilo.conf or config files for other
bootloaders, from grub to yaboot/quik, aboot, palo, you name it.  Yes,
the kernel-image postinst runs lilo, but lilo.conf is invariably out of
date, so this is relatively useless except for upgrades.

So why not (optionally) automate the process a bit?  Use a directory
e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf files
and running the bootloaders.

For example, quik could have debconf questions: "Manage quik.conf using
debconf?" and "Install new kernels automatically?" and perhaps "Global
kernel option defaults" (though perhaps this would be better outside of
each individual bootloader).  Then each kernel package would have a low-
to med-priority debconf question asking with what options to boot the
kernel starting from global defaults.  It could also ask whether to make
this image top priority in the .conf, and what name string to use for
this image.  Also, quik could Provide virtual package bootloader which
kernel-image packages could Suggest.

[A really fancy bootloader could also use debconf to prompt for info
about other OSes on other partitions for its .conf, e.g. "bye" for MacOS
in quik...]

The kernel-image's postinst would run all of the scripts in
/usr/lib/bootloaders/ with arguments like --add-index-entry --name
"2.4.20-2-powermac" --kernel /boot/vmlinuz-2.4.20-2-powermac --initrd
/boot/initrd.img-2.4.20-2-powermac (or --noinitrd) --boot-options
"root=/dev/hdb6 video=offb" --top-boot-priority .  If quik's "Manage
quik.conf automatically" answer is no, then /usr/lib/boot-loaders/quik
with these options does nothing.

Then the kernel-image's postinst runs the scripts with something like
--make-bootable and /usr/lib/bootloaders/quik goes off and makes the
first and second boot blocks, does its open firmware thing etc., and
reports back success (or not).  Again, if quik's "Install new kernels
automatically" answer is no, this does nothing.

The kernel prerms (or postrms?) would also have to run the scripts with
--remove-index-entry --name 2.4.20-2-powermac and again with
--make-bootable in order to clean up safely.

The only trouble I can think of is what to do with already-installed
kernels which don't have such postinst/prerm options.  The .conf files
can be generated automatically, but when a kernel is removed, they're
not cleaned up.  Any "/usr/lib/bootloaders/quik --regenerate-index" type
thing would have to be run manually on each kernel removal, though a
debconf info thing in the new quik package could let users know this.

Also, on Alphas running ARC/AlphaBIOS, Netwinders, etc. there would
still be manual configuration to do during the boot process, so this
wouldn't cure everybody's ills.

Aside from these bits of trouble, such a system would make a lot easier
the process of installing and removing what are now some of the most
annoying packages to deal with (for me at least), particularly given
quirks on different arches.

If there's interest (and no show-stoppers anyone can think of), I'll
start writing patches to kernel-package, lilo, maybe even quik :-) --
that is, unless someone else wants to, e.g. their maintainers.

[Please CC me in replies as I'm not subscribed.  And apologies if this
has been brought up before; searches on lists.debian.org didn't turn up
anything.]

Cheers,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

ITA: mpich: Parallel computing system

[Adam C Powell IV]

Package: wnpp
Severity: wishlist
Greetings,
I'm in the process of adopting mpich from Junichi Uekawa.  This is at 
Junichi's request, as described on the debian-beowulf list a few days ago.

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: dpkg bug #156463: second opinions?

[Adam C Powell IV]

Adam Heath wrote:
On Fri, 30 Aug 2002, Adam C Powell IV wrote:
 

Greetings,
Just writing to request a "second opinion" on this bug.
Current dpkg behavior does not allow a package to replace a directory
with a symlink during upgrade.  This broke a libc6-dev upgrade when I
made an unstable chroot from a potato tarball on an ARM system a couple
of months ago.  See bug 151669 and the debian-arm thread I started a
while ago (URL below) for details.
http://lists.debian.org/debian-arm/2002/debian-arm-200208/msg00017.html
Wichert promptly closed my bug reporting this, #156463, saying "this is
the way it's supposed to be".
IMHO, this is broken behavior, as it creates a limitation on package
upgrading which has nothing whatsoever to do with policy, or with any
sound reason for that matter.  Furthermore, that upgrade behaves
differently in this regard from remove then install (which works just
fine) sounds bizarre.  Is there something I'm overlooking such that
things should be this way?
Please cc me in replies as I'm not subscribed.
   

So, what happens when someone does this:
==
mkfs.ext2 /dev/sda5
mount /dev/sda5 /mount/sda5/
cp -a /usr /mount/sda5/usr
cp -a /var /mount/sda5/var
rm -rf /usr
rm -rf /var
ln -s mount/sda5/usr usr
ln -s mount/sda5/var var
 

Uh, then /usr and /var are simlinks?
I think you misunderstand part of the bug.  There was a directory which 
was only in use by a single package.  doing "dpkg --remove libc6-dev" 
would have removed it.  Having removed it, "dpkg --install 
libc6-dev...deb" would have created it as a symlink.  But merely 
upgrading libc6-dev resulted in its being left as an empty directory, 
causing packages to fail to build (because it was a subdir of 
/usr/include/asm).

In your situation, you replace directories which *tons* of packages 
(every package?) use, which is an entirely different matter.  If *any* 
other installed package had put files in /usr/include/asm/arch, then I 
could understand not replacing that dir with the new symlink.  But they 
didn't.

How is this not a dpkg bug?
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

dpkg bug #156463: second opinions?

[Adam C Powell IV]

 Greetings,
Just writing to request a "second opinion" on this bug.
Current dpkg behavior does not allow a package to replace a directory 
with a symlink during upgrade.  This broke a libc6-dev upgrade when I 
made an unstable chroot from a potato tarball on an ARM system a couple 
of months ago.  See bug 151669 and the debian-arm thread I started a 
while ago (URL below) for details.

http://lists.debian.org/debian-arm/2002/debian-arm-200208/msg00017.html
Wichert promptly closed my bug reporting this, #156463, saying "this is 
the way it's supposed to be".

IMHO, this is broken behavior, as it creates a limitation on package 
upgrading which has nothing whatsoever to do with policy, or with any 
sound reason for that matter.  Furthermore, that upgrade behaves 
differently in this regard from remove then install (which works just 
fine) sounds bizarre.  Is there something I'm overlooking such that 
things should be this way?

Please cc me in replies as I'm not subscribed.
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

ITP: ferite, a lightweight scripting language and engine

[Adam C Powell IV]

Package: wnpp
Version: N/A
Severity: wishlist
Greetings,
I am ITPing this lightweight extensible scripting language and engine, 
used by E17 and applicable to many other projects.  From the website:

   ferite is a scripting language and engine all in one managable
   chunk.  It is designed to be easily extended in terms of API, and to
   be used within other applications making them more configurable and
   useful to the end user.  It has a syntax similar to a number of
   other languages but remains clean and its own language.
For now I just have shlib and -dev packages, in the future -dev may be 
split into -modules, -scripts, -bin, etc.  License: BSD.

Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!