Neil Williams writes:
> The cases listed are the ones where the .la file can be removed.
> Packages with .la files which don't meet those criteria were not
> included in the list. However, it looks like there could be a flaw in
> the original data.
Indeed, there were a bunch of different problem
On Sun, 03 Apr 2011 15:04:01 -0700
Russ Allbery wrote:
> Neil Williams writes:
>
> > If you are listed in the attached dd-list, it means that the following
> > tasks should be done REAL SOON NOW in order to smooth the path for
> > Multi-Arch and comply with Policy 10.2:
>
> > 0: Check the list
Le dimanche 03 avril 2011 à 17:06 -0700, Steve Langasek a écrit :
> Now that this is largely out of the way, we should definitely look at a more
> general and scalable solution than filing patches against each package with
> a .la file.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534966
--
Michael Biebl (04/04/2011):
> I might be mistaken, but I think Steve's meant something more along
> the lines of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586082
I guess I could have been more specific, and quoted Steve a bit
further:
| Once that's made its way through the archive, we coul
Am 04.04.2011 02:19, schrieb Cyril Brulebois:
> Steve Langasek (03/04/2011):
>> In addition to changing dh-make to not install .la files by default,
>> as has already been suggested in this thread, I think we should look
>> to get the desired behavior out of the common helpers (dh and cdbs)
>> by
Steve Langasek (03/04/2011):
> In addition to changing dh-make to not install .la files by default,
> as has already been suggested in this thread, I think we should look
> to get the desired behavior out of the common helpers (dh and cdbs)
> by default.
As a guy who added something like the foll
Hi Neil,
On Sun, Apr 03, 2011 at 11:53:02AM +0100, Neil Williams wrote:
> http://lists.debian.org/debian-devel/2009/08/msg00808.html
> I'm now getting patches from Ubuntu to catch up the effects of this old
> Release Goal. I fully support the removal of .la files [0] but it would
> be good if we
Neil Williams writes:
> If you are listed in the attached dd-list, it means that the following
> tasks should be done REAL SOON NOW in order to smooth the path for
> Multi-Arch and comply with Policy 10.2:
> 0: Check the listed package for .la files in the current version in sid.
> 1: Modify you
Mathieu Parent writes:
> Hi,
>
> 2011/4/3 Neil Williams :
>> http://lists.debian.org/debian-devel/2009/08/msg00808.html
>>
> (...)
>>
>> Let's try and handle the .la file issue across all of Debian.
>
> dh-make 0.58 install .la files by default
> (/usr/share/debhelper/dh_make/debianl/package-dev.
On Sun, 3 Apr 2011 19:45:13 +0200
Andreas Metzler wrote:
> Neil Williams wrote:
> > Andreas: the process you used to create the initial list - is that
> > available as a script somewhere? Can it be re-run? Can the updated
> > output be filtered for the libraries which can have the .la files
> >
On Sun, 3 Apr 2011 19:49:22 +0200
Andreas Metzler wrote:
> Neil Williams wrote:
> [...]
> > It is far cleaner to simply not package the .la file than to mangle it
> > with sed in debian/rules - my contention is that removing the file is
> > the best solution to the harm done by the dependency_li
Neil Williams wrote:
[...]
> I'm now getting patches from Ubuntu to catch up the effects of this old
> Release Goal. I fully support the removal of .la files [0] but it would
> be good if we could refresh the original goal so that .la files can be
> removed rather than applying a piece-meal set of
Neil Williams wrote:
[...]
> It is far cleaner to simply not package the .la file than to mangle it
> with sed in debian/rules - my contention is that removing the file is
> the best solution to the harm done by the dependency_libs field.
[...]
Hello,
If you removed an la file that is listed in a
On Sun, 3 Apr 2011 14:57:22 +0200
Mathieu Parent wrote:
> Hi,
>
> 2011/4/3 Neil Williams :
> > http://lists.debian.org/debian-devel/2009/08/msg00808.html
> >
> (...)
> >
> > Let's try and handle the .la file issue across all of Debian.
>
> dh-make 0.58 install .la files by default
> (/usr/share
Hi,
2011/4/3 Neil Williams :
> http://lists.debian.org/debian-devel/2009/08/msg00808.html
>
(...)
>
> Let's try and handle the .la file issue across all of Debian.
dh-make 0.58 install .la files by default
(/usr/share/debhelper/dh_make/debianl/package-dev.install contains
"usr/lib/*.la")
Should
On 2011-04-03, Neil Williams wrote:
>> .la files themselves are harmless, if the dependency_libs field is
>> cleared.
>
> Harmless, but are they actually then useful?
I just gave a example on where it is not only useful, but required.
>> There might be hard to replace old copies of libltdl in va
On Sun, 3 Apr 2011 11:38:58 + (UTC)
Sune Vuorela wrote:
> On 2011-04-03, Neil Williams wrote:
> > I'm now getting patches from Ubuntu to catch up the effects of this old
> > Release Goal. I fully support the removal of .la files [0] but it would
> > be good if we could refresh the original g
On 2011-04-03, Neil Williams wrote:
> I'm now getting patches from Ubuntu to catch up the effects of this old
> Release Goal. I fully support the removal of .la files [0] but it would
> be good if we could refresh the original goal so that .la files can be
> removed rather than applying a piece-me
http://lists.debian.org/debian-devel/2009/08/msg00808.html
I'm now getting patches from Ubuntu to catch up the effects of this old
Release Goal. I fully support the removal of .la files [0] but it would
be good if we could refresh the original goal so that .la files can be
removed rather than appl
On Thu, Sep 10, 2009 at 12:35:12AM +0200, Kurt Roeckx wrote:
> On Wed, Aug 26, 2009 at 03:46:36AM -0400, Felipe Sateler wrote:
> > Steve Langasek wrote:
> >
> > > On Wed, Aug 26, 2009 at 02:08:40AM -0400, Felipe Sateler wrote:
> > >> But this will cause trouble anyway. Imagine this case: glib chan
On Wed, Aug 26, 2009 at 03:46:36AM -0400, Felipe Sateler wrote:
> Steve Langasek wrote:
>
> > On Wed, Aug 26, 2009 at 02:08:40AM -0400, Felipe Sateler wrote:
> >> But this will cause trouble anyway. Imagine this case: glib changes
> >> SONAME, both app and library depend on glib. app is recompiled
[Paul Wise]
> Summarizing the upstream thread, it seems the solution they prefer is
> to just ignore dependency_libs when linking dynamically.
Sounds good to me. I can't comment on the Libs/Libs.private split,
except that if Steve is right and this is mostly for Gtk, they're
already pretty marri
Le mardi 25 août 2009 à 23:24 -0700, Russ Allbery a écrit :
> That's what symbol versioning is for, in the general case. Provided that
> each library provides its own functions for accessing its own objects and
> doesn't let you look under the hood into objects that are directly based
> on underl
Steve Langasek wrote:
> On Wed, Aug 26, 2009 at 02:08:40AM -0400, Felipe Sateler wrote:
>> But this will cause trouble anyway. Imagine this case: glib changes
>> SONAME, both app and library depend on glib. app is recompiled, gtk isn't
>> yet.So then app NEEDED libglib-2.0.so.1, gtk NEEDED libglib
On Wed, Aug 26, 2009 at 02:08:40AM -0400, Felipe Sateler wrote:
> But this will cause trouble anyway. Imagine this case: glib changes SONAME,
> both app and library depend on glib. app is recompiled, gtk isn't yet.So
> then app NEEDED libglib-2.0.so.1, gtk NEEDED libglib-2.0.so.0. Kaboom! The
>
Felipe Sateler writes:
> But this will cause trouble anyway. Imagine this case: glib changes
> SONAME, both app and library depend on glib. app is recompiled, gtk
> isn't yet.So then app NEEDED libglib-2.0.so.1, gtk NEEDED
> libglib-2.0.so.0. Kaboom!
That's what symbol versioning is for, in the
Russ Allbery wrote:
> Felipe Sateler writes:
>
>> But:
>> % objdump -p /usr/lib/libgtk-x11-2.0.so.0.1600.5 | grep glib
>> NEEDED libglib-2.0.so.0
>
>> If gkt+ encourages using glib types, there is no problem while gtk itself
>> uses glib types, as far as I can see. Or is there s
Felipe Sateler writes:
> But:
> % objdump -p /usr/lib/libgtk-x11-2.0.so.0.1600.5 | grep glib
> NEEDED libglib-2.0.so.0
> If gkt+ encourages using glib types, there is no problem while gtk itself
> uses glib types, as far as I can see. Or is there something I'm missing?
The appl
Steve Langasek wrote:
> On Wed, Aug 26, 2009 at 12:16:46PM +0800, Paul Wise wrote:
>> Summarizing the upstream thread, it seems the solution they prefer is
>> to just ignore dependency_libs when linking dynamically.
>
> That should be reasonable.
>
>> Is there any situation where that wouldn't w
On Wed, Aug 26, 2009 at 12:16:46PM +0800, Paul Wise wrote:
> Summarizing the upstream thread, it seems the solution they prefer is
> to just ignore dependency_libs when linking dynamically.
That should be reasonable.
> Is there any situation where that wouldn't work in Debian? pkg-config has
> bo
On Tue, Aug 25, 2009 at 11:59 AM, Paul Wise wrote:
> I've just sent libtool upstream a mail referencing this thread and
> also my dependency_libs_shared idea:
>
> http://lists.debian.org/debian-release/2009/08/msg00218.html
>
> Hopefully they will implement something useful so that static linking
* Julien Cristau (jcris...@debian.org) [090825 21:05]:
> On Tue, Aug 25, 2009 at 20:55:04 +0200, Andreas Barth wrote:
>
> > * Julien Cristau (jcris...@debian.org) [090825 12:18]:
> > > You should exclude anything that isn't /usr/lib IMO.
> >
> > And not /lib and not /lib{32,64} and not /usr/lib{3
* Andreas Barth (a...@not.so.argh.org) [090825 00:46]:
> * Andreas Barth (a...@not.so.argh.org) [090824 22:25]:
> > So I'd recommend maintainers of packages with:
> >
> > 1. "no flag" to remove the la-file on next occasion
> >
> > 2. only "dependency_libs" to remove their la-file RSN, because the
On Tue, Aug 25, 2009 at 20:55:04 +0200, Andreas Barth wrote:
> * Julien Cristau (jcris...@debian.org) [090825 12:18]:
> > You should exclude anything that isn't /usr/lib IMO.
>
> And not /lib and not /lib{32,64} and not /usr/lib{32,64}, ...
>
/lib shouldn't contain any libtool file (just like it
* Julien Cristau (jcris...@debian.org) [090825 12:18]:
> On Tue, Aug 25, 2009 at 11:05:44 +0200, Andreas Barth wrote:
> > * Josselin Mouette (j...@debian.org) [090825 10:28]:
> > > Le lundi 24 août 2009 à 22:25 +0200, Andreas Barth a écrit :
> > > > gnome-applets:
> > >
> > > This is a false pos
On Tue, Aug 25, 2009 at 11:05:44 +0200, Andreas Barth wrote:
> * Josselin Mouette (j...@debian.org) [090825 10:28]:
> > Le lundi 24 août 2009 à 22:25 +0200, Andreas Barth a écrit :
> > > gnome-applets:
> >
> > This is a false positive. xmodmap.la is about the “la” locale, it’s not
> > a libtool
On mar, 2009-08-25 at 11:04 +0200, Andreas Barth wrote:
> Looking at the package, /usr/lib/gtk-2.0/2.10.0/engines/libmurrine.la
> looks like an la-file to me. As your package is only with
> dependency_libs, you could drop that file on building the package
> (depending on your installation method re
* Josselin Mouette (j...@debian.org) [090825 10:28]:
> Le lundi 24 août 2009 à 22:25 +0200, Andreas Barth a écrit :
> > gnome-applets:
>
> This is a false positive. xmodmap.la is about the “la” locale, it’s not
> a libtool file.
Thanks. I think I'll exclude the directory /usr/share/xmodmap/ as
* Yves-Alexis Perez (cor...@debian.org) [090825 10:31]:
> On lun, 2009-08-24 at 22:25 +0200, Andreas Barth wrote:
> > 2. only "dependency_libs" to remove their la-file RSN, because they
> >block removal of the la-files on another package (this flag can be
> >wrongly hit if a package depends
On lun, 2009-08-24 at 22:25 +0200, Andreas Barth wrote:
> 2. only "dependency_libs" to remove their la-file RSN, because they
>block removal of the la-files on another package (this flag can be
>wrongly hit if a package depends only on itself - but well,
>dropping the la-file is recomme
Le lundi 24 août 2009 à 22:25 +0200, Andreas Barth a écrit :
> gnome-applets:
This is a false positive. xmodmap.la is about the “la” locale, it’s not
a libtool file.
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future und
On Tue, Aug 25, 2009 at 4:18 AM, Emilio Pozuelo
Monfort wrote:
> Andreas Barth wrote:
>> Updated the list and put it on http://alius.ayous.org/~aba/la-view.txt
>> and updated in () the packages that depend on the current package.
>
> Can you also create a dd-list list?
I have created it here:
http
I've just sent libtool upstream a mail referencing this thread and
also my dependency_libs_shared idea:
http://lists.debian.org/debian-release/2009/08/msg00218.html
Hopefully they will implement something useful so that static linking
with libtool is still viable.
--
bye,
pabs
http://wiki.debi
Peter Samuelson writes:
> As far as I know, there are 3 ways to handle static linking:
> 1) Document somehow what a real link line will look like, or let people
>figure it out on their own;
> 2) libtool;
> 3) pkg-config.
> So, my upstream does not ship .pc files. I've thought about creating
[Andreas Barth]
> The idea is to ask all maintainers of the 672 packages to drop their
> *.la-file unless really needed, and any maintainer of any package to
> empty the dependency_libs.
As far as I know, there are 3 ways to handle static linking:
1) Document somehow what a real link line will lo
Andreas Barth wrote:
> Updated the list and put it on http://alius.ayous.org/~aba/la-view.txt
> and updated in () the packages that depend on the current package.
Can you also create a dd-list list?
Thanks,
Emilio
signature.asc
Description: OpenPGP digital signature
* Andreas Barth (a...@not.so.argh.org) [090824 22:25]:
> So I'd recommend maintainers of packages with:
>
> 1. "no flag" to remove the la-file on next occasion
>
> 2. only "dependency_libs" to remove their la-file RSN, because they
>block removal of the la-files on another package (this flag
* Julien BLACHE (jbla...@debian.org) [090823 11:53]:
> Please go ahead with that. It's going to be much much easier to remove
> the .la files if we have a coordinated effort and it'll greatly reduce
> the potential for breakages.
So, I have now a first list of affected packages (see below). This
l
* Julien BLACHE (jbla...@debian.org) [090823 11:53]:
> Andreas Barth wrote:
> > send a mail to d-d-a with "how to do it" and a list of affected
> > packages, and then step-by-step file the appropriate bug reports
> > (only for packages which can dump their la-file).
>
> Please go ahead with that.
Andreas Barth wrote:
Hi Aba,
> send a mail to d-d-a with "how to do it" and a list of affected
> packages, and then step-by-step file the appropriate bug reports
> (only for packages which can dump their la-file).
Please go ahead with that. It's going to be much much easier to remove
the .la fi
(followup from -release, text from there is reused, so if you read
-release things are not too new for you)
Hi,
from time to time we have "funny" RC bugs thanks to dependencies
hidden in .la-files. Also these files lead to unneeded dependencies
between packages (in the case package A needs lib B
51 matches
Mail list logo
