headers
Bruce Dubbs | 1 Aug 2007 01:54
Picon

[Fwd: List messages rejected]


-------- Original Message --------
Subject: List messages rejected
Date: Tue, 31 Jul 2007 13:50:31 -0700 (PDT)
From: David Olsson <davidolsson <at> yahoo.com>
To: blfs-dev-owner <at> linuxfromscratch.org

Hi.  Sorry to trouble you.  My messages to the list are being held and
rejected.  The last one, my own copy below, was held because, "Message
has a suspicious header".  Can you help me?  I'd like to participate in
BLFS.  Thanks.

David
Easthampton, MA

----- Rejected Message ----
>From David Olsson Sun Jul 29 18:08:38 2007
Received: from [68.142.200.245] by web31814.mail.mud.yahoo.com via HTTP;
Sun, 29 Jul 2007 18:08:38 PDT
Date: Sun, 29 Jul 2007 18:08:38 -0700 (PDT)
From: David Olsson <davidolsson <at> yahoo.com>
Subject: dhcpcd not stopped by ifdown
To: blfs-dev <at> linuxfromscratch.org
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="0-912148289-1185757718=:75736"
Content-Length: 1540

I noticed '/etc/rc.d/init.d/network stop' does not kill dhcpcd on my
BLFS system.  For example if I 'telinit 1', then 'telinit 3' I get a fat
(Continue reading)

Permalink | Reply | 752 comments |
headers
Bruce Dubbs | 1 Aug 2007 02:00
Picon

Re: Optional editline dependencies [Was Re: r6993 - in trunk/BOOK: . introduction/welcome postlfs/shells]

Dan Nicholson wrote:
> On 7/31/07, Ag. D. Hatzimanikas <a.hatzim <at> gmail.com> wrote:
>> For reference this is what installed with libedit.
>>
>> root:root       755     160628  /usr/lib/libedit.so.0.0.24
>> root:root       755     809     /usr/lib/libedit.la
>> root:root       644     181584  /usr/lib/libedit.a
>> root:root       644     18612   /usr/share/man/man3/editline.3
>> root:root       644     12594   /usr/share/man/man5/editrc.5
>> root:root       644     6771    /usr/include/editline/readline.h
>> root:root       644     6442    /usr/include/histedit.h
>>
>> Do you think that maybe there is a conflict?
> 
> There isn't a file conflict with readline. The conflict is that we
> (presumably) prefer readline when it's offered. Say I go to install
> dash, see the optional editline dependency and install that.
> Everything's great. Now I go to install xfsprogs and it will accept
> readline or editline but it takes editline by default (hypothetically,
> haven't checked). I've deviated from the book without knowing it. If I
> hit a bug here, it will be hard to debug since it will be hard to ask
> the right questions ("are you using readline or editline?").
> 
>> Do we have to test every of the aforementioned packages, just to
>> include the libedit (even as optional) dependency in Dash?
> 
> I don't think we need to test them. We need to find out if they take
> editline in addition to readline. If they do, we need to ensure that
> readline is used.
>
(Continue reading)

Permalink | Reply | 18 comments |
headers
Jeremy Huntwork | 1 Aug 2007 04:12
Picon
Favicon
Gravatar

Re: [Fwd: List messages rejected]

> MIME-Version: 1.0
> Content-Type: multipart/alternative;
> boundary="0-912148289-1185757718=:75736"
> Content-Length: 1540

David,

I'm not sure if Bruce mentioned this to you privately, but for your 
future reference, the above is probably the reason why your message was 
held for approval. The lists here tend to reject mail that is anything 
but plain text. And most large webmail providers (like yahoo) will send 
messages by default in html or some odd combination of html and plain text.

So, you'll probably want to see if you can get yahoo to compose mail in 
plain text only for the lists here, or maybe find another provider.

--
JH
--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Permalink | Reply | 0 comments |
headers
Randy McMurchy | 1 Aug 2007 15:23
Picon
Favicon

Re: Optional editline dependencies [Was Re: r6993 - in trunk/BOOK: . introduction/welcome postlfs/shells]

Bruce Dubbs wrote:

> I think the policy of omitting editline is valid, but if we do decide to
> add it as optional dependencies, we should also add a caution that in
> some cases editline conflicts with readline (which is installed in LFS).

I would prefer if we don't list libedit as a dependency. libedit
is really designed for BSD systems. And as has been mentioned
elsewhere, breaks other packages (some of them very badly).

We've had this discussion, and it was determined that the best
thing to do was simply not list libedit as a dependency.

-- 
Randy

--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Permalink | Reply | 17 comments |
headers
Dan Nicholson | 1 Aug 2007 15:48
Picon

Re: Optional editline dependencies [Was Re: r6993 - in trunk/BOOK: . introduction/welcome postlfs/shells]

On 8/1/07, Randy McMurchy <randy <at> linuxfromscratch.org> wrote:
> Bruce Dubbs wrote:
>
> > I think the policy of omitting editline is valid, but if we do decide to
> > add it as optional dependencies, we should also add a caution that in
> > some cases editline conflicts with readline (which is installed in LFS).
>
> I would prefer if we don't list libedit as a dependency. libedit
> is really designed for BSD systems. And as has been mentioned
> elsewhere, breaks other packages (some of them very badly).

Two things I think should be noted here. First, just because it's
designed on BSD and ported to Linux later doesn't mean it won't work
here. OpenSSH works the exact same way, and the opposite happens all
the time, too. The primary reason it's designed on BSD is because of
the non-GPL license.

Second, there is a very active port, pointed to in Ag's commit, that's
different from the Sourceforge version which is ancient. It'd be
interesting to know if the past breakage still occurs with this
version.

> We've had this discussion, and it was determined that the best
> thing to do was simply not list libedit as a dependency.

Any chance you can point to the old discussion? The only one I can find is here:

http://linuxfromscratch.org/pipermail/blfs-dev/2006-March/014048.html

Points 4 and 5 are not true using this port:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alexander E. Patrakov | 1 Aug 2007 15:54
Picon

Re: Optional editline dependencies [Was Re: r6993 - in trunk/BOOK: . introduction/welcome postlfs/shells]

Randy McMurchy wrote:
> Bruce Dubbs wrote:
>
>   
>> I think the policy of omitting editline is valid, but if we do decide to
>> add it as optional dependencies, we should also add a caution that in
>> some cases editline conflicts with readline (which is installed in LFS).
>>     
>
> I would prefer if we don't list libedit as a dependency. libedit
> is really designed for BSD systems. And as has been mentioned
> elsewhere, breaks other packages (some of them very badly).
>   

But Debian uses it where appropriate:

patrakov <at> home:~$ ldd /usr/bin/sftp
        libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb7f33000)
        libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 
