All the 6.1 bugs have been addressed one way or another. There are
still 52 outstanding bugs for 6.2/future in BZ.
If any editor does want to make a significant change to 6.1, please post
it here before starting. Typo/wording changes are still OK.
This is the last chance to get updates into 6.1
Randy McMurchy wrote these words on 07/26/05 15:57 CST:
> The E2fsprogs package in LFS installs a libcom_err.so symlink in the
> /usr/lib dir which points to a libcom_err.so.2 library in /lib.
>
> The MIT Kerberos package from BLFS installs a libcom_err.so symlink
> in the /usr/lib dir which poin
Thanks, Justin
Index: trunk/BOOK/x/installing/xorg.xml
===
--- trunk/BOOK/x/installing/xorg.xml(revision 4868)
+++ trunk/BOOK/x/installing/xorg.xml(working copy)
@@ -411,7 +411,7 @@
Create the xorg.conf file with:
-cd ~
Randy McMurchy wrote:
> Unfortunately, my build script has them all on one line so I never
> encountered this issue. (moral - make your build scripts match what
> is in the book for testing book instructions!)
Agreed. I use a technique I call "Document Centric Automation". It's
helped me tremendo
Ken Moffat wrote:
> The response I got implied that all blfs-related patches need to be
> aired on blfs-dev so that a blfs-editor can commit them to patches if
> they choose.
The BLFS editors need to have a firm handle on the patches that are
actually used in the book. We set up an understandin
On Sun, 31 Jul 2005, Bruce Dubbs wrote:
> Ken Moffat wrote:
> > I'm afraid its me again, still failing to understand the projects'
> > protocols. Last week I posted the attached patch or cpio to the patches
> > list (fixes CAN-1999-1575 (!), CAN-2005-, CAN-2005-1229).
> >
> > Apparently, I
On Sun, 31 Jul 2005, Randy McMurchy wrote:
> Andrew Benton wrote these words on 07/31/05 12:11 CST:
>
> > Also, make -f client.mk runs cvs update before anything else so that the
> > code is up to date.
>
> Is this what we want? Pull from CVS?
>
Almost certainly not. Thankfully, I don't have CV
On Sun, 31 Jul 2005, Randy McMurchy wrote:
> Now it makes me wonder if anyone is actually using the BLFS book
> method of building Firefox. I know there has been much talk of
> the profile issue, and resolutions for it. I will be examining
> this after the 6.1 release to see if we shouldn't use th
The current link command in the xsane page of the svn book:
ln -v -s /usr/bin/xsane /usr/lib/gimp/2.0/plug-ins/
produces this output:
create symbolic link `/usr/lib/gimp/2.0/plug-ins//xsane' to
`/usr/bin/xsane'
As a matter of aesthetics we might want to change the command to:
Andrew Benton wrote these words on 07/31/05 12:11 CST:
> There are some subtle but important differences between using CMMI and make
> -f client.mk
> make -f client.mk allows you to build in a separate obj.dir so you can build
> firefox,
Actually, the book uses the --disable-installer parameter
Randy McMurchy wrote:
Yes, in that I will be looking for a method to reliably build and
install so that the profile issue will go away for all 3 packages.
For Firefox the only solution I can see for the profile issue is to build from more recent code. The Firefox-1.0 branch is well past it's s
Randy McMurchy wrote:
You see, whether you use the BLFS method or your method, the same
thing is done, that is configure-make-make install. When the Moz
method 'make client.mk build' command is executed, it does nothing
more than run configure (with whatever options are specified) and
then make.
Randy McMurchy wrote:
> Bruce Dubbs wrote these words on 07/31/05 11:05 CST:
>
>
>>A agree with Randy that we need to have cut/paste work. It looks like
>>the the best alternative right now is to make the commands look like the
>>above, however, does anyone know why we don't use --enable-extensi
Bruce Dubbs wrote these words on 07/31/05 11:05 CST:
> A agree with Randy that we need to have cut/paste work. It looks like
> the the best alternative right now is to make the commands look like the
> above, however, does anyone know why we don't use --enable-extensions=all?
Richard already com
Randy McMurchy wrote:
> If this is what we have to do to make it work, then so be it. :-)
> The instructions will look funny in the book, but that is better
> than a broken build. Cut-and-paste ability is without question
> mandatory.
I did some cross checking here. My script has:
./config
Richard A Downing wrote these words on 07/31/05 10:26 CST:
> That said there is a rising head of steam to change. I would suggest
> that we look at it, post 6.1 release. It will need testing against all
> the options (which the LiveCD doesn't use, e.g. gnomeVFS).
Already on my todo list. Howeve
Randy McMurchy wrote:
Everyone responded that the CMMI works for them, why change things?
So it was left as a CMMI build.
Interesting. I don't recall that thread. I would have voted the other way.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratc
Randy McMurchy wrote:
Jeremy Huntwork wrote these words on 07/31/05 10:09 CST:
To be honest, the LiveCD build dropped the BLFS method a long time ago
in favor of the build-method that the mozilla site suggests using a
.mozconfig file and (approximately) the following commands:
Just for the
Ken Moffat wrote:
> I'm afraid its me again, still failing to understand the projects'
> protocols. Last week I posted the attached patch or cpio to the patches
> list (fixes CAN-1999-1575 (!), CAN-2005-, CAN-2005-1229).
>
> Apparently, I need to raise the issue on this list.
The best way
Jeremy Huntwork wrote these words on 07/31/05 10:17 CST:
> However, we chose to used that particular build method over BLFS's as
> it's the officially suggested and supported method and it makes it easy
> to maintain with the numerous configure options kept neatly in a
> separate file. From my
Jeremy Huntwork wrote:
> Jeremy Huntwork wrote:
>
>>
>> The build method is pretty stable and I would venture to guess doesn't
>> suffer from the same whitespace issue.
>
>
> Just realized that of course you'd still have to be careful for
> whitespace due to line-wrapping and presentation of the
M.Canales.es wrote:
> El Domingo, 31 de Julio de 2005 08:05, Bruce Dubbs escribió:
>
>
>>>Noticed on some of the packages is that "Last Updated On" information is
>>>not included at the bottom of the page. AbiWord and Thunderbird for sure.
>>
>>Manuel,
>> This looks like an xsl problem. The xml
TheOldFellow wrote these words on 07/31/05 10:14 CST:
> Well lots of the download URL's are longer than 71 chars. But you
> don't need to read those, just click 'em.
Those are not instructions inside [literal] tags. Huge difference
in HTML and PDF render.
Anything over about 71 characters insid
Jeremy Huntwork wrote these words on 07/31/05 10:09 CST:
> To be honest, the LiveCD build dropped the BLFS method a long time ago
> in favor of the build-method that the mozilla site suggests using a
> .mozconfig file and (approximately) the following commands:
Just for the record:
The BLFS bu
Jeremy Huntwork wrote:
The build method is pretty stable and I would venture to guess doesn't
suffer from the same whitespace issue.
Just realized that of course you'd still have to be careful for
whitespace due to line-wrapping and presentation of the commands in the
BLFS book - wasn't thi
On 31/07/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>Kind of a rock and a hard place here. We can't have instructions hat
>extend past about 71 characters, and it would be nice to have the
>parameters lined up in the book's instructions. Unfortunately, it
>appears that we cannot have it both wa
Randy McMurchy wrote:
Nice discovery! :-)
Now it makes me wonder if anyone is actually using the BLFS book
method of building Firefox. I know there has been much talk of
the profile issue, and resolutions for it. I will be examining
this after the 6.1 release to see if we shouldn't use the Moz
i
TheOldFellow wrote these words on 07/31/05 09:38 CST:
> I should say that I've ALWAYS had this problem building Firefox with the
> BLFS instructions and always taken these two switches out.
I will take responsibility for mucking up the instructions. When
I changed the --enable-extensions= line in
TheOldFellow wrote these words on 07/31/05 09:35 CST:
> OK, I've found out what the problem is. mozilla's configure doesn't
> like whitespace between options in --enable-extensions.
>
> These whitespace chars get put in by a cut and paste from the book.
Nice discovery! :-)
Now it makes me wond
Resend, so out of sequence. (mucked up the address copying from nntp to
mail)
>From blfs.book:
Randy McMurchy wrote:
> TheOldFellow wrote these words on 07/31/05 08:32 CST:
>
>
>>My mileage varied from yours. I don't have Heimeros and it refuses to
>>configure with the option set. I decid
Randy McMurchy wrote:
> TheOldFellow wrote these words on 07/31/05 08:32 CST:
>
>
>>My mileage varied from yours. I don't have Heimeros and it refuses to
>>configure with the option set. I decided to document it the way I did
>>for that reason.
>
>
> That is very odd. I never noticed this bef
I'm afraid its me again, still failing to understand the projects'
protocols. Last week I posted the attached patch or cpio to the patches
list (fixes CAN-1999-1575 (!), CAN-2005-, CAN-2005-1229).
Apparently, I need to raise the issue on this list.
Ken
--
das eine Mal als Tragödie, das a
El Domingo, 31 de Julio de 2005 08:05, Bruce Dubbs escribió:
> >
> > Noticed on some of the packages is that "Last Updated On" information is
> > not included at the bottom of the page. AbiWord and Thunderbird for sure.
>
> Manuel,
> This looks like an xsl problem. The xml for the files look co
Bruce Dubbs wrote:
> I can only go by what is in the bug. Are the current instructions for
> the specified version wrong? If so, go ahead and fix it. If not, we
> need to get the other bugs targeted for 6.1 fixed this weekend.
Sorry, didn't mean to sound soo dramatic. :-) Yes the current
inst
34 matches
Mail list logo
