Bug#1081586: RFS: log2ram/1.7.2+ds-1 [ITP] -- Write log files to RAM

[Steve M]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "log2ram":

 * Package name : log2ram
   Version  : 1.7.2+ds-1 
   Upstream contact : Azlux 
 * URL  : https://github.com/azlux/log2ram
 * License  : MIT
 * Vcs  : https://salsa.debian.org/melizas-guest/log2ram
   Section  : embedded

The source builds the following binary packages:

  log2ram - redirects log file writes into RAM

To access further information about this package, please visit the following
URL:

  https://mentors.debian.net/package/log2ram/

Alternatively, you can download the package with 'dget' using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/l/log2ram/log2ram_1.7.2+ds-1.dsc

Changes for the initial release:

log2ram (1.7.2+ds-1) unstable; urgency=low
 .
   * Initial release (Closes: #1038399)



log2ram is very popular on embedded systems such as a Raspberry Pi as it reduces
wear on the uSD card.

After installing log2ram you will probably need to edit /etc/log2ram.conf and
change "SIZE" from the default of 128MB to something larger. I needed at least
256MB for a non-embedded system. Then you will need to reboot.

Regards,
Steve

Bug#1051525: RFS: wxformbuilder/3.10.1-1 [RFP] -- GUI designer for the wxWidgets toolkit

[Steve M]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "wxformbuilder":

 * Package name : wxformbuilder
   Version  : 3.10.1-1
   Upstream contact : Steffen Olszewski 
 * URL  : http://wxformbuilder.org/
 * License  : MIT, GPL-2+, BOOST, BSD-3-Clause, MD5, CC0-1.0, ZLIB
 * Vcs  : https://github.com/wxFormBuilder/wxFormBuilder
   Section  : devel

The source builds the following binary packages:

  wxformbuilder - GUI designer for the wxWidgets toolkit

To access further information about this package, please visit the following
URL:

  https://mentors.debian.net/package/wxformbuilder/

Alternatively, you can download the package with 'dget' using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/w/wxformbuilder/wxformbuilder_3.10.1-1.dsc

Changes for the initial release:

 wxformbuilder (3.10.1-1) unstable; urgency=low
 .
   * Initial release (Closes: #390135)

Regards,
Steve

Re: Package does not show up and no REJECT e-mail

[Steve M]

On Wed, 2022-08-31 at 14:09 -0700, Steve M wrote:
> On Wed, 2022-08-31 at 19:46 +0200, Baptiste Beauplat wrote:
> > Hi Steve,
> > 
> > On 2022/08/30 05:14 PM, Mattia Rizzolo wrote:
> > > On Mon, Aug 29, 2022 at 08:31:44PM -0700, Steve M wrote:
> > > > > Quite interestingly, all these 3 uploads caused the service to be
> > > > > killed
> > > > > by the OOM killer
> > > > > https://salsa.debian.org/mentors.debian.net-team/debexpo/-/issues/143
> > > > > 
> > > > > So I guess that's why you are not seeing any answer from mentors.
> > 
> > We've deployed a fix to mentors.debian.net. Could you try to re-upload
> > your package?
> > 
> > Best,
> 
> Baptiste,
> 
> I have re-uploaded swiftlang to mentors several minutes ago. Lintian takes
> about
> an hour to run so it is too soon for me to know if it has worked or not.
> 
> Thanks
> -Steve

My package "swiftlang" has been accepted on mentors now. It is missing lintian
results: "lintian failed to run: None", but that is ok.

Thanks for the help.
-Steve

Re: Package does not show up and no REJECT e-mail

[Steve M]

On Wed, 2022-08-31 at 19:46 +0200, Baptiste Beauplat wrote:
> Hi Steve,
> 
> On 2022/08/30 05:14 PM, Mattia Rizzolo wrote:
> > On Mon, Aug 29, 2022 at 08:31:44PM -0700, Steve M wrote:
> > > > Quite interestingly, all these 3 uploads caused the service to be killed
> > > > by the OOM killer
> > > > https://salsa.debian.org/mentors.debian.net-team/debexpo/-/issues/143
> > > > 
> > > > So I guess that's why you are not seeing any answer from mentors.
> 
> We've deployed a fix to mentors.debian.net. Could you try to re-upload
> your package?
> 
> Best,

Baptiste,

I have re-uploaded swiftlang to mentors several minutes ago. Lintian takes about
an hour to run so it is too soon for me to know if it has worked or not.

Thanks
-Steve

Re: Package does not show up and no REJECT e-mail

[Steve M]

On Mon, 2022-08-29 at 09:36 +0200, Mattia Rizzolo wrote:
> Hi!
> 
> On Fri, Aug 26, 2022 at 11:30:09PM -0700, Steve M wrote:
> > My apologies for making another "my package won't show up" thread, but that
> > is
> > my problem and I can't figure it out. My package "swiftlang" takes about 3
> > hours
> > to build and uses about 23GiB of disk space, so that may play a role.
> > 
> > My first upload on Tuesday afternoon resulted in a REJECT e-mail due to an
> > error
> > in the d/copyright file. I fixed that and uploaded again on Tuesday evening.
> > We
> > are now about 72 hours later and no acknowledgment has been received. I
> > tried
> > again 14 hours ago and it has been the same, no REJECT or ACCEPT e-mail and
> > it
> > doesn't show up in the list of mentor packages.
> 
> mentors processes uploads every few minutes, so waiting more than 1
> hour almost certanly means something went wrong.
> 
> Anyway, I don't want to compute what "afternoon" and "evening" is for
> you, but this is from mentors' logs:
> 
> Aug 23 23:05:33 wv-debian-mentors1 celery[1121]: [2022-08-23 23:05:33,095:
> INFO/Beat] Scheduler: Sending due task importer
> (debexpo.importer.tasks.importer)
> Aug 23 23:05:33 wv-debian-mentors1 celery[524]: [2022-08-23 23:05:33,098:
> INFO/MainProcess] Received task: debexpo.importer.tasks.importer[f0d330ec-
> 73c2-423a-a537-d85eca4ef8bb]
> Aug 23 23:05:35 wv-debian-mentors1 celery[1120]: [2022-08-23 23:05:35,989:
> INFO/ForkPoolWorker-3] POST https://bugs.debian.org/cgi-bin/soap.cgi
> Aug 23 23:06:00 wv-debian-mentors1 celery[1120]: Failed to import swift:
> Source package is invalid
> Aug 23 23:06:00 wv-debian-mentors1 celery[1120]: Failed to parse
> debian/copyright: Files paragraph missing License field
> Aug 23 23:06:00 wv-debian-mentors1 celery[1120]: [2022-08-23 23:06:00,703:
> ERROR/ForkPoolWorker-3] Failed to import swift: Source package is invalid
> Aug 23 23:06:00 wv-debian-mentors1 celery[1120]: Failed to parse
> debian/copyright: Files paragraph missing License field
> Aug 23 23:06:04 wv-debian-mentors1 celery[1120]: [2022-08-23 23:06:04,021:
> INFO/ForkPoolWorker-3] Task debexpo.importer.tasks.importer[f0d330ec-73c2-
> 423a-a537-d85eca4ef8bb] succeeded in 30.92165717900206>
> 
> 
> This is likely the reject you had.
> 
> 
> Then, I see another upload on Aug 24 04:30:25 of "swift" and another one
> on Aug 26 15:30:16.  This is followed by a "swiftlang" upload on Aug 28
> 00:31:15.
> 
> Quite interestingly, all these 3 uploads caused the service to be killed
> by the OOM killer
> https://salsa.debian.org/mentors.debian.net-team/debexpo/-/issues/143
> 
> So I guess that's why you are not seeing any answer from mentors.

Thank you for looking into this. Please let me know if there is anything you
need me to do to help with the debug.

Regards
-Steve

Re: Package does not show up and no REJECT e-mail

[Steve M]

On Sun, 2022-08-28 at 01:58 +0500, Andrey Rahmatullin wrote:
> On Sat, Aug 27, 2022 at 09:34:57AM -0700, Steve M wrote:
> > > > > > Successfully uploaded swift_5.6.2-1.dsc to mentors.debian.net for
> > > > > > mentors.
> > > > > Note that there is already a package called "swift" in the archive.
> > > > 
> > > > This made me go look at the REJECTED e-mail again and I noticed it says
> > > > "Unfortunately your package "swift" was rejected". That's not right. My
> > > > package
> > > > is "swiftlang" 
> > > No, your source package is named "swift".
> > So then maybe I did it all correctly to have my package named "swiftlang"
> > and my
> > upstream named "swift"? It took me a while to get the build tools to be
> > happy so
> > I thought I must have.
> You didn't, as, like as I said and the quote line proves, your source
> package name is "swift".

I renamed the upstream to "swiftlang" and uploaded to Mentors again, but still
nothing 22 hours later. If anyone can help me figure out why that would be
appreciated, if not then I'll just have to get along without it.


> > > > something correctly there. I am aware of the existing package "swift"
> > > > and my
> > > > package is marked as being a conflict with it due to both packages
> > > > having
> > > > binaries named "swift".
> > > This is wrong as well, see
> > > https://www.debian.org/doc/debian-policy/ch-files.html#binaries
> > 
> > I had to read that policy a few times, but now I see that I am not allowed
> > to
> > use the "conflicts" mechanism is this situation. My "swift" binary is
> > actually
> > just a symbolic link to "swift-frontend", but it is the main mechanism by
> > which
> > the compiler and REPL is called. Also, "swiftc" is also a symbolic link to
> > that
> > same "swift-frontend" so it might be possible to simply drop "swift" and
> > depend
> > on "swiftc" which would then only be an issue for people trying to follow
> > documentation that tells then to run the "swift" command. Should I now reach
> > out
> > to debian-devel to ask about it?
> You can try that, yes, but generally it should be an upstream decision.

I'm certain that upstream won't rename their "swift" binary/link, but I have
asked about using "switfc" instead to see if there is any problem not having
"swift" available. Sylvestre Ledru has kindly agreed to sponsor this package so
I will work with him on how to best address this naming conflict issue and any
other policy issues that I need to clean up. 

Thank you for your help.
-Steve

Re: Package does not show up and no REJECT e-mail

[Steve M]

On Sat, 2022-08-27 at 12:28 +0500, Andrey Rahmatullin wrote:
> On Sat, Aug 27, 2022 at 12:23:51AM -0700, Steve M wrote:
> > > > Successfully uploaded swift_5.6.2-1.dsc to mentors.debian.net for
> > > > mentors.
> > > Note that there is already a package called "swift" in the archive.
> > 
> > This made me go look at the REJECTED e-mail again and I noticed it says
> > "Unfortunately your package "swift" was rejected". That's not right. My
> > package
> > is "swiftlang" 
> No, your source package is named "swift".

So then maybe I did it all correctly to have my package named "swiftlang" and my
upstream named "swift"? It took me a while to get the build tools to be happy so
I thought I must have.


> > something correctly there. I am aware of the existing package "swift" and my
> > package is marked as being a conflict with it due to both packages having
> > binaries named "swift".
> This is wrong as well, see
> https://www.debian.org/doc/debian-policy/ch-files.html#binaries

I had to read that policy a few times, but now I see that I am not allowed to
use the "conflicts" mechanism is this situation. My "swift" binary is actually
just a symbolic link to "swift-frontend", but it is the main mechanism by which
the compiler and REPL is called. Also, "swiftc" is also a symbolic link to that
same "swift-frontend" so it might be possible to simply drop "swift" and depend
on "swiftc" which would then only be an issue for people trying to follow
documentation that tells then to run the "swift" command. Should I now reach out
to debian-devel to ask about it?


> Also, what is the ITP bug number for this package?

The ITP bug # is 788327
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788327

Thanks
-Steve

Re: Package does not show up and no REJECT e-mail

[Steve M]

On Sat, 2022-08-27 at 11:46 +0500, Andrey Rahmatullin wrote:
> On Fri, Aug 26, 2022 at 11:30:09PM -0700, Steve M wrote:
> > My apologies for making another "my package won't show up" thread, but that
> > is
> > my problem and I can't figure it out. My package "swiftlang" takes about 3
> > hours
> > to build and uses about 23GiB of disk space, so that may play a role.
> Mentors doesn't build binary packages, no.

I didn't realize that. Good to know.

> > My first upload on Tuesday afternoon resulted in a REJECT e-mail due to an
> > error
> > in the d/copyright file. 
> Oh, does mentors do REJECTs now?
> 
> > Successfully uploaded swift_5.6.2-1.dsc to mentors.debian.net for mentors.
> Note that there is already a package called "swift" in the archive.

This made me go look at the REJECTED e-mail again and I noticed it says
"Unfortunately your package "swift" was rejected". That's not right. My package
is "swiftlang" and the upstream name is "swift" so I've clearly not done
something correctly there. I am aware of the existing package "swift" and my
package is marked as being a conflict with it due to both packages having
binaries named "swift".

Thanks
-Steve

Package does not show up and no REJECT e-mail

[Steve M]

Dear Mentors,

My apologies for making another "my package won't show up" thread, but that is
my problem and I can't figure it out. My package "swiftlang" takes about 3 hours
to build and uses about 23GiB of disk space, so that may play a role.

My first upload on Tuesday afternoon resulted in a REJECT e-mail due to an error
in the d/copyright file. I fixed that and uploaded again on Tuesday evening. We
are now about 72 hours later and no acknowledgment has been received. I tried
again 14 hours ago and it has been the same, no REJECT or ACCEPT e-mail and it
doesn't show up in the list of mentor packages. Yesterday I had two ACCEPTed
uploads for a different package so I am fairly certain I've got everything set
up correctly on my end. Can someone try to find out why it is not completing?

Successfully uploaded swift_5.6.2-1.dsc to mentors.debian.net for mentors.
Successfully uploaded swift_5.6.2.orig.tar.gz to mentors.debian.net for mentors.
Successfully uploaded swift_5.6.2-1.debian.tar.xz to mentors.debian.net for
mentors.
Successfully uploaded swift_5.6.2-1_amd64.buildinfo to mentors.debian.net for
mentors.
Successfully uploaded swiftlang-dbgsym_5.6.2-1_amd64.deb to mentors.debian.net
for mentors.
Successfully uploaded swiftlang_5.6.2-1_amd64.deb to mentors.debian.net for
mentors.
Successfully uploaded swift_5.6.2-1_amd64.changes to mentors.debian.net for
mentors.


Thanks
-Steve

Conflicting architectures in Swift build

[Steve M]

Dear Mentors,

I am working to package the Swift programming language (swiftlang) and
am having some trouble with the Swift build process and how it is
detecting the architecture of my computer and am uncertain of the best
way to proceed.

Building Swift involves building other bundled tools such as llvm and
ninja. Some of these other builds appear to use config.guess and come
up with x86_64-pc-linux-gnu for the host achitecture, but the main
Swift build uses its own architecture selection mechanism in its cmake
files:

if("${prefix}" STREQUAL "LINUX")
if(arch MATCHES "(armv6|armv7)")
set(SWIFT_SDK_LINUX_ARCH_${arch}_TRIPLE "${arch}-unknown-linux-
gnueabihf")
elseif(arch MATCHES
"(aarch64|i686|powerpc64|powerpc64le|s390x|x86_64)")
set(SWIFT_SDK_LINUX_ARCH_${arch}_TRIPLE "${arch}-unknown-linux-
gnu")
else()
message(FATAL_ERROR "unknown arch for ${prefix}: ${arch}")
endif()


This is causing parts of the Swift build to select x86_64-unknown-
linux-gnu instead of x86_64-pc-linux-gnu. The net result being that
during validation of the build swiftc cannot find the modules it needs
as they now have different names than what it expects (x86_64-unknown-
linux-gnu.swiftmodule instead of x86_64-pc-linux-gnu.swiftmodule).

How should I resolve this? I could patch the cmake file to cause it to
better align with config.guess and submit a patch to upstream. Is there
a better way?

Thanks
-Steve

Bug#951629: RFS: timeshift/19.01+ds-2.1 [NMU] [RC] -- System restore utility

[Steve M]

On Wed, 19 Feb 2020 10:05:49 -0500 Boyuan Yang  wrote:

> Hi Steve, wrar,

> 

> On Wed, 19 Feb 2020 12:40:15 +0500 Andrey
Rahmatullin  wrote:

> > Control: tags -1 + moreinfo

> > 

> > Unfortunately you ignored 

> https://lists.debian.org/debian-mentors/2020/02/msg00124.html

> > lintian even tells you about the mangled
changelog.

> 

> I'm letting you know that I am keeping an eye on
package timeshift since I

> granted the original maintainer DM permission. I
know the original maintainer

> privately and it looks like he is extremely unlikely
to work on timeshift (and

> any other Debian work) in the foreseeable future.
For now, I will not work on

> fixing it or salvaging the package since it's a
perfectly valuable chance for

> you (Steve) to practice and participate in Debian's
work.

> 

> Steve: I took a look at the source package you
provided on mentors.debian.net.

> Actually wrar gave some valuable advice and there
are some bugs that *must* be

> fixed before anyone accept your work (namely the
duplicated changelog

> entries). If you are unsure about what changes you
made, please take advantage

> of the debdiff(1) tool and check the differences
between the existing version

> and your proposed version.

> 

> Please *DO* fix it and let us know when you are
ready. I will be glad to help

> you upload this NMU. Let me know if you have any
doubts.

> 

> -- 

> Thanks,

> Boyuan YangThank you both and kokoye2007for your feedback and for enduring my ignorance.wrar, for some reason I did not receive your very helpful reply on debian mentors that you linked me to. I will of course now follow your advise and clean things up.Boyua, I would be happy to assist or take over from the current maintainer in whatever capacity they desire.Thanks-Steve Meliza

Need help with NMU

[Steve M]

Hello,

I have never contributed before and am trying to make a NMU patch to prevent 
package timeshift from being removed on 21Feb2020. The autoremoval bug for 
timeshift is 948130 [1]. I attempted to contact the maintainer 3 days ago but 
have not yet received a reply. This leaves me little hope that this RC bug can 
be closed in time without an NMU.

The fix is quite simple and was made in the upstream git repo, but has not been 
released yet. I have built the package locally but am at a loss of how to 
proceed next. I was lead to believe that using nmudiff was the correct next 
step, but I’m afraid I’ve stuffed that up as it made a new bug report [2] 
instead of sending it to the existing bug [1].

Please advise on how I should proceed.

Thanks
-Steve Meliza


[1] https://bugs.debian.org/948130 
[2] https://bugs.debian.org/951590 

Bug#809642: sponsorship-requests: RFS: digikam/4:4.14.0-1.1~bpo8+1 [NMU]

[Steve M. Robbins]

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 backport of 4.14.0-1 was versioned 4.14.0-1.1~bpo8+1.   I did read 
through http://backports.debian.org/Contribute/ (thanks to Mattia Rizzolo for 
the reference!) and under the "basic rules" it says to simply append "~bpo..." 
to the version.  Do you really also need to change from "-1" to "-1.1"? 

Best,
-Steve

On January 2, 2016 12:13:59 PM Gianfranco Costamagna wrote:
> Control: tags -1 moreinfo
> 
> Hi Matthias, if you need a backport, please ask the team or the previous
> uploaders to perform it.
> 
> I cced the actual maintainers for the package, they will follow up with an
> upload if possible (I hope).
> 
> BTW this kind of requests are usually performed with a bug against the
> package, unless the package is mostly unmaintained.
> 
> cheers,
> 
> G.
> 
> 
> 
> 
> Il Sabato 2 Gennaio 2016 11:34, Matthias Erich Popp  ha
> scritto: Package: sponsorship-requests
> Severity: normal
> 
> Package: sponsorship-requests
>   Severity: normal
> 
>   Dear mentors,
> 
>   I am looking for a sponsor for my package "digikam"
> 
> * Package name: digikam
>Version : 4:4.14.0-1.1~bpo8+1
> * URL : http://www.digikam.org
>Section : graphics
> 
>   It builds those binary packages:
> 
> digikam- digital photo management application for KDE
> digikam-data - digiKam architecture-independant data
> digikam-doc - handbook for digiKam
> digikam-private-libs - private libraries for digiKam and kipi plugins
> kipi-plugins - image manipulation/handling plugins for KIPI aware programs
> kipi-plugins-common - kipi-plugins architecture-independent data
> showfoto   - image viewer/editor for KDE
> 
>   To access further information about this package, please visit the
> following URL:
> 
>   http://mentors.debian.net/package/digikam
> 
> 
>   Alternatively, one can download the package with dget using this command:
> 
> dget -x
> http://mentors.debian.net/debian/pool/main/d/digikam/digikam_4.14.0-1.1~bpo8
> +1.dsc
> 
>   More information about hello can be obtained from http://www.example.com.
> 
>   Changes since the last upload:
> 
>   * Non-maintainer upload.
>   * Rebuild for jessie-backports.t changelog entry]
> 
> 
>   Regards,
>Matthias Erich Popp
> 
> 
> 
> -- System Information:
> Debian Release: 8.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (450,
> 'stable'), (4, 'testing'), (3, 'unstable'), (2, 'oldstable') Architecture:
> amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.2.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)


signature.asc
Description: This is a digitally signed message part.

Re: Specify package to build only on a single architecture?

[Steve M. Robbins]

On June 29, 2013 10:59:24 PM Michael Biebl wrote:
> Am 30.06.2013 05:42, schrieb Steve M. Robbins:
> > Hi,
> > 
> > I have a package that is only useful on 1 architecture.  How is that
> > stated in the control file?  I tried putting "Architecture" in the
> > initial paragraph but the build complains:
> > 
> > dpkg-source: warning: unknown information field 'Architecture' in input
> > data in general section of control info file
> > 
> > What's the mechanism for this?
> 
> You set the Architecture for the binary package , not the source
> package. See [1] as an example

OK.  This is a library with 3 binary packages: runtime, dev, and doc.  I can 
set the first two, but the latter is arch "all".

Is there anything that has to be done to let the other autobuilders know not 
to look at this source package?

Thanks,
-Steve


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201306301251.44788.st...@sumost.ca

Specify package to build only on a single architecture?

[Steve M. Robbins]

Hi,

I have a package that is only useful on 1 architecture.  How is that stated in 
the control file?  I tried putting "Architecture" in the initial paragraph but 
the build complains:

dpkg-source: warning: unknown information field 'Architecture' in input data in 
general section of control info file

What's the mechanism for this?

Thanks,
-Steve


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201306292242.05000.st...@sumost.ca

Re: RFS: graph isomorphism package nauty

[Steve M. Robbins]

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 
> 
>   http://mentors.debian.net/debian/pool/non-free/n/nauty/nauty_2.4~b7-1.dsc

I had a very quick look.  It builds and seems to produce correct packages.
However, there is some weird output during the process:

  dh --with quilt /usr/share/topgit/tg2quilt.mk 
 
  dh: Unknown sequence /usr/share/topgit/tg2quilt.mk (choose from: binary 
binary-arch binary-indep build clean install patch)

I don't have topgit installed.  Maybe you do, and don't see this
warning.  As I say, on first glance the .debs appear OK, so this
doesn't appear to do any harm; but better if it can be avoided.


Cheers,
-Steve


signature.asc
Description: Digital signature

Re: how to support 32- & 64-bit versions of libraries

[Steve M. Robbins]

On Wed, Apr 01, 2009 at 05:39:33PM +0200, Goswin von Brederlow wrote:
> "Steve M. Robbins"  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.  So on amd64, for
> > example, I have two incompatible gmp.h files.  Matthias provided a
> > gmp.h wrapper from Redhat that selects between architecture variants
> > based on preprocessor symbols, e.g.
> >
> > #if defined(__i386__)
> > #include "gmp-i386.h"
> > #elif defined(__ia64__)
> > #include "gmp-ia64.h"
> > ...
> >
> > However, in the case at hand it is the same architecture.  One
> > variant is compiled with -m32 and the other with -m64.  Is there a
> > symbol that can distinguish the two so that I can use the Redhat
> > trick?  Other solutions?
> 
> -m32 defines __i386__ while -m64 defined __x86_64__ and so on for each
> architecture. So just use the architecture defines. The Redhat trick
> already does the job.

Hey, that's great!  My next question is: how can I discover the suffix
programmatically?  Is there something like "dpkg-architecture
-qDEB_HOST_GNU_CPU" or "gcc -dumpmachine" that will spit out the right
suffix when given -m32 or -m64, etc?

Thanks,
-Steve


signature.asc
Description: Digital signature

Re: how to support 32- & 64-bit versions of libraries

[Steve M. Robbins]

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 the zlib example in some detail, along
with the solutions provided by Matthias K. and Bill A.  Inspired by
zlib, I figured I might as well build lib32xxx and lib64xxx wherever
possible, rather than just on amd64 and ppc, respectively.  

I'd greatly appreciate it if interested parties would have a look
at what I've done [1] and offer constructive criticism.

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.  So on amd64, for
example, I have two incompatible gmp.h files.  Matthias provided a
gmp.h wrapper from Redhat that selects between architecture variants
based on preprocessor symbols, e.g.

#if defined(__i386__)
#include "gmp-i386.h"
#elif defined(__ia64__)
#include "gmp-ia64.h"
...

However, in the case at hand it is the same architecture.  One
variant is compiled with -m32 and the other with -m64.  Is there a
symbol that can distinguish the two so that I can use the Redhat
trick?  Other solutions?


Incidentally, the zlib debian/rules uses "gcc -m64" on architectures
s390, sparc, i386, and powerpc.  The info page on compiler options for
gcc 4.3, however, says:

 These `-m' switches are supported in addition to the above on AMD
 x86-64 processors in 64-bit environments.

`-m32'
`-m64'
 Generate code for a 32-bit or 64-bit environment.  The 32-bit
 environment sets int, long and pointer to 32 bits and
 generates code that runs on any i386 system.  The 64-bit
 environment sets int to 32 bits and long and pointer to 64
 bits and generates code for AMD's x86-64 architecture. For
 darwin only the -m64 option turns off the `-fno-pic' and
 `-mdynamic-no-pic' options.

Does it really work to use -m64 on an i386?  Does amd64 code result?

Thanks,
-Steve


[1] http://svn.debian.org/wsvn/pkg-scicomp/gmp/trunk/?rev=0&sc=0


signature.asc
Description: Digital signature

how to support 32- & 64-bit versions of libraries

[Steve M. Robbins]

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 wiki page on the latter [1] has a
lot of old design proposals, but no current status?  Can someone
summarize the status of these things?

Thanks,
-Steve

[1] http://wiki.debian.org/multiarch/



signature.asc
Description: Digital signature

Re: debian OID / dicom3tools packaging

[Steve M. Robbins]

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 PS3.5), and I assume subsquent posts in this thread
mistakenly call that an OID.



On Tue, Jan 27, 2009 at 01:16:35PM +0100, Michael Hanke wrote:
> On Tue, Jan 27, 2009 at 01:05:25PM +0100, Mathieu Malaterre wrote:

> >   One important step of the packaging is the DICOM UID. In order to
> > write a DICOM file, one need a unique UID for each instance of a DICOM
> > object.  For more details:

> I wonder whether it is possible/feasible to come up with a single OID
> suiteable for all users. IMHO every user/institution would need an OID
> -- since somehow each DICOM generated by that OID needs to result in a unique
> UID.

It's not exactly the case that every user/institution needs their own
UID Root.  

I used to work for a PACS company and all UIDs generated by our
software -- running across hundreds of different PCs in dozens of
client sites -- use the same UID Root.  We could do that because we
controlled the algorithm for generating the UID suffix.  I expect that
pretty much all PACS vendors do the same thing.

To pull this off, you need to be sure that everyone using the same UID
Root is using a good algorithm; e.g. one that encodes something unique
(e.g. an ethernet address) from the computer, and a time/date stamp
with sufficient resolution (millisecond?) to guarantee uniqueness.  

An industrial-strength user will likely be using their own UID Root,
but a common Debian UID Root for the rest of us is probably fine.

By the way, since UIDs are only 64 characters long (restricted to 0-9
and "."), I'd urge you to consider keeping the Root as short as
possible, so as to leave room for the suffix generation.  Instead of
adding "med | od -b", perhaps just add ".0" for dicom3tools:

  1.3.6.1.4.1.9586.0

The next software package that needs a UID Root could then use

  1.3.6.1.4.1.9586.1

etc.  Basically, the idea is to parcel up the Debian UID space across
different UID generation algorithms -- i.e. the one in dicom3tools
versus the next one (using ".1" root).


Cheers,
-Steve


signature.asc
Description: Digital signature

autoconfigurable package: how to build two configurations?

[Steve M. Robbins]

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 that I need to run
the autoconf-generated configure script twice and build each
configuration in its own build directory.  

I'd like to see a package that does this already.
Preferably, one that uses cdbs.

Any suggestions?

Thanks,
-Steve

[1] http://lists.debian.org/debian-devel/2007/08/msg00700.html



signature.asc
Description: Digital signature

RFS: cgal (updated package)

[Steve M. Robbins]

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

tight coupling for related libraries

[Steve M. Robbins]

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 package depend on the
libgmp package with identical version number.  I'd like to use
something like the following for libgmpxx package

Depends: ${shlibs:Depends}, libgmp3 (= ${Source-Version})

but the dependencies are then

... libgmp3, ... libgmp3 (= x.y.z)

and lintian complains about the "duplication".

How do I get a single "libgmp3 (= x.y.z)" dependency?  I don't want
to mess with the shlibs file for libgmp3 itself.

Thanks,
-Steve

tight coupling for related libraries

[Steve M. Robbins]

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 package depend on the
libgmp package with identical version number.  I'd like to use
something like the following for libgmpxx package

Depends: ${shlibs:Depends}, libgmp3 (= ${Source-Version})

but the dependencies are then

... libgmp3, ... libgmp3 (= x.y.z)

and lintian complains about the "duplication".

How do I get a single "libgmp3 (= x.y.z)" dependency?  I don't want
to mess with the shlibs file for libgmp3 itself.

Thanks,
-Steve


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

Re: pure python and postinst

[Steve M. Robbins]

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, and
> > then running "compileall.py" in the postinst.  Would someone comment on
> > this?  Is it a requirement -- is it a bug to include the compiled
> > python files in the .deb?
> 
> they are not included because that would just be extra space taken up in
> the .deb file for something which can be generated on the users machine.
> 
> also, different versions of python might havent different formats for
> the bytecode (.pyc files) and thus the output of the compilation process
> would be different depending on what version of python is installed.

True.  However, the compiled files live under /usr/lib/pythonX.Y, so I
hadn't expected this to be an issue.

> is there any reason you want the files installed?

No.  I was just curious.  

The proposed python policy doc is very explicit on many things such as
the package naming scheme, how to support one or many python versions,
and the like.  But it is silent about the compiled files.


Thanks,
-Steve

Re: pure python and postinst

[Steve M. Robbins]

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, and
> > then running "compileall.py" in the postinst.  Would someone comment on
> > this?  Is it a requirement -- is it a bug to include the compiled
> > python files in the .deb?
> 
> they are not included because that would just be extra space taken up in
> the .deb file for something which can be generated on the users machine.
> 
> also, different versions of python might havent different formats for
> the bytecode (.pyc files) and thus the output of the compilation process
> would be different depending on what version of python is installed.

True.  However, the compiled files live under /usr/lib/pythonX.Y, so I
hadn't expected this to be an issue.

> is there any reason you want the files installed?

No.  I was just curious.  

The proposed python policy doc is very explicit on many things such as
the package naming scheme, how to support one or many python versions,
and the like.  But it is silent about the compiled files.


Thanks,
-Steve


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

pure python and postinst

[Steve M. Robbins]

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 covered in the policy)
is the practice of deleting the ".pyc" files in debian/rules, and
then running "compileall.py" in the postinst.  Would someone comment on
this?  Is it a requirement -- is it a bug to include the compiled
python files in the .deb?

Thanks,
-Steve

P.S.  Other comments on my package (url above) greatly appreciated!

pure python and postinst

[Steve M. Robbins]

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 covered in the policy)
is the practice of deleting the ".pyc" files in debian/rules, and
then running "compileall.py" in the postinst.  Would someone comment on
this?  Is it a requirement -- is it a bug to include the compiled
python files in the .deb?

Thanks,
-Steve

P.S.  Other comments on my package (url above) greatly appreciated!


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

Re: debhelper "I have no package to build"

[Steve M. Robbins]

Hi,

In response to the two replies,

John H. Robinson, IV is correct to point out that HTML files are
excluded from compression by default.  I didn't realise that.  In the
case at hand, however, the HTML tree has more than .html files: it
includes programming examples in .cpp files, for instance.  Compressing
those broke browsing.

Since I'm the first to do this deliberately, according to Joey Hess,
I'll simply continue using "|| true".

Thanks to all,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

debhelper "I have no package to build"

[Steve M. Robbins]

Hi,

I regularly use the template debian/rules file

  /usr/share/doc/debhelper/examples/rules.multi2

that has binary-indep and binary-arch rules that both use a single
binary-common rule.  The binary-common rule has lots of dh_* stuff
there, including dh_compress.  I decided that compressing the HTML
files would be a bad idea, so I modified it to skip that one
package using

dh_compress -Nlibboost-doc

However, the binary-indep rule sets DH_OPTIONS=-i before building
binary-common meaning that there is *no* package for dh_compress
to act upon when "binary-indep" is invoked.  The build dies with
the complaint of the subject line.

After puzzling this out, I worked around the problem using

dh_compress -Nlibboost-doc || true

to ignore the error.  

Surely this is not the first time someone has run into this.  Am I
doing something silly?  It seems a bit odd to make the "no package to
build" diagnostic a fatal error.

Thanks,
-Steve

P.S.  Cc's appreciated, as I don't subscribe.

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: gcc and -fPIC

[Steve M. Robbins]

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 granularity of compiler options easily in a build system and I
> > build an executable with -fPIC in order to build an accompanying library
> > correctly, am I trading off speed or footprint to any significant degree?
> 
> On most architectures, it doesn't really matter except for heavy
> mathematics and 3D. The only exception is i386, where the performance
> decrease is actually measurable.

Do you really mean "i386", or do you mean "ix86"?
Is there a performance hit with -fPIC on Pentium II/III/IV ?

Curiously yours,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: gcc and -fPIC

[Steve M. Robbins]

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 granularity of compiler options easily in a build system and I
> > build an executable with -fPIC in order to build an accompanying library
> > correctly, am I trading off speed or footprint to any significant degree?
> 
> On most architectures, it doesn't really matter except for heavy
> mathematics and 3D. The only exception is i386, where the performance
> decrease is actually measurable.

Do you really mean "i386", or do you mean "ix86"?
Is there a performance hit with -fPIC on Pentium II/III/IV ?

Curiously yours,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: binary-or-shlib-defines-rpath

[Steve M. Robbins]

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 should.  In this case, imagine GNU libc 3 comes out, Debian
> > decides to migrate to it, and libraries linked against glibc 2 are
> > moved to /usr/i386-glibc2-linux/lib or what not.
> 
> Aha, I didn't realize there was that kind of black magic in ld.so
> (documented in ldconfig).  Well, then I'd venture that ld.so is
> imperfect.  If it knows to ignore certain paths in ld.so.conf, it
> should have sufficient information to ignore those paths when they
> appear as rpath.  However, I sincerely hope there will be no more
> major changes in libc, making this feature needless to implement!
> (If the need arises, ld.so with such a patch can be distributed ahead
> of time.)
> 
> To explain my outburst: Proper use of rpath is a hobby horse of mine,
> as I've spent a lot of time with Solaris, trying to get applications
> and libraries coming from Linux to set it properly.  An unpriveleged
> user can not install large suites of software like GNOME or KDE
> without rpath, be it on Linux or Solaris.  libtool has eventually made
> this mostly work.  The messages implied that libtool was broken to add
> rpath, and needed fixing.  I vehemently oppose that.  Patching libtool
> in debian/rules is fine with me, though :-)

Although the latter is a horrible kludge that is going to
break when the internals of libtool change.

Is it not possible for libtool to accept a switch that means "this
library is going to be installed in a system path and I don't want
-rpath set" ?  Maybe libtool already has such a switch or will
in a future version?  Comments from the libtool maintainer ?

-S


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Best practices for shared C++ libs?

[Steve M. Robbins]

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 just by changing
the compiler.  Some folks think that templates cause a problem, too
(see below).  How difficult is it to maintain binary compatibility
with C++ libraries?  Should we bother trying, or just give up
and embed the complete "major.minor.micro" version string into
its SONAME?

Is libtool safe to use to build C++ libraries with Debian's
compilers?  The libtool manual has this to say about C++
libraries:

 from libtool manual -


11.1 Writing libraries for C++ 

Creating libraries of C++ code should be a fairly straightforward
process, because its object files differ from C ones in only three
ways: 

  1.Because of name mangling, C++ libraries are only usable by
the C++ compiler that created them. This decision was made
by the designers of C++ in order to protect users from
conflicting implementations of features such as constructors,
exception handling, and RTTI. 

  2.On some systems, the C++ compiler must take special actions
for the dynamic linker to run dynamic (i.e., run-time)
initializers. This means that we should not call `ld' directly to
link such libraries, and we should use the C++ compiler
instead. 

  3.C++ compilers will link some Standard C++ library in by
default, but libtool does not know which are these libraries, so
it cannot even run the inter-library dependence analyzer to
check how to link it in. Therefore, running `ld' to link a C++
program or library is deemed to fail. However, running the
C++ compiler directly may lead to problems related with
inter-library dependencies. 

The conclusion is that libtool is not ready for general use for C++
libraries. You should avoid any global or static variable
initializations that would cause an "initializer element is not
constant" error if you compiled them with a standard C compiler. 

There are other ways of working around this problem, but they are
beyond the scope of this manual. 

Furthermore, you'd better find out, at configure time, what are the
C++ Standard libraries that the C++ compiler will link in by
default, and explicitly list them in the link command line.
Hopefully, in the future, libtool will be able to do this job by itself. 

-

Is #2 or #3 an issue with any of the compilers in Debian?


Here's a message about the Boost libraries.  Remember that
John Maddock is concerned about binary compatibility
on many different platforms, not just Debian.  However,
I'm curious whether this is an issue for Debian or not.


- Forwarded message from John Maddock <[EMAIL PROTECTED]> -

To: "INTERNET:[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
From: John Maddock <[EMAIL PROTECTED]>
Mailing-List: list [EMAIL PROTECTED]; contact [EMAIL PROTECTED]
Date: Sun, 20 Jan 2002 06:45:52 -0500
Subject: Re: [boost] building shared boost libraries
Reply-To: [EMAIL PROTECTED]


At the risk of throwing cold water all over the place, one reason that I've
always avoided version numbering shared libraries with the regex code is
that it's not at all clear to me that it's possible to maintain binary
compatibility in C++.  In C it's pretty obvious if you do anything to break
binary compatibility, it's not clear to me what in C++ breaks compatibility
and what doesn't, particularly when the library contains template instances
*and* the compiler does link-time template instantiation.  I would guess
that one would have to ensure that the library always contained the same
template instances - probably by doing explicit template instantiation - I
for one don't want to go into that level of detail.  It is also apparent to
me that at least one commercial vendor of C++ libraries (Rogue Wave) never
assume that updated versions of their standard lib are binary compatible
with previous versions, I would be interested to know if anyone has ever
maintained binary compatibility with in C++ libraries as complex as boost. 
So the question is, if binary compatibility is effectively impossible, what
do we do?  Increment the major version number with every boost release? 
Remember that even if I think that regex hasn't changed, something it
depends upon (shared pointer for eg) may have :-(

- End forwarded message -

-Steve


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Best practices for shared C++ libs?

[Steve M. Robbins]

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 just by changing
the compiler.  Some folks think that templates cause a problem, too
(see below).  How difficult is it to maintain binary compatibility
with C++ libraries?  Should we bother trying, or just give up
and embed the complete "major.minor.micro" version string into
its SONAME?

Is libtool safe to use to build C++ libraries with Debian's
compilers?  The libtool manual has this to say about C++
libraries:

 from libtool manual -


11.1 Writing libraries for C++ 

Creating libraries of C++ code should be a fairly straightforward
process, because its object files differ from C ones in only three
ways: 

  1.Because of name mangling, C++ libraries are only usable by
the C++ compiler that created them. This decision was made
by the designers of C++ in order to protect users from
conflicting implementations of features such as constructors,
exception handling, and RTTI. 

  2.On some systems, the C++ compiler must take special actions
for the dynamic linker to run dynamic (i.e., run-time)
initializers. This means that we should not call `ld' directly to
link such libraries, and we should use the C++ compiler
instead. 

  3.C++ compilers will link some Standard C++ library in by
default, but libtool does not know which are these libraries, so
it cannot even run the inter-library dependence analyzer to
check how to link it in. Therefore, running `ld' to link a C++
program or library is deemed to fail. However, running the
C++ compiler directly may lead to problems related with
inter-library dependencies. 

The conclusion is that libtool is not ready for general use for C++
libraries. You should avoid any global or static variable
initializations that would cause an "initializer element is not
constant" error if you compiled them with a standard C compiler. 

There are other ways of working around this problem, but they are
beyond the scope of this manual. 

Furthermore, you'd better find out, at configure time, what are the
C++ Standard libraries that the C++ compiler will link in by
default, and explicitly list them in the link command line.
Hopefully, in the future, libtool will be able to do this job by itself. 

-

Is #2 or #3 an issue with any of the compilers in Debian?


Here's a message about the Boost libraries.  Remember that
John Maddock is concerned about binary compatibility
on many different platforms, not just Debian.  However,
I'm curious whether this is an issue for Debian or not.


- Forwarded message from John Maddock <[EMAIL PROTECTED]> -

To: "INTERNET:[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
From: John Maddock <[EMAIL PROTECTED]>
Mailing-List: list [EMAIL PROTECTED]; contact [EMAIL PROTECTED]
Date: Sun, 20 Jan 2002 06:45:52 -0500
Subject: Re: [boost] building shared boost libraries
Reply-To: [EMAIL PROTECTED]


At the risk of throwing cold water all over the place, one reason that I've
always avoided version numbering shared libraries with the regex code is
that it's not at all clear to me that it's possible to maintain binary
compatibility in C++.  In C it's pretty obvious if you do anything to break
binary compatibility, it's not clear to me what in C++ breaks compatibility
and what doesn't, particularly when the library contains template instances
*and* the compiler does link-time template instantiation.  I would guess
that one would have to ensure that the library always contained the same
template instances - probably by doing explicit template instantiation - I
for one don't want to go into that level of detail.  It is also apparent to
me that at least one commercial vendor of C++ libraries (Rogue Wave) never
assume that updated versions of their standard lib are binary compatible
with previous versions, I would be interested to know if anyone has ever
maintained binary compatibility with in C++ libraries as complex as boost. 
So the question is, if binary compatibility is effectively impossible, what
do we do?  Increment the major version number with every boost release? 
Remember that even if I think that regex hasn't changed, something it
depends upon (shared pointer for eg) may have :-(

- End forwarded message -

-Steve


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: help with splint

[Steve M. Robbins]

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 guide says that you don't have to hack
> makefiles for programs that use autoconf/automake because dh_make does
> it for you, so i really haven't monkeyed with install directories.
> 
> perhaps i'm doing something wrong.  are there any gotchas for
> automake/autoconf that people may suggest?

The "gotcha" is actually a bug in dh_make, as discussed here just two
weeks ago


http://lists.debian.org/debian-mentors/2002/debian-mentors-200201/msg00058.html

See http://lists.debian.org/search.html

See also http://bugs.debian.org/97811 for a couple of work-arounds.
Using DESTDIR is slightly superior, IMHO.


> also, for applications that install their man page via autoconf/make
> makefiles, do i still need to use dh_installman to install man pages?

No.  However, you usually need to specify --mandir=/usr/share/man on
the configure invocation.


Cheers,
-Steve


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: help with splint

[Steve M. Robbins]

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 guide says that you don't have to hack
> makefiles for programs that use autoconf/automake because dh_make does
> it for you, so i really haven't monkeyed with install directories.
> 
> perhaps i'm doing something wrong.  are there any gotchas for
> automake/autoconf that people may suggest?

The "gotcha" is actually a bug in dh_make, as discussed here just two
weeks ago

http://lists.debian.org/debian-mentors/2002/debian-mentors-200201/msg00058.html

See http://lists.debian.org/search.html

See also http://bugs.debian.org/97811 for a couple of work-arounds.
Using DESTDIR is slightly superior, IMHO.


> also, for applications that install their man page via autoconf/make
> makefiles, do i still need to use dh_installman to install man pages?

No.  However, you usually need to specify --mandir=/usr/share/man on
the configure invocation.


Cheers,
-Steve


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: Include bison-generated files in package?

[Steve M. Robbins]

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 included in the distribution, it should be left alone.
> 
> But it is a generated file, which shouldn't be included in the
> tarball, 

No.  Being "generated" is not the criterion used to determine what is
distributed or not.  The file "configure" is both generated and
distributed.  YACC output is generally treated in the same manner.

Ask yourself: is there any benefit from having the installer
convert the yacc input to C code?  No, there isn't.  So authors
tend to distribute the yacc-generated files (and the yacc input
files, too --- in case someone wants to modify them).


-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: Include bison-generated files in package?

[Steve M. Robbins]

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 included in the distribution, it should be left alone.
> 
> But it is a generated file, which shouldn't be included in the
> tarball, 

No.  Being "generated" is not the criterion used to determine what is
distributed or not.  The file "configure" is both generated and
distributed.  YACC output is generally treated in the same manner.

Ask yourself: is there any benefit from having the installer
convert the yacc input to C code?  No, there isn't.  So authors
tend to distribute the yacc-generated files (and the yacc input
files, too --- in case someone wants to modify them).


-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: dpkg-source: unrepresentable changes to source

[Steve M. Robbins]

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 file. These needed
> files are not included in upstream source. 
> Upstream provides an autogen.sh script. The user is supposed
> to run that script and a normal "make;make install" works
> after that.

I think you should educate the upstream author(s).  
Introduce them to "make dist".


> > However, after a number of bug reports, I have changed my mind.  It
> > doesn't pay to mess around with automake/autoconf/libtool and stuff
> > inside debian/rules.  All I do now is: make any tweaks to Makefile.am
> > or configure.in, re-run the auto-stuff on my local copy, and live with
> > the enlarged diff that results.  
> 
> I do not need to change anything until now. But I need to run these
> tools. You say you "re-run the auto-stuff on your local copy". As I understand
> you here you run it manually and then you build the diff after that. 
> I want to reach the same goal, but don't want to do it manually.
> Therefore I do "mess around with automake/.. inside debian/rules" and call the
> apropriate scripts there. This should lead to the same results, right?

Not quite.  

You might get the same .deb, but you'll also get more bug reports if
you try to do it inside debian/rules.


> >  If you need to run-something like
> > autogen.sh that has "automake --add-missing --force", just replace the
> > resulting symlinks by the corresponding file.  Again, you need only do
> > this once.
> 
> What do you mean by saying I only need to do this once? I do 
> replace this files everytime the symlinks get created. That is,
> everytime I build a new Debian package including the diff. 
> I feel I am missing your point here absolutely.  ;)

What I wrote only makes sense in the context of building from
properly-packaged sources.  By that I mean a tarball that contains
configure et al, and which you build using "./configure; make".

Apparently, it doesn't apply to your case.  But I think that is a
mistake, and I encourage you to educate upstream about "make dist".

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: dpkg-source: unrepresentable changes to source

[Steve M. Robbins]

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 file. These needed
> files are not included in upstream source. 
> Upstream provides an autogen.sh script. The user is supposed
> to run that script and a normal "make;make install" works
> after that.

I think you should educate the upstream author(s).  
Introduce them to "make dist".


> > However, after a number of bug reports, I have changed my mind.  It
> > doesn't pay to mess around with automake/autoconf/libtool and stuff
> > inside debian/rules.  All I do now is: make any tweaks to Makefile.am
> > or configure.in, re-run the auto-stuff on my local copy, and live with
> > the enlarged diff that results.  
> 
> I do not need to change anything until now. But I need to run these
> tools. You say you "re-run the auto-stuff on your local copy". As I understand
> you here you run it manually and then you build the diff after that. 
> I want to reach the same goal, but don't want to do it manually.
> Therefore I do "mess around with automake/.. inside debian/rules" and call the
> apropriate scripts there. This should lead to the same results, right?

Not quite.  

You might get the same .deb, but you'll also get more bug reports if
you try to do it inside debian/rules.


> >  If you need to run-something like
> > autogen.sh that has "automake --add-missing --force", just replace the
> > resulting symlinks by the corresponding file.  Again, you need only do
> > this once.
> 
> What do you mean by saying I only need to do this once? I do 
> replace this files everytime the symlinks get created. That is,
> everytime I build a new Debian package including the diff. 
> I feel I am missing your point here absolutely.  ;)

What I wrote only makes sense in the context of building from
properly-packaged sources.  By that I mean a tarball that contains
configure et al, and which you build using "./configure; make".

Apparently, it doesn't apply to your case.  But I think that is a
mistake, and I encourage you to educate upstream about "make dist".

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: dpkg-source: unrepresentable changes to source

[Steve M. Robbins]

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".  Normally one would expect the
source distribution to include these files (INSTALL, install-sh, etc).
The absence of such files suggests that either you are packaging from
CVS, or perhaps that you are deleting the files in debian/rules
"clean".

If you're building from CVS (I'll ignore the question "why?"), you'll
need a ".orig.tar" file to upload anyway, so the best thing to do
is "make dist", and work from the resulting tarball which will have
all the required files.

If you are deleting the files yourself, then the fix is simple: don't
do that.  Notwithstanding autotools-dev README, I find the best policy
for dealing with auto-based packages is to simply drop in the latest
/usr/share/misc/config.{guess,sub}, if required, and build.

When I packaged my first package, I thought it would be a good idea to
make the diff as small as possible.  I read the diff to double-check
the modifications I make to the sources when I package things.  Having
the diff of "configure" and "config.guess" and the like mixed in was
annoying, so I used to remove "configure" in debian/rules clean, and
run "autoconf" in debian/rules build-stamp.  The diff is much smaller
and easier to read.

However, after a number of bug reports, I have changed my mind.  It
doesn't pay to mess around with automake/autoconf/libtool and stuff
inside debian/rules.  All I do now is: make any tweaks to Makefile.am
or configure.in, re-run the auto-stuff on my local copy, and live with
the enlarged diff that results.  If you need to run-something like
autogen.sh that has "automake --add-missing --force", just replace the
resulting symlinks by the corresponding file.  Again, you need only do
this once.



On Sun, Nov 04, 2001 at 08:18:47PM +0100, Florian Hinzmann wrote:

> >> In fact I do run autogen.sh in the clean rule. Please
> > 
> > WHAT? You should CLEAN, not generate something in the clean rule.
> 
> From /usr/share/doc/autotools-dev/README.Debian.gz:
> 
> > Do note that a properly done autogen.sh invocation runs before dpkg has a
> > chance to build the source package, so as to make sure an user does NOT need
> > any of the programs called by autogen.sh to build the package. This will, in
> > fact, ease the load on auto-builders as well since the program will build 
> > much
> > faster.
> 
> Please tell me where I should call the autogen.sh if not
> in clean rule to archive this.

As I read this section, Henrique is talking about regenerating files
that are not stored in CVS.  I don't know why he put this in the
README.  Debian packaging assumes you start from a "source
distribution" tarball that *includes* all these files.  

Actually, I find Henrique's wording is slightly confusing.  It is not
true that the configure script and Makefile.in are "supposed to be
regenerated at every build".  These files need to be rebuilt each time
their input (i.e. configure.in) changes.  No more often than that.
You really only need to worry if you patch configure.in or
Makefile.am.

In addition, you need to worry about config.{guess,sub} 
*if used by the sources*.  However, it's easy enough to 
drop in the latest version when you prepare a new upload.  
The rest of /usr/share/doc/autotools-dev/README.Debian.gz 
can be safely ignored.

-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: dpkg-source: unrepresentable changes to source

[Steve M. Robbins]

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".  Normally one would expect the
source distribution to include these files (INSTALL, install-sh, etc).
The absence of such files suggests that either you are packaging from
CVS, or perhaps that you are deleting the files in debian/rules
"clean".

If you're building from CVS (I'll ignore the question "why?"), you'll
need a ".orig.tar" file to upload anyway, so the best thing to do
is "make dist", and work from the resulting tarball which will have
all the required files.

If you are deleting the files yourself, then the fix is simple: don't
do that.  Notwithstanding autotools-dev README, I find the best policy
for dealing with auto-based packages is to simply drop in the latest
/usr/share/misc/config.{guess,sub}, if required, and build.

When I packaged my first package, I thought it would be a good idea to
make the diff as small as possible.  I read the diff to double-check
the modifications I make to the sources when I package things.  Having
the diff of "configure" and "config.guess" and the like mixed in was
annoying, so I used to remove "configure" in debian/rules clean, and
run "autoconf" in debian/rules build-stamp.  The diff is much smaller
and easier to read.

However, after a number of bug reports, I have changed my mind.  It
doesn't pay to mess around with automake/autoconf/libtool and stuff
inside debian/rules.  All I do now is: make any tweaks to Makefile.am
or configure.in, re-run the auto-stuff on my local copy, and live with
the enlarged diff that results.  If you need to run-something like
autogen.sh that has "automake --add-missing --force", just replace the
resulting symlinks by the corresponding file.  Again, you need only do
this once.



On Sun, Nov 04, 2001 at 08:18:47PM +0100, Florian Hinzmann wrote:

> >> In fact I do run autogen.sh in the clean rule. Please
> > 
> > WHAT? You should CLEAN, not generate something in the clean rule.
> 
> From /usr/share/doc/autotools-dev/README.Debian.gz:
> 
> > Do note that a properly done autogen.sh invocation runs before dpkg has a
> > chance to build the source package, so as to make sure an user does NOT need
> > any of the programs called by autogen.sh to build the package. This will, in
> > fact, ease the load on auto-builders as well since the program will build much
> > faster.
> 
> Please tell me where I should call the autogen.sh if not
> in clean rule to archive this.

As I read this section, Henrique is talking about regenerating files
that are not stored in CVS.  I don't know why he put this in the
README.  Debian packaging assumes you start from a "source
distribution" tarball that *includes* all these files.  

Actually, I find Henrique's wording is slightly confusing.  It is not
true that the configure script and Makefile.in are "supposed to be
regenerated at every build".  These files need to be rebuilt each time
their input (i.e. configure.in) changes.  No more often than that.
You really only need to worry if you patch configure.in or
Makefile.am.

In addition, you need to worry about config.{guess,sub} 
*if used by the sources*.  However, it's easy enough to 
drop in the latest version when you prepare a new upload.  
The rest of /usr/share/doc/autotools-dev/README.Debian.gz 
can be safely ignored.

-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: place of ldconfig in postinst

[Steve M. Robbins]

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 scripts, it checks for some common
> > variants, and warns if your version didn't match what it expected.
> > 
> > Since you do the right thing, just ignore this warning, as it's a
> > false alarm.
> 
> maybe he waits for and "if" construct.

The lintian check is looking for an "if" construct.  You can see the
precise check in /usr/share/lintian/checks/shared-libs.

-Steve

P.S.  You guys should pay more attention to debian-mentors: the answer
was contained in a post made not more than 2-3 days ago!


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: place of ldconfig in postinst

[Steve M. Robbins]

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)
> 
> ;;
> 
> *)
> echo "postinst called with unknown argument \`$1'" >&2

By the way, if you use the debhelper scripts (dh_makeshlibs in
particular) , you don't need to write the postinst by hand,
and as a bonus, lintian will not complain about it.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: place of ldconfig in postinst

[Steve M. Robbins]

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)
> 
> ;;
> 
> *)
> echo "postinst called with unknown argument \`$1'" >&2

By the way, if you use the debhelper scripts (dh_makeshlibs in
particular) , you don't need to write the postinst by hand,
and as a bonus, lintian will not complain about it.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: place of ldconfig in postinst

[Steve M. Robbins]

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 scripts, it checks for some common
> > variants, and warns if your version didn't match what it expected.
> > 
> > Since you do the right thing, just ignore this warning, as it's a
> > false alarm.
> 
> maybe he waits for and "if" construct.

The lintian check is looking for an "if" construct.  You can see the
precise check in /usr/share/lintian/checks/shared-libs.

-Steve

P.S.  You guys should pay more attention to debian-mentors: the answer
was contained in a post made not more than 2-3 days ago!


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: New Lintian errors/warnings

[Steve M. Robbins]

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 call guarded like this:
> 
> if [ "$1" = "configure" ]; then
>   ldconfig
> fi
> 
> Is this a bug in lintian?

Possibly.  Understand that lintian is based on heuristic checks,
so yes there can be false warnings.  This particular check is
tuned to detect the shell code emitted by debhelper.  The exact
(perl) regular expression that lintian will NOT warn about is:

  /^if\s+\[\s+"\$1"\s+=\s+"configure"\s+\];\s+then\s+ldconfig\b/

On first glance, your code appears to be OK.  Maybe the "if"
is not in column 1?

A separate limitation of lintian is that it will only ignore
ONE instance of "ldconfig".  If you put the same code in there
twice, you'll get a warning.  I have done this accidentally by
putting in my own "ldconfig" *as well as* using #DEBHELPER
(which will insert the same ldconfig code).

Regards,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: New Lintian errors/warnings

[Steve M. Robbins]

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 call guarded like this:
> 
> if [ "$1" = "configure" ]; then
>   ldconfig
> fi
> 
> Is this a bug in lintian?

Possibly.  Understand that lintian is based on heuristic checks,
so yes there can be false warnings.  This particular check is
tuned to detect the shell code emitted by debhelper.  The exact
(perl) regular expression that lintian will NOT warn about is:

  /^if\s+\[\s+"\$1"\s+=\s+"configure"\s+\];\s+then\s+ldconfig\b/

On first glance, your code appears to be OK.  Maybe the "if"
is not in column 1?

A separate limitation of lintian is that it will only ignore
ONE instance of "ldconfig".  If you put the same code in there
twice, you'll get a warning.  I have done this accidentally by
putting in my own "ldconfig" *as well as* using #DEBHELPER
(which will insert the same ldconfig code).

Regards,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: lintian - man pages

[Steve M. Robbins]

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: binary-without-manpage redael-filmview
> W: redael: file-in-unusual-dir share/man/man1/redael.1
> W: redael: file-in-unusual-dir share/man/man1/redael-filmview.1
> 
> This seems really silly.  Do i need to pass some options to dh_installman?
> i read the man page, but my impression is that dh_installman is designed
> for upstream packages that don't have man pages.  i'm missing something
> really obvious.

The manpages are in the wrong place; they should be in usr/share/man/man1.
If the manpages are installed using the upstream "make install", then you
don't need to fool with "dh_installman".

Perhaps you did
make install prefix=debian/tmp
instead of
make install prefix=debian/tmp/usr

where "tmp" might be "redael", depending on how you set DH_COMPAT.

If the upstream is done right with automake, you could also use
"make install DESTDIR=debian/tmp"

 
> ** problem2:
> 
> W: redael: package-contains-upstream-install-documentation 
> usr/share/doc/redael/INSTALL
> E: redael: symlink-should-be-relative usr/share/doc/redael/INSTALL 
> /usr/share/automake/INSTALL
> 
> A generic INSTALL is required by GNU standards, no?

GNU standards apply to the source package, not the binary one.
I tend not to include install instructions in the .deb.


>  i'm using autotools
> to build stuff.  Should i replace the symlink with a copy of the file?

I wouldn't include anything, but if you insist, it should simply be a relative
link, like the (second) error message says.  The link should be, in other words,
"../../automake/INSTALL".


-Steve

P.S.  Lintian's "-i" option can be extremely helpful!

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: lintian - man pages

[Steve M. Robbins]

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: binary-without-manpage redael-filmview
> W: redael: file-in-unusual-dir share/man/man1/redael.1
> W: redael: file-in-unusual-dir share/man/man1/redael-filmview.1
> 
> This seems really silly.  Do i need to pass some options to dh_installman?
> i read the man page, but my impression is that dh_installman is designed
> for upstream packages that don't have man pages.  i'm missing something
> really obvious.

The manpages are in the wrong place; they should be in usr/share/man/man1.
If the manpages are installed using the upstream "make install", then you
don't need to fool with "dh_installman".

Perhaps you did
make install prefix=debian/tmp
instead of
make install prefix=debian/tmp/usr

where "tmp" might be "redael", depending on how you set DH_COMPAT.

If the upstream is done right with automake, you could also use
"make install DESTDIR=debian/tmp"

 
> ** problem2:
> 
> W: redael: package-contains-upstream-install-documentation 
>usr/share/doc/redael/INSTALL
> E: redael: symlink-should-be-relative usr/share/doc/redael/INSTALL 
>/usr/share/automake/INSTALL
> 
> A generic INSTALL is required by GNU standards, no?

GNU standards apply to the source package, not the binary one.
I tend not to include install instructions in the .deb.


>  i'm using autotools
> to build stuff.  Should i replace the symlink with a copy of the file?

I wouldn't include anything, but if you insist, it should simply be a relative
link, like the (second) error message says.  The link should be, in other words,
"../../automake/INSTALL".


-Steve

P.S.  Lintian's "-i" option can be extremely helpful!

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: lintian-warning copyright-lists-upstream-authors-like-dh_make

[Steve M. Robbins]

Hi,

By way of preface, I really meant to make the general observation that
"help" text -- like package descriptions -- should be carefully
crafted.  My intention is not to pick on the author of this particular
text (I'm surely guilty of equally-bad phrasing).  And yes, I know
that this particular 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. This is not a
> > > N:   fixed field name, it's just a default dh_make value. You should 
> > > adjust
> > > N:   it.
> > > N:
> > 
> > ... this "long description" is spectacularly uninformative!
> 
> Er, what else is there to say but that what I said above? 

Well to start with, there is no need to mention "dh_make".  I
understand that one source of this "error" comes from copying the
dh_make template verbatim.  But for other folks who just copied
another copyright file --- and have never used dh_make --- the
reference is puzzling red herring.


> It says that you
> should adjust the string "Upstream Author(s)" in your copyright file, isn't
> it obvious? And isn't it obvious that it is left to you to change it the way
> you like it[1], since there is no specific format mentioned?

Well, no.  It's not obvious to me.  

Already in the first sentence, I am unsure whether you mean the string
"Upstream Author(s)", or the actual authors listed in my copyright
file.  In the second line, I'm confused what "dh_make" has to do with
it.  And what "dh_make value" is being referred to?  By now I'm so
confused that I don't know what "it" refers to in the final sentence.

There were already a couple of good clarifications in the -mentors
thread.  As I understand it, the intent is to say

Do not use "Upstream Author(s)" in the copyright file.  Use
either "Upstream Author" or, if there are multiple authors,
"Upstream Authors".


-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: lintian-warning copyright-lists-upstream-authors-like-dh_make

[Steve M. Robbins]

Hi,

By way of preface, I really meant to make the general observation that
"help" text -- like package descriptions -- should be carefully
crafted.  My intention is not to pick on the author of this particular
text (I'm surely guilty of equally-bad phrasing).  And yes, I know
that this particular 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. This is not a
> > > N:   fixed field name, it's just a default dh_make value. You should adjust
> > > N:   it.
> > > N:
> > 
> > ... this "long description" is spectacularly uninformative!
> 
> Er, what else is there to say but that what I said above? 

Well to start with, there is no need to mention "dh_make".  I
understand that one source of this "error" comes from copying the
dh_make template verbatim.  But for other folks who just copied
another copyright file --- and have never used dh_make --- the
reference is puzzling red herring.


> It says that you
> should adjust the string "Upstream Author(s)" in your copyright file, isn't
> it obvious? And isn't it obvious that it is left to you to change it the way
> you like it[1], since there is no specific format mentioned?

Well, no.  It's not obvious to me.  

Already in the first sentence, I am unsure whether you mean the string
"Upstream Author(s)", or the actual authors listed in my copyright
file.  In the second line, I'm confused what "dh_make" has to do with
it.  And what "dh_make value" is being referred to?  By now I'm so
confused that I don't know what "it" refers to in the final sentence.

There were already a couple of good clarifications in the -mentors
thread.  As I understand it, the intent is to say

Do not use "Upstream Author(s)" in the copyright file.  Use
either "Upstream Author" or, if there are multiple authors,
"Upstream Authors".


-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: lintian-warning copyright-lists-upstream-authors-like-dh_make

[Steve M. Robbins]

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 fill out the dh_make template?
> > i could not find this rule anymore in the lintian on the mips box i
> > just checked, btw. So maybe this is already removed.
> 
> You can always find out more about a lintian message like this:
> 
> $ echo 'W: prips: copyright-lists-upstream-authors-like-dh_make' | 
> lintian-info

Sage advice, indeed.  However ...

> W: prips: copyright-lists-upstream-authors-like-dh_make
> N:
> N:   There is "Upstream Author(s)" in your copyright file. This is not a
> N:   fixed field name, it's just a default dh_make value. You should adjust
> N:   it.
> N:

... this "long description" is spectacularly uninformative!

Whoever is worrying about package descriptions should include lintian
and other "help" messages in their consideration.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: lintian-warning copyright-lists-upstream-authors-like-dh_make

[Steve M. Robbins]

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 fill out the dh_make template?
> > i could not find this rule anymore in the lintian on the mips box i
> > just checked, btw. So maybe this is already removed.
> 
> You can always find out more about a lintian message like this:
> 
> $ echo 'W: prips: copyright-lists-upstream-authors-like-dh_make' | lintian-info

Sage advice, indeed.  However ...

> W: prips: copyright-lists-upstream-authors-like-dh_make
> N:
> N:   There is "Upstream Author(s)" in your copyright file. This is not a
> N:   fixed field name, it's just a default dh_make value. You should adjust
> N:   it.
> N:

... this "long description" is spectacularly uninformative!

Whoever is worrying about package descriptions should include lintian
and other "help" messages in their consideration.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: Upstream changelog

[Steve M. Robbins]

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 that do not download the source package.
> > The NEWS file, on the other hand, just lists the actual compound
> > changes between releases.
> 
> In all the packages I've seen with something like this, the ChangeLog was
> included as changelog.gz and NEWS was included as NEWS.gz.

That's what I would recommend also.  I am one of those who will look
into the detailed source changelog from time-to-time.  And the NEWS
file is useful, too; probably more useful.  Include both.  

Never rename "NEWS" to "changelog" --- the two files serve disparate
needs.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: Upstream changelog

[Steve M. Robbins]

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 that do not download the source package.
> > The NEWS file, on the other hand, just lists the actual compound
> > changes between releases.
> 
> In all the packages I've seen with something like this, the ChangeLog was
> included as changelog.gz and NEWS was included as NEWS.gz.

That's what I would recommend also.  I am one of those who will look
into the detailed source changelog from time-to-time.  And the NEWS
file is useful, too; probably more useful.  Include both.  

Never rename "NEWS" to "changelog" --- the two files serve disparate
needs.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: cleanrule of my package

[Steve M. Robbins]

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 problems config.cache
> N:   and config.status are produced by GNU autoconf's configure scripts. If
> N:   they are left in the source package, autobuilders may pick up settings
> N:   for the wrong architecture, causing problems. The clean rule for the
> N:   package should remove this file.
> N:
> E: eroaster source: autoconf-generated-file-in-source config.cache
> ---
> I´ve added the following to my cleanrule, but i still get the message:
> (taken from debian/rules)
> ---
> clean:
> dh_testdir
> dh_testroot
> rm -f build-stamp configure-stamp
> 
> # Add here commands to clean up after the build process.
> rm -f eroaster Makefile configure.cache configure.log
> configure.status constants.py ecat.py

Instead of removing things by hand, why not use a simple "make clean"?
If that does not clean enough (probably a bug upstream), then you
can remove other things explicitly.

By the way, the files in question are "config.cache", "config.log",
and "config.status".  Have a careful look at the lintian "E" line
you quoted above.

-S


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: cleanrule of my package

[Steve M. Robbins]

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 problems config.cache
> N:   and config.status are produced by GNU autoconf's configure scripts. If
> N:   they are left in the source package, autobuilders may pick up settings
> N:   for the wrong architecture, causing problems. The clean rule for the
> N:   package should remove this file.
> N:
> E: eroaster source: autoconf-generated-file-in-source config.cache
> ---
> I´ve added the following to my cleanrule, but i still get the message:
> (taken from debian/rules)
> ---
> clean:
> dh_testdir
> dh_testroot
> rm -f build-stamp configure-stamp
> 
> # Add here commands to clean up after the build process.
> rm -f eroaster Makefile configure.cache configure.log
> configure.status constants.py ecat.py

Instead of removing things by hand, why not use a simple "make clean"?
If that does not clean enough (probably a bug upstream), then you
can remove other things explicitly.

By the way, the files in question are "config.cache", "config.log",
and "config.status".  Have a careful look at the lintian "E" line
you quoted above.

-S


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: versioned shlibs file -- when and why

[Steve M. Robbins]

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. bump the version uncondtionally) simply
> > the lazy-man's way of doing this?
> 
> Yes. More kindly phrased, it's the conservative option; it always
> ensures that other packages' shared library dependencies are at least as
> tight as they need to be, so that if the maintainer screws up then they
> won't break. The flip side is that packages might end up with
> dependencies that are too tight and so find it harder to be upgraded in
> testing: GNOME packages used to have this problem until the gnome-core
> maintainer started generating a more accurate shlibs file.
> 
> Joey, perhaps dh_makeshlibs(1) could have a note in its man page saying
> something like this?

I agree it would be nice if dh_makeshlibs had a note explaining what
you did about the -V option.

I also think it would be nice to have a note somewhere that the
optional version field is useful for changes in the library ABI.
Would the policy manual section on "shlibs" (either 9.1 or 9.4) be a
suitable place for that?

-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: versioned shlibs file -- when and why

[Steve M. Robbins]

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. bump the version uncondtionally) simply
> > the lazy-man's way of doing this?
> 
> Yes. More kindly phrased, it's the conservative option; it always
> ensures that other packages' shared library dependencies are at least as
> tight as they need to be, so that if the maintainer screws up then they
> won't break. The flip side is that packages might end up with
> dependencies that are too tight and so find it harder to be upgraded in
> testing: GNOME packages used to have this problem until the gnome-core
> maintainer started generating a more accurate shlibs file.
> 
> Joey, perhaps dh_makeshlibs(1) could have a note in its man page saying
> something like this?

I agree it would be nice if dh_makeshlibs had a note explaining what
you did about the -V option.

I also think it would be nice to have a note somewhere that the
optional version field is useful for changes in the library ABI.
Would the policy manual section on "shlibs" (either 9.1 or 9.4) be a
suitable place for that?

-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: versioned shlibs file -- when and why

[Steve M. Robbins]

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 need to
> increment the library so number (and thereby change the package name).
> However, a binary compiled against libfoo 2.1.2 that uses foo_read will /not/
> work with libfoo 2.1.1, so you need a version in shlibs.

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. bump the version uncondtionally) simply
the lazy-man's way of doing this?

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

versioned shlibs file -- when and why

[Steve M. Robbins]

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 immediately comes to mind is if package version
1.1 produces "libfoo", and version 1.2 produces "libfoo" *and*
"libbar".  You'd need version info for "libbar", yes?

Other reasons?

How is the -V option of dh_makeshlibs used?  Using naked "-V"
(i.e. not "-V 1.2"), you get a package that claims only the latest
version is sufficient to satisfy the dependency on "libfoo".
What is the purpose of doing that?

-S


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: versioned shlibs file -- when and why

[Steve M. Robbins]

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 need to
> increment the library so number (and thereby change the package name).
> However, a binary compiled against libfoo 2.1.2 that uses foo_read will /not/
> work with libfoo 2.1.1, so you need a version in shlibs.

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. bump the version uncondtionally) simply
the lazy-man's way of doing this?

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

versioned shlibs file -- when and why

[Steve M. Robbins]

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 immediately comes to mind is if package version
1.1 produces "libfoo", and version 1.2 produces "libfoo" *and*
"libbar".  You'd need version info for "libbar", yes?

Other reasons?

How is the -V option of dh_makeshlibs used?  Using naked "-V"
(i.e. not "-V 1.2"), you get a package that claims only the latest
version is sufficient to satisfy the dependency on "libfoo".
What is the purpose of doing that?

-S


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: Shared libraries and sections

[Steve M. Robbins]

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 cannot reside on the same system. Does this need to be 
> fixed? There doesn't seem to be any explicit policy on this.

We just had a discussion on this last week.  I suggest you check the
archives.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: Shared libraries and sections

[Steve M. Robbins]

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 cannot reside on the same system. Does this need to be 
> fixed? There doesn't seem to be any explicit policy on this.

We just had a discussion on this last week.  I suggest you check the
archives.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: upstream library without a SONAME

[Steve M. Robbins]

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
> SONAME.

Are we?  

I thought I was speaking of a library that does not have any SONAME whatsoever.

Is there another meaning of SONAME of which I am not aware?  I thought
it referred *only* to the tag embedded in the file; i.e. the one you can
find using "objdump -p xxx.so | grep SONAME".

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: upstream library without a SONAME

[Steve M. Robbins]

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 in policy.  [...]

> > 2a. If so, what to do about upstream packages that don't supply one?
> 
> I would suggest that it's a maintainer's responsibility, as liaison
> to the upstream developers, to petition them to adopt SONAMEs in any
> shared libraries they provide that will be linked by external
> applications.

While I agree with you, and have started the petitioning process, I'd
still really appreciate suggestions on what SONAME to use for the
package between now and such time as upstream adopts a SONAME.

I could arbitrarily start with SONAME libInventor.so.0, and fix up the
packaging with an epoch if I get stuck later.  Or, since the source
version is 2.something, I could start with SONAME libInventor.so.2.
Or is the correct approach to just embed the entire source version
in the SONAME, i.e. libInventor.so.2.1.5-7 (yes, upstream source
version ends in -7)?

Thanks,
-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: upstream library without a SONAME

[Steve M. Robbins]

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 I guess I'm still searching for the answer to my original questions:
> > 
> > 1.  Does Debian require a SONAME for a shared lib?
> 
> You mean the tag inside the library itself?

Yes.
 
> All of the shared libraries I have installed on my machine have an
> embedded SONAME tag.  I thought this was required by the dynamic linker?

Not so!

cd /usr/lib
for x in *.so ; do objdump -p $x | grep -q SONAME || echo $x; done

Results:

>From my preliminary inventor packages:
libInventor.so  These are mine
libInventorXt.so

>From package gmt:
libgmt.so
libpsl.so

>From package swig:
libswigpl.so
libswigpy.so
libswigtcl.so
libswigtcl8.so

These are perfectly good shared libs, in the sense that I can
link against them:

[EMAIL PROTECTED] /usr/bin/ivview |grep Inventor
libInventorXt.so => /usr/lib/libInventorXt.so (0x40026000)
libInventor.so => /usr/lib/libInventor.so (0x400b8000)

 
I gather from Steve L's response that he would consider these packages
to be in violation of policy, however.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: upstream library without a SONAME

[Steve M. Robbins]

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 of
> > the file name, at least in principle.
> 
> It's not quite that simple.
> 
> There's a good description of things included in the libtool documentation.
> Install libtool-doc and read the texinfo section on versioning.

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.  More importantly, all libtool does is manage
the choice of SONAME for you.  At the end of the day, there is still a
single SONAME embedded in your shared library.


So I guess I'm still searching for the answer to my original questions:

1.  Does Debian require a SONAME for a shared lib?
2a. If so, what to do about upstream packages that don't supply one?
2b. If not, what the heck does the discussion on package naming in
policy section 11.3 mean?

Anyone?

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: upstream library without a SONAME

[Steve M. Robbins]

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
> SONAME.

Are we?  

I thought I was speaking of a library that does not have any SONAME whatsoever.

Is there another meaning of SONAME of which I am not aware?  I thought
it referred *only* to the tag embedded in the file; i.e. the one you can
find using "objdump -p xxx.so | grep SONAME".

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: upstream library without a SONAME

[Steve M. Robbins]

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
file.  As I understand things, the SONAME is completely independent of
the file name, at least in principle.  In typical practice, the
filename _is_ the SONAME plus some minor version digits.

For example, the file libz.so.1.1.3 has SONAME libz.so.1:

  [EMAIL PROTECTED] -p /usr/lib/libz.so.1.1.3 | grep SONAME
SONAME  libz.so.1


> Policy uses
> this term incorrectly to refer to the extension of the soname.
> Saying that a shared library must have a SONAME is then equivalent
> to saying that it must have a filename by which it is known.

Are you saying that the intention of policy section 11.3 is to say

if the library filename is libfoo.x.y.z, then please
name the package libfoox 
?

That makes some sense.  If true, we need to correct the language
of the policy document.

 
> > If true, what is the procedure for packaging, say Inventor, that
> > builds two shared libs without a SONAME?  
> 
> Assuming you mean it doesn't have an extension with an ABI version code,
> you can just package it as it is, with the knowledge that future updates
> to the ABI may break compatibility.  You should bug upstream about this.

I don't know what you mean by "extension with an ABI version code".

The situation is this.  The library is built in a file named
libInventor.so.  This file has *no* SONAME embedded in it.

I could simply name the package "libinventor".  

On the other hand, the source version is 2.1.5-7, so I could name
the package "libinventor2".  However, it would not contain the file
"/usr/lib/libInventor.so.2", as one should expect.

 
> > If, for the sake of argument, upstream is unwilling to commit to
> > a version number, should one just make it up?
> 
> No.  Any precompiled third-party apps will need to use the official SONAME,

Ah, good point.  Thanks.

-Steve


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: upstream library without a SONAME

[Steve M. Robbins]

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 in policy.  [...]

> > 2a. If so, what to do about upstream packages that don't supply one?
> 
> I would suggest that it's a maintainer's responsibility, as liaison
> to the upstream developers, to petition them to adopt SONAMEs in any
> shared libraries they provide that will be linked by external
> applications.

While I agree with you, and have started the petitioning process, I'd
still really appreciate suggestions on what SONAME to use for the
package between now and such time as upstream adopts a SONAME.

I could arbitrarily start with SONAME libInventor.so.0, and fix up the
packaging with an epoch if I get stuck later.  Or, since the source
version is 2.something, I could start with SONAME libInventor.so.2.
Or is the correct approach to just embed the entire source version
in the SONAME, i.e. libInventor.so.2.1.5-7 (yes, upstream source
version ends in -7)?

Thanks,
-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: upstream library without a SONAME

[Steve M. Robbins]

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 I guess I'm still searching for the answer to my original questions:
> > 
> > 1.  Does Debian require a SONAME for a shared lib?
> 
> You mean the tag inside the library itself?

Yes.
 
> All of the shared libraries I have installed on my machine have an
> embedded SONAME tag.  I thought this was required by the dynamic linker?

Not so!

cd /usr/lib
for x in *.so ; do objdump -p $x | grep -q SONAME || echo $x; done

Results:

>From my preliminary inventor packages:
libInventor.so  These are mine
libInventorXt.so

>From package gmt:
libgmt.so
libpsl.so

>From package swig:
libswigpl.so
libswigpy.so
libswigtcl.so
libswigtcl8.so

These are perfectly good shared libs, in the sense that I can
link against them:

steve@riemann{steve}ldd /usr/bin/ivview |grep Inventor
libInventorXt.so => /usr/lib/libInventorXt.so (0x40026000)
libInventor.so => /usr/lib/libInventor.so (0x400b8000)

 
I gather from Steve L's response that he would consider these packages
to be in violation of policy, however.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

upstream library without a SONAME

[Steve M. Robbins]

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 without a SONAME?  

I suppose the best option is to bug upstream until they give me a
version to use, and that's what I intend to do.

If, for the sake of argument, upstream is unwilling to commit to
a version number, should one just make it up?  Start with version 0?
Major version of the package?  Or can one leave off the SONAME entirely?

Thanks,
-Steve


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: upstream library without a SONAME

[Steve M. Robbins]

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 of
> > the file name, at least in principle.
> 
> It's not quite that simple.
> 
> There's a good description of things included in the libtool documentation.
> Install libtool-doc and read the texinfo section on versioning.

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.  More importantly, all libtool does is manage
the choice of SONAME for you.  At the end of the day, there is still a
single SONAME embedded in your shared library.


So I guess I'm still searching for the answer to my original questions:

1.  Does Debian require a SONAME for a shared lib?
2a. If so, what to do about upstream packages that don't supply one?
2b. If not, what the heck does the discussion on package naming in
policy section 11.3 mean?

Anyone?

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: upstream library without a SONAME

[Steve M. Robbins]

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
file.  As I understand things, the SONAME is completely independent of
the file name, at least in principle.  In typical practice, the
filename _is_ the SONAME plus some minor version digits.

For example, the file libz.so.1.1.3 has SONAME libz.so.1:

  steve@riemann{steve}objdump -p /usr/lib/libz.so.1.1.3 | grep SONAME
SONAME  libz.so.1


> Policy uses
> this term incorrectly to refer to the extension of the soname.
> Saying that a shared library must have a SONAME is then equivalent
> to saying that it must have a filename by which it is known.

Are you saying that the intention of policy section 11.3 is to say

if the library filename is libfoo.x.y.z, then please
name the package libfoox 
?

That makes some sense.  If true, we need to correct the language
of the policy document.

 
> > If true, what is the procedure for packaging, say Inventor, that
> > builds two shared libs without a SONAME?  
> 
> Assuming you mean it doesn't have an extension with an ABI version code,
> you can just package it as it is, with the knowledge that future updates
> to the ABI may break compatibility.  You should bug upstream about this.

I don't know what you mean by "extension with an ABI version code".

The situation is this.  The library is built in a file named
libInventor.so.  This file has *no* SONAME embedded in it.

I could simply name the package "libinventor".  

On the other hand, the source version is 2.1.5-7, so I could name
the package "libinventor2".  However, it would not contain the file
"/usr/lib/libInventor.so.2", as one should expect.

 
> > If, for the sake of argument, upstream is unwilling to commit to
> > a version number, should one just make it up?
> 
> No.  Any precompiled third-party apps will need to use the official SONAME,

Ah, good point.  Thanks.

-Steve


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

upstream library without a SONAME

[Steve M. Robbins]

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 without a SONAME?  

I suppose the best option is to bug upstream until they give me a
version to use, and that's what I intend to do.

If, for the sake of argument, upstream is unwilling to commit to
a version number, should one just make it up?  Start with version 0?
Major version of the package?  Or can one leave off the SONAME entirely?

Thanks,
-Steve


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: Re: Makefile.in

[Steve M. Robbins]

On Sun, Jul 08, 2001 at 08:57:38PM +0200, Robert Millan wrote:
> On Sun, 8 Jul 2001 12:51:31 -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'
> >
> On Sun, 8 Jul 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
> > the INSTALL file!
> 
> i'm sorry, i forgot to say i don't want to install it but to make a package :)

Making a package involves "installing" it!  

You had better re-read the packaging manual.  The New Maintainer's
Guide http://www.debian.org/doc/maint-guide/ is quite good.  Then have
a look at debian/rules in a package that uses autoconf (e.g.
isapnptools).

> will changing the "prefix = @prefix@" line to "prefix = /usr" do?

No.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: Makefile.in

[Steve M. Robbins]

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.  And if you're installing things in /etc, set
--sysconfdir=/etc.


In general: don't be afraid to run ./configure --help nor to read
the INSTALL file!

-S


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: Re: Makefile.in

[Steve M. Robbins]

On Sun, Jul 08, 2001 at 08:57:38PM +0200, Robert Millan wrote:
> On Sun, 8 Jul 2001 12:51:31 -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'
> >
> On Sun, 8 Jul 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
> > the INSTALL file!
> 
> i'm sorry, i forgot to say i don't want to install it but to make a package :)

Making a package involves "installing" it!  

You had better re-read the packaging manual.  The New Maintainer's
Guide http://www.debian.org/doc/maint-guide/ is quite good.  Then have
a look at debian/rules in a package that uses autoconf (e.g.
isapnptools).

> will changing the "prefix = @prefix@" line to "prefix = /usr" do?

No.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: Makefile.in

[Steve M. Robbins]

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.  And if you're installing things in /etc, set
--sysconfdir=/etc.


In general: don't be afraid to run ./configure --help nor to read
the INSTALL file!

-S


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: undocumented(7)

[Steve M. Robbins]

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
> symlinks to undocumented(7), which didn't exist.

My humble opinion?  Undocumented(7) is simply a crutch for lazy
developers.  File the bug!  Write the missing manpage and attach
it to the bug report.  

The sooner we can remove undocumented(7) without causing dangling
links, the better debian will be.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: undocumented(7)

[Steve M. Robbins]

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
> symlinks to undocumented(7), which didn't exist.

My humble opinion?  Undocumented(7) is simply a crutch for lazy
developers.  File the bug!  Write the missing manpage and attach
it to the bug report.  

The sooner we can remove undocumented(7) without causing dangling
links, the better debian will be.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: removing old conffiles on upgrade

[Steve M. Robbins]

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 the new one is 
> > /etc/filerunner
> > and the problem is that when installing new package, and an older version is
> > installed, dpkg gives an error message, and the old conffile directory,
> > not being empty, does not get removed.
> 
> You could you copy the old version to the new in the preinst and
> remove the old version in the postinst.  Yes, dpkg will warn that the
> old directory is not empty, but don't worry about it.  But be careful
> to check the value of $1 and only to do them when the value is
> sensible (eg not when it's abort-*).

What if you MOVED the file, rather than copying it: would dpkg still
complain?

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: removing old conffiles on upgrade

[Steve M. Robbins]

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 the new one is /etc/filerunner
> > and the problem is that when installing new package, and an older version is
> > installed, dpkg gives an error message, and the old conffile directory,
> > not being empty, does not get removed.
> 
> You could you copy the old version to the new in the preinst and
> remove the old version in the postinst.  Yes, dpkg will warn that the
> old directory is not empty, but don't worry about it.  But be careful
> to check the value of $1 and only to do them when the value is
> sensible (eg not when it's abort-*).

What if you MOVED the file, rather than copying it: would dpkg still
complain?

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: Depricating a library

[Steve M. Robbins]

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 need the library.
> > 
> > Would I need to make an empty package of libqtecasound to ensure
> > it no longer exists, or do I make newer version of ecawave and qtecasound
> > to Conflicts: with them, or do I just leave them there ? 
> 
> Since the only apps that used to depend on it, now no longer need it, file a
> bug against ftp.d.o asking for libqtecasound to be removed from the
> archives, and make new versions of qtecasound and evawave, that have
> Conflicts: libqtecasound, to make sure it gets removed from systems as well.

Surely removing the library from the archives is enough.  Dselect will
then show it as "obsolete".

Making two packages artificially conflict with the obsolete lib seems
obnoxious.  Leave it to the local admin to decide what to do with an
obsolete package.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: Depricating a library

[Steve M. Robbins]

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 need the library.
> > 
> > Would I need to make an empty package of libqtecasound to ensure
> > it no longer exists, or do I make newer version of ecawave and qtecasound
> > to Conflicts: with them, or do I just leave them there ? 
> 
> Since the only apps that used to depend on it, now no longer need it, file a
> bug against ftp.d.o asking for libqtecasound to be removed from the
> archives, and make new versions of qtecasound and evawave, that have
> Conflicts: libqtecasound, to make sure it gets removed from systems as well.

Surely removing the library from the archives is enough.  Dselect will
then show it as "obsolete".

Making two packages artificially conflict with the obsolete lib seems
obnoxious.  Leave it to the local admin to decide what to do with an
obsolete package.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: Sponsoring, signing, etc.

[Steve M. Robbins]

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 sponsored guy? (some time ago,
> when I was sponsored before entering Debian, I remember registering in
> some web page with a list of sponsors and sponsored people).

I know of a page where folks register to FIND a sponsor.  (Look at the
list of "projects" in the Debian Developer's Corner.)  Since he already
has one, the value of registering is lost on me.
 

> - What should I include in control, his name or my name?
> 
> - What should I include in changelog, his name or my name?

It would be the package maintainer creating those files.  You should
not touch them.  Your job is only to take the .orig and .diff files,
build the package, and upload it.


> I saw a discussion in this list some time ago about all this, but I do
> not find an answer to these questions. I saw nothing in w.d.o/devel
> either, although maybe I did'n look at the correct places...

Indeed, it has been discussed.  Look harder!


> I assume that, once these questions are answered, I can just rebuild
> the package with:
> 
> dpkg-buildpackage [EMAIL PROTECTED] -rfakeroot -sgpg -tc

The last time this came up, I saved the following two suggestions.

Rick Younie suggested:

dpkg-buildpackage -rfakeroot -k"your key"

where "your key" identifies the key the sponsor wants to sign
with

and Adrian Bunk responded that he prefers to use

dpkg-buildpackage -us -uc -rfakeroot
debsign -m'Adrian Bunk' package.changes


I use Rick's procedure and have not had problems.


> And dput it to incoming. Am I missing something? In particular, are
> the bugs against this package going to be assigned to somebody?

The bugs will be sent to the Maintainer: listed in the control file, I
believe.  That's why you should leave it to the real maintainer ...


Cheers,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: Sponsoring, signing, etc.

[Steve M. Robbins]

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 sponsored guy? (some time ago,
> when I was sponsored before entering Debian, I remember registering in
> some web page with a list of sponsors and sponsored people).

I know of a page where folks register to FIND a sponsor.  (Look at the
list of "projects" in the Debian Developer's Corner.)  Since he already
has one, the value of registering is lost on me.
 

> - What should I include in control, his name or my name?
> 
> - What should I include in changelog, his name or my name?

It would be the package maintainer creating those files.  You should
not touch them.  Your job is only to take the .orig and .diff files,
build the package, and upload it.


> I saw a discussion in this list some time ago about all this, but I do
> not find an answer to these questions. I saw nothing in w.d.o/devel
> either, although maybe I did'n look at the correct places...

Indeed, it has been discussed.  Look harder!


> I assume that, once these questions are answered, I can just rebuild
> the package with:
> 
> dpkg-buildpackage [EMAIL PROTECTED] -rfakeroot -sgpg -tc

The last time this came up, I saved the following two suggestions.

Rick Younie suggested:

dpkg-buildpackage -rfakeroot -k"your key"

where "your key" identifies the key the sponsor wants to sign
with

and Adrian Bunk responded that he prefers to use

dpkg-buildpackage -us -uc -rfakeroot
debsign -m'Adrian Bunk' package.changes


I use Rick's procedure and have not had problems.


> And dput it to incoming. Am I missing something? In particular, are
> the bugs against this package going to be assigned to somebody?

The bugs will be sent to the Maintainer: listed in the control file, I
believe.  That's why you should leave it to the real maintainer ...


Cheers,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: Autoconf test for Debian?

[Steve M. Robbins]

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 hope 
> at some stage to feed these diffs upstream (things like file paths, etc). 

I'm really confused about what the purpose of this is.

If you're packaging existing source for Debian, then just make the
changes, and they'll show up in the package's .diff file.

If you are the author of the code in question, or want to propose
changes to the upstream author, make things customizable in a generic
manner, then set them appropriately in debian/rules.

For example, if the issue is the location of a config file, then
change the code to use, e.g. ${sysconfdir}/bla.conf, then call
"./configure --sysconfdir=/etc" in debian/rules.


> ...and all other changes in scripts are based on "#ifdef DEBIAN".

Euh ... basing _any_ source variations on DEBIAN strikes me as a
really bad idea, in general.  Use the power of autoconf to do things
in a generic manner, then specialize them for debian in debian/rules.

Regards,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: Autoconf test for Debian?

[Steve M. Robbins]

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 hope 
> at some stage to feed these diffs upstream (things like file paths, etc). 

I'm really confused about what the purpose of this is.

If you're packaging existing source for Debian, then just make the
changes, and they'll show up in the package's .diff file.

If you are the author of the code in question, or want to propose
changes to the upstream author, make things customizable in a generic
manner, then set them appropriately in debian/rules.

For example, if the issue is the location of a config file, then
change the code to use, e.g. ${sysconfdir}/bla.conf, then call
"./configure --sysconfdir=/etc" in debian/rules.


> ...and all other changes in scripts are based on "#ifdef DEBIAN".

Euh ... basing _any_ source variations on DEBIAN strikes me as a
really bad idea, in general.  Use the power of autoconf to do things
in a generic manner, then specialize them for debian in debian/rules.

Regards,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: dpkg tries to remove a config file twice ...

[Steve M. Robbins]

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 package.

Everyone is in agreement that "rm -f" is the correct procedure, for
the reason stated above.

But I'm still curious about the cause of the initial question: why does
the file get removed twice?

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: dpkg tries to remove a config file twice ...

[Steve M. Robbins]

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 package.

Everyone is in agreement that "rm -f" is the correct procedure, for
the reason stated above.

But I'm still curious about the cause of the initial question: why does
the file get removed twice?

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: file move between versions

[Steve M. Robbins]

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 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 been a bug (in dpkg/apt/whatever) that
> > broke this?
> > 
> > I ask because I have suddenly discovered /usr/bin/gvx (dated from
> > march 2000) which is the old location for /usr/lib/geomview/gvx.  I
> > changed the location when I adopted the package last fall.  I'm
> > wondering if I now need to add a "rm -f /usr/bin/gvx" in the postinst.
> 
> Er, that would be bad. dpkg should have removed the old file when installing
> the new package.
> 
> I guess it would be hard to file a bug unless you can reproduce it...

Well, it's always easy to _file_ a bug.  :-) But you're right to say
that it would be hard to file a *useful* bug report.

I'm not planning to file a bug.  I don't know for sure whether it was
the package tools, or whether I muddled up something by hand.  I don't
think I ever put anying in /usr/bin by hand.  But I can't rule out me
doing something stupid.  

So I thought I'd see if there were any known package tool problems in
the past six months or so.  I've been tracking unstable reasonably
closely during this period, so I could have been bitten even by
short-lived bugs.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: file move between versions

[Steve M. Robbins]

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 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 been a bug (in dpkg/apt/whatever) that
> > broke this?
> > 
> > I ask because I have suddenly discovered /usr/bin/gvx (dated from
> > march 2000) which is the old location for /usr/lib/geomview/gvx.  I
> > changed the location when I adopted the package last fall.  I'm
> > wondering if I now need to add a "rm -f /usr/bin/gvx" in the postinst.
> 
> Er, that would be bad. dpkg should have removed the old file when installing
> the new package.
> 
> I guess it would be hard to file a bug unless you can reproduce it...

Well, it's always easy to _file_ a bug.  :-) But you're right to say
that it would be hard to file a *useful* bug report.

I'm not planning to file a bug.  I don't know for sure whether it was
the package tools, or whether I muddled up something by hand.  I don't
think I ever put anying in /usr/bin by hand.  But I can't rule out me
doing something stupid.  

So I thought I'd see if there were any known package tool problems in
the past six months or so.  I've been tracking unstable reasonably
closely during this period, so I could have been bitten even by
short-lived bugs.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

file move between versions

[Steve M. Robbins]

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 been a bug (in dpkg/apt/whatever) that
broke this?

I ask because I have suddenly discovered /usr/bin/gvx (dated from
march 2000) which is the old location for /usr/lib/geomview/gvx.  I
changed the location when I adopted the package last fall.  I'm
wondering if I now need to add a "rm -f /usr/bin/gvx" in the postinst.

Regards,
-S


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

file move between versions

[Steve M. Robbins]

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 been a bug (in dpkg/apt/whatever) that
broke this?

I ask because I have suddenly discovered /usr/bin/gvx (dated from
march 2000) which is the old location for /usr/lib/geomview/gvx.  I
changed the location when I adopted the package last fall.  I'm
wondering if I now need to add a "rm -f /usr/bin/gvx" in the postinst.

Regards,
-S


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


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

Re: Advice regarding splitting package 'hitop'

[Steve M. Robbins]

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 archive it goes in?
> > 
> 
> anything in non-us does not appear on the default Debian cd.  Whether or not
> you care about this is another matter.

That's a bit misleading.

There are TWO versions of "Debian CD 1", and *both* are official.

One version is for folks in the US who wish to sell it to a customer
outside the US.  The other version is for everyone else.  The
poorly-named "non_US" is omitted from the first version of CD 1.

-Steve


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants