gmane.linux.lfs.automated

Re: Can I use jhalfs with an already exist "tools"?

xinglp — 2012-05-13T18:24:25

2012/5/8 Pierre Labastie <pierre.labastie< at >neuf.fr>:
This works well, Thanks a lot :-)

Re: jhalfs not deal with the Chapter 9 of lfs

Bruce Dubbs — 2012-05-12T21:35:03

I think that's a good codename.

   -- Bruce

Re: jhalfs not deal with the Chapter 9 of lfs

Pierre Labastie — 2012-05-12T21:21:13

Le 12/05/2012 22:57, Pierre Labastie a écrit :
Sorry, I had an old version of the book. I see that
/etc/lsb-release is different now. I'll put that in jhalfs,
but still hardcoded I think. Has anybody something
to say against DISTRIB-CODENAME being
"<username>-jhalfs"?

I'll do that tomorrow if no one speaks up.

Regards
Pierre

Re: jhalfs not deal with the Chapter 9 of lfs

Bruce Dubbs — 2012-05-12T21:05:43

Everything from Chapter 6 on is root.  I do agree that there should be some 
commands from Chapter 9 in jhalfs, but the creation of lfs-release is hard-coded 
in the Makefile, not extracted from Chapter 9.  Up until a couple of days ago, 
that was the only thing there.

   -- Bruce

Re: jhalfs not deal with the Chapter 9 of lfs

Pierre Labastie — 2012-05-12T20:57:22

Le 12/05/2012 22:11, xinglp a écrit :
Thanks for pointing that. I think it is corrected now.
For the remaining of chapter 9, I wouldn't think
that it has to be included in jhalfs, since it is
mainly "get counted", which is something you do at
most once in your life.

Pierre

jhalfs not deal with the Chapter 9 of lfs

xinglp — 2012-05-12T20:11:11

and the ownership of /etc/lfs-release is not root

Re: Can I use jhalfs with an already exist "tools"?

xinglp — 2012-05-10T07:00:38

2012/5/8 Pierre Labastie <pierre.labastie< at >neuf.fr>:
Thanks, I'll test this later days, and give feedback.

Re: Can I use jhalfs with an already exist "tools"?

Pierre Labastie — 2012-05-07T17:00:14

Le 07/05/2012 15:23, xinglp a écrit :
I have never tried that, so all I'll write below should be considered
"experimental".

First, as it is rather difficult to be clear in explanations because
there are several files or directories called jhalfs, let me precise a
bit of vocabulary:
- when I write 'jhalfs source', it means the directory where you
checked out the jhalfs svn.
- when I write 'jhalfs', it means the directory which is created
under $BUILDDIR (by default /mnt/build_dir, but I usually change
its name to /mnt/lfs)

I think it is possible to do the following :
- Run make in the jhalfs source, and be careful NOT to select
'Run the makefile' nor 'Rebuild files' under 'General settings'.
Otherwise, select whatever is adapted to your wills.
Answer yes to 'Do you wish to save your new JHALFS
configuration', then yes twice (unless something goes wrong),
and let the program run to completion.

- There should be a directory named jhalfs in /mnt/lfs (or
whatever name you chose for the build directory).
cd to

Re: Can I use jhalfs with an already exist "tools"?

Bruce Dubbs — 2012-05-07T16:23:34

After a break, just use 'make' and it will pick up where it left off.  Anything 
else doesn't make sense.

   -- Bruce

Can I use jhalfs with an already exist "tools"?

xinglp — 2012-05-07T13:23:02

I want to use an exist "tools" to save some time.
But the jhalfs only give BREAKPOINT but not STARTPOIN.
So, is there any way to do that?

Thanks.

Re: host system requirements

Bruce Dubbs — 2012-03-28T15:50:41

I can change the host requirements to 5.0.0.  I believe that 5.0.3 was 
current when we added it to the book.

I've got another minor tweak to make so I'll do that today.

   -- Bruce

host system requirements

Pierre Labastie — 2012-03-28T11:56:38

Hi,

Currently, the host version required for xz in the book is 5.0.3, which 
is the current stable and less than one year old. It is also what is 
enforced in jhalfs. It seems to me that 5.0.0 (2 years old) is enough, 
and I propose to only enforce that in jhalfs. Anybody against that?

Regards
Pierre

Re: Should we strip all symbols in .so libraries when doing ICA?

Pierre Labastie — 2012-03-17T18:39:54

Le 17/03/2012 17:18, Bruce Dubbs a écrit :
Well, I am right now comparing Jeremy's method and current trunk,
stripping only debug symbols in .so files. It seems that it does not 
introduce
so many differences. There are other differences though.
When I am done, I'll report on the LFS list.
Yes and no:
Without LVM, it now works. For LVM, I use another machine,
and I think I do not set the kernel configuration right (not LVM
related, I think. The problem seems to be with the radeon module, which 
gives a black
screen, so that I do not know what happens). I do not have access to 
that machine
right now, so I cannot recompile the kernel with only vga...

Regards
Pierre

Re: Should we strip all symbols in .so libraries when doing ICA?

Bruce Dubbs — 2012-03-17T16:18:31

You can try, but I suspect there are just too many differences and will 
be overwhelmed with them.

BTW, did you ever get initramfs to work the way you wanted?

   -- Bruce

Should we strip all symbols in .so libraries when doing ICA?

Pierre Labastie — 2012-03-17T12:58:12

Hi,

Presently, the ICA preparation step strips debug symbols from .o files 
and all symbols from
any other file. It means that it strips all symbols from .so libraries. 
This has been like that since G. Schaffer's
original ICA files were copied. But I wonder if we should not try to 
compare the .so libraries with all their non-debug
symbols.

Any thought?

Pierre

Re: jhalfs lost a endef

Pierre Labastie — 2012-03-15T15:44:00

Le 15/03/2012 11:27, xinglp a écrit :
fixed in r3604. Thanks

jhalfs lost a endef

xinglp — 2012-03-15T10:27:39

lost a endef
svn di svn://svn.linuxfromscratch.org/ALFS/jhalfs/trunk -r3602:3603

Re: SBU report

Pierre Labastie — 2012-02-28T13:21:54

Le 27/02/2012 10:34, Pierre Labastie a écrit :
Committed in rev 3580 (with slight modification of the `du'
command)

Pierre

Re: SBU report

Peter Palmer — 2012-02-27T15:00:05

Ok, tested on a CLFS-1.2 build and it looks good here.

BASELOG picks the first one from these logs what I believe is correct:

/jhalfs/logs$ ll ???-binutils
-rw-r--r-- 1 clfs clfs 257362 Feb 20 10:46 042-binutils
-rw-r--r-- 1 clfs clfs 316082 Feb 20 11:41 054-binutils
-rw-r--r-- 1 root root 328938 Feb 20 13:17 124-binutils

I compared some weird entries for disk usage but in all cases the
problem is coming from the log files rather than from this report.

My apologies, I should have tested your earlier patch too after
bringing the thing up :/

If anyone wants to see the log I'll send it out directly to you.

Re: bug, but good...

Pierre Labastie — 2012-02-27T14:47:30

Le 27/02/2012 15:04, Pierre Labastie a écrit :
No, please don't. I do not understand myself... Sorry for the noise.

Pierre

Re: bug, but good...

Peter Palmer — 2012-02-27T14:23:43


 $no_empty_builddir != no_empty_builddir

That's why it's not working.

I am still trying to get my head around the whole build process
control so I don't have an opinion yet.