El Sábado, 24 de Febrero de 2007 21:34, M.Canales.es escribió:
I'm doing now a new ICA/farce build but with M4 to see if that two binaries
differs also or not.
Another cause could be that my system have now a very big load and ocasionally
I have aleatories build fails (two times in the last
El Sábado, 24 de Febrero de 2007 21:38, Jeremy Huntwork escribió:
I had thought that the alphabetical branch didn't even touch chapter 5?
There was some changes, included the removal of the commented-out Bison and
Flex lines, when doned the merge. See
svn diff -r7279:7489
El Domingo, 25 de Febrero de 2007 00:43, Ken Moffat escribió:
Sorry I'm a bit later than I'd like in replying to this, but I saw
these running farce on the book as it was in December. Didn't
bother reporting it, so feel free to moan at me.
Thanks for remembering that now.
My second
El Viernes, 23 de Febrero de 2007 19:39, Matthew Burgess escribió:
If anyone can confirm the above, could you also suggest an explanation as
to why the above two libraries are problematic? I initially thought it was
a problem specific to jhalfs, because of the way it executes scripts under
El Viernes, 23 de Febrero de 2007 19:53, Dan Nicholson escribió:
I think the issue in jhalfs may be because progress-bar.sh is using
/bin/bash. Just a guess, but I saw the same issue before and that was
what initially struck me.
Not, reducing the Makefile target to just:
116-strippingagain:
El Viernes, 23 de Febrero de 2007 20:18, Matthew Burgess escribió:
Ah, slight clarification here! I'm actually running the command via the
following (from chapter06/revisedchroot.html):
sudo chroot $LFS /usr/bin/env -i \
HOME=/root TERM=\$TERM\ PS1='\u:\w\$ ' \
El Viernes, 23 de Febrero de 2007 20:26, M.Canales.es escribió:
That should corfim that the issue is in jhalfs, not related with the book
or the GCC/Glibc planned updates.
And fixed.
After knowing what was causing the segfault in both a full build and later in
my partial build tests, the fix
El Martes, 20 de Febrero de 2007 09:22, Dan Nicholson escribió:
3. Is m4 really needed in Chapter 5? I thought the only reason it was
there was because of Binutils, but it doesn't need m4 now...
Is that why? I have no idea, and I think you're probably most
qualified since you did all the
El Miércoles, 14 de Febrero de 2007 19:59, Matthew Burgess escribió:
Well, I've done a couple of LFS-svn builds recently on this box and never
encountered this problem, so I'm not sure that `dash' is the cause.
If you are using jhalfs to do the builds you will not find the bug.
We changed all
El Miércoles, 14 de Febrero de 2007 20:22, Matthew Burgess escribió:
Oh, and Manuel, if jhalfs is using any other workarounds currently, or
needs to in the future, could you let lfs-dev know so we can see whether
the book needs to integrate the fixes? Thanks.
In an ideal world, jhalfs
El Miércoles, 14 de Febrero de 2007 21:11, Matthew Burgess escribió:
Thinking about this a bit more, now that we know that LFS needs to be built
under bash, can we not just get rid of the workaround of doing `make
SHELL=/bin/bash' in jhalfs and instead just do a config check on the host
El Viernes, 9 de Febrero de 2007 08:53, Matthew Burgess escribió:
I'm not sure I understand this argument, Bruce. Rendering the book is
already dependent on DocBook, DocBook-XSL (and a specific version at that),
libxml2, libxslt and Fop, for PDF output. The XSLROOTDIR is overridable on
the
El Viernes, 9 de Febrero de 2007 03:07, Randy McMurchy escribió:
That's great, but I'm proposing we don't have them at all in SVN.
Seems, though, that in the conversation you don't remember, Manuel
mentioned something why we should continue to carry them in SVN.
I don't remember what it was.
El Jueves, 8 de Febrero de 2007 21:49, Matthew Burgess escribió:
Hi folks,
Do you think it's worth creating a branch so we can work on updating the
book rendering infrastructure? This way, if we can't get it sorted in time
for a release we simply don't merge from that branch? It also means
El Jueves, 8 de Febrero de 2007 15:40, Dan Nicholson escribió:
I completely forgot about this. Sorry. I think you need to use 1.69.1.
According to our local XSL guru, our book is broken using newer
versions.
http://wiki.linuxfromscratch.org/blfs/ticket/2088
That ticket was about 1.70.1,
El Jueves, 8 de Febrero de 2007 20:05, Matthew Burgess escribió:
I'll go through Trac and reassess milestones and such like tonight, but I
think a 6.3 release within 1 month is feasible. Does everyone else agree?
That would meant not time to me to do the update to
El Jueves, 8 de Febrero de 2007 20:17, Matthew Burgess escribió:
1. Wait for BLFS-6.2 to be released - we don't want to be screwing with
Quantum's rendering infrastructure so close to a release. It'd also be
nice to have the DocBook-4.5 instructions in BLFS and installed on Quantum
according
El Jueves, 8 de Febrero de 2007 20:44, Dan Nicholson escribió:
I'd like to second that we wait on the book source conversion for a
release. This will have to happen sooner or later, and after
BLFS-6.2.0 is as good a time as any. This doesn't mean we can't keep
moving the book towards
El Miércoles, 24 de Enero de 2007 21:53, Randy McMurchy escribió:
No hurry. Thanks Manuel.
Done in r6464. See stylesheets/wget-list.xsl for a more-in-deeper links test.
Attached the true_bad_links file generated with the new test-links target
for r6463. From 930 tested URLs there is only 44
El Martes, 16 de Enero de 2007 23:37, Vincent escribió:
In the -unlikely- event that you only need translators to start it, I
stand as a candidate to do a bit (or even a lot) of English - French
translation.
See this, you could to help them ;-)
http://www.fr.linuxfromscratch.org/
--
El Domingo, 14 de Enero de 2007 18:31, Justin R. Knierim escribió:
Justin R. Knierim wrote:
Anyways, any thoughts or a way to do this would help much. :)
Committed in r6393 an LFS-like stylesheet to create a wget-list file. To
generate it, run make wget-list.
Attached is the one generated
El Lunes, 11 de Diciembre de 2006 07:00, Luca escribió:
In blfs-book-sources Makefile there's the target make tex that has the
dependency of db2latex; the latter is not installed in blfs-book (I
installed it following the stylesheets installation); when I tried
passing make tex it broke
El Lunes, 11 de Diciembre de 2006 12:46, Luca escribió:
Now it's clearer; I'm not 100% sure but when I passed make tex maybe the
errors were others and not the one you mentioned, they should be
something like DB2Latex: Need to process XPath match book/xi:include but
as already said not sure.
El Lunes, 11 de Diciembre de 2006 12:06, M.Canales.es escribió:
I never played with it due that are very buggy, are unmantained, and I
don't know TeX sintax.
Actually looks that there is some very slow development, in
http://db2latex.sourceforge.net/snapshot/
the last snapshop is dated 06
El Sábado, 9 de Diciembre de 2006 05:30, Alexander E. Patrakov escribió:
Please don't ask questions how to do the above - you are assumed to know
this, otherwise jhalfs is not for you.
Objections? Corrections?
Good, I like it.
Plus, that
El Viernes, 8 de Diciembre de 2006 15:41, Alexander E. Patrakov escribió:
May I include it into the LFS LiveCD 6.2-4 instead of jhalfs-1.0?
Yezs you should.
But take note that now jhalfs-2.x must be run as unprivileged user with sudo
privileges.
--
Manuel Canales Esparcia
Usuario de LFS
El Viernes, 8 de Diciembre de 2006 16:50, Alexander E. Patrakov escribió:
I propose, instead of the current setup, to add the new jhalfs user to
/etc/passwd on the CD, setup sudo, put the jhalfs tarball in
/lfs-sources, and put some README file into root's home directory (or
append this
In HLFS trunk:
glibc-2.5-dl_execstack_PaX-1.patch does not match MD5SUMS value
NEW MD5SUM: d3c45b9f63a3f0f6cf5847d4ae4f9759
glibc-2.5-localedef_segfault-1.patch does not match MD5SUMS value
NEW MD5SUM: 879fcc4d60526a4796e5d99d5839de38
texinfo-4.8a-tempfile_fix-2.patch not found in the
El Jueves, 7 de Diciembre de 2006 13:57, M.Canales.es escribió:
All that missing patches prevent HLFS be build using jhalfs and also
prevent to update the FTP mirrors.
Sorry, missing patches are actually the ones listed in
http://www.linuxfromscratch.org/patches/hlfs/svn/copyerrs
and
http
The jhalfs development team is pleased to announce the release of jhalfs-2.1.
New features in this version:
- Better support for CLFS Sysroot book
- Added support for CLFS Embedded book
- Several bugs fixes and code clean-up
The jhalfs-2.1 tarball can be downloaded from
Hi,
Doing yesterday a SVN-20061201 build to test current ICA/farce support in
jhalfs I found that the first iterative build of Glibc fails at the configure
stage with that:
=== ./configure output fragment
checking how to run the C preprocessor... /lib/cpp
configure: error: C preprocessor
El Miércoles, 6 de Diciembre de 2006 12:10, Greg Schafer escribió:
IMHO there is little point in reinstalling the kernel headers during
subsequent ICA iterations. I've never done it. After all, they are not
binary, they are just ascii text.
Are the headers files already sanitized inside the
El Jueves, 30 de Noviembre de 2006 17:11, Jeremy Huntwork escribió:
Or are there any other ideas?
Maybe to install Sed before E2fsprogs like is done in CLFS?
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano:
El Lunes, 6 de Noviembre de 2006 00:25, Matthew Burgess escribió:
Manuel, does jhalfs have an option/feature for producing a list of files
installed by a particular package? I couldn't see one, nor could I see
an easy way of parsing the log files that jhalfs produces to see what
files were
El Viernes, 3 de Noviembre de 2006 16:13, Robert Baker escribió:
Thank you for the welcome its great to be a part of the team.
Welcome Robert. Is nice to see more people involved on HLFS developent.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en
El Martes, 31 de Octubre de 2006 19:18, Gerard Beekmans escribió:
I plan to use the opportunity to get LFS out of maintenance mode and
back as a forward moving project the way we all want it to be, and it
used to be.
Can have you on-board again are good news :-))
--
Manuel Canales Esparcia
El Lunes, 30 de Octubre de 2006 19:12, Jeremy Huntwork escribió:
Hi Everyone,
Hi :-)
I'm very happy to see you again.
First off, the ALFS project as a whole needs some re-structuring. I
gather that development on jhalfs is still hot (I've taken a peek at
recent code - you guys are doing
The jhalfs development team is pleased to announce the release of jhalfs-2.0.
New features in this version:
- Added support for CLFS-2.0 development book
- Added support for BLFS via blfs-tool framework
- Added support to install blfs-tool dependencies while installing xLFS
systems
El Lunes, 25 de Septiembre de 2006 21:39, Dan Nicholson escribió:
I've been thinking about this for a while. Is there any reason why
jhalfs doesn't use the $package-url entity to find out the tarball
instead of assuming that there is a 1:1 mapping between package and
tarball?
With a small
El Lunes, 25 de Septiembre de 2006 22:45, Matthew Burgess escribió:
I was going to simply call it Linux Headers and have it being written
out to linux_headers.html. Does that help you at all?
Yes. With that we can know that the needed change is to replace in
get_package_tarball_name()
El Jueves, 21 de Septiembre de 2006 19:32, Peter Ennis escribió:
cat /etc/udev/rules.d/82-cdrom.rules EOF
sbould be:
cat /etc/udev/rules.d/82-cdrom.rules EOF
Not.
That EOF must not be quoted to can have each udev rule spited in the book, due
layout issues, but dumped on an unique line
El Jueves, 21 de Septiembre de 2006 20:33, Matthew Burgess escribió:
Sorry about that complete and utter lie above. It's the other way
around, of course. If EOF is unquoted, shell expansion occurs within
the here-document.
Yes.
Additionally, as bash(1) states, newline handling
differs
El Miércoles, 13 de Septiembre de 2006 19:04, Gerard Beekmans escribió:
Hi all,
I'd like to officially welcome Bryan as a new member to our editorial
team. I don't think more introductions are needed, you (should) all know
Bryan and his work by now.
Welcome Bryan, having new editors with
El Miércoles, 13 de Septiembre de 2006 18:11, Alexander E. Patrakov escribió:
I am sorry to say this, but it would be better if LFS goes on without
me.
I hope that at least you continue sending posts and comments. Your
contributions are very appreciated.
This also means that LFS should
El Jueves, 24 de Agosto de 2006 02:06, Martin Ereth escribió:
1) The md5sum (and maybe the sha1sum, too) of the grub disk geometry patch
was wrong. Maybe this is reported, yet.
You downloaded it from an FTP mirror, right?
The one in
El Jueves, 24 de Agosto de 2006 21:03, Dan Nicholson escribió:
Do the other servers mirror off of Justin's server? How does this work?
Justin update the master one, then the others mirrors are sync using rsync,
like the web mirrors.
--
Manuel Canales Esparcia
Usuario de LFS nº2886:
El Sábado, 19 de Agosto de 2006 16:51, Chris Staub escribió:
Note: A similar warning should be added to the ALFS webpage, saying that
you should not even attempt ALFS until you can successfully build a
system manually without errors and without any help from support
channels, and that any
El Martes, 22 de Agosto de 2006 06:13, Bruce Dubbs escribió:
He and Ryan are proposing the Open Publication License,
http://www.opencontent.org/openpub, for all the books. I've looked at
it and it seems to meet the standards of having a recognized license and
protecting the books. If it is
El Martes, 15 de Agosto de 2006 18:37, Bryan Kadzban escribió:
Does that still break cdrtools? It used to, with an early 2.6 kernel
(2.6.1 maybe?) and possibly-old cdrtools version. That was the point
where I started putting the kernel source tree in my home directory
instead of /usr/src
El Miércoles, 9 de Agosto de 2006 20:53, Peter Ennis escribió:
1. Does the mount --bind take care of this normally
with cut and paste?
Yes, after the mount -bind ... $LFS/dev/{pts,shm} must exist.
3. Is there a reason not to explicitly create
/dev/pts and /dev/shm under $LFS ?
Due that
El Miércoles, 2 de Agosto de 2006 19:14, M.Canales.es escribió:
glibc-2.3.6-inotify-1.patch does not match MD5SUMS value
NEW MD5SUM: 94f6d26ae50a0fe6285530fdbae90bbf glibc-2.3.6-inotify-1.patch
If that can't be fixed, we have the first entry for the errata page.
That has been fixed
El Domingo, 30 de Julio de 2006 17:49, Tor Olav Stava escribió:
I got this while testing jhalfs:
lfs-bootscripts-20060712.tar.bz2 does not match MD5SUMS value
NEW MD5SUM: a6c176e365323f23b63173adbdeb4692
lfs-bootscripts-20060712.tar.bz2
udev-config-20060715.tar.bz2 does not match MD5SUMS
El Domingo, 30 de Julio de 2006 22:11, Bruce Dubbs escribió:
Manuel, I know why you split the lines, but AFAIK udev does not respect
the baskslash as a line continuation character.
I am open to suggestions.
Try the commands and look at the generated files ;-)
--
Manuel Canales Esparcia
El Viernes, 28 de Julio de 2006 06:24, Bruce Dubbs escribió:
I did this because I really don't expect the udev and bootscripts to
change prior to final, so they are now in their final form. Could you
do a quick sed in the jhalfs scripts to remove the -pre{$num} from the
instructions?
The jhalfs development team is pleased to announce the release of jhalfs-1.0.
This new version includes support for current LFS, CLFS and HLFS books. The
under development code for BLFS is included also in the tarball.
Among the ability to build a system directly from the book's sources, this
El Sábado, 8 de Julio de 2006 20:21, Matthew Burgess escribió:
As such, I think my continued involvement with the LFS project is actually
hindering it more than it is helping. It is therefore with some regret I
will be resigning from both the LFS-coordinators role and my editors
position
El Lunes, 10 de Julio de 2006 03:10, Gerard Beekmans escribió:
Hi guys,
To get the ball rolling on this 6.2 release Bruce has stepped up to the
plate and offered to get that coordinated and I've given him the green
light if you will to get this done without further delays.
Great, I'm anxious
El Lunes, 10 de Julio de 2006 04:24, Dan Nicholson escribió:
Very quickly, here are some relevant links and locations if you want
to try jhalfs. It won't take long to get familiarized with the tools.
If you find anything you think is a bug, please report to
alfs-discuss. George and Manuel are
El Lunes, 10 de Julio de 2006 06:39, Bruce Dubbs escribió:
Also at the suggestion of several people, I have given Dan and Tushar
full LFS commit privileges, so they can now make changes.
Great.
Remember that you, Dan, and Tushar must to be subscribed to lfs-book to allow
that the commit logs
El Miércoles, 7 de Junio de 2006 17:12, Chris Staub escribió:
Tried adding [ to the list for coreutils. However, this causes
validation problems with the xml. Perhaps someone knows a way to add
this without screwing up the xml code?
All ID values must start with a letter, and several
El Sábado, 27 de Mayo de 2006 21:51, M.Canales.es escribió:
In the same way that we adding || true to each make test command, we
could try to add a redirection to a JHALFSDIR/test-logs/ directory.
Done.
Now testsuite logs are created into a separate $JHALFSDIR/test-logs directory
El Domingo, 28 de Mayo de 2006 00:00, Matthew Burgess escribió:
Because I don't think the proposed method of dealing with the rules is
beneficial to the LFS book, relative to the current organisation. I've
already described how the books and bootscripts are handled (and it
seems most agree
El Sábado, 27 de Mayo de 2006 06:18, Alexander E. Patrakov escribió:
1) The translation must be done with the same DocBook XML tools as the
English book, and a link to the DocBook source must be provided
2) The translation should be compatible with jhalfs, and the non-obvious
differences in
El Sábado, 27 de Mayo de 2006 13:13, Randy McMurchy escribió:
You may want to see if the sgmldiff program from docutils can help.
It may work with XML just fine. And if so, it sounds like it may
help.
That type of tools help comparing XML trees, but not CDATA.
CDATA (the actual output text)
El Sábado, 27 de Mayo de 2006 21:20, Jeremy Huntwork escribió:
I don't really care what scripting method does it, I just liked the idea
of archiving the results of several builds. jhalfs might make this very
easy and practical. You're right that the test-results only are
required. Manuel,
El Martes, 23 de Mayo de 2006 19:24, Matthew Burgess escribió:
And as much as you say you want a joint effort, you're unprepared to
drop your package in favour of the one that LFS is using without any
technical justification, merely saying we had a tarball first.
IMHO, the best solution is
El Sábado, 13 de Mayo de 2006 01:08, Jeremy Huntwork escribió:
Seems to me that the only one that needs to stay (maybe) is LFS-RNG. The
rest have either been merged or abandoned.
Cab be removed.
It is very out-of-date and the move-on to DocBook-5.0 depend on upstream
developing XSL-2.0
El Lunes, 8 de Mayo de 2006 02:30, Archaic escribió:
Yes. And due to Ken's convincing emails, 2.6 will be updated possibly
right up to the day the book is released.
2.6.16.X, I suppose that you meant.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS
El Jueves, 4 de Mayo de 2006 02:42, Archaic escribió:
jhalfs was discussed in dozens of threads a long time ago. What you are
arguing against is a method to test the book directly from it's XML.
And that was one of the goals listed in the specifications when the work on
the newxml format was
El Jueves, 4 de Mayo de 2006 23:29, Jim Gifford escribió:
The biggest problem I've had about the md5sums in ALFS is that they are
ones we have created. We shouldn't be recreating them, but using the
author's version. I know we have repackages items so they are .bz2, but
that's not keeping a
El Martes, 2 de Mayo de 2006 02:01, Jeremy Huntwork escribió:
Also, here's an svn diff of the source files so you can see what I did
with the XIncludes. Manuel is this good enough, or do you have a better
idea?
http://linuxfromscratch.org/~jhuntwork/sanity-checks.diff
The method used is not
El Lunes, 1 de Mayo de 2006 22:48, Archaic escribió:
The patch is in the repo, but doesn't get copied over until the book
re-renders.
Oh, right. jhalfs is trying to download it from
http://www.linuxfromscratch.org/patches/lfs/development, of course.
--
Manuel Canales Esparcia
Usuario de LFS
El Lunes, 1 de Mayo de 2006 22:53, Archaic escribió:
Yes, and something that will be greatly helped along by jhalfs, but
going back in memory to previous SBU threads, I believe it was decided
that SMP machines would be quite skewed. Hyprethreading acts like SMP
(to what extent I'm not sure)
El Sábado, 29 de Abril de 2006 18:40, Gerard Beekmans escribió:
Intel Pentium D @ 3.0 GHz
2 GB RAM
Dual 160 GB SATA hard drives
A very nice beast ;-)
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano:
El Martes, 25 de Abril de 2006 01:49, Bryan Kadzban escribió:
So you're right: not drastic, and not many packages. I don't know how
widespread the differences here are; I'd chalk most of it up to just not
having updated the SBU numbers since 6.1.1.
I'm now making a script that will do report
El Martes, 25 de Abril de 2006 19:01, M.Canales.es escribió:
I'm now making a script that will do report with the SBUs and disk space
calculations from jhalfs build logs.
When ready, anyone using jhalfs to build the book could to submit us that
report and we could to use it to update
Hi
I made some changes to jhalfs to do more accurate disk usage and build time
measurements. Due that into the editor's guide there is no mention (yet)
about how to do that measurements, I implemented the next approach:
Disk usage is made in to steeps, a first du -skx $LFS before to unpack
El Lunes, 24 de Abril de 2006 22:03, Dan Nicholson escribió:
Approximate build time: 8 SBU
I get 9.2 SBU for gcc-pass1. I didn't measure disk usage with those.
Well, my time values can be smallest than yours due that I'm using an
HiperThreading enabled Intel CPU.
What I can't undestart
El Lunes, 24 de Abril de 2006 22:10, Randy McMurchy escribió:
unpack additional packages (like libidn, bash-doc or vim-languages)
To me, this skews things badly. We've never ever counted unpacking
source tarballs before.
[EMAIL PROTECTED]:~/sources$ time { tar -xjf
El Lunes, 24 de Abril de 2006 22:25, Randy McMurchy escribió:
[EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.2-Pass1 cat sbu.time
8.64 SBU
And on my doggy 500mhz P3, just recently built (20060322):
[EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.3-Pass1 cat sbu.time
9.38 SBU
El Viernes, 21 de Abril de 2006 06:26, Justin R. Knierim escribió:
Hi guys,
After manually reviewing packages and patches, these out-of-order
patches have always bugged me, so here is a patch. Applies to LFS
trunk, moves inetutils patches before kbd, alpha orders tar security and
sparce
El Jueves, 20 de Abril de 2006 04:46, Chris Staub escribió:
I like that new Appendix - great way to list all the dependencies. I've
attached a patch with some dependency (and text) corrections, as well as
a couple of packages that were left out entirely. Also, I have some
additional
El Jueves, 20 de Abril de 2006 22:30, Chris Staub escribió:
It wouldn't really be accurate to label Expect as a build-time
dependency of anything, because it isn't. It is needed, but only at
runtime, when DejaGNU runs it.
Thus Expect is a testsuite run-time dependency like DejaGNU.
The issue
El Jueves, 20 de Abril de 2006 13:01, Bryan Kadzban escribió:
2.6 may not be required for udev, but it is still (AFAIK) required for
NPTL to build. (Well, TLS in binutils, but without that, glibc won't
build NPTL either.)
So the reason may not be valid, but the requirement is, at least
El Jueves, 20 de Abril de 2006 23:48, Bruce Dubbs escribió:
2. The package names seem pretty large. Perhaps changing to
renderas=sect3 would be better. Alternatively a change to the font
size may only need to be a css change.
See if look better now.
3. Housekeeping: Why is there
El Viernes, 21 de Abril de 2006 01:14, Gerard Beekmans escribió:
If I refused it, I don't remember doing so.
Was near the same days that we was fixing the PDF look for the LFS-6.1 printed
book.
But I can't remember the reasons to reject it then.
The only thing I would object to is to
El Domingo, 16 de Abril de 2006 01:08, M.Canales.es escribió:
A similar issue when reinstalling Module-Init-Tools.
http://wiki.linuxfromscratch.org/lfs/ticket/1771
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http
El Sábado, 15 de Abril de 2006 05:50, Chris Staub escribió:
Yeah, I also agree it would be good to eliminate that stuff from the
package installation page, and just put it all in one place. The
dependency info is useful and important, but it just isn't needed at the
time a package is being
El Sábado, 15 de Abril de 2006 17:42, Archaic escribió:
I think it should be reverted. Seems kinda silly to have an identical
link in every package when we can just make a note in the intro
material.
Agreed. Adding a good note in chapter06/introduction.xml will make that links
redundant.
Hi,
Doing several LFS builds to test the ICA/farce support in jhalfs, I noticed
that when reinstalling Readline the
existent /lib/lib{history,readline}.so.5.1 libraries are renamed
to /lib/lib{history,readline}.so.5.1.old AND the
symliks /lib/lib{history,readline}.so.5 are changed to to
El Viernes, 14 de Abril de 2006 07:58, Chris Staub escribió:
I agree there, although I think that is only in the deps. page because
Manuel, in creating the patch, was simply copying-and-pasting my
comments about dependencies I had made in the ticket. Those notes
certainly should go into the
El Lunes, 10 de Abril de 2006 07:06, Bruce Dubbs escribió:
OK, here it is. I also updated the chapter07/hosts.xml file as
discussed earlier.
Applied, many thanks.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano:
El Viernes, 14 de Abril de 2006 17:05, Archaic escribió:
Actually, I was thinking that pulling anything in was rather wasted
effort. Why should the individual packages list their deps when the
exact same info is in the Appendix?
That is wy I'm ofering a new template.
If that is done, the
El Jueves, 13 de Abril de 2006 20:47, Archaic escribió:
The rendered book can be found at:
http://linuxfromscratch.org/~archaic/lfs-20060413/
Good.
I hope to can do some builds with jhalfs+ICA/farce this weekend :-)
--
Manuel Canales Esparcia
Usuario de LFS nº2886:
El Martes, 11 de Abril de 2006 16:55, Jeremy Huntwork escribió:
1) Manuel can you re-send that email? I can't seem to find it right now.
I might have deleted it accidentally... :/
Searching it ...
2) I think the page should be in the Appendix - not everyone will need
or want to read it.
El Lunes, 10 de Abril de 2006 07:06, Bruce Dubbs escribió:
OK, here it is. I also updated the chapter07/hosts.xml file as
discussed earlier.
Many thanks.
I will apply it after Jeremy and Archiac do the udev_update merge.
At the same time I will fix the images issue in the {C,H}LFS
El Lunes, 10 de Abril de 2006 15:33, Dan Nicholson escribió:
The ICA run finished up on the merged alphabetical/udev_update branch.
Results were as clean as always. Results can be found in the farce
and ica directories here:
Please Dan, can you corfirm if the next file, for example, is into
El Lunes, 10 de Abril de 2006 20:39, M.Canales.es escribió:
Please Dan, can you corfirm if the next file, for example, is into your
copied trees for iteration analisys?
../usr/include/sys/procfs.h
I think that do_ica_files is skipping the full /usr/include/sys tree, and
maybe others files
El Lunes, 10 de Abril de 2006 21:12, Dan Nicholson escribió:
Yeah, that fixed it. I should report that one back to the author. :-)
Are you getting differences in the headers?
Not full test yet. I'm fixing the bugs as they bombs the Makefile run ;-)
--
Manuel Canales Esparcia
Usuario de LFS
El Lunes, 10 de Abril de 2006 21:22, Dan Nicholson escribió:
I'll make another run later. I'm doing a run with all the testsuites.
In automake right now. I'll be crossing my fingers that this won't
be a problem.
I will start a new build now also.
iteration-1 now run until the end, but
101 - 200 of 321 matches
Mail list logo
