Hi,
I'm maintaining a package (geomview) whose source is free, but parts
of it require a non-free library (xforms) to compile. Currently, the
debian source package builds a single package that omits the programs
that require xforms. There is a wishlist bug requesting that a second
package be
True or False: a .deb may NOT contain hard links ?
The policy manual has a note forbidding links in a _source_ package.
But I cannot find anything about binary packages.
Thanks,
-Steve
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL
On Sun, Mar 04, 2001 at 08:34:25PM -1000, Brian Russo wrote:
On Mon, Mar 05, 2001 at 01:28:51AM -0500, Steve M. Robbins wrote:
Hi,
I'm maintaining a package (geomview) whose source is free, but parts
of it require a non-free library (xforms) to compile. Currently, the
debian source
On Tue, Mar 06, 2001 at 06:54:31PM -0300, Henrique M Holschuh wrote:
On Tue, 06 Mar 2001, Martin Bialasinski wrote:
* Steve M Robbins [EMAIL PROTECTED] wrote:
What I am proposing is a source package that generates *both* a
"main" and a "contrib" .deb.
On Tue, Mar 06, 2001 at 06:21:19AM -0600, Christian T. Steigies wrote:
On Mon, Mar 05, 2001 at 01:10:19PM -0500, Steve M. Robbins wrote:
Can't find Motif header file Xm/Xm.h. Geomview requires Motif
(or Lesstif). See the file INSTALL.Geomview for details.
Hmm? lesstif-dev was installed
On Tue, Apr 03, 2001 at 09:00:31AM -0700, John H. Robinson, IV wrote:
On Tue, Apr 03, 2001 at 04:28:37PM +0200, Dennis Schoen wrote:
On Tue, Apr 03, 2001 at 09:49:41AM -0400, Steve M. Robbins wrote:
What is the point?
policy :)
i hate that catch 22.
can't file a bug, since
On Sun, Apr 15, 2001 at 09:37:49PM +0100, Julian Gilbey wrote:
On Fri, Apr 13, 2001 at 05:09:51PM -0400, Steve M. Robbins wrote:
W: ktouch: zero-byte-file-in-doc-directory
usr/share/doc/HTML/en/ktouch/.anchors
N:
N: package contains a file which is empty
N:
Well
On Mon, Apr 16, 2001 at 01:21:45PM -0700, Sean 'Shaleh' Perry wrote:
To mistake a hard link for a zero-length file is sloppy coding.
This is a bug in lintian.
lintian gets its information from tar's output. A hardlink is shown as a zero
byte file.
Before you accuse sloppy coding
On Thu, Apr 26, 2001 at 04:07:38PM -0400, Wolfgang Sourdeau wrote:
The dh_installchangelogs doesn't accept a ChangeLog parameter when the
package is a native debian package. However, the GNU HaliFAX project
is (as its name implies) an official GNU project, which besides other
things, mean
On Mon, Apr 30, 2001 at 10:39:13PM +0200, Robert Bihlmeyer wrote:
Steve M. Robbins [EMAIL PROTECTED] writes:
On Thu, Apr 26, 2001 at 04:07:38PM -0400, Wolfgang Sourdeau wrote:
The dh_installchangelogs doesn't accept a ChangeLog parameter when the
package is a native debian package
On Fri, May 11, 2001 at 09:01:28AM -0700, Sean 'Shaleh' Perry wrote:
If I did this, would I still have to move the hitop packages into
non-US (since it would still build-depend upon libpgsql-dev which is
now non-US)? Is there any way around this? Should I even care which
part of the
Suppose version 1 of the package had a file named /foo/A,
and version 2 had changed the location to be /bar/A.
Without doing anything special on the part of the developer, is it
always true that upgrading the package version 1-2 will remove /foo/A
before installing /bar/A?
If so, has there ever
On Thu, May 17, 2001 at 07:36:34PM +0200, Josip Rodin wrote:
On Thu, May 17, 2001 at 11:38:06AM -0400, Steve M. Robbins wrote:
Suppose version 1 of the package had a file named /foo/A,
and version 2 had changed the location to be /bar/A.
Without doing anything special on the part
On Mon, May 21, 2001 at 08:10:59PM +0200, Robert Bihlmeyer wrote:
Ben Collins [EMAIL PROTECTED] writes:
Change it to rm -f That way, you wont get an error. You should do
it this way anyway, else your package becomes uninstallable if the user
removes the file before removing the
On Fri, Jun 01, 2001 at 12:18:30AM +0800, James Bromberger wrote:
I've been thinking about an autoconf test I have for checking that my package
is being created on a Debian system. The reason is that I have a very small
set of diffs that I want applied to the package only for Debian, and
On Wed, Jun 06, 2001 at 05:48:46PM +0200, Jesus M. Gonzalez-Barahona wrote:
I'm going to sponsor a guy who has already completed a package which
seems to be in good shape. It is my first sponsorship, and I'd like to
upload his package. Now the questions:
- Should he register somewhere as a
On Sun, Jul 08, 2001 at 06:23:37PM +1000, Sam Couter wrote:
Actually, the reason I ask is because I *did* miss undocumented(7), without
realising it. In fact, a bug almost got filed against an entirely unrelated
package for not having man pages for its binaries, when in reality it had
On Sun, Jul 08, 2001 at 12:51:31PM -0400, [EMAIL PROTECTED] wrote:
Use the --prefix=/usr option to ./configure
Then when running 'make install' do this instead:
'make install prefix=/path/to/temporary/directory'
Also, set --mandir=/usr/share/man and --infodir=/usr/share/info, if
applicable.
2001 13:08:57 -0400, Steve M. Robbins [EMAIL PROTECTED]
wrote:
Also, set --mandir=/usr/share/man and --infodir=/usr/share/info, if
applicable. And if you're installing things in /etc, set
--sysconfdir=/etc.
In general: don't be afraid to run ./configure --help nor to read
Hi,
I'm under the impression that any shared library *must* have
a SONAME. I can't find that precise statement in the policy
manual, but section 11.3 says the package must be named
librarynamesoversion.
If true, what is the procedure for packaging, say Inventor, that
builds two shared libs
On Wed, Jul 25, 2001 at 02:30:49PM -0400, [EMAIL PROTECTED] wrote:
I'm under the impression that any shared library *must* have
a SONAME.
Yes, but SONAME just means the name of the .so file.
OK, now I'm truly confused.
I thought a SONAME was something embedded into the shared object
On Wed, Jul 25, 2001 at 03:18:56PM -0400, [EMAIL PROTECTED] wrote:
Yes, but SONAME just means the name of the .so file.
OK, now I'm truly confused.
I thought a SONAME was something embedded into the shared object
file. As I understand things, the SONAME is completely independent
On Wed, Jul 25, 2001 at 04:41:53PM -0400, [EMAIL PROTECTED] wrote:
That is a nice, rational versioning scheme, I agree.
I don't see how it fits in this discussion, though. For one thing,
I'm not using libtool.
But all shared libraries are recommended to follow this convention.
So
On Wed, Jul 25, 2001 at 03:50:47PM -0500, Steve Langasek wrote:
On Wed, 25 Jul 2001, Steve M. Robbins wrote:
So I guess I'm still searching for the answer to my original questions:
1. Does Debian require a SONAME for a shared lib?
Yes, although this may not be spelled out clearly
On Wed, Jul 25, 2001 at 06:18:04PM -0400, Matt Zimmerman wrote:
I think the confusion here is between a SONAME and a library version number.
Typically, the library version number is part of the SONAME. What we are
speaking of here is libraries which do not have a version number in their
On Thu, Aug 02, 2001 at 04:24:17PM +0100, Will Newton wrote:
Two quick questions for anyone who has the time:
1. I have a package that by default installs a library libname.so (as opposed
to a versioned name like libname.so.1). I assume this is bad because it means
two major versions
Hello,
Suppose I have a package that produces a shared lib. Debian policy
9.1 says I need to create a shlibs file. No problem;
dh_makeshlibs does exactly this.
Now, the shlibs file can optionally have version info in it.
Why would I want to put version info in there?
One case that
On Sun, Sep 02, 2001 at 01:22:32PM -0500, Steve Langasek wrote:
Version 2.1.1 of libfoo provides functions foo_open, foo_close. Version 2.1.2
of libfoo provides functions foo_open, foo_close, and foo_read. This doesn't
break the ABI; foo_open and foo_close have not changed, so there's no
On Sun, Sep 02, 2001 at 03:44:32PM -0500, Colin Watson wrote:
On Sun, Sep 02, 2001 at 04:04:11PM -0400, Steve M. Robbins wrote:
This suggests that one ought to increase the version in the shlibs file
each time the ABI is changed, but not change it otherwise.
So is dh_makeshlibs -V (i.e
On Sun, Sep 16, 2001 at 07:32:19PM +0200, Martin Butterweck wrote:
hi,
lintian gives me the following errormessage:
---
mb:~/debian$lintian -i eroaster_2.0.11-1.dsc
E: eroaster source: autoconf-generated-file-in-source config.status
N:
N: Leaving config.cache/status causes autobuilders
On Wed, Sep 19, 2001 at 08:35:32AM +0200, Josip Rodin wrote:
On Wed, Sep 19, 2001 at 07:16:49AM +0200, peter karlsson wrote:
without seeing the files, why is changelog not human readable?
Well, because it has a lot of noise, with minor changes to files that
are not interesting for
On Mon, Oct 01, 2001 at 02:10:18PM -0500, Colin Watson wrote:
On Mon, Oct 01, 2001 at 06:41:35PM +0200, Erich Schubert wrote:
W: prips: copyright-lists-upstream-authors-like-dh_make
I've run into that warning with my packages, too.
Is this really intended?
Is it a bad-thing (tm) to
On Tue, Oct 30, 2001 at 01:11:46PM +0100, Andreas Rottmann wrote:
I repackaged a previously lintian-clean package of mine right now and
the new lintian (v1.20.16) barks:
W: libucxx0: postinst-unsafe-ldconfig
W: libsigcx0-gtk: postinst-unsafe-ldconfig
But both of them have the ldconfig
On Thu, Nov 01, 2001 at 04:18:46PM +0100, Christian Surchi wrote:
On Thu, Nov 01, 2001 at 04:13:36PM +0100, Gergely Nagy wrote:
case $1 in
configure)
ldconfig
W: iiwusynth: postinst-unsafe-ldconfig
Sorry, I don't get it !
Lintian is cannot parse shell
On Thu, Nov 01, 2001 at 04:00:34PM +0100, Eric Van Buggenhaut wrote:
Hi,
I'm building my first packages with shared library.
This is what my postinst states:
case $1 in
configure)
ldconfig
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
*)
Florian,
In your original mail, the question was what to do about symbolic
links like missing -- /usr/share/automake/missing. The answer is:
replace them by the file to which they are linked.
More puzzling, though, is that the output of dpkg-source says that
the old version is nonexistent.
On Mon, Nov 12, 2001 at 01:47:04PM +0100, Florian Hinzmann wrote:
On 04-Nov-2001 Steve M. Robbins wrote:
the old version is nonexistent. Normally one would expect the
source distribution to include these files (INSTALL, install-sh, etc).
No, I am packaging from the official release tar
On Sun, Oct 14, 2001 at 03:22:55PM -0700, [EMAIL PROTECTED] wrote:
i'm the upstream maintainer for a package, but i'm add the initial
debian support too. i built a deb, but lintian 1.20.16 is complaining:
** problem1:
E: redael: binary-without-manpage redael
E: redael:
text has already been removed.
On Tue, Oct 02, 2001 at 10:55:04AM +0200, Josip Rodin wrote:
On Mon, Oct 01, 2001 at 03:17:09PM -0400, Steve M. Robbins wrote:
W: prips: copyright-lists-upstream-authors-like-dh_make
N:
N: There is Upstream Author(s) in your copyright file
On Sun, Jan 06, 2002 at 08:55:38PM +0100, Gergely Nagy wrote:
make distclean should not delete the files in the first place. The
distclean target should remove only generated files which are not included
in the distribution (such as object code), and since this bison output is
rightly
On Mon, Jan 21, 2002 at 09:27:44AM -0800, Peter Jay Salzman wrote:
i'm trying to package splint, which uses automake/autoconf.
the main problem is that when i install the packages, it puts all the
files that should go in /usr/local/splint/share into /share. :(
the packager's maintenance
Hello,
The Debian policy for shared libraries works well for C libraries.
In particular, one can generally tell if the library has retained
or broken binary compatibility so one knows whether to change the
SONAME (i.e. SONAME version) or not.
For C++ libraries, in contrast, the ABI can change
On Thu, Mar 21, 2002 at 02:27:45PM +0100, Simon Richter wrote:
On Wed, 20 Mar 2002, Will Newton wrote:
[PIC or not PIC]
I understand the need for PIC, but I was asking whether or not compiling
whole binaries with PIC unnecesarily might be a bad thing. e.g. if I cannot
control the
Hi,
To begin, I think there's some confusion about UID and OID. They
are actually the same thing, according to Clunie:
What DICOM calls UIDs are referred to in the
ISO OSI world as Object Identifiers (OIDs).
What Mathieu is talking about is the UID Root (or org root,
according to DICOM
Hi,
For package gmp, I have two open requests to provide 64-bit versions
of the libraries on ppc. One of the requests also asks for a 32-bit
version on amd64.
What is the best way to do this?
Is this related to biarch or multiarch? I can not find any
information on the former, while the
Goswin,
Thanks very much for the succinct lesson on biarch and multiarch.
On Wed, Mar 18, 2009 at 07:31:18PM +0100, Goswin von Brederlow wrote:
If you want to support 64bit (and n32) gmp on ppc, s390, sparc, mips
and mipsel NOW then look at zlib as an example.
Great. So I've gone through
On Wed, Apr 01, 2009 at 05:39:33PM +0200, Goswin von Brederlow wrote:
Steve M. Robbins st...@sumost.ca writes:
I've run into a roadblock, however, in that the header gmp.h is
generated by configure. It has some parameters (size of a limb) that
depend on whether compiled for 32 or 64 bits
Hi David,
I'm willing to sponsor nauty.
On Sat, Sep 05, 2009 at 02:11:20PM -0300, David Bremner wrote:
I found a silly packaging bug that causes the package to FTBFS almost
everywhere.
I uploaded a new version to
Hello,
Are there any examples of a package that builds two binary packages,
each from a distinct run of configure?
My specific case is soqt, which provides a Qt interface to Coin
(OpenInventor). There is a sentiment [1] that I provide packages for
Qt3 as well as packages for Qt4. I believe
Hello,
Recently Joachim posted a request for sponsoring CGAL. This is
to let you all know that I've just uploaded it.
Thanks,
-Steve
signature.asc
Description: Digital signature
Howdy,
I've just finished my first attempt at packaging a python module.
This module (people.debian.org/~smr/pyvtk) is purely python.
I followed the python policy outlined in /usr/share/doc/python, and
also looked at a couple of example packages.
One thing I noticed in the packages (that isn't
On Tue, Nov 19, 2002 at 09:06:55PM -0600, Graham Wilson wrote:
On Tue, Nov 19, 2002 at 08:17:28PM -0500, Steve M. Robbins wrote:
Howdy,
hello.
One thing I noticed in the packages (that isn't covered in the policy)
is the practice of deleting the .pyc files in debian/rules
Hi,
I'm maintaining a package (gmp) that produces a C library (libgmp) and
a C++ library (libgmpxx). The latter links against, and depends on
the internals of, the former.
The libraries go into different binary packages, but since they are so
tightly coupled, I'd like to have the libgmpxx
Howdy,
I've just finished my first attempt at packaging a python module.
This module (people.debian.org/~smr/pyvtk) is purely python.
I followed the python policy outlined in /usr/share/doc/python, and
also looked at a couple of example packages.
One thing I noticed in the packages (that isn't
On Tue, Nov 19, 2002 at 09:06:55PM -0600, Graham Wilson wrote:
On Tue, Nov 19, 2002 at 08:17:28PM -0500, Steve M. Robbins wrote:
Howdy,
hello.
One thing I noticed in the packages (that isn't covered in the policy)
is the practice of deleting the .pyc files in debian/rules
Hi,
I'm maintaining a package (gmp) that produces a C library (libgmp) and
a C++ library (libgmpxx). The latter links against, and depends on
the internals of, the former.
The libraries go into different binary packages, but since they are so
tightly coupled, I'd like to have the libgmpxx
Hi,
I'm maintaining a package (geomview) whose source is free, but parts
of it require a non-free library (xforms) to compile. Currently, the
debian source package builds a single package that omits the programs
that require xforms. There is a wishlist bug requesting that a second
package be
True or False: a .deb may NOT contain hard links ?
The policy manual has a note forbidding links in a _source_ package.
But I cannot find anything about binary packages.
Thanks,
-Steve
On Sun, Mar 04, 2001 at 08:34:25PM -1000, Brian Russo wrote:
On Mon, Mar 05, 2001 at 01:28:51AM -0500, Steve M. Robbins wrote:
Hi,
I'm maintaining a package (geomview) whose source is free, but parts
of it require a non-free library (xforms) to compile. Currently, the
debian source
On Tue, Mar 06, 2001 at 06:54:31PM -0300, Henrique M Holschuh wrote:
On Tue, 06 Mar 2001, Martin Bialasinski wrote:
* Steve M Robbins [EMAIL PROTECTED] wrote:
What I am proposing is a source package that generates *both* a
main and a contrib .deb.
This is not allowed.
Or rather
On Tue, Mar 06, 2001 at 06:21:19AM -0600, Christian T. Steigies wrote:
On Mon, Mar 05, 2001 at 01:10:19PM -0500, Steve M. Robbins wrote:
Can't find Motif header file Xm/Xm.h. Geomview requires Motif
(or Lesstif). See the file INSTALL.Geomview for details.
Hmm? lesstif-dev was installed
On Tue, Apr 03, 2001 at 03:23:59PM +0200, Karel Gardas wrote:
Hi,
I have many binaries compiled from my source package and I would like to
attach 'undocumented' man page to these files. How can I do it?
Aigh, no, please don't do that!
Those drive me crazy!!
The undocumented page
On Tue, Apr 03, 2001 at 09:00:31AM -0700, John H. Robinson, IV wrote:
On Tue, Apr 03, 2001 at 04:28:37PM +0200, Dennis Schoen wrote:
On Tue, Apr 03, 2001 at 09:49:41AM -0400, Steve M. Robbins wrote:
What is the point?
policy :)
i hate that catch 22.
can't file a bug, since
On Fri, Apr 13, 2001 at 12:18:43PM +0200, Christian SPENER wrote:
this are my last errors, don't know how to fix them
also the programmer of the program doesn't know how to fix them, so someone
can giveme some hints, where the problem could be?
[...]
W: ktouch:
On Sun, Apr 15, 2001 at 09:37:49PM +0100, Julian Gilbey wrote:
On Fri, Apr 13, 2001 at 05:09:51PM -0400, Steve M. Robbins wrote:
W: ktouch: zero-byte-file-in-doc-directory
usr/share/doc/HTML/en/ktouch/.anchors
N:
N: package contains a file which is empty
N:
Well
On Mon, Apr 16, 2001 at 02:17:44AM +0100, Julian Gilbey wrote:
On Sun, Apr 15, 2001 at 08:06:02PM -0400, Steve M. Robbins wrote:
And note that hard links are forbidden by policy.
Ah! I looked for that bit of policy a few months ago, and couldn't find it.
Where did you find
On Mon, Apr 16, 2001 at 10:30:45AM -0700, Sean 'Shaleh' Perry wrote:
On 16-Apr-2001 Julian Gilbey wrote:
On Sun, Apr 15, 2001 at 09:59:50PM -0400, Steve M. Robbins wrote:
On Sun, Apr 15, 2001 at 08:06:02PM -0400, Steve M. Robbins wrote:
And note that hard links are forbidden by policy
On Mon, Apr 16, 2001 at 01:21:45PM -0700, Sean 'Shaleh' Perry wrote:
To mistake a hard link for a zero-length file is sloppy coding.
This is a bug in lintian.
lintian gets its information from tar's output. A hardlink is shown as a zero
byte file.
Before you accuse sloppy coding
On Thu, Apr 26, 2001 at 04:07:38PM -0400, Wolfgang Sourdeau wrote:
The dh_installchangelogs doesn't accept a ChangeLog parameter when the
package is a native debian package. However, the GNU HaliFAX project
is (as its name implies) an official GNU project, which besides other
things, mean
On Mon, Apr 30, 2001 at 10:39:13PM +0200, Robert Bihlmeyer wrote:
Steve M. Robbins [EMAIL PROTECTED] writes:
On Thu, Apr 26, 2001 at 04:07:38PM -0400, Wolfgang Sourdeau wrote:
The dh_installchangelogs doesn't accept a ChangeLog parameter when the
package is a native debian package
On Fri, May 11, 2001 at 09:01:28AM -0700, Sean 'Shaleh' Perry wrote:
If I did this, would I still have to move the hitop packages into
non-US (since it would still build-depend upon libpgsql-dev which is
now non-US)? Is there any way around this? Should I even care which
part of the
Suppose version 1 of the package had a file named /foo/A,
and version 2 had changed the location to be /bar/A.
Without doing anything special on the part of the developer, is it
always true that upgrading the package version 1-2 will remove /foo/A
before installing /bar/A?
If so, has there ever
On Thu, May 17, 2001 at 07:36:34PM +0200, Josip Rodin wrote:
On Thu, May 17, 2001 at 11:38:06AM -0400, Steve M. Robbins wrote:
Suppose version 1 of the package had a file named /foo/A,
and version 2 had changed the location to be /bar/A.
Without doing anything special on the part
On Mon, May 21, 2001 at 08:10:59PM +0200, Robert Bihlmeyer wrote:
Ben Collins [EMAIL PROTECTED] writes:
Change it to rm -f That way, you wont get an error. You should do
it this way anyway, else your package becomes uninstallable if the user
removes the file before removing the
On Fri, Jun 01, 2001 at 12:18:30AM +0800, James Bromberger wrote:
I've been thinking about an autoconf test I have for checking that my package
is being created on a Debian system. The reason is that I have a very small
set of diffs that I want applied to the package only for Debian, and
On Wed, Jun 06, 2001 at 05:48:46PM +0200, Jesus M. Gonzalez-Barahona wrote:
I'm going to sponsor a guy who has already completed a package which
seems to be in good shape. It is my first sponsorship, and I'd like to
upload his package. Now the questions:
- Should he register somewhere as a
On Mon, Jun 18, 2001 at 05:02:12PM +1000, Daniel Stone wrote:
On Mon, Jun 18, 2001 at 10:49:35AM +0900, Junichi Uekawa wrote:
Hello,
Upstram of qtecasound has depricated libqtecasound,
and the only application which depended upon libqtecasound (qtecasound, and
ecawave)
no longer
On Tue, Jun 19, 2001 at 07:28:27PM +0100, Julian Gilbey wrote:
On Tue, Jun 19, 2001 at 05:54:25PM +0100, Muhammad Hussain Yusuf wrote:
Hi,
I've just changed the directories of the conffile, binaries etc. to
conform with Policy 3.5.5.0.
The old conffile dir was /etc/X11/filerunner and
On Sun, Jul 08, 2001 at 06:23:37PM +1000, Sam Couter wrote:
Actually, the reason I ask is because I *did* miss undocumented(7), without
realising it. In fact, a bug almost got filed against an entirely unrelated
package for not having man pages for its binaries, when in reality it had
On Sun, Jul 08, 2001 at 12:51:31PM -0400, [EMAIL PROTECTED] wrote:
Use the --prefix=/usr option to ./configure
Then when running 'make install' do this instead:
'make install prefix=/path/to/temporary/directory'
Also, set --mandir=/usr/share/man and --infodir=/usr/share/info, if
applicable.
2001 13:08:57 -0400, Steve M. Robbins [EMAIL PROTECTED]
wrote:
Also, set --mandir=/usr/share/man and --infodir=/usr/share/info, if
applicable. And if you're installing things in /etc, set
--sysconfdir=/etc.
In general: don't be afraid to run ./configure --help nor to read
On Wed, Jul 25, 2001 at 03:50:47PM -0500, Steve Langasek wrote:
On Wed, 25 Jul 2001, Steve M. Robbins wrote:
So I guess I'm still searching for the answer to my original questions:
1. Does Debian require a SONAME for a shared lib?
Yes, although this may not be spelled out clearly
On Sun, Sep 02, 2001 at 01:22:32PM -0500, Steve Langasek wrote:
Version 2.1.1 of libfoo provides functions foo_open, foo_close. Version 2.1.2
of libfoo provides functions foo_open, foo_close, and foo_read. This doesn't
break the ABI; foo_open and foo_close have not changed, so there's no
On Sun, Sep 02, 2001 at 03:44:32PM -0500, Colin Watson wrote:
On Sun, Sep 02, 2001 at 04:04:11PM -0400, Steve M. Robbins wrote:
This suggests that one ought to increase the version in the shlibs file
each time the ABI is changed, but not change it otherwise.
So is dh_makeshlibs -V (i.e
On Sun, Sep 16, 2001 at 07:32:19PM +0200, Martin Butterweck wrote:
hi,
lintian gives me the following errormessage:
---
mb:~/debian$lintian -i eroaster_2.0.11-1.dsc
E: eroaster source: autoconf-generated-file-in-source config.status
N:
N: Leaving config.cache/status causes autobuilders
On Wed, Sep 19, 2001 at 08:35:32AM +0200, Josip Rodin wrote:
On Wed, Sep 19, 2001 at 07:16:49AM +0200, peter karlsson wrote:
without seeing the files, why is changelog not human readable?
Well, because it has a lot of noise, with minor changes to files that
are not interesting for those
On Mon, Oct 01, 2001 at 02:10:18PM -0500, Colin Watson wrote:
On Mon, Oct 01, 2001 at 06:41:35PM +0200, Erich Schubert wrote:
W: prips: copyright-lists-upstream-authors-like-dh_make
I've run into that warning with my packages, too.
Is this really intended?
Is it a bad-thing (tm) to
text has already been removed.
On Tue, Oct 02, 2001 at 10:55:04AM +0200, Josip Rodin wrote:
On Mon, Oct 01, 2001 at 03:17:09PM -0400, Steve M. Robbins wrote:
W: prips: copyright-lists-upstream-authors-like-dh_make
N:
N: There is Upstream Author(s) in your copyright file
On Sun, Oct 14, 2001 at 03:22:55PM -0700, [EMAIL PROTECTED] wrote:
i'm the upstream maintainer for a package, but i'm add the initial
debian support too. i built a deb, but lintian 1.20.16 is complaining:
** problem1:
E: redael: binary-without-manpage redael
E: redael:
On Tue, Oct 30, 2001 at 01:11:46PM +0100, Andreas Rottmann wrote:
I repackaged a previously lintian-clean package of mine right now and
the new lintian (v1.20.16) barks:
W: libucxx0: postinst-unsafe-ldconfig
W: libsigcx0-gtk: postinst-unsafe-ldconfig
But both of them have the ldconfig
On Thu, Nov 01, 2001 at 04:00:34PM +0100, Eric Van Buggenhaut wrote:
Hi,
I'm building my first packages with shared library.
This is what my postinst states:
case $1 in
configure)
ldconfig
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
*)
On Thu, Nov 01, 2001 at 04:18:46PM +0100, Christian Surchi wrote:
On Thu, Nov 01, 2001 at 04:13:36PM +0100, Gergely Nagy wrote:
case $1 in
configure)
ldconfig
W: iiwusynth: postinst-unsafe-ldconfig
Sorry, I don't get it !
Lintian is cannot parse shell
Florian,
In your original mail, the question was what to do about symbolic
links like missing -- /usr/share/automake/missing. The answer is:
replace them by the file to which they are linked.
More puzzling, though, is that the output of dpkg-source says that
the old version is nonexistent.
On Mon, Nov 12, 2001 at 01:47:04PM +0100, Florian Hinzmann wrote:
On 04-Nov-2001 Steve M. Robbins wrote:
the old version is nonexistent. Normally one would expect the
source distribution to include these files (INSTALL, install-sh, etc).
No, I am packaging from the official release tar
On Sun, Jan 06, 2002 at 08:55:38PM +0100, Gergely Nagy wrote:
make distclean should not delete the files in the first place. The
distclean target should remove only generated files which are not included
in the distribution (such as object code), and since this bison output is
rightly
Hello,
The Debian policy for shared libraries works well for C libraries.
In particular, one can generally tell if the library has retained
or broken binary compatibility so one knows whether to change the
SONAME (i.e. SONAME version) or not.
For C++ libraries, in contrast, the ABI can change
On Mon, Feb 11, 2002 at 07:01:09PM +0100, Kjetil Torgrim Homme wrote:
David Z Maze [EMAIL PROTECTED] writes:
Kjetil Torgrim Homme [EMAIL PROTECTED] writes:
This is a bug in lintian. It should not complain about rpath being
set to directories which are part of Debian.
Yes, it
On Thu, Mar 21, 2002 at 02:27:45PM +0100, Simon Richter wrote:
On Wed, 20 Mar 2002, Will Newton wrote:
[PIC or not PIC]
I understand the need for PIC, but I was asking whether or not compiling
whole binaries with PIC unnecesarily might be a bad thing. e.g. if I cannot
control the
Hello Matthias,
Thank you for your interest in backporting digikam. I can't speak for the
other maintainers, but I personally do not have time to maintain backports and
I would welcome your efforts to do so.
I have not looked at your package. But I was a little surprised that the
proposed
99 matches
Mail list logo
