[gentoo-dev] Re: packages up for grabs
Daniel Drake [EMAIL PROTECTED] writes: dev-dotnet/evolution-sharp I was going to ask you about this last week, I guess I'll look into it (although it makes me feel dirty to work with .NET stuff, I've been working with worse stuff :P). -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpg2jdRM4KaJ.pgp Description: PGP signature
Re: [gentoo-dev] DEFAULT_* proposal
В Сбт, 08/11/2008 в 17:20 -0500, Thomas Anderson пишет: This is a reposting of a call for discussion on DEFAULT_* variables. The original discussion was at [1]. How does this proposal answers concerns raised during last discussion? I did my best and reread all the discussions and both proposals. I found two reasons supporting this change is that it makes ebuilds more flexible[1] or much simpler[2]. With all due respect I disagree. 1. Functions we have now are much more flexible then proposed arrays. Do I need to think of some example of code that is impossible to do with arrays but still possible with functions? 2. Much simpler? No, it's not: (2.1) Such arrays do not not reduce the number of keys to be pressed. They require even more typing for small ebuilds [3] (example proposed by you, btw) and the only example which expose some improvement (presented by Santiago M. Mola[4]) shows that we still didn't learned how to use syntax we already have and (2.2) some extensions to the current syntax will just complicate things. Look if you remove $myconf variable from that ebuild[4], remove || die after econf and in EAPI=2 you can drop emake || die you'll see that the gain is small even for such medium size ebuild. At the same time this new syntax make some things worse: 1. it hides real code under this variables. 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad practice of using patches instead of sed. 3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES, btw). (highlighting helps here but does not makes that variables easier to read or type in?) 4. it also conflates multiple concepts into a single variable name (the function name, whether it's USE-dependent, and how the configure flag is passed). (-- Donnie Berkholz [6]) 5. One of the great things about ebuilds is that they're very natural to write in most cases, if you can manage to build the program by hand. Raising this barrier of entry for questionable benefit seems like a bad idea. (-- Donnie Berkholz [7]) So, why to reiterate this discussion without providing clear answer to the above concerns? At the same time default src_install is different proposal and having it implemented is a good idea. [1] http://article.gmane.org/gmane.linux.gentoo.devel/57990 [2] http://article.gmane.org/gmane.linux.gentoo.devel/58728 [3] http://thread.gmane.org/gmane.linux.gentoo.devel/57990 [4] http://article.gmane.org/gmane.linux.gentoo.devel/57996 [5] http://archive.devwebpro.com/devwebpro-39-200305063ReasonsNotToUseUppercase.html [6] http://article.gmane.org/gmane.linux.gentoo.devel/58061 [7] http://article.gmane.org/gmane.linux.gentoo.devel/58051 -- Peter.
Re: [gentoo-dev] DEFAULT_* proposal
On Sun, Nov 09, 2008 at 03:39:12PM +0300, Peter Volkov wrote: В Сбт, 08/11/2008 в 17:20 -0500, Thomas Anderson пишет: This is a reposting of a call for discussion on DEFAULT_* variables. The original discussion was at [1]. 1. Functions we have now are much more flexible then proposed arrays. Do I need to think of some example of code that is impossible to do with arrays but still possible with functions? And more complex. Remember, I said that these proposals were not for every case. Showing how it can't be used in one case says nothing about it otherwise being used. 2. Much simpler? No, it's not: (2.1) Such arrays do not not reduce the number of keys to be pressed. They require even more typing for small ebuilds [3] (example proposed by you, btw) and the only example which expose some improvement (presented by Santiago M. Mola[4]) shows that we still didn't learned how to use syntax we already have and (2.2) some extensions to the current syntax will just complicate things. Look if you remove $myconf variable from that ebuild[4], remove || die after econf and in EAPI=2 you can drop emake || die you'll see that the gain is small even for such medium size ebuild. At the same time this new syntax make some things worse: Here's an example of how much gain there is with this approach: http://tinyurl.com/6jj8a5 1. it hides real code under this variables. As mentioned, so do use_enable, use_with, emake(though these are functions hiding code, DOCS. Hiding code is not always a bad thing. 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad practice of using patches instead of sed. How so? We already have a ton of PATCHES variables as mentioned. How is this standardization of what we already have going to promote bad practices? 3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES, btw). (highlighting helps here but does not makes that variables easier to read or type in?) Ok, so you could find a different name. The names aren't really important. You could use USE_ENABLES and USE_WITHS and DEFAULT_PATCHES. 4. it also conflates multiple concepts into a single variable name (the function name, whether it's USE-dependent, and how the configure flag is passed). (-- Donnie Berkholz [6]) 5. One of the great things about ebuilds is that they're very natural to write in most cases, if you can manage to build the program by hand. Raising this barrier of entry for questionable benefit seems like a bad idea. (-- Donnie Berkholz [7]) No one is raising the barrier. People can continue to use use_enable and use_with as they have for ages. The only thing that changes is that ebuild devs now have another way(which is simpler from my experience and that of others) to write ebuilds. Also, it's not that more So, why to reiterate this discussion without providing clear answer to the above concerns? Because we came up with a more comprehensive proposal covering more phase functions. At the same time default src_install is different proposal and having it implemented is a good idea. [1] http://article.gmane.org/gmane.linux.gentoo.devel/57990 [2] http://article.gmane.org/gmane.linux.gentoo.devel/58728 [3] http://thread.gmane.org/gmane.linux.gentoo.devel/57990 [4] http://article.gmane.org/gmane.linux.gentoo.devel/57996 [5] http://archive.devwebpro.com/devwebpro-39-200305063ReasonsNotToUseUppercase.html [6] http://article.gmane.org/gmane.linux.gentoo.devel/58061 [7] http://article.gmane.org/gmane.linux.gentoo.devel/58051 -- Peter. pgp7EgxTeYlsl.pgp Description: PGP signature
Re: [gentoo-dev] DEFAULT_* proposal
Hello,
El dom, 09-11-2008 a las 15:39 +0300, Peter Volkov escribió:
1. Functions we have now are much more flexible then proposed arrays. Do
I need to think of some example of code that is impossible to do with
arrays but still possible with functions?
The same concern was raised in the default src_install proposal. Making
default functions a bit more flexible doesn't mean we need default
functions which cover every possible case, that's just impossible.
At the same time this new syntax make some things worse:
2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad
practice of using patches instead of sed.
As shown in the proposal, this variable is already used in many eclasses
and it has been proven useful.
I'm not sure the existence of PATCHES is promoting any kind of patch
abuse. As far as I know, it's more common the concern about abusing sed
for things that should be patched rather than the other way.
But, in any case, both methods would still be available:
src_prepare {
epatch ${FILESDIR}/some-stuff.patch
sed -i -e s:FOO:BAR:g Makefile
}
would still be correct.
If someone is using the PATCHES variable like this:
PATCHES=( 'stome-stuff.patch' 'more-patches.patch' ... ... ... )
a sed call would be easy to add if needed as follows:
PATCHES=( 'stome-stuff.patch' 'more-patches.patch' ... ... ... )
src_prepare() {
default
sed -i -e s:FOO:BAR:g Makefile
}
It's quite straight-forward.
3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus
easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES,
btw). (highlighting helps here but does not makes that variables easier
to read or type in?)
This is the easier part to address. If these names are a problem, other
names can be used. For example, what it's called
DEFAULT_SRC_INSTALL_DOCS in this proposal, it's called just DOCS in
others.
If people likes this approach better, then similar names can be chosen
for the rest of proposed variables. For example:
DEFAULT_SRC_PREPARE_PATCHES - PATCHES, EPATCHES...
DEFAULT_SRC_CONFIGURE_ENABLES - ECONF_ENABLES
DEFAULT_SRC_COMPILE_PARAMS - EMAKE_PARAMS, EMAKE_EXTRA_PARAMS...
Anyway, it'd be better if people focus on discussing the actual
functionality rather than the chosen names.
4. it also conflates multiple concepts into a single variable name (the
function name, whether it's USE-dependent, and how the configure flag is
passed). (-- Donnie Berkholz [6])
ECONF_USE_ENABLES might solve that problem.
5. One of the great things about ebuilds is that they're very natural
to write in most cases, if you can manage to build the program by hand.
Raising this barrier of entry for questionable benefit seems like a bad
idea. (-- Donnie Berkholz [7])
Functions would still be overridable. And, in fact, they will need to be
overriden in many cases. There's no change there. With respect this
barrier, it already exists with the many eclasses we have.
Regards,
--
Santiago Moisés Mola
Jabber: [EMAIL PROTECTED] | GPG: AAD203B5
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] DEFAULT_* proposal
Well for myself I found compromise. Although in both proposals as I see you've omitted part where you'll discuss how you are going to implement this feature, implementing this feature as eclass addresses most of my concerns, since: 1. ebuild's syntax does not change 2. people will have to inherit some.eclass to use them and thus will do this only when it's really saves time/efforts I've dropped all other answers I was going to give you since I started to feel that this is just another cycle. We can discuss them off list if necessary. :) -- Peter.
Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support
On Sunday 02 November 2008, Peter Alfredsen wrote: The attached patch for bug 238753 makes base.eclass support EAPI 2 functions. Applied -- /PA signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Please review: function epunt_la_files for eutils.eclass
I attach here a proposed new function for eutils.eclass. Review
requested. Thanks to zlin and igli for initial review and suggestions
on #gentoo-dev-help.
--
/PA
--- /usr/portage/eclass/eutils.eclass 2008-09-28 07:06:15.0 +0200
+++ eutils1.eclass 2008-11-06 22:22:51.0 +0100
@@ -1805,5 +1805,37 @@
) || die
else
newbin ${tmpwrapper} ${wrapper} || die
fi
}
+
+# @FUNCTION: epunt_la_files
+# @USAGE: [dir to scan]
+# @DESCRIPTION:
+# .la files can cause many unpleasantries when they disappear,
+# forcing rebuilds of seemingly unrelated packages.
+# This function removes the .la files from [dir to scan], ${D} if not set.
+# A good time to start punting .la files may be when a .so bump happens,
+# so dependent packages do not have to be rebuilt twice.
+#
+# See also:
+# bug 245889
+# http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later
+
+epunt_la_files() {
+ debug-print-function $FUNCNAME $@
+ local TARGET=$1
+ [ -z ${TARGET} ] TARGET=${D}
+
+ # If this is a non-ELF system, chances are good that the .la files will be needed.
+ if type -P scanelf /dev/null
+ then
+ debug-print Scanelf found, proceeding...
+ ebegin Removing useless .la files
+ find ${TARGET} -name '*.la' '(' -type l -o -type f ')' -exec rm -f '{}' '+'
+ eend 0
+ else
+ debug-print scanelf not found, this appears to be a non-ELF system.
+ debug-print non-ELF systems are likely to need .la files.
+ debug-print .la files not removed from ${TARGET}
+ fi
+}
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
+ # If this is a non-ELF system, chances are good that the .la files will
be needed.
+ if type -P scanelf /dev/null
I think this is a not so cool way to check for an ELF system.
+ then
+ debug-print Scanelf found, proceeding...
+ ebegin Removing useless .la files
+ find ${TARGET} -name '*.la' '(' -type l -o -type f ')' -exec
rm -f '{}' '+'
+ eend 0
+ else
+ debug-print scanelf not found, this appears to be a non-ELF
system.
+ debug-print non-ELF systems are likely to need .la files.
+ debug-print .la files not removed from ${TARGET}
rationale?
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Sunday 09 November 2008, Fabian Groffen wrote:
On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
+ # If this is a non-ELF system, chances are good that the .la
files will be needed. + if type -P scanelf /dev/null
I think this is a not so cool way to check for an ELF system.
Indeed, I think it's a horrid way. Please find a better one.
+ then
+ debug-print Scanelf found, proceeding...
+ ebegin Removing useless .la files
+ find ${TARGET} -name '*.la' '(' -type l -o -type f ')' -exec
rm -f '{}' '+' +eend 0
+ else
+ debug-print scanelf not found, this appears to be a non-ELF
system. + debug-print non-ELF systems are likely to need .la
files. + debug-print .la files not removed from ${TARGET}
rationale?
I've been told that .la files are really only needed on non-ELF
systems and with plugin systems that use dlopen. I actually have no way
of knowing that the .la files are needed on those arches, but I had
your archs in mind when doing the patch.
--
/PA
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On 09-11-2008 18:34:31 +0200, Peter Alfredsen wrote:
On Sunday 09 November 2008, Fabian Groffen wrote:
On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
+ # If this is a non-ELF system, chances are good that the .la
files will be needed. + if type -P scanelf /dev/null
I think this is a not so cool way to check for an ELF system.
Indeed, I think it's a horrid way. Please find a better one.
% uname -a
Darwin tefnut.cheops.ods.org 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10
18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
PowerMac8,2 Darwin
% scanelf --version
pax-utils-0.1.18_pre0004: scanelf.c compiled Oct 19 2008
$Id: scanelf.c,v 1.194 2008/09/29 06:05:55 vapier Exp $
scanelf written for Gentoo by solar and vapier @ gentoo.org
% scanmacho --version
pax-utils-0.1.18_pre0004: scanmacho.c compiled Oct 19 2008
$Id: scanmacho.c,v 1.5 2008/10/19 18:11:59 grobian Exp $
scanmacho written for Gentoo by solar, vapier and grobian @ gentoo.org
You could identify ELF a bit more reliable by running file on e.g.
${ROOT}/bin/bash, or just by building a list of CHOSTs that you know
are ELF systems.
+ debug-print scanelf not found, this appears to be a non-ELF
system. +debug-print non-ELF systems are likely to need
.la
files. + debug-print .la files not removed from ${TARGET}
rationale?
I've been told that .la files are really only needed on non-ELF
systems and with plugin systems that use dlopen. I actually have no way
of knowing that the .la files are needed on those arches, but I had
your archs in mind when doing the patch.
Ok. What worries me though is that this would result in some systems
having libtool files whereas the majority does not. E.g. removing them
apparently fixes a problem that then crops up on those systems or
something. Can't think of any atm.
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On 09-11-2008 19:46:12 +0200, Peter Alfredsen wrote:
Ok. What worries me though is that this would result in some systems
having libtool files whereas the majority does not. E.g. removing
them apparently fixes a problem that then crops up on those systems
or something. Can't think of any atm.
I can. If you have .la files, you will need to revdep-rebuild a lot
more. But c'est la vie.
I meant I can't think of an issue when there is no .la file.
--- /usr/portage/eclass/eutils.eclass 2008-09-28 07:06:15.0 +0200
+++ eutils1.eclass2008-11-09 18:26:44.0 +0100
@@ -1805,5 +1805,37 @@
) || die
else
newbin ${tmpwrapper} ${wrapper} || die
fi
}
+
+# @FUNCTION: epunt_la_files
+# @USAGE: [dir to scan]
+# @DESCRIPTION:
+# .la files can cause many unpleasantries when they disappear,
+# forcing rebuilds of seemingly unrelated packages.
+# This function removes the .la files from [dir to scan], ${D} if not set.
+# A good time to start punting .la files may be when a .so bump happens,
+# so dependent packages do not have to be rebuilt twice.
+#
+# See also:
+# bug 245889
+#
http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later
+
+epunt_la_files() {
+ debug-print-function $FUNCNAME $@
+ local TARGET=$1
+ [ -z ${TARGET} ] TARGET=${D}
+
+ # If this is a non-ELF system, chances are good that the .la files will
be needed.
+ if [[ $(file ${ROOT}/bin/bash) =~ ELF ]]
+ then
+ debug-print ELF system found, proceeding...
+ ebegin Removing useless .la files
+ find ${TARGET} -name '*.la' '(' -type l -o -type f ')' -exec
rm -f '{}' '+'
+ eend 0
+ else
+ debug-print This appears to be a non-ELF system.
+ debug-print non-ELF systems are likely to need .la files.
+ debug-print .la files not removed from ${TARGET}
+ fi
+}
--
Fabian Groffen
Gentoo on a different level
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-11-09 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-11-09 23h59 UTC. Removals: net-dns/resolvconf-gentoo 2008-11-03 13:04:40 armin76 x11-misc/obpager2008-11-03 23:46:13 darkside x11-themes/lxappearance 2008-11-07 21:26:05 yngwin dev-java/gnu-jaxp 2008-11-09 08:18:46 serkan Additions: dev-ruby/uuidtools 2008-11-03 01:27:39 flameeyes dev-ruby/flickr 2008-11-03 01:38:07 flameeyes gnustep-libs/cddb 2008-11-03 12:08:43 voyageur gnustep-apps/cdplayer 2008-11-03 12:17:17 voyageur sys-block/hpacucli 2008-11-03 16:02:16 wschlich net-misc/aqbanking3-tool2008-11-05 09:04:16 hanno x11-libs/gtkhotkey 2008-11-05 18:24:54 serkan dev-tcltk/tkcon 2008-11-05 21:32:54 bicatali x11-libs/xpa2008-11-05 21:45:11 bicatali sci-astronomy/ast 2008-11-05 22:05:26 bicatali sci-astronomy/funtools 2008-11-05 22:13:59 bicatali lxde-base/lxappearance 2008-11-07 14:28:51 yngwin lxde-base/lxde-common 2008-11-07 14:46:37 yngwin lxde-base/lxlauncher2008-11-07 14:59:32 yngwin lxde-base/lxpanel 2008-11-07 15:07:05 yngwin lxde-base/lxrandr 2008-11-07 15:28:52 yngwin lxde-base/lxsession-lite2008-11-07 15:46:52 yngwin lxde-base/lxtask2008-11-07 15:56:08 yngwin lxde-base/lxterminal2008-11-07 16:10:24 yngwin lxde-base/lxde-meta 2008-11-07 16:33:33 yngwin dev-cpp/pangomm 2008-11-08 22:48:32 eva media-sound/xfi-drivers 2008-11-09 13:32:05 loki_val -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-dns/resolvconf-gentoo,removed,armin76,2008-11-03 13:04:40 x11-misc/obpager,removed,darkside,2008-11-03 23:46:13 x11-themes/lxappearance,removed,yngwin,2008-11-07 21:26:05 dev-java/gnu-jaxp,removed,serkan,2008-11-09 08:18:46 Added Packages: dev-ruby/uuidtools,added,flameeyes,2008-11-03 01:27:39 dev-ruby/flickr,added,flameeyes,2008-11-03 01:38:07 gnustep-libs/cddb,added,voyageur,2008-11-03 12:08:43 gnustep-apps/cdplayer,added,voyageur,2008-11-03 12:17:17 sys-block/hpacucli,added,wschlich,2008-11-03 16:02:16 net-misc/aqbanking3-tool,added,hanno,2008-11-05 09:04:16 x11-libs/gtkhotkey,added,serkan,2008-11-05 18:24:54 dev-tcltk/tkcon,added,bicatali,2008-11-05 21:32:54 x11-libs/xpa,added,bicatali,2008-11-05 21:45:11 sci-astronomy/ast,added,bicatali,2008-11-05 22:05:26 sci-astronomy/funtools,added,bicatali,2008-11-05 22:13:59 lxde-base/lxappearance,added,yngwin,2008-11-07 14:28:51 lxde-base/lxde-common,added,yngwin,2008-11-07 14:46:37 lxde-base/lxlauncher,added,yngwin,2008-11-07 14:59:32 lxde-base/lxpanel,added,yngwin,2008-11-07 15:07:05 lxde-base/lxrandr,added,yngwin,2008-11-07 15:28:52 lxde-base/lxsession-lite,added,yngwin,2008-11-07 15:46:52 lxde-base/lxtask,added,yngwin,2008-11-07 15:56:08 lxde-base/lxterminal,added,yngwin,2008-11-07 16:10:24 lxde-base/lxde-meta,added,yngwin,2008-11-07 16:33:33 dev-cpp/pangomm,added,eva,2008-11-08 22:48:32 media-sound/xfi-drivers,added,loki_val,2008-11-09 13:32:05 Done.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Sunday 09 November 2008, Fabian Groffen wrote:
You could identify ELF a bit more reliable by running file on e.g.
${ROOT}/bin/bash, or just by building a list of CHOSTs that you
know are ELF systems.
D'oh, should have thought of that. See attached patch.
+ debug-print scanelf not found, this appears to be a
non-ELF
system. + debug-print non-ELF systems are likely to need
.la
files. + debug-print .la files not removed from
${TARGET}
rationale?
I've been told that .la files are really only needed on non-ELF
systems and with plugin systems that use dlopen. I actually have no
way of knowing that the .la files are needed on those arches, but I
had your archs in mind when doing the patch.
Ok. What worries me though is that this would result in some systems
having libtool files whereas the majority does not. E.g. removing
them apparently fixes a problem that then crops up on those systems
or something. Can't think of any atm.
I can. If you have .la files, you will need to revdep-rebuild a lot
more. But c'est la vie.
--
/PA
--- /usr/portage/eclass/eutils.eclass 2008-09-28 07:06:15.0 +0200
+++ eutils1.eclass 2008-11-09 18:26:44.0 +0100
@@ -1805,5 +1805,37 @@
) || die
else
newbin ${tmpwrapper} ${wrapper} || die
fi
}
+
+# @FUNCTION: epunt_la_files
+# @USAGE: [dir to scan]
+# @DESCRIPTION:
+# .la files can cause many unpleasantries when they disappear,
+# forcing rebuilds of seemingly unrelated packages.
+# This function removes the .la files from [dir to scan], ${D} if not set.
+# A good time to start punting .la files may be when a .so bump happens,
+# so dependent packages do not have to be rebuilt twice.
+#
+# See also:
+# bug 245889
+# http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later
+
+epunt_la_files() {
+ debug-print-function $FUNCNAME $@
+ local TARGET=$1
+ [ -z ${TARGET} ] TARGET=${D}
+
+ # If this is a non-ELF system, chances are good that the .la files will be needed.
+ if [[ $(file ${ROOT}/bin/bash) =~ ELF ]]
+ then
+ debug-print ELF system found, proceeding...
+ ebegin Removing useless .la files
+ find ${TARGET} -name '*.la' '(' -type l -o -type f ')' -exec rm -f '{}' '+'
+ eend 0
+ else
+ debug-print This appears to be a non-ELF system.
+ debug-print non-ELF systems are likely to need .la files.
+ debug-print .la files not removed from ${TARGET}
+ fi
+}
signature.asc
Description: This is a digitally signed message part.
