card soldered to the motherboard
can be replaced by a USB WiFi interface.
So, if you consider seriously the introduction of a non-free-firmware
repo, please take the opportunity to introduce a non-DFSG docs repo as
well.
Best,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free
on it.
the bundling is certainly more convenient
... for whom? Are both priorities being well-served by this bundling?
Best,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
FSFLA Board Member ¡Sé Libre! = http
by suggestions of more
appropriate Debian mailing lists.
Thanks in advance,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
FSFLA Board Member ¡Sé Libre! = http://www.fsfla.org/
Red Hat Compiler Engineer [EMAIL PROTECTED
On 28 Oct, 2008, Josselin Mouette [EMAIL PROTECTED] wrote:
Le mardi 28 octobre 2008 à 14:12 -0200, Alexandre Oliva a écrit :
I hope the prevalent interpretation of Debian's rules and policies
isn't so lax as to make room for such manipulation as packaging stuff
in main that belongs in contrib
positions and
procedures.
On Oct 25, 2008, Ben Hutchings [EMAIL PROTECTED] wrote:
On Sat, 2008-10-25 at 18:28 -0200, Alexandre Oliva wrote:
My understanding is that portions of the Debian system that depend on
non-Free Software, in spite of being Free themselves, belong in
contrib, not in main
and
that led me to an incorrect conclusion?
Thanks in advance for any enlightenment you may be able to offer,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
FSFLA Board Member ¡Sé Libre! = http://www.fsfla.org/
Red Hat
at kernel.org.
Thanks, and keep up the good work,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
FSFLA Board Member ¡Sé Libre! = http://www.fsfla.org/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
--
To UNSUBSCRIBE
be that, even if libraries
that are part of Devian packages are properly installed in /dev/lib,
they will not be found by Devian programs, because /dev/lib will not
be searched.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com
this marvelous tool that is libtool...
I'm pretty sure we'll be able to work it out :-)
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
with the same soname is installed in the
hard-coded path or in some directory the dynamic linker is configured
to use, the user (or the packager) is asking for trouble, and that's
what he'll get.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org
for users that have
already upgraded to libc6. You'll have to do it at some time anyway,
when standard distributors stop including libc5 in their default
installations, so why not start doing it now?
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org
listed in ld.so.conf (or just in sys_lib_search_path_spec, for a
start). I'd implement it myself if I were not so much overloaded with
academic issues.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de
On Jan 30, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote:
On 30 Jan 1999, Alexandre Oliva wrote:
I agree there is a problem to be fixed, I just think that libtool
is not the only piece of software that may have to be changed to
fix it, because it is not the only piece of software that uses
, though, to create a shared library with `-soname
/usr/lib/libfoo.so.2', but then it becomes absolutely impossible to
move the library around. There are times when this behavior is
desirable, but libtool never does this, and there is no way to tell
libtool to do it.
--
Alexandre Oliva http
On Jan 30, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote:
On 30 Jan 1999, Alexandre Oliva wrote:
Thanks God I've got only one group of developers almost forcing me to
change something that is correct, and whose change wouldn't even help
them work around a problem they're facing.
shrug I'm
On Jan 29, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote:
Didn't we decide that all of the available alternatives that you have
suggested are not a feasable solution (does this mail help make it clear
why)?
On 29 Jan 1999, Alexandre Oliva wrote:
You may have missed the ugly one I
On Jan 29, 1999, Hamish Moffatt [EMAIL PROTECTED] wrote:
On Fri, Jan 29, 1999 at 07:11:54AM -0200, Alexandre Oliva wrote:
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
Therefore, we chose to solve that particular problem (the libc5-6
transition) by moving libraries around, knowing
On Jan 29, 1999, Hamish Moffatt [EMAIL PROTECTED] wrote:
On Fri, Jan 29, 1999 at 07:27:28AM -0200, Alexandre Oliva wrote:
Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the
library search path in certain circumstances? The hack is incomplete,
you just have to fix
the libtool script, after it is
generated, so as to set hardcode_libdir_flag_spec to the empty
string. The attached script should do it; just run it after configure
in any Debian package and you're done.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org
it.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
directories listed in
sys_lib_search_path_spec (but not in $shlibpath_var) in executables
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
in libtool, and a partial fix for it, by
Edouard Parmelan, is already installed in the CVS tree. Hopefully,
someone will soon be able to complete his work, based on the short
description of what is missing he recently provided.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL
distributions would not
run in any other, because /dev/lib is not listed in /etc/ld.so.conf,
and libtool had failed to add /dev/lib to the rpath of Devian
programs. Who's to blame for that?
Of course, the solution is easy: adding the directory to ld.so.conf or
to LD_LIBRARY_PATH.
--
Alexandre Oliva
On Jan 27, 1999, Marcus Brinkmann [EMAIL PROTECTED] wrote:
On Wed, Jan 27, 1999 at 08:22:09PM -0200, Alexandre Oliva wrote:
3) I don't want to regret having introduced a flag that caused as much
or more trouble than -rpath; and
I don't understand this comment. Which trouble with --rpath do
as it is.
Not in the interface it presents to its users. Internally, it's
obviously full of special cases to support all the crazyness of OS
developers and their wonderful dynamic linkers.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade
, but that could be avoided by
modifying other pieces of software that are doing their jobs
correctly.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
may be able to adopt it in
the future, on platforms that support it.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
replacing a
library with an (in)compatible version of it. Since you shouldn't do
that, libtool is not the piece of software to be blamed for using
-rpath.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade
/libc5 first,
right? Then why doesn't ld.so follow this rule, by replacing /usr/lib
with /usr/lib/libc5 when it finds this directory in the rpath too?
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de
On Jan 29, 1999, Richard Braakman [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:
ld.so is trying to outsmart everybody, but it is not smart enough to
do it. When you moved libc5-compatible libraries from /usr/lib to
/usr/lib/libc5, you established a rule that, if any program was linked
to prevent having to move
libraries in the first place: creating a libc6-specific directory
right now, instead of installing libraries in /usr/lib and having to
move them into another directory when libc7 should be released.
However, Alexandre Oliva [EMAIL PROTECTED] brings up an important
point: -rpath
On Jan 27, 1999, J.H.M. Dassen [EMAIL PROTECTED] wrote:
On Wed, Jan 27, 1999 at 17:07:30 -0200, Alexandre Oliva wrote:
You might have included my suggestion to prevent having to move libraries
in the first place: creating a libc6-specific directory right now, instead
of installing libraries
/local, and even then, they will only work on GNU/Linux.
I want to avoid this situation at all costs.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
On 27 Jan 1999, Alexandre Oliva wrote:
Having libtool default to -rpath is what's causing problems.
This is IMHO completely backwards :-)
When a program is linked with a shared library, a contract is
established [...] If you move
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
On 27 Jan 1999, Alexandre Oliva wrote:
Except that, if you replace the library with an incompatible one, you
*are* breaking the contract.
We don't replace libraries with incompatible ones.
Oh yes, you are.
We bring in new libraries
On Jan 27, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote:
On 27 Jan 1999, Alexandre Oliva wrote:
Having libtool default to -rpath is what's causing problems.
This is IMHO completely backwards :-)
You know, I seem to remember that there is another rather unpleasent
side-effect of rpath
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
On 27 Jan 1999, Alexandre Oliva wrote:
Can you tell -rpath to store the rpath for libmycustomthing.so and
not for libc.so?
No, but, on some systems (for example, GNU/Linux), it is possible to
hard-code the full pathname
to
use -rpath.
As I have already pointed out, the solution is not complete, otherwise
you'd not be observing any problem.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
38 matches
Mail list logo
