Change History (24)
follow-up: 3 comment:1 by , 18 years ago
follow-up: 4 comment:2 by , 18 years ago
Another note about the Xterm instructions: Luit is listed as an optional dependency, yet the default instructions for building Xterm seem to require it. It is confusing to me.
follow-up: 18 comment:3 by , 18 years ago
Replying to randy@linuxfromscratch.org:
Precedent is set to make the section where the original XORG_CONFIG is set have an xref id added, and then in the various instructions (mesalib, xterm, etc.), mention that the XORG_CONFIG should be the same as blah, blah, blah, with a link to the section where XORG_CONFIG was originally set.
Actually, in some cases it's $XORG_CONFIG, and some cases it's $XORG_PREFIX. So, maybe both variables would need to be mentioned, although $XORG_PREFIX is implied by $XORG_CONFIG. But I agree that an xref would help things out and should be added. Maybe it could be rolled into xincludes/xorg7-only.xml?
follow-up: 5 comment:4 by , 18 years ago
Replying to randy@linuxfromscratch.org:
Another note about the Xterm instructions: Luit is listed as an optional dependency, yet the default instructions for building Xterm seem to require it. It is confusing to me.
--enable-luit just tells configure to look for luit in the PATH. It will happily move along if it's not found. This should be clearer in the Command Explanations. I'll try to fix it up.
follow-up: 6 comment:5 by , 18 years ago
Replying to dnicholson@linuxfromscratch.org:
--enable-luit just tells configure to look for luit in the PATH. It will happily move along if it's not found. This should be clearer in the Command Explanations. I'll try to fix it up.
Actually (at least in version 224 which I installed), it looks for luit but falls back to a mini-luit version contained in the source tree if it can't find an installed copy.
comment:6 by , 18 years ago
Replying to randy@linuxfromscratch.org:
Actually (at least in version 224 which I installed), it looks for luit but falls back to a mini-luit version contained in the source tree if it can't find an installed copy.
I just checked again in 223 to make sure, but mini-luit or luit will only be used if the corresponding --enable is used.
Actually, it might be smarter if we add --enable-mini-luit for 223. In this case, you'll still get wide character support and it still checks for the system luit.
follow-up: 21 comment:7 by , 18 years ago
Expect has a testsuite and it can be run before installation by issuing 'make test'. All 25 tests complete successfully for me.
follow-up: 9 comment:8 by , 18 years ago
I'm experiencing a re-visioning of the old BLFS-Deps hint.
The power of BLFS is documenting dependencies, and 'twould be nice if the dependencies lists were formatted more rigorously (on the html side) wrt spelling (hyphenation and capitalization) of names and delimiting of alternatives, but no matter....
Here's a patch for some piffling little typos that my automatic parser stumbled over:
o http://wiki.linuxfromscratch.org/blfs/attachment/ticket/2242/my-changes.diff
comment:9 by , 18 years ago
Replying to CRhode:
The power of BLFS is documenting dependencies, and 'twould be nice if the dependencies lists were formatted more rigorously (on the html side) wrt spelling (hyphenation and capitalization) of names and delimiting of alternatives, but no matter....
Do you mean for the external links? Or the internal ones?
o http://wiki.linuxfromscratch.org/blfs/attachment/ticket/2242/my-changes.diff
Thanks. The 1st and 3rd diffs look good. The second one is actually a false positive because I think the module is really called Boost.Python.
comment:10 by , 18 years ago
about midnight commander 4.6.1 (blfs chapter 11)
If blfs-6.2.0 is to follow-up on lfs-6.2, why is there a patch for a bash-3.2? (lfs-6.2 is build with bash-3.1)
follow-up: 16 comment:11 by , 18 years ago
BLFS-6.2.0 is not only a follow-up to LFS-6.2. It would be stupid to exclude valid fixes for LFS-SVN problems that were added before branching. However, the "required" status of the patch is wrong for BLFS-6.2.0, thanks for the report. The same applies to the reiserfs patch, BTW.
Since I am going to sleep now, I woold not mind if anyone else fixes the issue.
by , 18 years ago
| Attachment: | fixes.diff added |
|---|
comment:13 by , 18 years ago
FWIW, I'm the one that put the data there and it is exactly what my logs indicate (lynx entities). Remember, they are approximate numbers.
comment:14 by , 18 years ago
No big deal. Anyway that's the reason of my question in Blfs-dev and I double checked the size.
Anyway it is in my intentions in my next build -waiting for the gcc 4.1.2 -to check the build sizes. There is a difference in sizes if you use du -skx with df -k.
Here is an example. Imagemagick with my options.
With du 86.70507812. With df 83348.
3 Mbytes of difference.
comment:15 by , 18 years ago
A few % is trivial (the ImageMagick note). In disk space, it isn't worth fixing unless it is grossly wrong. They change every time the package is updated as well. Depending on filesystem type, how it was formatted, etc., all play into how much space is used. I use the DU figure (instead of DF) as it is a higher (normally) number so that is some extra cushion for the reader.
Remember, it is not supposed to be exact, but more sort of indicate how much space you'll need to build and install.
comment:16 by , 18 years ago
Replying to alexander@linuxfromscratch.org:
BLFS-6.2.0 is not only a follow-up to LFS-6.2. It would be stupid to exclude valid fixes for LFS-SVN problems that were added before branching. However, the "required" status of the patch is wrong for BLFS-6.2.0, thanks for the report. The same applies to the reiserfs patch, BTW.
I'm sorry, but I have to disagree. I've been rejecting changes in regard to LFS-SVN for a long time now. BLFS-SVN will track LFS-SVN. IMO, it would be inconsistent for us to include something like the headers fixes for reiserfs when other programs are definitely broken in the same situation (vsftpd, for example). GCC-4.1 stuff comes to mind, too. The fixes are still going to be there in SVN. They're just not applicable to 6.2.0.
I'm going to comment out these two changes.
comment:18 by , 18 years ago
Replying to dnicholson@linuxfromscratch.org:
Actually, in some cases it's $XORG_CONFIG, and some cases it's $XORG_PREFIX. So, maybe both variables would need to be mentioned, although $XORG_PREFIX is implied by $XORG_CONFIG. But I agree that an xref would help things out and should be added. Maybe it could be rolled into xincludes/xorg7-only.xml?
I added info for setting XORG_CONFIG and XORG_PREFIX to xincludes/xorg7-only.xml in r6608 and r6609. I that should take care of this issue. If you want to turn this into an <xref>, go for it.
comment:19 by , 18 years ago
Replying to Ag.Hatzim:
A small patch with some minor text changes attached.
Thanks, Ag. I applied the s/Mangers/Managers/ fix, Randy fixed the Mesa size, and I think we're ignoring the small differences in lynx size. So, I think everything here has been addressed.
comment:20 by , 18 years ago
I think everything in this ticket has been addressed. Chuck, maybe we should start a new thread on blfs-dev about any more of the link troubles. There's already a thread about external URLs:
http://linuxfromscratch.org/pipermail/blfs-dev/2007-February/016634.html
If no one adds anything new by the end of of the day (PST), I'll close the ticket.
comment:21 by , 18 years ago
Replying to randy@linuxfromscratch.org:
Expect has a testsuite and it can be run before installation by issuing 'make test'. All 25 tests complete successfully for me.
Forgot about this. Randy, do you want to handle this? I haven't used expect outside of /tools ever. The current text says that expect doesn't have a reliable test suite. I don't know what to make of this.
comment:22 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I think everything is done now that Randy has fixed expect in r6225. Closing.
In the various instructions that use the XORG_CONFIG variable, it should be identified that this should be the same as what was used during the Xorg installation. Precedent is set to make the section where the original XORG_CONFIG is set have an xref id added, and then in the various instructions (mesalib, xterm, etc.), mention that the XORG_CONFIG should be the same as blah, blah, blah, with a link to the section where XORG_CONFIG was originally set.