On Thu, 2010-04-29 at 00:45 +0900, Norbert Preining wrote:
On Mi, 28 Apr 2010, Tanguy Ortolo wrote:
Should I increase the Debian version number of my package before I
upload a new revision?
No, you *should* not, because nothing has been uploaded. Just tell
me when you have uploaded a
On Mon, 2009-05-11 at 15:11 +0200, Filippo Rusconi wrote:
On Mon, May 11, 2009 at 02:11:18PM +0200, Julien Cristau wrote:
On Mon, May 11, 2009 at 13:46:30 +0200, Lionel Elie Mamane wrote:
No, policy is very clear on that: if you call the build target, you
_must_ satisfy
Greetings,
I just received bug #141738 against petsc2.1.1-doc saying that links
from /usr/share/doc/petsc2.1.1-doc/include are going to
/lib/petscdir/2.1.1/include instead of /usr/lib/petscdir/2.1.1/include.
This is really odd, as I made them using dh_link and the links seem
correct
Michel Dänzer wrote:
On Mon, 2002-04-08 at 13:45, Adam C Powell IV wrote:
I just received bug #141738 against petsc2.1.1-doc saying that links
from /usr/share/doc/petsc2.1.1-doc/include are going to
/lib/petscdir/2.1.1/include instead of /usr/lib/petscdir/2.1.1/include.
This is really odd
David Caldwell wrote:
I think it means you should fsck your disk. Possibly the '..' in
/usr/share is pointing to the wrong directory (/ instead of /usr).
What happens when you 'cd ..' repeatedly out to root? Does it skip /usr?
I'm very sorry, I discovered this afternoon that the problem
Greetings,
I just received bug #141738 against petsc2.1.1-doc saying that links
from /usr/share/doc/petsc2.1.1-doc/include are going to
/lib/petscdir/2.1.1/include instead of /usr/lib/petscdir/2.1.1/include.
This is really odd, as I made them using dh_link and the links seem
correct
Michel Dänzer wrote:
On Mon, 2002-04-08 at 13:45, Adam C Powell IV wrote:
I just received bug #141738 against petsc2.1.1-doc saying that links
from /usr/share/doc/petsc2.1.1-doc/include are going to
/lib/petscdir/2.1.1/include instead of /usr/lib/petscdir/2.1.1/include.
This is really odd
David Caldwell wrote:
I think it means you should fsck your disk. Possibly the '..' in
/usr/share is pointing to the wrong directory (/ instead of /usr).
What happens when you 'cd ..' repeatedly out to root? Does it skip /usr?
I'm very sorry, I discovered this afternoon that the problem is
Greetings,
I just looked at buildd.debian.org, and my package petsc has failed on
arm and ia64 because of missing atlas2-base-dev. But Build-Depends says
(among other things):
atlas2-base-dev | blas-dev, atlas2-base-dev | lapack-dev
Why won't the buildds parse this properly and, seeing that
James Troup wrote:
Adam C Powell IV [EMAIL PROTECTED] writes:
Why won't the buildds parse this properly and, seeing that there's
no atlas2-base-dev, pick up blas-dev and lapack-dev?
Because or'ed build-depends are satan spawn and the root of all evil
in the world today. Seriously, use arch
Greetings,
In a post to this list about a year ago, someone suggested that complex
dependencies such as (A B) | C be handled with: A | C, B | C. Now
this generates a lintian error:
E: petsc2.1.1-dev: package-has-a-duplicate-relation blas-dev |
atlas2-base-dev, lapack-dev | atlas2-base-dev
Greetings,
In a post to this list about a year ago, someone suggested that complex
dependencies such as (A B) | C be handled with: A | C, B | C. Now
this generates a lintian error:
E: petsc2.1.1-dev: package-has-a-duplicate-relation blas-dev |
atlas2-base-dev, lapack-dev | atlas2-base-dev
Stefano Zacchiroli wrote:
On Sun, Nov 25, 2001 at 01:29:18PM +, Mark Brown wrote:
Do you actually need to call auto*? Normally packages just use the
generated files upstream provides unless there's some particular reason
not to.
yes, I need to call auto* because the sources are from a cvs
Nicolas Boullis wrote:
On Sat, Nov 24, 2001 at 09:49:29PM -0500, Adam C Powell IV wrote:
Can I Build-Depends: ccc [alpha], cfal [alpha] and still have the
source package in main?
No, that would violate policy (2.1.2).
Right, thanks for pointing this out (I need to RTFP :-). So the source
Stefano Zacchiroli wrote:
On Sun, Nov 25, 2001 at 01:29:18PM +, Mark Brown wrote:
Do you actually need to call auto*? Normally packages just use the
generated files upstream provides unless there's some particular reason
not to.
yes, I need to call auto* because the sources are from a
Greetings,
Having got the non-free cfal (Compaq Fortran for Linux Alpha, yes, the
acronym is backwards :-) compiler to work using my contrib Debian
packaging (realplayer-style RPM unpacker), I built PETSc using it, and
WOW, is it FAST! On a 600 MHz ev5, it is more than 2.5 times as fast
per
James Troup wrote:
Adam C Powell IV [EMAIL PROTECTED] writes:
Can I Build-Depends: ccc [alpha], cfal [alpha] and still have the
source package in main?
No, that would violate policy (2.1.2).
Right, thanks for pointing this out (I need to RTFP :-). So the source
would become contrib, because
Greetings,
Having got the non-free cfal (Compaq Fortran for Linux Alpha, yes, the
acronym is backwards :-) compiler to work using my contrib Debian
packaging (realplayer-style RPM unpacker), I built PETSc using it, and
WOW, is it FAST! On a 600 MHz ev5, it is more than 2.5 times as fast
per
James Troup wrote:
Adam C Powell IV [EMAIL PROTECTED] writes:
Can I Build-Depends: ccc [alpha], cfal [alpha] and still have the
source package in main?
No, that would violate policy (2.1.2).
Right, thanks for pointing this out (I need to RTFP :-). So the source
would become contrib
Greetings,
I'm trying to make petsc Build-Depends: on atlas for most arches, but
lapack where there is no atlas. Actually, to make things simpler inside
the package, I link against lapack on PPC, m68k and sparc, so they can
share configuration information, since they are all 32-bit
Greetings,
I'm trying to make petsc Build-Depends: on atlas for most arches, but
lapack where there is no atlas. Actually, to make things simpler inside
the package, I link against lapack on PPC, m68k and sparc, so they can
share configuration information, since they are all 32-bit
Sean 'Shaleh' Perry wrote:
On 16-Mar-2001 Adam C Powell IV wrote:
Greetings,
I just uploaded the latest version of my package, petsc. And got back
notices
about an NMU.
if name in changelog != name in control file:
upload is NMU
Oops! (Was wondering where that came from
Sean 'Shaleh' Perry wrote:
On 16-Mar-2001 Adam C Powell IV wrote:
Greetings,
I just uploaded the latest version of my package, petsc. And got back
notices
about an NMU.
if name in changelog != name in control file:
upload is NMU
Oops! (Was wondering where that came from
Greetings,
I just uploaded the latest version of my package, petsc. And got back notices
about an NMU.
The only thing I did differently was to upload i386 binaries, I usually upload
powerpc.
The maintainer consistently listed in debian/changes is Adam C. Powell, IV
[EMAIL PROTECTED
Greetings,
I just uploaded the latest version of my package, petsc. And got back notices
about an NMU.
The only thing I did differently was to upload i386 binaries, I usually upload
powerpc.
The maintainer consistently listed in debian/changes is Adam C. Powell, IV
[EMAIL PROTECTED
-0500, Adam C Powell IV wrote:
I see. So something has changed recently in unstable such that braces don't
always work
any more? I usually use parentheses myself, but upstream has braces all over the
place-
I assumed they were interchangable (okay, so I'm a "make" newbie :-).
-0500, Adam C Powell IV wrote:
I see. So something has changed recently in unstable such that braces
don't always work
any more? I usually use parentheses myself, but upstream has braces all
over the place-
I assumed they were interchangable (okay, so I'm a make newbie :-).
No.
Hmm
changed
in version 1.2.0 and later versions. It is now found under $MPI_HOME
which in the case of Debian /usr/lib/mpich
In my second post you'll notice:
Adam C Powell IV wrote:
# For mpich: (woody mpich uses /usr/lib/mpich/lib, potato the longer dir)
ifeq ($(PETSC_MPI),mpich)
MPI_HOME
Julian Gilbey wrote:
On Tue, Feb 27, 2001 at 09:11:08PM -0500, Adam C Powell IV wrote:
[snip]
PETSC_LIB = -L${LDIR} -lpetscts -lpetscsnes -lpetscsles -lpetscdm
-lpetscmat \
-lpetscvec ${PETSC_SYS_LIB}
[snip]
Where's the definition of LDIR?
That's defined in bmake
Steve Langasek wrote:
Hi Adam,
On Tue, 27 Feb 2001, Adam C Powell IV wrote:
Have you copied the -L option verbatim? If so, the error is clear:
there's no $ between the -L and the {. Otherwise, I have no idea.
I'm sorry, I was very imprecise. Here are the details:
# For mpich
Hello,
I'm having the darndest time figuring out what's going wrong with the PETSc
build. It was fine when I built and uploaded PPC packages three weeks ago,
and alpha, sparc and arm seemed to build fine, but it breaks now in exactly
that way on unstable i386 and powerpc and testing alpha.
The
Julian Gilbey wrote:
On Tue, Feb 27, 2001 at 04:32:38PM -0500, Adam C Powell IV wrote:
The problem is that it's setting MPI_LIBS to -L{MPI_HOME}/build/... like
it's
substituting ${MPI_HOME} with {MPI_HOME} instead of the value of the
Have you copied the -L option verbatim? If so
Luis Arocha wrote:
Y el lunes 12 de febrero, Adam C Powell IV escribi:
Which release are you using? Which version of libdb2-dev?
If woody/sid, you will find /usr/lib/libdb.so in libdb2-dev 2.7.7-2.2. If potato,
you will find it in libc6-dev 2.1.3-15.
Installed packages:
ii
Luis Arocha wrote:
Y el lunes 12 de febrero, Adam C Powell IV escribió:
Which release are you using? Which version of libdb2-dev?
If woody/sid, you will find /usr/lib/libdb.so in libdb2-dev 2.7.7-2.2. If
potato,
you will find it in libc6-dev 2.1.3-15.
Installed packages:
ii
Luis Arocha wrote:
Y el viernes 9 de febrero, Ben Collins escribió:
No, latest glibc does not include compile support for libdb. Install and
Build-Depends on libdb2-dev
I think it will not be so easy. Configure script still write '-ldb' in
Makefile.
How can I say it must write
Ben Collins wrote:
On Fri, Feb 09, 2001 at 04:31:39PM +, Luis Arocha -data- wrote:
Investigating this error I found this libs:
yoda:~ (.22 Mb)$ ls /usr/lib/libdb*
lrwxrwxrwx1 root root 16 feb 2 21:17
/usr/lib/libdb1.so-/lib/libdb1.so.2
lrwxrwxrwx1 root
Ben Collins wrote:
On Fri, Feb 09, 2001 at 04:31:39PM +, Luis Arocha -data- wrote:
Investigating this error I found this libs:
yoda:~ (.22 Mb)$ ls /usr/lib/libdb*
lrwxrwxrwx1 root root 16 feb 2 21:17
/usr/lib/libdb1.so-/lib/libdb1.so.2
lrwxrwxrwx1 root
Eric VB wrote:
Didn't he download his packages on a win machine ?
Nope. In the i386 case, his transcript shows an http download using apt-get
source
evolver.
And in any case, if that were the problem, it would corrupt the md5sums, which
isn't
happening.
Zeen,
-Adam P.
GPG fingerprint:
Henrique M Holschuh wrote:
On Thu, 08 Feb 2001, Adam C Powell IV wrote:
I'd blame tar or the MIPS port, but that he reproduced on i386 completely
baffles me...
See http://bugs.debian.org/84829
Well, IMHO, if the md5sums are OK in his side as the bug report states, and
tar still fails
Colin Watson wrote:
Adam C Powell IV [EMAIL PROTECTED] wrote:
I received a bizarre bug report a few days ago, saying that the source .tar.gz
for my package doesn't unpack on MIPS, then the guy repeated the problem on
i386. The md5sums are right, so I have no clue why it isn't working
Greetings,
I received a bizarre bug report a few days ago, saying that the source .tar.gz
for my package doesn't unpack on MIPS, then the guy repeated the problem on
i386. The md5sums are right, so I have no clue why it isn't working for him.
apt-get source evolver works just fine for me on i386
Henrique M Holschuh wrote:
On Thu, 08 Feb 2001, Adam C Powell IV wrote:
I'd blame tar or the MIPS port, but that he reproduced on i386 completely
baffles me...
See http://bugs.debian.org/84829
Well, IMHO, if the md5sums are OK in his side as the bug report states, and
tar still fails
Colin Watson wrote:
Adam C Powell IV [EMAIL PROTECTED] wrote:
I received a bizarre bug report a few days ago, saying that the source
.tar.gz
for my package doesn't unpack on MIPS, then the guy repeated the problem on
i386. The md5sums are right, so I have no clue why it isn't working
Greetings,
I'd like to be able to have a build-time setting determine the names of
binary packages. For example, on my petsc package:
debian/rules PETSC_ARCH=linux_alpha_dec binary
builds using the Compaq ccc compiler. I'd like to make it generate
packages with non-standard names, e.g.
Peter S Galbraith wrote:
"Sean 'Shaleh' Perry" wrote:
problem is you have to have valid package names in debian/control.
Perhaps you could do something like a control.in which gets
dynamically created based on the parameters you set.
I agree. I'm setup to build unofficial binary
Greetings,
I'd like to be able to have a build-time setting determine the names of
binary packages. For example, on my petsc package:
debian/rules PETSC_ARCH=linux_alpha_dec binary
builds using the Compaq ccc compiler. I'd like to make it generate
packages with non-standard names, e.g.
Peter S Galbraith wrote:
Sean 'Shaleh' Perry wrote:
problem is you have to have valid package names in debian/control.
Perhaps you could do something like a control.in which gets
dynamically created based on the parameters you set.
I agree. I'm setup to build unofficial binary packages
Junichi Uekawa wrote:
Hi,
I am packaging mpich, and to fix the outstanding wishlist bug, I have created
binaries which
call "ssh" instead of "rsh".
It seems this will slow things down a LOT, and considering MPI is usually used for
high-performance computing, I wouldn't make this standard
Junichi Uekawa wrote:
Hi,
I am packaging mpich, and to fix the outstanding wishlist bug, I have created
binaries which
call ssh instead of rsh.
It seems this will slow things down a LOT, and considering MPI is usually used
for
high-performance computing, I wouldn't make this standard
Michel LESPINASSE wrote:
On Tue, Nov 28, 2000 at 06:11:47AM +0100, Samuel Hocevar wrote:
On Mon, Nov 27, 2000, Ben Collins wrote:
IMO, the better way would be if the CPU intensive portions were in a
shared library (even if the library is only used for this application).
Then you
Michel LESPINASSE wrote:
On Tue, Nov 28, 2000 at 06:11:47AM +0100, Samuel Hocevar wrote:
On Mon, Nov 27, 2000, Ben Collins wrote:
IMO, the better way would be if the CPU intensive portions were in a
shared library (even if the library is only used for this application).
Then you could
Adam C Powell IV wrote:
Okay, check out this freakiness...
Here's the substvars file:
linear-algebra=atlas2
linear-algebra-dev=atlas2-dev
I've attached the control file. So why do I get the following warning:
dpkg-gencontrol: warning: unknown substitution variable
${linear-algebra
Drew Parsons wrote:
On Wed, Nov 22, 2000 at 09:41:51PM +1100, Drew Parsons wrote:
When I try to start X (using either startx or xdm, I didn't try xinit), it
starts loading, and then the computer freezes up utterly.
Ctrl-Alt-Backspace doesn't shutdown X, Alt-Fn doesn't switch over to a
Drew Parsons wrote:
On Wed, Nov 22, 2000 at 09:41:51PM +1100, Drew Parsons wrote:
When I try to start X (using either startx or xdm, I didn't try xinit), it
starts loading, and then the computer freezes up utterly.
Ctrl-Alt-Backspace doesn't shutdown X, Alt-Fn doesn't switch over to a
If nobody can figure it out, I'll assume it must be a bug in dpkg-dev. Reporting
now...
Adam C Powell IV wrote:
Okay, check out this freakiness...
Here's the substvars file:
linear-algebra=atlas2
linear-algebra-dev=atlas2-dev
I've attached the control file. So why do I get
If nobody can figure it out, I'll assume it must be a bug in dpkg-dev.
Reporting now...
Adam C Powell IV wrote:
Okay, check out this freakiness...
Here's the substvars file:
linear-algebra=atlas2
linear-algebra-dev=atlas2-dev
I've attached the control file. So why do I get
Okay, check out this freakiness...
Here's the substvars file:
linear-algebra=atlas2
linear-algebra-dev=atlas2-dev
I've attached the control file. So why do I get the following warning:
dpkg-gencontrol: warning: unknown substitution variable
${linear-algebra}
and it leaves a blank in the
Jean-Marc V. Liotier wrote:
I wonder if somebody has an experience:
I have a potato machine at work and woody at home and I want
to make a woody mirror at work to have faster updates from home.
I'd like to mirror only the packages I have installed at home
and I want the process to be
Hello,
I have a package which depends on atlas-dev for non-PPC, and lapack-dev
for PPC, (atlas doesn't build on PPC because of a compiler bug).
I noticed that freeamp has arches in Build-Depends, e.g. nasm [i386],
but putting this in Depends: for a binary package results in an error.
Is there
Hello,
I have a package which depends on atlas-dev for non-PPC, and lapack-dev
for PPC, (atlas doesn't build on PPC because of a compiler bug).
I noticed that freeamp has arches in Build-Depends, e.g. nasm [i386],
but putting this in Depends: for a binary package results in an error.
Is there
Antti-Juhani Kaijanaho wrote:
On 20001115T123053-0500, Adam C Powell IV wrote:
Is there any way I can do this?
Use substvars (see dpkg-genchanges(1)). My package build-essential
does this.
Cool. Thanks much!
-Adam P.
Welcome to the best software in the world today cafe!
Steve Langasek wrote:
On Sun, 12 Nov 2000, Adam C Powell IV wrote:
Which of Debian's architectures are big-endian, and are there any
machines online that I, as a Debian developer, can log in and test the
software I maintain to see if it works properly on big-endian?
There's also 64
Steve Langasek wrote:
On Sun, 12 Nov 2000, Adam C Powell IV wrote:
Which of Debian's architectures are big-endian, and are there any
machines online that I, as a Debian developer, can log in and test the
software I maintain to see if it works properly on big-endian?
There's also 64
Hello,
I have a dumb newbie maintainer gpg question. I changed my package
maintainer address to @debian.org, and added a new uid to my key, but
can't sign using it, secret key not available. So I tried to
--edit-keys, toggle, and adduid but it wouldn't let me add a uid to my
secret key.
How
Hello,
I have a dumb newbie maintainer gpg question. I changed my package
maintainer address to @debian.org, and added a new uid to my key, but
can't sign using it, secret key not available. So I tried to
--edit-keys, toggle, and adduid but it wouldn't let me add a uid to my
secret key.
How do
Hello,
Found the problem. I had added the uid on another machine, exported the
(public) key, then imported it here. So the new uid showed up on the
public but not secret key.
All set now.
-Adam P.
Welcome to the best software in the world today cafe!
Josip Rodin wrote:
On Sat, Oct 21, 2000 at 08:59:17PM +0100, Roger Leigh wrote:
I fail to see how to run configure twice, with different options in the
build-stamp rule and then install both into the right place in the install
rule (I just get identical stuff pacakged in two locations),
Josip Rodin wrote:
On Sat, Oct 21, 2000 at 08:59:17PM +0100, Roger Leigh wrote:
I fail to see how to run configure twice, with different options in the
build-stamp rule and then install both into the right place in the install
rule (I just get identical stuff pacakged in two locations),
Christian Surchi wrote:
I have a doubt. I have ITPed loserjabber, a gtk client for
livejournal.com. It can use xmms to extract title of played song directly
form it and use it when it adds entry to journal. If I build package
without xmms-dev clearly it will be impossible to use this
Christian Surchi wrote:
I have a doubt. I have ITPed loserjabber, a gtk client for
livejournal.com. It can use xmms to extract title of played song directly
form it and use it when it adds entry to journal. If I build package
without xmms-dev clearly it will be impossible to use this marginal
"Jeremy T. Bouse" wrote:
I'm curious to find some differeing opinions pro/con use of XML for
configuration files...
Pro: nice hierarchical structure, very readable, parser available (see below).
Con: Not necessarily easy to edit, larger files.
That's all I can think of.
also lookin
Jeremy T. Bouse wrote:
I'm curious to find some differeing opinions pro/con use of XML for
configuration files...
Pro: nice hierarchical structure, very readable, parser available (see below).
Con: Not necessarily easy to edit, larger files.
That's all I can think of.
also lookin to
Josip Rodin wrote:
On Wed, Aug 23, 2000 at 02:56:26PM -0400, Adam C Powell IV wrote:
As a newbie soon-to-be maintainer, I'd like to recommend a change in
policy regarding "examples" (section 6.7), such that source code and
shell scripts must either live in /usr/share/doc/pa
Josip Rodin wrote:
On Wed, Aug 23, 2000 at 02:56:26PM -0400, Adam C Powell IV wrote:
As a newbie soon-to-be maintainer, I'd like to recommend a change in
policy regarding examples (section 6.7), such that source code and
shell scripts must either live in /usr/share/doc/package-name
Greetings,
As a newbie soon-to-be maintainer, I'd like to recommend a change in
policy regarding "examples" (section 6.7), such that source code and
shell scripts must either live in /usr/share/doc/package-name/examples,
or (here's the change) if the package name ends in "examples", then just
Greetings,
As a newbie soon-to-be maintainer, I'd like to recommend a change in
policy regarding examples (section 6.7), such that source code and
shell scripts must either live in /usr/share/doc/package-name/examples,
or (here's the change) if the package name ends in examples, then just
Greetings,
I just attempted my first package, of PETSc, the Portable Extensible
Toolkit for Scientific Computing, project homepage at
http://www-fp.mcs.anl.gov/petsc/ .
It depends on MPI, BLAS/LAPACK, and xlib. It's largely a beowulf thing.
Would someone be interested in sponsoring me?
First
Julian Gilbey wrote:
On Wed, Mar 29, 2000 at 01:44:12PM -0500, Nestor A. Diaz L. wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, i have built a debian package of the Bladenc, it works with Debian
2.2 a.k.a. potato i would like to include this release into the
next official
Jaldhar H. Vyas wrote:
While not strictly speaking a Debian issue, it is for a future Debian
package so...
For a package I'm working on, I decided to add GNU
automake/autoconf/libtool support.
The directory structure looks like this
+-- include -- package
|
top-+-- lib
|
79 matches
Mail list logo
