Re: Sharutils

Igor Zivkovic wrote:

>Randy McMurchy wrote:
>  
>
>>I'm considering adding a package to BLFS, but not sure if it is
>>warranted. The GNU sharutils-4.2.1 package provides uuencode,
>>uudecode, shar and unshar. These are (these days) infrequently
>>used commands. I found a need installing a current package for
>>the uudecode program.
>>    
>>
>
>UUDeview is a much better option if you need uudecode/uuencode because
>it supports yEnc. Plus, slrn can use it too. See:
>
>http://www.fpx.de/fp/Software/UUDeview/
>

I'm not familiar with this package, but if it is currently maintained, 
then it is a better altenative.  uuencode/decode is not exactly in 
demand (or particularly hard to program), so I'm not really wild about 
adding either to the book. 

One alternative would be to add the instructions of uudecode directly 
into the application that needs it.  We already do that with lndir in 
xorg (although a separate download is not required).

  -- Bruce

BLFS Bugzilla

All,

Jeremy U and I wanted to know your thoughts on merging the two BZ's 
together.  We want to upgrade to the 2.18 series, but before we go, we 
need to know what you all want to do.  Here are some options:

1. Leave BLFS BZ alone and slowly migrate bugs over to the LFS BZ. 
Don't create any new bugs in the old and just leave it there until the 
old ones are complete.  If you do this, you get no bug history.

2. Close BLFS BZ completely.  Export all the data and import into the 
LFS BZ DB.  This would require a lot of manual editing and seding to get 
the bug numbers in BLFS BZ to be unique in the LFS BZ.  This means that 
all bugs in BLFS BZ would get new numbers.  The good side is all history 
is preserved.  The downside is it could take a few days to get it right 
and that could impact your development.

I would like a consensus on this by end of week.  If you pick #1, then I 
will look into upgrading asap.  If you pick #2, this will be a longer 
process as I will need to do some extensive testing on test db's before 
doing it in production.

James
-- 
James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 -- http://counter.li.org
Reg. LFS User   -- #6981   -- http://www.linuxfromscratch.org
LFS Bugzilla Maintainer    -- http://{blfs-}bugs.linuxfromscratch.org
--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev

Re: BLFS Bugzilla

James Robertson wrote:

> All,
>
> Jeremy U and I wanted to know your thoughts on merging the two BZ's 
> together.  We want to upgrade to the 2.18 series, but before we go, we 
> need to know what you all want to do.  Here are some options:
>
> 1. Leave BLFS BZ alone and slowly migrate bugs over to the LFS BZ. 
> Don't create any new bugs in the old and just leave it there until the 
> old ones are complete.  If you do this, you get no bug history.
>
> 2. Close BLFS BZ completely.  Export all the data and import into the 
> LFS BZ DB.  This would require a lot of manual editing and seding to 
> get the bug numbers in BLFS BZ to be unique in the LFS BZ.  This means 
> that all bugs in BLFS BZ would get new numbers.  The good side is all 
> history is preserved.  The downside is it could take a few days to get 
> it right and that could impact your development.
>
> I would like a consensus on this by end of week.  If you pick #1, then 
> I will look into upgrading asap.  If you pick #2, this will be a 
> longer process as I will need to do some extensive testing on test 
> db's before doing it in production. 

My preference is #2. 
  -- Bruce

--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html

Re: BLFS Bugzilla

On Tue, Nov 30, 2004 at 08:49:37PM -0600, Bruce Dubbs wrote:
> 
> My preference is #2. 

Same here. It seems the least amount of maintenance in the long run.

-- 
Archaic

Good intentions will always be pleaded for every assumption of
authority. It is hardly too strong to say that the Constitution was made
to guard the people against the dangers of good intentions. There are
men in all ages who mean to govern well, but they mean to govern. They
promise to be good masters, but they mean to be masters.

- Daniel Webster

--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: Sharutils