(0xb7df2000)
        libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7ded000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7dd8000)
        libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7dc0000)
        libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb7d92000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7d6a000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7ce3000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7cbd000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7cba000)
        libedit.so.2 => /usr/lib/libedit.so.2 (0xb7c9f000)
        libncurses.so.5 => /lib/libncurses.so.5 (0xb7c5c000)
(Continue reading)

Permalink | Reply | 11 comments |
headers
Randy McMurchy | 1 Aug 2007 16:11
Picon
Favicon

Re: Optional editline dependencies

Dan Nicholson wrote:

> Two things I think should be noted here. First, just because it's
> designed on BSD and ported to Linux later doesn't mean it won't work
> here. OpenSSH works the exact same way,

Not sure how OpenSSH and libedit have some sort of commonality,
but unless this item is the same as your next item (the new
active port), I don't understand what you are driving at. Could
you please clarify (if it is important to the discussion).

> Second, there is a very active port, pointed to in Ag's commit, that's
> different from the Sourceforge version which is ancient. It'd be
> interesting to know if the past breakage still occurs with this
> version.

This I did not realize. Thanks for pointing it out. We will need
to check it out. I do know that most packages that use libedit,
use the version from SF (at least I think so), and that is no
good.

> Any chance you can point to the old discussion? The only one I can find is here:
> 
> http://linuxfromscratch.org/pipermail/blfs-dev/2006-March/014048.html

I am going on memory. If it really matters (I remember there
being more than just one post on the subject), we'll need to
search the archives. I'm not very good at it. Seems you and
Archaic have both recently posted about some tools you use that
make searching the Archives easier. I've never used either of
(Continue reading)

Permalink | Reply | 1 comment |
headers
Randy McMurchy | 1 Aug 2007 16:15
Picon
Favicon

Re: Optional editline dependencies

