Re: binary NMUs and version numbers
On Thu, Dec 09, 2004 at 02:24:33PM +0100, Jeroen van Wolffelaar wrote: > On Thu, Dec 09, 2004 at 01:13:09PM +, Andreas Metzler wrote: > > It is a payoff, larger diff for less frequent orig.tar.gz uploads. Instead > > of uploading a 3MB mutt_1.5.6-20040915.orig.tar.gz the mutt maintainers can > > upload a 400KB mutt_1.5.6-20040915+1.diff.gz when updating to CVS 20040915. > > This bandwith consideration is nice, but IMHO in no way is anywhere near > as important as the property that you can find Debian-specific changes > in the .diff.gz, and upstream sources in the .orig.tar.gz. It's quite > difficult to find out what was changed in Debian and what's directly > from upstream CVS this way. .orig.tar.gz size only matters (marginally) > for mirrors and developers downloading mutt's sources. As bandwith & > diskspace is cheap compared to developer time, I think it's much more > important to keep the upstream/Debian specific separation that is > intended with .orig.tar.gz/.diff.gz. I tend to agree for vanilla diff.gz files. A lot of packages are using patch systems these days, however, that provide alternative means to distinguish the origins of patches. The mutt package, for instance, separates them in upstream/patches, debian/patches etc. For my own packages, I usually add a "CVS" suffix to the patch name and a note to the comment section. Which should be clear enough for anyone looking at the package source, and keeps the orig.tar.gz always at a released upstream version. Regards, Daniel.
Re: fftw3 non-pic k7 optimisations
On Mon, Mar 07, 2005 at 07:05:40PM +0100, Marco d'Itri wrote: > On Mar 07, Paul Brossier <[EMAIL PROTECTED]> wrote: > > > 10.2. Libraries > > --- > > > > The shared version of a library must be compiled with `-fPIC', and the > > static version must not be. In other words, each source unit (`*.c', > > for example, for C files) will need to be compiled twice. > > > > hrm, but yeah of course, one could say that it's fine if a > > library compiled with -fPIC still contains non position > > independant code. :) > It's still not generally acceptable, but the policy does not reflect > current practice. > The idea is that PIC code is acceptable on architectures which can > support it (i386 and IIRC another one) *IF* there is a positive tradeoff > between the speed gain and the wasted RAM. > The most situation where non-PIC code is a good idea is a library > containing hand-optimized assembly code. It may still be possible to > rewrite it to be PIC without a major performance loss, but it would > probably take a lot of time. Marco, what's your current feeling towards #175077 (non-PIC code in libdv) that you submitted back then when prelink entered Debian? It's a case of hand-optimized assembly in a multimedia lib, and here I've indeed tried (and failed miserably) to convert to position-independent assembly. Should we keep such bugs open, waiting for policy to be changed, downgrade them to wishlist, or simply close them unfixed? Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345017: ITP: graphicsmagick -- collection of image processing tools
Package: wnpp Severity: wishlist Owner: Daniel Kobras <[EMAIL PROTECTED]> * Package name: graphicsmagick Version : 1.1.7 Upstream Author : Bob Friesenhahn <[EMAIL PROTECTED]> * URL : http://www.graphicsmagick.org/ * License : MIT/X Description : collection of image processing tools GraphicsMagick provides a set of command-line applications, as well as libraries in several programming languages to manipulate image files across various file formats. It is a fork of the ImageMagick project and therefore offers a similar set of features, but puts a larger emphasis on stability. Interface instability of ImageMagick has been a recurring problem for the Debian package and its reverse dependencies. GraphicsMagick was forked to address this very issue with a different development process. Both variants usually coexist nicely because they use different names for libraries, applications, and header locations. Optional compatibility packages will provide the necessary symlink and wrapper magic to make GraphicsMagick more of a drop-in replacement for ImageMagick. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITK: debmake
On Thu, Dec 29, 2005 at 07:13:05PM +0100, Santiago Vila wrote: > There are less than 80 packages in unstable still using it, and there > is an excellent package called debhelper which can do everything that > debmake does and probably much better, so it does not make much sense > to keep debmake alive forever. > > Therefore, I hereby announce my Intention To Kill debmake. (...) > Stage 2. "Please switch away from debmake". > > This is the stage that starts today. So, everybody please, switch away > from debmake. From past experience converting orphaned packages to > debhelper, I would say that debhelper is the logical choice, but every > person has his preferences regarding helper packages. For reference, this is the list of the 58 packages in unstable that still build-depend on debmake: Stefan Alfredsson <[EMAIL PROTECTED]> biew cksfv Hakan Ardo <[EMAIL PROTECTED]> libcompface Malc Arnold <[EMAIL PROTECTED]> af ucbmpeg-play Eric Van Buggenhaut <[EMAIL PROTECTED]> vsound Debian Hamradio Maintainers fbb Bernd Eckenfels <[EMAIL PROTECTED]> cadaver Mark W. Eichin <[EMAIL PROTECTED]> lx-gdb Oliver Elphick <[EMAIL PROTECTED]> verse Jochen Friedrich <[EMAIL PROTECTED]> liveice snmptrapfmt Richard A. Hecker <[EMAIL PROTECTED]> set6x86 Michael Holzt <[EMAIL PROTECTED]> obexserver Morten Hustveit <[EMAIL PROTECTED]> kwavecontrol LaMont Jones <[EMAIL PROTECTED]> xdelta Tibor Koleszar <[EMAIL PROTECTED]> falselogin Antonin Kral <[EMAIL PROTECTED]> fmirror Anand Kumria <[EMAIL PROTECTED]> gtk-gnutella Corrin Lakeland <[EMAIL PROTECTED]> gnubg Frederic Lepied <[EMAIL PROTECTED]> xinput Jonathan McDowell <[EMAIL PROTECTED]> fidogate David H. Munro <[EMAIL PROTECTED]> yorick Kenshi Muto <[EMAIL PROTECTED]> xjokes Cajus Pollmeier <[EMAIL PROTECTED]> gnarwl Tomas Pospisek <[EMAIL PROTECTED]> xxdiff Filip Van Raemdonck <[EMAIL PROTECTED]> xmon Anibal Monsalve Salazar <[EMAIL PROTECTED]> translate xtranslate Alain Schroeder <[EMAIL PROTECTED]> wmsmpmon Nathan Scott <[EMAIL PROTECTED]> acl attr dmapi xfsdump Paul Slootman <[EMAIL PROTECTED]> linpopup Joop Stakenborg <[EMAIL PROTECTED]> baken baycomepp colrconv cwdaemon fbbdoc gcb hamsoft ibp twclock twlog xcall xconvers xdx z8530-utils2 David Starner <[EMAIL PROTECTED]> music123 Warren Stramiello <[EMAIL PROTECTED]> xdrawchem Marcela Tiznado <[EMAIL PROTECTED]> gtkgo Matthew Vernon <[EMAIL PROTECTED]> floppybackup Jim Westveer <[EMAIL PROTECTED]> barcode ean13 Martin Wuertele <[EMAIL PROTECTED]> kdc2tiff James R. Van Zandt <[EMAIL PROTECTED]> flip libwn6 Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITK: debmake
On Thu, Dec 29, 2005 at 10:59:22AM -0800, Russ Allbery wrote: > I've adopted gnubg with Corrin's permission and this is now fixed in the > version just uploaded yesterday. Here's an updated and now hopefully complete list that also takes into account build-depends-indep. Removing gnubg from the list, this makes it a total of 78 packages affected. Regards, Daniel. ---[snip]--- Stefan Alfredsson <[EMAIL PROTECTED]> biew cksfv Hakan Ardo <[EMAIL PROTECTED]> avr-libc ftpwatch libcompface picon-domains picon-misc picon-news picon-unknown picon-usenix picon-users picon-weather Malc Arnold <[EMAIL PROTECTED]> af ucbmpeg-play James Bromberger <[EMAIL PROTECTED]> cvsweb Eric Van Buggenhaut <[EMAIL PROTECTED]> vsound Debian Hamradio Maintainers fbb Ludovic Drolez <[EMAIL PROTECTED]> tkusr websec Bernd Eckenfels <[EMAIL PROTECTED]> cadaver Mark W. Eichin <[EMAIL PROTECTED]> lx-gdb Oliver Elphick <[EMAIL PROTECTED]> verse Jochen Friedrich <[EMAIL PROTECTED]> liveice snmptrapfmt Christian Garbs <[EMAIL PROTECTED]> whatsnewfm John Goerzen <[EMAIL PROTECTED]> pilot-template Richard A. Hecker <[EMAIL PROTECTED]> set6x86 Michael Holzt <[EMAIL PROTECTED]> obexserver Morten Hustveit <[EMAIL PROTECTED]> kwavecontrol LaMont Jones <[EMAIL PROTECTED]> xdelta Tibor Koleszar <[EMAIL PROTECTED]> falselogin Antonin Kral <[EMAIL PROTECTED]> fmirror Anand Kumria <[EMAIL PROTECTED]> gtk-gnutella Mario Lang <[EMAIL PROTECTED]> crypt++el Frederic Lepied <[EMAIL PROTECTED]> xinput Eduardo Marcel Macan <[EMAIL PROTECTED]> fortunes-br Jonathan McDowell <[EMAIL PROTECTED]> fidogate A Mennucc1 <[EMAIL PROTECTED]> hp-ppd David H. Munro <[EMAIL PROTECTED]> yorick yorick-doc Kenshi Muto <[EMAIL PROTECTED]> xjokes Cajus Pollmeier <[EMAIL PROTECTED]> gnarwl Tomas Pospisek <[EMAIL PROTECTED]> xxdiff Filip Van Raemdonck <[EMAIL PROTECTED]> xmon Anibal Monsalve Salazar <[EMAIL PROTECTED]> translate xtranslate Alain Schroeder <[EMAIL PROTECTED]> wmsmpmon Nathan Scott <[EMAIL PROTECTED]> acl attr dmapi xfsdump Paul Seelig <[EMAIL PROTECTED]> ethiop localepurge Paul Slootman <[EMAIL PROTECTED]> linpopup Joop Stakenborg <[EMAIL PROTECTED]> baken baycomepp colrconv cwdaemon fbbdoc gcb hamsoft ibp twclock twlog xcall xconvers xdx z8530-utils2 David Starner <[EMAIL PROTECTED]> music123 Warren Stramiello <[EMAIL PROTECTED]> xdrawchem Marcela Tiznado <[EMAIL PROTECTED]> gtkgo Matthew Vernon <[EMAIL PROTECTED]> floppybackup Jim Westveer <[EMAIL PROTECTED]> barcode ean13 Martin Wuertele <[EMAIL PROTECTED]> kdc2tiff James R. Van Zandt <[EMAIL PROTECTED]> emacspeak flip libwn6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#349424: ITP: xcftools -- command-line tools for extracting data for XCF files
On Sun, Jan 22, 2006 at 10:29:27PM +0100, Henning Makholm wrote: > There is a "xcftopnm" binary in gimp-perl, but it is very slow, > starting the Gimp engine to do the work. "Convert" from imagemagick > supposedly also understands XCF files, but not the ones I work with, > and it would probably be overkill to try to extend its command-line > interface to know about layers. Imagemagick in general can handle multi-layered images just fine. I'm not sure whether this is true for its xcf module already, but the necessary framework is certainly there. So if you don't want to keep maintaining a separate utility, merging it with the code in imagemagick might be an option for you. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Recommending an image viewer
On Tue, Feb 14, 2006 at 06:59:53PM +0200, Lars Wirzenius wrote: > ti, 2006-02-14 kello 16:28 +0100, Henning Makholm kirjoitti: > > Does anybody have a better idea than trying (in vain) to keep myself > > informed about the supply of image viewers in unstable and adjust the > > dependencies appropriately? > > Something similar to sensible-browser or such would sort of suggest > itself. That is, a command (/usr/bin/sensible-image-viewer) that uses > alternatives or some other mechanism to determine which image viewer to > start. Image viewer packages would have to be modified to maintain the > alternative, and I'm not sure if the effort is worth it. We already have see(1) from mime-support as a generic way to display images, we're only lacking a way to ensure that a suitable image viewer has registered itself with mailcap. Terve, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Sat, Mar 19, 2005 at 01:21:15AM +0100, Marco d'Itri wrote: > On Mar 18, Steve Langasek <[EMAIL PROTECTED]> wrote: > > > There would definitely be duplication of arch:all between ftp.debian.org > > and ports.debian.org (let's call it ports), as well as duplication of the > > source. > As a mirror operator, I think that this sucks. Badly. What's wrong with splitting into ftp-full-monty.d.o, carrying all archs, including the popular ones, and ftp.d.o, carrying only the most popular subset? This way, there's no need to mirror from both of them, and duplication is kept to a minimum. Slightly increased traffic from the fullblown server is the only drawback I see compared to the ports proposal. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to write Build-depends argument for gfortran
On Thu, Jun 02, 2005 at 02:52:41AM -0400, kamaraju kusumanchi wrote: > I want to build debian package for a library called fortranposix. The > upstream source can be found at > > http://sourceforge.net/projects/fortranposix > > This library depends on some kind of fortran 90 compiler being installed > on the system. gfortran is the Fortran 90 compiler available in latest > versions of gcc. Currently gfortran is available (on sid atleast) only > through gcc-snapshot. However the description of gcc-snapshot > specifically asks not to build packages against it. > > So now my questions are > > 1) How can I make sure that the user has gfortran installed on his system. > > 2) From reading > http://www.debian.org/doc/manuals/maint-guide/ch-dreq.en.html , I know > that only package names can be listed as arguments to Build-Depends > command. Is there any way I can list binary name (gfortran) instead of > package name (gcc-snapshot) as dependency? A proper gfortran package is available in experimental already and will move to sid once sarge is released. Therefore, you can either hold back your upload to sid, or consider uploading your package to experimental. I'd suggest a Build-Depends line like 'gfortran-4.0 | fortran95-compiler', unless your code has strict requirements on the compiler version used. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote:
> On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
> > Steve Langasek schrieb:
> > >>Package: oldpkg
> > >>Depends: newpkg
> > >>Description: transitional dummy package
>
> > >>Package: newpkg
> > >>Replaces: oldpkg
> > >>Conflicts: oldpkg
> > >>Description: ...
>
> > >*NO* *NO* *NO* *NO* *NO*. Look closely at the package relationships you've
> > >specified. Why would you upload a package to the archive that *can never
> > >be installed*?
>
> > Hm, that used to be a "magic" combination that would let dpkg do the
> > right thing.
>
> I've heard this stated before, but if it was ever true, it's definitely not
> the case with apt (or with britney), and it's not mentioned in policy.
It may well cause problems to britney, but policy section 7.5.2
('Replacing whole packages, forcing their removal') definitely mentions
the behaviour of Replaces+Conflicts.
Regards,
Daniel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
On Wed, May 31, 2006 at 11:52:53AM -0700, Steve Langasek wrote:
> On Wed, May 31, 2006 at 02:05:13PM +0200, Daniel Kobras wrote:
> > On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote:
> > > On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
> > > > Steve Langasek schrieb:
> > > > >>Package: oldpkg
> > > > >>Depends: newpkg
> > > > >>Description: transitional dummy package
>
> > > > >>Package: newpkg
> > > > >>Replaces: oldpkg
> > > > >>Conflicts: oldpkg
> > > > >>Description: ...
>
> > > > >*NO* *NO* *NO* *NO* *NO*. Look closely at the package relationships
> > > > >you've
> > > > >specified. Why would you upload a package to the archive that *can
> > > > >never
> > > > >be installed*?
>
> > > > Hm, that used to be a "magic" combination that would let dpkg do the
> > > > right thing.
>
> > > I've heard this stated before, but if it was ever true, it's definitely
> > > not
> > > the case with apt (or with britney), and it's not mentioned in policy.
>
> > It may well cause problems to britney, but policy section 7.5.2
> > ('Replacing whole packages, forcing their removal') definitely mentions
> > the behaviour of Replaces+Conflicts.
>
> It explains Replaces+Conflicts. It does *not* say "create a dummy package
> that can't be installed because it depends on the thing that conflicts it".
Indeed, but current policy makes it very tempting to do so.
Replaces+Conflicts are the documented way to replace a package.
Versioned conflicts on earlier packages are explicitly discouraged, and
one needs a Depends to pull in the renamed package. Which leads directly
to the above relationships and all their problems. The Developer's
Reference also only talks about Replaces+Conflicts in the section about
renaming packages. Both documents should probably be updated, so which
one do you like best:
Method A
Package: oldpkg
Depends: newpkg
Version: 1.0
Description: transitional dummy package
Package: newpkg
Replaces: oldpkg (<< 1.0)
Method B
Package: oldpkg
Depends: newpkg
Files:
/usr/share/doc/oldpkg -> /usr/share/doc/newpkg
(and nothing else)
Package: newpkg
Replaces: oldpkg
Provides: oldpkg
Files:
(...)
/usr/share/doc/oldpkg -> /usr/share/doc/newpkg
Method A relies on the user or external programs like deborphan to clean
up the dummy package. Method B gets rid of it automatically, using a
dpkg feature, but requires an extra symlink in newpkg.
Regards,
Daniel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
On Thu, Jun 01, 2006 at 03:15:02PM +0200, Frank Küster wrote: > Daniel Kobras <[EMAIL PROTECTED]> wrote: > > On Wed, May 31, 2006 at 11:52:53AM -0700, Steve Langasek wrote: > >> It explains Replaces+Conflicts. It does *not* say "create a dummy package > >> that can't be installed because it depends on the thing that conflicts it". > > Indeed, but current policy makes it very tempting to do so. (...) > Only when you don't read the policy with proper context, and don't think > about how dpkg works. Steve wondered why people suggest package relationships that cause problems during upgrades. I claimed that policy may well be the source of the confusion. The fact that you can read different meanings into it isn't quite the point. Well, actually it proves the point of policy being ambiguous here. > > Both documents should probably be updated, so which > > one do you like best: > > > > Method A > > > > Package: oldpkg > > Depends: newpkg > > Version: 1.0 > > Description: transitional dummy package > > > > Package: newpkg > > Replaces: oldpkg (<< 1.0) > > Why no Provides: here? I don't think it's mandatory in this scenario, unlike the method described below where newpkg hijacks the /usr/share/doc/oldpkg symlink. > > Method B > > > > Package: oldpkg > > Depends: newpkg > > Files: > > /usr/share/doc/oldpkg -> /usr/share/doc/newpkg > > (and nothing else) > > > > Package: newpkg > > Replaces: oldpkg > > Provides: oldpkg > > Files: > > (...) > > /usr/share/doc/oldpkg -> /usr/share/doc/newpkg > > Note that if newpkg has some files that oldpkg also had, newpkg has to > conflict anyway (at least with older versions of oldpkg, see above). dpkg version 1.13.2 got rid of this restriction. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
On Thu, Jun 01, 2006 at 01:06:20PM -0700, Steve Langasek wrote: > On Thu, Jun 01, 2006 at 01:39:30PM +0200, Daniel Kobras wrote: > > Method B > > > Package: oldpkg > > Depends: newpkg > > Files: > > /usr/share/doc/oldpkg -> /usr/share/doc/newpkg > > (and nothing else) > > > Package: newpkg > > Replaces: oldpkg > > Provides: oldpkg > > Files: > > (...) > > /usr/share/doc/oldpkg -> /usr/share/doc/newpkg > > > Method A relies on the user or external programs like deborphan to clean > > up the dummy package. Method B gets rid of it automatically, using a > > dpkg feature, but requires an extra symlink in newpkg. > > Oooh, Method B is one I haven't seen proposed before in the context of dummy > packages. That looks far more elegant to me than the alternatives. Have > you tested that dpkg really does do the right thing here, given that the > replacing package gets installed first (since it's a dependency)? I did that once in 2003 for dx but hit a different bug then: dpkg would try to configure oldpkg when it had disappeared already. It worked fine with a patch to dpkg that went into the sarge version, but I haven't tested it since then. I'll give it another try to be sure. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
On Fri, Jun 02, 2006 at 09:19:42AM +0200, Andreas Fester wrote:
> Absolutely. Its also the method I would prefer because it adds minimal
> overhead providing the most seamless upgrade. I implemented it for my
> package, and the first test succeeded very well (amd64 testing/unstable),
> but today I tried it on another machine (i386 testing/unstable) and it
> failed with
>
> # apt-get dist-upgrade -V
> Reading package lists... Done
> Building dependency tree... Done
> Calculating upgrade...Done
> The following NEW packages will be installed
>crossvc (1.5.0-1)
> The following packages will be upgraded:
>lincvs (1.4.4-2 => 1.5.0-1)
> ...
> Get: 1 http://littletux.homelinux.org unstable/non-free lincvs 1.5.0-1 [744B]
> Get: 2 http://littletux.homelinux.org unstable/non-free crossvc 1.5.0-1
> [1289kB]
> Fetched 1290kB in 27s (47.0kB/s)
> (Reading database ... 82122 files and directories currently installed.)
> Preparing to replace lincvs 1.4.4-2 (using .../lincvs_1.5.0-1_all.deb) ...
> Unpacking replacement lincvs ...
> Selecting previously deselected package crossvc.
> Unpacking crossvc (from .../crossvc_1.5.0-1_i386.deb) ...
> (Noting disappearance of lincvs, which has been completely replaced.)
> Setting up crossvc (1.5.0-1) ...
>
> dpkg: error processing lincvs (--configure):
> no package named `lincvs' is installed, cannot configure
> Errors were encountered while processing:
> lincvs
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> # dpkg --version
> Debian `dpkg' package management program version 1.13.19 (i386).
Oh crap. This looks exactly like a reincarnation of #202997 which is
supposed to be fixed since 1.10.22. Let's see... In fact, it still works
fine when using 'dpkg -i oldpkg newpkg'. However, apt splits it up into
'dpkg --unpack oldpkg newpkg', 'dpkg --configure oldpkg newpkg', and
doesn't notice that oldpkg has vanished inbetween. I wonder why it used
to work for me before. In any case, this rules out using this method for
etch. If we want to have it available for etch+1, we could either teach
apt about disappearing package or change dpkg to ignore attempts to
configure package that are not installed instead of spitting out an
error. I don't know how hard it would be to change it in apt (deity list
Cc'ed therefore), but the alternative patch to dpkg is quite simple (see
below). Alas, it changes current behaviour.
Regards,
Daniel.
--- src/packages.c.orig 2006-06-02 14:40:47.0 +0200
+++ src/packages.c 2006-06-02 14:41:06.0 +0200
@@ -191,11 +191,11 @@
assert(dependtry <= 4);
}
switch (cipaction->arg) {
+case act_configure:
case act_install:
/* Don't try to configure pkgs that we've just disappeared. */
if (pkg->status == stat_notinstalled)
break;
-case act_configure:
deferred_configure(pkg);
break;
case act_remove: case act_purge:
Re: Renaming a package
On Thu, Jun 01, 2006 at 11:46:12PM +0200, Daniel Kobras wrote: > On Thu, Jun 01, 2006 at 01:06:20PM -0700, Steve Langasek wrote: > > Oooh, Method B is one I haven't seen proposed before in the context of dummy > > packages. That looks far more elegant to me than the alternatives. Have > > you tested that dpkg really does do the right thing here, given that the > > replacing package gets installed first (since it's a dependency)? > > I did that once in 2003 for dx but hit a different bug then: dpkg would > try to configure oldpkg when it had disappeared already. It worked fine > with a patch to dpkg that went into the sarge version, but I haven't > tested it since then. I'll give it another try to be sure. Looking at the actual control file I used back then, an additional Conflicts: oldpkg (<< First-Dummy-Version) is needed to ensure correct ordering. newpkg needs to be unpacked after the dummy version of oldpkg. Which makes the solution a lot less elegant, but apt still is able to cope. Not sure about britney, though. Anyway, as noted in my previous mail to this thread, when testing this method on unstable and sarge, I hit a bug in apt that rules it out for etch. If you still like this method, we can get the necessary fixes in and promote it for etch+1, though. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
On Fri, Jun 09, 2006 at 02:15:06PM +0100, Ian Jackson wrote:
> Daniel Kobras writes ("Re: Renaming a package"):
> > but the alternative patch to dpkg is quite simple (see
> > below). Alas, it changes current behaviour.
>
> I don't think it this patch is correct as is, but something similar
> might not be unreasonable if it had to be turned on with a command
> line option.
[Context: When renaming a package, can we make use of dpkg's feature to
disappear the old package on upgrade?]
So you're thinking of 'dpkg --configure --dont-fail-if-not-installed'
that could be used by default in apt? What about teaching apt to remove
a package from the list when it goes into state not-installed during
unpack?
Regards,
Daniel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cleaning /var/lib/dpkg/available
On Wed, Jun 14, 2006 at 01:34:36PM +0200, Jérôme Warnier wrote: > I've been upgrading my machines since Woody to Sarge, then to Etch. Now, > my /var/lib/dpkg/available are huge (15MB), and it seems they never get > cleaned. > How am I supposed to clean them? Isn't there any automated tools in > Debian to do that? Try 'dpkg --forget-old-unavail'. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My orphaned packages.
On 10 Sep 2000, Karl M. Hegbloom wrote: > `scsh' ought to be taken over by someone who actually uses it. I've > not even looked at it in over a year. If nobody objects I'd like to do this together with Martin Gasbichler who wrote a fair part of scsh 0.6. But me having just applied for Debian maintainership this will take some time... Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Scsh (Was: Re: My orphaned packages.)
On 11 Sep 2000, Karl M. Hegbloom wrote: > >>>>> "Daniel" == Daniel Kobras <[EMAIL PROTECTED]> writes: > > Daniel> On 10 Sep 2000, Karl M. Hegbloom wrote: > >> `scsh' ought to be taken over by someone who actually uses it. I've > >> not even looked at it in over a year. > > Daniel> If nobody objects I'd like to do this together with Martin > Daniel> Gasbichler who wrote a fair part of scsh 0.6. But me > Daniel> having just applied for Debian maintainership this will > Daniel> take some time... > > I also have an adoption offer from Georg Bauer (Cc'd), who I > responded to on the attached message, telling him that if he contacts > the new maintainer team and has a working `scsh' package, he can have > it. > > Since you are teaming with Martin Gasbichler, and since Martin is a > co-author of Scsh, I'd say that puts you two in as most qualified to > handle the package. (Daniel? Please forward this mail to Martin.) > > Perhaps the three of you could team? What do you all think? Sounds good to me. Martin is on vacation for a couple of days but I'm sure we can work out a scheme everyone's confident with as soon as he's back. The big problem IMHO however being that neither of us is registered as a developer so far. I'd be happy to work on debs for a recent version of scsh but we'd really need some maintainer to adopt the package until my appliance gets through. Regards, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Scsh (Was: Re: My orphaned packages.)
On Tue, 12 Sep 2000, Christian Kurz wrote: > You don't need a package maintainer to adopt the package for getting a > new package uploaded. A sponsor for you and Martin would be enough to > upload the package to the archive. Okay, sorry, wrong wording. That's what I had in mind. Someone to take the scsh package and put it up for us. In fact, it's the very procedure Joey Hess and I follow for noflushd. > Do you already are in the NM-Queue (nm.debian.org)? Yes. I had just applied when I saw Karl's mail about orphaned scsh. Thanks, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages needing a new maintainer
On Tue, 26 Dec 2000, Martin Michlmayr wrote: > Below is a listing of packages needing a new maintainer. I know that > all the information is in the WNPP already, but I thought it would > be a good idea to post a summary since the WNPP bugs were not CCed > here. [...] > Martin Schulze <[EMAIL PROTECTED]> > O: manpages-de -- German manpages I'd be willing to take them, if it's just for the Debian maintainership and fixing the few outstanding bugs. However, Joey, I see you are also the whole project's leader. The webpages at infodrom didn't show much activity for the past year and a half. Can you comment on the current status of manpages-de? Thanks, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net
Re: List of packages needing a new maintainer
On Thu, 28 Dec 2000, Martin Schulze wrote: > Daniel Kobras wrote: > > > O: manpages-de -- German manpages > > > > I'd be willing to take them, if it's just for the Debian maintainership > > and fixing the few outstanding bugs. However, Joey, I see you are also > > Please take over Debian maintainership. Okay, will do so within the next few days. > > the whole project's leader. The webpages at infodrom didn't show much > > activity for the past year and a half. Can you comment on the current > > status of manpages-de? > > A lot of things have happened, together with the inability to run an > ftp server after moving. The pages will be updated soon. Yup, noticed that when I was looking for the current upstream version. ;-) Anyway, if you need help with the project as a whole, I might try to arrange sort of a joint effort within our local Linux user group. If you're interested, just drop me a note. Regards, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net
How to gracefully rename a package?
Moi!
The new version of the OpenDX toolkit now provides sane libraries, so I
wanted to restructure the packages a bit. In particular, there is a new
package libdx4, so I wanted to rename what used to be dx-dev package as
libdx4-dev. This turned out to be harder than I thought.
The -dev package will usually be used for compiling local modules, so
nothing within Debian depends on it. dx-dev's dependency on the main dx
package is versioned with (= ${Source-Version}), so when trying to
upgrade, apt wants to remove it without even considering to replace it
with the new libdx4-dev (which conflicts, provides, and replaces
dx-dev). So I created a dummy dx-dev package that simply depends on
libdx4-dev. Works fine. But I also wanted to be nice to the user and
automatically remove the dummy dx-dev once it's no longer needed.
Therefore, libdx4-dev replaces anything in dx-dev, and dpkg removes the
package. Works fine as well. Now the final problem is libdx4-dev and
dx-dev are getting upgraded at the same time, and dpkg tries to setup
dx-dev when it already has been removed:
Preparing to replace dx-dev 1:4.2.0-8 (using dx-dev_4.3.0-1_all.deb) ...
Unpacking replacement dx-dev ...
Selecting previously deselected package libdx4-dev.
Unpacking libdx4-dev (from libdx4-dev_4.3.0-1_i386.deb) ...
Replacing files in old package dx-dev ...
(Noting disappearance of dx-dev, which has been completely replaced.)
dpkg: error processing dx-dev (--install):
no package named `dx-dev' is installed, cannot configure
Setting up libdx4-dev (4.3.0-1) ...
Errors were encountered while processing:
dx-dev
The error can simply be ignored, but it's ugly, and I'd like to avoid
it. So am I trying to do something stupid? Is there a better way to do
it? Or should I simply go file a bug on dpkg?
Any hints welcome,
Daniel.
Re: How to gracefully rename a package?
On Thu, Jul 24, 2003 at 04:37:55PM +0200, Michael Piefel wrote: > Alternatively, there could be a new control field, say "Supersedes:", > which would result in the above behaviour. Of course, there'd have to be > a change in policy... This has already been proposed as "Previously:" (#33344), and "Successor-of:" (#77325), but is probably nothing that dpkg itself can take care of (cf. #33344). Regards, Daniel.
Re: package name change (moviemate -> mediamate)
On Wed, Jul 30, 2003 at 08:47:53PM -0600, Jamin W. Collins wrote: > I was thinking about the dummy package approach, but then the dummy > package would just hang around indefinitely, right? If the new package replaces all files in the dummy package, dpkg removes it automatically. But cf. #202997. I ended up with a dummy package only containing a symlink in /usr/share/doc from to , and stuffing that into the new package as well. Regards, Daniel.
Re: shared library -dev package naming proposal
On Fri, Jul 15, 2005 at 10:44:04PM +0900, Junichi Uekawa wrote: > Stephen's points are valid and quite useful > considering an upstream developer's point of view, > but for random user joe who is trying to find a development > package, one of the following may help him find the right package > > > 1. creating a system-wide list of what -dev package does what. > > -> centrally requires work. Already started in d-shlibs. > > 2. creating a devlibs file which points to what shared library > is handled by which -dev package. > > -> requires manual intervention by all developers, > and utilizes an i-node for all shared library installations. > > 3. creating a package policy to Provides: a symbollic name >that can be traced from the shared library package name or >the shared library soname. > > -> non-invasive if it's done gradually. Make shared library packages Suggest: their corresponding -dev packages. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what to do with iputils (ping, etc)
On Fri, Oct 21, 2005 at 04:41:48PM -0400, Stephen Frost wrote: > It seems like the 'sensible' thing to do might be to provide both. > Typically I would think the standard 'ping' would be, well, pretty > standard, and would work across multiple kernels/OSes/etc. We could > also have an 'lping' or some such which supported all the > latest-greatest linux-based stuff. How about naming the packages netkit-ping and iputils-ping, respectively? Oh, wait, we have that already... iputils-arping also has a more portable, alternative implementation (cf. package arping). That leaves us with tracepath that indeed appears to be Linux-only at the moment. But then we have a couple of traceroute packages that offer roughly similar functionality. So what's all the fuzz about? Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome-swallow_1.2-2_source.changes REJECTED
On Fri, Nov 11, 2005 at 12:18:00AM +0100, Joerg Jaspert wrote: > On 10469 March 1977, Josselin Mouette wrote: > > I can't see the rationale for rejecting source uploads, and they used to > > be accepted in the past. > > Because people then fuck up their packages even more. > > No, they havent been accepted in the past. Ubuntu does that, Debian not. They were accepted by katie in the past, but strongly discouraged by the i386 buildd admin. Been there, done that. Nowadays, I think that pbuilder and friends have mostly alleviated the need for source-only uploads, but Josselin seems to disagree. Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Wed, Jul 04, 2007 at 01:40:05AM -0400, Jordi Gutierrez Hermoso wrote: > On 03/07/07, Klaus Ethgen <[EMAIL PROTECTED]> wrote: > >I heard this crap only when using alsa. > > which is a problem, since OSS is deprecated in favour of ALSA. It's only OSS-the-kernel-drivers that are deprecated. OSS-the-programming-interface still works fine. Not sure, which part of ALSA actually gave rise to Klaus's problems, though. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Hardcoding of .la file paths in .la files
On Tue, Oct 14, 2003 at 09:52:28AM +0200, Josselin Mouette wrote: > I really feel we should get rid of all these static libraries. Who uses > static linking now that even our glibc doesn't support it correctly > across versions? People who want their binaries to run across different Linux machines. People who don't want to keep up with rapidly changing library APIs. People who want to have reliable emergency recovery tools available. People who use performance critical libs on register-starved machines. People who need to minimize startup times. To name but a few. Just because there's little incentive to use static linkage when building Debian packages doesn't mean that we should deprecate it. Unless you're willing to convince the admin of the beowulf cluster next door to install libyoddafoo on several hundred nodes for me. Daniel.
Re: Hardcoding of .la file paths in .la files
On Tue, Oct 14, 2003 at 08:09:32AM -0500, Steve Greenland wrote: > Which doesn't, in any way, promote the idea that we should keep the .la > files. People who need/want a statically linked binary often want to > control exactly *which* libraries are statically linked, and will build > the link command by hand. This is probably true when performance tuning. However, when I prepare a binary to submit to a supercomputer, or an executable for a CD (that should Just Work when I pull it out after two years), I usually just plonk in a '-static' and be done with it. I'd hate to see this functionality go. If you ever tried to get, say, ten static libs in the right order for a medium-sized application, you know what tedious task I'm taking about. From my personal point of view, removal of .la files would significantly degrade Debian's usability as a build platform. Daniel.
Re: Hardcoding of .la file paths in .la files
On Tue, Oct 14, 2003 at 11:57:40AM -0400, Daniel Jacobowitz wrote: > On Tue, Oct 14, 2003 at 10:38:49AM +0200, Daniel Kobras wrote: > > On Tue, Oct 14, 2003 at 09:52:28AM +0200, Josselin Mouette wrote: > > > I really feel we should get rid of all these static libraries. Who uses > > > static linking now that even our glibc doesn't support it correctly > > > across versions? > > > > People who want their binaries to run across different Linux machines. > > Dynamic linking to an old version of glibc is more portable than > statically linking to any version. Exhibit A is NSS; exhibit B is > iconv. Neither works properly when statically linked unless run > against the exact same glibc version. The sentence I refer to reads: 'I really feel we should get rid of all these static libraries.' _All_ static libraries. glibc is quite special in this regard because it's likely to be present even on a minimalist system. > > People who need to minimize startup times. > > Static linking does _not_ minimize startup times; in fact it's quite > inefficient. Dynamic linking + prelinking is much faster if you care > about startup times. Prelinking is also quite recent and not yet available on any platform as far as I know. Are you claiming that startup performance of statically linked objects is equal to shared objects even without prelink? Daniel.
Re: Hardcoding of .la file paths in .la files
On Tue, Oct 14, 2003 at 12:48:28PM -0400, Daniel Jacobowitz wrote: > Often worse, due to the dramatically increased amount of data which > must be loaded from disk in a cold-cache situation. Another 800K of > glibc you've got to read in. The memory usage sucks too. That's glibc. It's already in memory. This is not necessarily the case for less widespread libs. Depending on the contents of the .a, and the number of functions actually used, you might end up reading in less data from disk, and also save on filesystem and dynamic symbol lookup. I'm not advocating to link in glibc statically. I'm advocating to leave it up to the users to pick their preferred method of linking, and not put up extra hurdles. > Prelinking is now available on almost all Debian architectures, so I'm > not sure what you mean. I'm referring to % apt-cache showsrc prelink | grep Architecture Architecture: alpha i386 powerpc I'm glad to hear that support for further architectures is apparently getting along. Still, this whole prelink issue is tangent to the main point: There are valid reasons for static linking, and I oppose the blanket statement that we should deprecate this method. Daniel.
Re: dpkg-buildpackage -rfakeroot error
On Sun, Aug 11, 2002 at 01:29:19PM -0400, Matt Zimmerman wrote: > On Sun, Aug 11, 2002 at 02:12:25PM +0200, Daniel Kobras wrote: > > Rather 'chmod +x /usr/bin/make' according to the error message. Weird. > > It is a confusing (confused) error message. The permission problem is with > the script, not the interpreter. Huh? % chmod a-x debian/rules % dpkg-buildpackage -rfakeroot -us -uc dpkg-buildpackage: source package is noflushd dpkg-buildpackage: source version is 2.6.3-1 dpkg-buildpackage: source maintainer is Daniel Kobras <[EMAIL PROTECTED]> dpkg-buildpackage: host architecture is i386 fakeroot debian/rules clean sh: line 1: debian/rules: Permission denied % chmod a+x debian/rules % sudo chmod a-x /usr/bin/make % dpkg-buildpackage -rfakeroot -us -uc dpkg-buildpackage: source package is noflushd dpkg-buildpackage: source version is 2.6.3-1 dpkg-buildpackage: source maintainer is Daniel Kobras <[EMAIL PROTECTED]> dpkg-buildpackage: host architecture is i386 fakeroot debian/rules clean sh: debian/rules: /usr/bin/make: bad interpreter: Permission denied The last line exactly matches the original error messages. Clearly not a problem with debian/rules, but with make. Regards, Daniel.
Re: man/tbl portability
On Mon, Aug 19, 2002 at 01:25:26PM +0200, Mikael Hedin wrote: > I've enhanced oglerc(5) by adding a tbl section (.TS and .TE and the > things in between). On my system (sid) it is preproccessed by tbl(1) > when I run 'man ./oglerc.5', but on the upstream author's sytem > (solaris something), the tbl preprocessing does not happen. Did I > miss some magic to insert? Or does this just not work on other > Unices? (The man page is in the ogle packge >= 0.8.5-2). See the NOTES section in man(7). You need '\ t' at the beginning of the man page. But also have a look at section SAFE SUBSET, which suggests to not use those macros in the first place. Regards, Daniel.
Re: Packages not making it into testing
On Wed, Apr 25, 2001 at 11:57:50PM +1000, Hamish Moffatt wrote: > On Wed, Apr 25, 2001 at 03:46:55AM -0500, Rahul Jain wrote: > > Why does xcdroast need to be setgid? I think it's terrible to have any user > > able to burn or screw up a burn... why can't they use sudo or su? > > Doesn't the user have to belong to the relevant group anyway? > We already control access to things like floppy drives, sound > cards etc through groups, so cd burning is another good example. Isn't the xcdroast/cdrecord suid/sgid stuff about grabbing realtime scheduling priority? You can't control this via group ownership. Capabilities on the other hand might help... Regards, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net
Re: Packages not making it into testing
On Fri, Apr 27, 2001 at 09:41:46PM +0300, Tommi Virtanen wrote: > Anthony Towns writes: > > > + mpg123 uploaded 125 days ago, out of date by 115 days! > > mpg123-alsa is uninstallable (needs alsa-base 0.4, which is no > > longer available?) > > mpg123 won't work with the newer ALSA, and there seems to be > no real mpg123 activity. I'll drop ALSA support when I get time > to update the package (not very soon). Current mix of alsa-headers and -libs doesn't allow you to build anything on unstable anyway. If you want some help on that package drop me a note. I've hacked on mpg123 before, and we're in the process of getting ALSA 0.9 support into Glame at the moment. Regards, Daniel. pgpbdbgZNr5wT.pgp Description: PGP signature
Re: ITP: ardour -- professional multitrack audio editing tool
On Wed, May 09, 2001 at 10:23:22AM -0500, Pat Mahoney wrote: > On Tue, May 08, 2001 at 02:22:16PM +0900, Junichi Uekawa wrote: > > [EMAIL PROTECTED] cum veritate scripsit: > > > > Please be careful with ladspa.h > > It's currently not free. > > Why do you say this? http://www.ladspa.org/ladspa_sdk/ladspa.h.txt > contains the standard LGPL stuff at the top. The license was changed yesterday evening when there were too many complaints about ladspa.h being non-free. ;-) Regards, Daniel.
Re: Bug#111274: ITA: doc-linux-ja -- Linux HOWTOs in Japanese
On Wed, Sep 05, 2001 at 09:54:45AM +0200, Martin Michlmayr wrote: > * GOTO Masanori <[EMAIL PROTECTED]> [20010905 10:17]: > > I intend to adopt doc-linux-ja, Japanese version of doc-linux. > > The reason to adopt is that Colin Watson is also written as follows: > > > > Marco Budde is packaged in 1999.12, but we JF Project > > I already orphaned it. The same goes for: (...) > * #110948: O: doc-linux-de -- Linux HOWTOs in German I'd be willing to step in for the Debian package, but the problem is Marco also seems to be upstream for the German Linux HOWTOs. Does anyone if there's German Linux documentation that's still actively developped? Regards, Daniel.
Re: upload rejected: md5sum for .orig.tar.gz doesn't match .dsc
On Wed, Apr 10, 2002 at 10:37:35AM +0200, Joost van Baal wrote: > Your package upload (cl-imho, manpages-de, tiger) was rejected due to a > mismatch in the original source md5sum. I saw this in > auric:/org/ftp.debian.org/incoming/REJECT/*.reason . The package I > maintain (lire) was rejected for the same reason. I have absolutely no > idea how this was caused, or how to fix it. Most likely this is caused by different timestamps in the tarballs. It happens to me occasionally when I cvs-buildpackage on a machine where the .orig.tar.gz is not present and thus rebuilt from a new CVS checkout. Just apt-get source the tarball from the archive and dpkg-buildpackage with it. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Writing symbols files for C++ libraries.
Hi!
I'm currently fighting with deb symbols files for a C++ library I'm
packaging, and I'd like to get some insight in how others are coping
with this task. In particular, I wonder how to get rid of symbols from
standard template instances that leak into the ABI, eg.
$ cat test.cpp
#include
std::string foome(const std::string& bar)
{
return "foo" + bar + "foo";
}
$ g++ -fPIC -c test.cpp
$ readelf -Wds test.o | grep -v UND | grep -v HIDDEN | grep -E
'(FUNC|OBJECT)'
18: 23 FUNCWEAK DEFAULT9
_ZNSt11char_traitsIcE6lengthEPKc
22: 155 FUNCWEAK DEFAULT 11
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_
30: 104 FUNCWEAK DEFAULT 14
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_PKS3_
33: 124 FUNCGLOBAL DEFAULT5 _Z5foomeRKSs
I can hide the operator+() and related instances from with a version
script, of course, but due to C++ name mangling they tend to be
arch-specific and thus hard to maintain. Does anyone know of a more
lightweight solution to limit visibility of template instances and
ensure a clean ABI for C++ libraries? What are the current best
practises when writing symbols files for C++ libraries, or is it simply
not recommended?
Regards,
Daniel.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Writing symbols files for C++ libraries.
On Tue, Apr 07, 2009 at 12:15:19PM +0200, Josselin Mouette wrote: > Le mardi 07 avril 2009 à 11:57 +0200, Mike Hommey a écrit : > > I found nothing better than using a version script. I'm lucky that the > > library in question (WebKit) only really exports C symbols, and C++ is only > > internal details, so I'm filtering everything that starts with _Z, now. > > BTW, for such simple things, you can let libtool create the version > script for you, using -export-symbols-regex. Have you used this option successfully with a C++ library? In this case, libtool creates input for the linker option "-retain-symbols-file" rather than a version script like it does with C libs. In my tests, "-retain-symbols-file" only affected static symbols, but didn't touch the list of dynamic symbols. Which is quite pointless for my use case. Is this a known bug/misfeature or might I by doing something wrong here? Regards, Daniel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Writing symbols files for C++ libraries.
Hi! On Wed, Apr 08, 2009 at 02:42:16AM +0200, Michael Biebl wrote: > Daniel Kobras schrieb: > > Have you used this option successfully with a C++ library? In this case, > > libtool creates input for the linker option "-retain-symbols-file" > > rather than a version script like it does with C libs. In my tests, > > "-retain-symbols-file" only affected static symbols, but didn't touch > > the list of dynamic symbols. Which is quite pointless for my use case. > > Is this a known bug/misfeature or might I by doing something wrong here? > > libtool's -export-symbols(-regex) only works with C libraries afaik. > > For C++ libs the only way I know of is to use GCC's visibility support [1]. As Mike noted earlier on in this thread, the troublemaker symbols are forced to default visibility in the standard headers. Hence, -fvisibility doesn't gain us much here. I conclude from this thread that using symbols files for C++ ABIs is pretty much a bad idea at the moment. Thanks for the input! Daniel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