Bruce Dubbs wrote:
> Igor Zivkovic wrote:
>> http://www.fpx.de/fp/Software/UUDeview/
> 
> I'm not familiar with this package, but if it is currently maintained, 
> then it is a better altenative.  uuencode/decode is not exactly in 
> demand (or particularly hard to program), so I'm not really wild about 
> adding either to the book.
> One alternative would be to add the instructions of uudecode directly 
> into the application that needs it.  We already do that with lndir in 
> xorg (although a separate download is not required).

Well if you could pass along the instructions to uudecode something,
I will do that. But all I have now is the C code to create a binary
that does the uudecoding and I need to be able to do the uudecoding
from a shell script.

Thanks,
Randy
--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: Sharutils

Randy McMurchy wrote:

> Well if you could pass along the instructions to uudecode something,
> I will do that. But all I have now is the C code to create a binary
> that does the uudecoding and I need to be able to do the uudecoding
> from a shell script.

Use the attached files.  I did some very minor hacking to get around 
some constants.
Compile with
  gcc -o uudecode uudecode.c
  gcc -o uuencode uuencode.c

Encode with:

  cat orig-file | uuencode save-filename > uuencoded-file

Decode with:

  cat uuencoded-file | uudecode

The file will be saved as save-filename.

  -- Bruce

P.S.  We might just want to decode the file and tell users where to 
download the decoded file (as a patch?)

/* uudecode utility.

Re: Sharutils

Bruce Dubbs wrote:
> Randy McMurchy wrote:
> 
>> Well if you could pass along the instructions to uudecode something,
>> I will do that. But all I have now is the C code to create a binary
>> that does the uudecoding and I need to be able to do the uudecoding
>> from a shell script.
> 
> Use the attached files.  I did some very minor hacking to get around 
> some constants.
> Compile with
>  gcc -o uudecode uudecode.c
>  gcc -o uuencode uuencode.c
> 
> Encode with:
> 
>  cat orig-file | uuencode save-filename > uuencoded-file
> 
> Decode with:
> 
>  cat uuencoded-file | uudecode
> 
> The file will be saved as save-filename.
> 
>  -- Bruce
> 
> P.S.  We might just want to decode the file and tell users where to 
> download the decoded file (as a patch?)

Not to be argumentative, but instead, looking for a solution,

Re: LibXv.a won't compile

[cc'd to blfs.dev]

David Jensen wrote in blfs.support:
> leclerch wrote:
> 
>> Hello,
>>
>> I'm using LFS 5.1.1 whith 2.4.26 kernel, and when I compile
>> Xorg 6.8.1 or XFree86 4.4.0, I can't get the file libXv.a, I
>> only get the libXv.so.1 and its link, despite the fact that
>> it reports a successful compilation. Thus, xine can't build
>> its xv plugin.
> 
> 
> There is a patch in blfs patches/xine to have xine check for and use the 
> shared lib.
> 
> xine-lib-1-rc7_Xv-2.patch

Has anyone used this patch yet and actually tested that it works
as designed? (not questioning the validity of the patch, but if it
works as designed, and Xine successfully can use the Xv driver with
the shared library, I'm thinking the patch should be added to BLFS)

Any comments?

-- 
Randy
--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev

pango and VTE

Installed Pango-1.6.0...the pc file shows versions 1.0.  VTE-0.11.11 is 
looking for pangoxft-1.1  Think we need to drop back to vte-0.11.10 for 
the moment.  Will check back in a few.

-- DJ Lucas
--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: pango and VTE

DJ Lucas wrote:
> Installed Pango-1.6.0...the pc file shows versions 1.0.  VTE-0.11.11 is 
> looking for pangoxft-1.1  Think we need to drop back to vte-0.11.10 for 
> the moment.  Will check back in a few.
> 

And back, and nope...am I suffering from an ID ten T error someplace? 
VTE 11.10 dates back to BLFS-5.1...which also had pango-1.4.0 ???? 
Anybody see this yet?

-- DJ LUcas
--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page