Alexander E. Patrakov wrote:

> But Debian uses it where appropriate:
> 
> patrakov <at> home:~$ ldd /usr/bin/sftp
>         libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb7f33000)
>         libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 
> (0xb7df2000)
>         libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7ded000)
>         libz.so.1 => /usr/lib/libz.so.1 (0xb7dd8000)
>         libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7dc0000)
>         libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb7d92000)
>         libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7d6a000)
>         libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7ce3000)
>         libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7cbd000)
>         libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7cba000)
>         libedit.so.2 => /usr/lib/libedit.so.2 (0xb7c9f000)
>         libncurses.so.5 => /lib/libncurses.so.5 (0xb7c5c000)
>         libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7b15000)
>         libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7b11000)
>         libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7b08000)
>         libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb7b05000)
>         /lib/ld-linux.so.2 (0xb7f54000)

Not arguing, but what package is actually linked to libedit (I'm
curious more than anything)? Some folks have the wrong impression
that because something is listed in the output of ldd for a particular
binary, it is used by that binary. That is an incorrect assumption.

For example, just because libedit is listed in ldd output of sftp,
(Continue reading)

Permalink | Reply | 10 comments |
headers
Alexander E. Patrakov | 1 Aug 2007 16:33
Picon

Re: Optional editline dependencies

Randy McMurchy wrote:
> Not arguing, but what package is actually linked to libedit (I'm
> curious more than anything)? Some folks have the wrong impression
> that because something is listed in the output of ldd for a particular
> binary, it is used by that binary. That is an incorrect assumption.
>
> For example, just because libedit is listed in ldd output of sftp,
> it does *not* mean it is used (not even pulled in directly) by
> sftp. It only means that one of *any* of the packages linked to
> sftp is linked directly to libedit.
>   
patrakov <at> home:~$ readelf -a /usr/bin/sftp | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libresolv.so.2]
 0x00000001 (NEEDED)                     Shared library: 
[libcrypto.so.0.9.8]
 0x00000001 (NEEDED)                     Shared library: [libutil.so.1]
 0x00000001 (NEEDED)                     Shared library: [libz.so.1]
 0x00000001 (NEEDED)                     Shared library: [libnsl.so.1]
 0x00000001 (NEEDED)                     Shared library: [libcrypt.so.1]
 0x00000001 (NEEDED)                     Shared library: 
[libgssapi_krb5.so.2]
 0x00000001 (NEEDED)                     Shared library: [libkrb5.so.3]
 0x00000001 (NEEDED)                     Shared library: [libk5crypto.so.3]
 0x00000001 (NEEDED)                     Shared library: [libcom_err.so.2]
 0x00000001 (NEEDED)                     Shared library: [libedit.so.2]
 0x00000001 (NEEDED)                     Shared library: [libncurses.so.5]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

So sftp is linked to libedit directly. Moreover, it uses symbols from 
libedit:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Nicholson | 1 Aug 2007 16:36
Picon

Re: Optional editline dependencies

On 8/1/07, Randy McMurchy <randy <at> linuxfromscratch.org> wrote:
> Dan Nicholson wrote:
>
> > Two things I think should be noted here. First, just because it's
> > designed on BSD and ported to Linux later doesn't mean it won't work
> > here. OpenSSH works the exact same way,
>
> Not sure how OpenSSH and libedit have some sort of commonality,
> but unless this item is the same as your next item (the new
> active port), I don't understand what you are driving at. Could
> you please clarify (if it is important to the discussion).

Well, it seemed that you were marking down a reason not to use
editline as that it was developed on BSD. I just wanted to point out
that OpenSSH is developed in the same way where it's ported from BSD
to Linux. The point being that we already heavily rely on a package
which is a port to Linux.

> > Second, there is a very active port, pointed to in Ag's commit, that's
> > different from the Sourceforge version which is ancient. It'd be
> > interesting to know if the past breakage still occurs with this
> > version.
>
> This I did not realize. Thanks for pointing it out. We will need
> to check it out. I do know that most packages that use libedit,
> use the version from SF (at least I think so), and that is no
> good.

I didn't either till Ag posted it, but it makes sense that this would
be worked out. There are quite a few packages that want to use
(Continue reading)

Permalink | Reply | 0 comments |

Gmane