lfs-via-rpm-devel — LFS via RPM Developers Mailing List

Re: [LvR] Entry to list, Spec files

[Jaco G. <ja...@pu...>]

Jeffrey B. Ferland wrote:

> I figured that as I had an interest in this project, I ought to join the 
> mailing list...


Welcome :)

 
> My first inquiry is as to the Spec files. After looking through many of the 
> packages, they appear to me as being less of a skeleton setup and more of a 
> "build me and I'll work." 


The specs basically encapsulate the LFS commands as described in the 
book. Instead of using the "cut-n-paste" technique, it allows RPM to act 
as the scripting engine for the LFS scripts. At this point, I think none 
of us are truly exstatic about the layout, it can be a bit complex 
especially for new starts, taking away some fun in toying.

Jason has already proposed a simpler spec layout which we will adopt 
after LFS 3.2-final.

> The impression I got from Jaco was that these would 
> be designed to be very basic and possible only usable if modified. But it 
> seems that with the Changelogs at the bottom that become part of the package 
> and the LFS-specific variables, it's becoming an RPM-ized LFS distro rather 
> than a tool to make your own.


I still think it is as basic as can be. It is still full LFS at heart, 
instead of typing in the commands, RPM does the script execution for 
you. What might shed some more light on the subject is Jason's HOWTO, 
http://www.puxedo.org/lvr/howto/.


> Am I heading in a different direction than you with what I expect?


I'm not sure I understand your direction well enough to comment on the 
above ;) The specs are supposed to be easy to tweak, in their base form 
they only wrap the LFS commands. Unfortionately we try to get them to 
build out of the box ;) Granted, we have put in extra things like 
granular packages, it just allows you to have a slimmer system without 
deleting files all over your HDD. (Just don't install what you don't need.)


> Granted, this is not the best way to join a list by being controversial, but 
> I am interested... and controversial.


*grin* Nothing wrong with that.

Greetings,
Jaco

[LvR] Entry to list, Spec files

[Jeffrey B. F. <aut...@li...>]

I figured that as I had an interest in this project, I ought to join the 
mailing list...

My first inquiry is as to the Spec files. After looking through many of the 
packages, they appear to me as being less of a skeleton setup and more of a 
"build me and I'll work." The impression I got from Jaco was that these would 
be designed to be very basic and possible only usable if modified. But it 
seems that with the Changelogs at the bottom that become part of the package 
and the LFS-specific variables, it's becoming an RPM-ized LFS distro rather 
than a tool to make your own.

Am I heading in a different direction than you with what I expect?

Granted, this is not the best way to join a list by being controversial, but 
I am interested... and controversial.

-Jeff
SIG: HUP

[LvR] Entry to list, Spec files

[Jeffrey B. F. <aut...@li...>]

I figured that as I had an interest in this project, I ought to join the 
mailing list...

My first inquiry is as to the Spec files. After looking through many of the 
packages, they appear to me as being less of a skeleton setup and more of a 
"build me and I'll work." The impression I got from Jaco was that these would 
be designed to be very basic and possible only usable if modified. But it 
seems that with the Changelogs at the bottom that become part of the package 
and the LFS-specific variables, it's becoming an RPM-ized LFS distro rather 
than a tool to make your own.

Am I heading in a different direction than you with what I expect?

Granted, this is not the best way to join a list by being controversial, but 
I am interested... and controversial.

-Jeff
SIG: HUP

Re: [LvR] Website Update: Specs

[Jaco G. <ja...@pu...>]

> I've updates the package lists with the latest specs from CVS. 
> Unfortionately this is still a manual process, until I can find a way to 
> do the CVS checkout automatically. 


Thanks to some pointers from Michael, we are updating the site 
automagically once every hour. Nice to have the actual site reflect CVS 
for a change without me having to spend lots of time on it.

Greetings,
Jaco

Re: [LvR] I finally got the automated buildscript build all modules

[Jaco G. <ja...@pu...>]

On Tue, 19 Feb 2002 17:11:53 +0100, mic...@t-... (Michael Ring)
wrote :
> ./compile.sh --verbose (Now go to a shop, buy coffee, brew it, drink it, 
> drink another one, talk to your fiancee, marry her... (aehm..)

Or you could just plonk this into a "buildscript" HOWTO, send it to me,
allow me to update the website and finally have a lvr-system ;)

*nudge* *nudge* *wink* *wink*

For those of you who are wondering - this approach will not replace the
current howto, rather we have the two complementatry systems for the
following reasons:

1. Newbies who still need to understand the system fully, should follow
the HOWTO

2. Seasoned professionals who knows what this is all about, should follow
the buildscript route.

Once you have done it a couple of times, you are looking for a more
automated solution.

Greetings,
Jaco

[LvR] I finally got the automated buildscript build all modules

[<mic...@t-...>]

Phew....

Misson (hopefully) completed!

I have checked in a new version of lfs-build.sh and also a lot of spec 
files.

Changes I did to the spec-files are as follows:

Most:
Simply removed tab's, replaced them by spaces to increase readibility

A number:
Made them buildable. There were some packages that had lost their 
dependencies, some with small errors

Some:
Did not install to /var/tmp/xxx, but tried to change /usr directly. 
Thaks to the fact that lfs-build.sh buils packages as an ordinary user 
those could be found easily

Even less:
Neeeded a rework because they could not be installed as non-root.


What you can do now is the following:

become root
Create an empty directory (mkdir /home/lfs/test)
LFS=The_directory_name    (LFS=/home/lfs/test)
export LFS                (export LFS)

now copy lfs-build.sh from cvs to $LFS
create softlinks named bootstrap.sh and compile.sh to lfs-build.sh
copy bootstrap.conf and compile.conf to $LFS

create directories $LFS/usr/src/lvr/specs and $LFS/usr/src/lvr/sources
copy all specs from CVS to $LFS/usr/src/lvr/specs
take all your sources+patches and put them to $LFS/usr/src/lvr/sources

make sure that you have rpm-4.0.3-04.patch.bz2 and also copy it to 
$LFS/usr/src/lvr/sources (This is soon to change, when Jason and I merge 
our rpm-patches)

cd $LFS

./bootstrap.sh --verbose (Now take a large cup of coffee, or talk to 
your grandmother on the phone)

after this the /static directory is done and you are ready for chroot.

/usr/sbin/chroot $LFS /static/usr/bin/env -i HOME=/root TERM=$TERM 
PATH=/bin:/usr/bin:/static/bin:/static/usr/bin /static/bin/bash --login

Now make sure that you have a /bin directory, and that there's a sh 
(link to /static/bin/bash) inside. If not, create it

if yes:

./compile.sh --verbose (Now go to a shop, buy coffee, brew it, drink it, 
drink another one, talk to your fiancee, marry her... (aehm..)

quite after a while your first lvr-system should be up and running!

Michael

Re: [LvR] Website Update: Specs

[<mic...@t-...>]

Jaco Greeff wrote:
> Michael Ring wrote:
> 
>> There is more than one way to work arround this:
>>
>> a) Use anonymous cvs to update the webpage, since read-only access 
>> should be enough for this task. The trick is to do the cvs login thing 
>> only once. cvs saves the password and in your script you only do the 
>> checkout.
> 
> 
> 
> I'm not understanding correctly. I'm currently using anon-cvs for the 
> checkout. Do you suggest I do a login to the CVS interface as some user 
> and then have a cron job that does the execution as the same user?

exactly. The logon is only needed once, after that the password is 
cached somewhere by cvs.

All my cvs mirroring goes that way.

Michael

Re: [LvR] TODO's before 3.2-rc2

[<lfs...@li...>]

Hi all,

Just a quick update on how we are doing with the 3.2-rc2 TODO's:

> 1. Currently the scripts have been wrongly changed to indicate 
> "requires" for some packages where they are actually "buildrequires". 
> Following the HOWTO, this does not have any impact of the success of the 
> build, but is wrong in rpm terms.


Changes implemented, altough there are some nigglies with glibc. 
Potentially we would like to define "lvr_rpm_none" in the bootstrap RPM 
patch and take out the ugly "expand" definition at the top of the specs. 
More feedback on this from Michael and Jason. (Putting it in the patch 
means that we will need to maintain two - one for bootstrap, one for 
normal operation.)

 
> 2. Further testing and fixing is to be done using Michael's automatic Ch 
> 5 & 6 building scripts. Building the system via the HOWTO works, but if 
> you know what to do, why not do it automagically? (As a first learning 
> step, the HOWTO is still the way to go.)


Michael busy with this. (All the time.)


> 3. The kernel.spec file needs to be split out into kernel-header.spec 
> and kernel.spec again. My experiment of using one spec file for the two 
> packages doesn't cover all the angles.


Done. (Jaco/Michael)


> 4. Update to newest LFS 3.2 CVS version. Following the LFS lists, not 
> much has really changed in LFS. Mostly work on the book itself, but all 
> scripts needs to be verified again. (This will happen as LFS 3.2-rc2 is 
> released, allowing us a day delay in getting LvR 3.2-rc2 out.)


Some work done. (Jaco/Michael)


> 5. Fix all the issues relating to CFLAGS not being set/unset.


Done. (Jason/Michael)


> 6. Actual updating of the lvr-release.spec file to reflect 3.2-rc2. (I 
> think we've missed this one in rc1)


Done. (Jaco, Will re-do for rc2, once it leaves the building)


> 7. Incorporate all feedback and bug fixes into the specs.


/dev/null issue incorporated.


> 8. When we build as a user in the buildscript, this user should default 
> to "lvr" instead of the current "lfs".


Nothing yet. (Michael)


> 9. Clean up the rpm "hack", allowing us to default the rpms to 
> /usr/src/lvr/*.


Done. (Jason, RPM patch)


> 10. Evaluate the use of furter rpm macros to clean up the specs.


Decided to leave these for 3.2.1 (Jaco/Jason/Michael)


> 11. Testing, testing, testing...


Busy, busy, busy... (All)


Greetings,

Jaco

[LvR] FAQ Entries

[Jaco G. <ja...@pu...>]

Hi,

I would like to start with the FAQ before we go into 3.2-final. Are 
there any pressing question you guys and gals think I should be 
addressing in this page?

I've got a couple already (at home, damned if I can think of any now) 
but would like to expand as much as possible.

Greetings,
Jaco

[LvR] CVS Module for patches

[Jaco G. <ja...@pu...>]

Hi,

I've created a section in CVS where we can submit patches for the 
system. (Both Michael and Jason has been shouting for this.) The setup 
currently looks as follow:

patches/base      - Patches for the base system
patches/bootstrap - Patches for the bootstrap system
patches/other     - Others, eg. for X

Michael, Jason, will one of you put in the patches for RPM and bootstrap 
RPM? Thanks :)

Greetings,
Jaco

Re: [LvR] Website Update: Specs

[Jaco G. <ja...@pu...>]

Michael Ring wrote:

> b) If you must have write access, add your public key to cvs. This can 
> be done via the sourceforge interface. Then either son't use a 
> passphrase on your private key (weak security) or have a password proxy 
> installed.


Any password proxy that you can recommend? This can be a very viable 
option just to get around the prompt.

Greetings,
Jaco

PS: Are you at home again? Do you ever work? ;)

Re: [LvR] Website Update: Specs

[Jaco G. <ja...@pu...>]

Michael Ring wrote:

> There is more than one way to work arround this:
> 
> a) Use anonymous cvs to update the webpage, since read-only access 
> should be enough for this task. The trick is to do the cvs login thing 
> only once. cvs saves the password and in your script you only do the 
> checkout.


I'm not understanding correctly. I'm currently using anon-cvs for the 
checkout. Do you suggest I do a login to the CVS interface as some user 
and then have a cron job that does the execution as the same user?

Basically currently it goes something like this:

1. I run the script
2. A password prompt pops up, I just press enter
3. I FTP the pages across.

I can automate 1 & 3, 2 maybe as described above.

Greetings,
Jaco

Re: [LvR] Website Update: Specs

[<mic...@t-...>]

Jaco Greeff wrote:
> Hi all,
> 
> I've updates the package lists with the latest specs from CVS. 
> Unfortionately this is still a manual process, until I can find a way to 
> do the CVS checkout automatically. (When it prompts for a password, it 
> has to be manual.)

There is more than one way to work arround this:

a) Use anonymous cvs to update the webpage, since read-only access 
should be enough for this task. The trick is to do the cvs login thing 
only once. cvs saves the password and in your script you only do the 
checkout.

b) If you must have write access, add your public key to cvs. This can 
be done via the sourceforge interface. Then either son't use a 
passphrase on your private key (weak security) or have a password proxy 
installed.

> 
> You can get the latest lowdown on the CVS specs at 
> http://www.puxedo.org/lvr/packages/
> 
> Greetings,
> Jaco
> 
> 
> _______________________________________________
> Lfs-via-rpm-devel mailing list
> Lfs...@li...
> https://lists.sourceforge.net/lists/listinfo/lfs-via-rpm-devel

[LvR] Website Update: Specs

[Jaco G. <ja...@pu...>]

Hi all,

I've updates the package lists with the latest specs from CVS. 
Unfortionately this is still a manual process, until I can find a way to 
do the CVS checkout automatically. (When it prompts for a password, it 
has to be manual.)

You can get the latest lowdown on the CVS specs at 
http://www.puxedo.org/lvr/packages/

Greetings,
Jaco

[LvR] More commits to cvs

[<mic...@t-...>]

I did a number of commits to cvs in this moment.

Basically I cleaned up the specs, removed tabs in the first because they
never seemed to match in my editor.

I also made changes to the specs to include tools I need for
lfs-build.sh (su, id)

I also removed a few typos from jason's patchfile for rpm and further
improved it.

I will write in detail what I did tomorrow, now I am ready for some rest

To test what I've done, remove/rename the static dir and use
lfs-build.sh to build the bootstrap part.

To do this, copy lfs-build.sh, bootstrap.conf, compile.conf  to your
$LFS-dir, make sure that all specs are under $LFS/usr/src/lvr/specs and
all sources are in $LFS/usr/src/lvr/sources

Now create a symbolic link named bootstrap.sh that shows to lfs-build.sh
   and with ./bootstrap.sh --verbose the fun should start.


Michael

cvs commit -l -m 'Changed specs to be more fhs compatible
Added changes needed for lfs-build to run
normalized spec-files, all modules are (roughly) built the same way'
'buildscripts/compile.conf' 'buildscripts/lfs-build.sh'
'SPECS/LFS-Bootstrap/bootstrap-bzip2.spec'
'SPECS/LFS-Bootstrap/bootstrap-diffutils.spec'
'SPECS/LFS-Bootstrap/bootstrap-file.spec'
'SPECS/LFS-Bootstrap/bootstrap-fileutils.spec'
'SPECS/LFS-Bootstrap/bootstrap-findutils.spec'
'SPECS/LFS-Bootstrap/bootstrap-gcc.spec'
'SPECS/LFS-Bootstrap/bootstrap-grep.spec'
'SPECS/LFS-Bootstrap/bootstrap-gzip.spec'
'SPECS/LFS-Bootstrap/bootstrap-make.spec'
'SPECS/LFS-Bootstrap/bootstrap-mawk.spec'
'SPECS/LFS-Bootstrap/bootstrap-patch.spec'
'SPECS/LFS-Bootstrap/bootstrap-rpm.spec'
'SPECS/LFS-Bootstrap/bootstrap-sed.spec'
'SPECS/LFS-Bootstrap/bootstrap-tar.spec'
'SPECS/LFS-Bootstrap/bootstrap-texinfo.spec'
'SPECS/LFS-Bootstrap/bootstrap-textutils.spec'
'SPECS/LFS-Bootstrap/bootstrap-util-linux.spec'
'SPECS/LFS/kernel-headers.spec' 'SPECS/LFS/lfs-bootscripts.spec'
'SPECS/LFS/lfs-filesystem.spec' 'SPECS/LFS/lfs-passwd.spec'
'SPECS/LFS/lfs-rootfiles.spec' 2>&1
Checking in buildscripts/compile.conf;
/cvsroot/lfs-via-rpm/LvR/buildscripts/compile.conf,v  <--  compile.conf
new revision: 1.2; previous revision: 1.1
done
Checking in buildscripts/lfs-build.sh;
/cvsroot/lfs-via-rpm/LvR/buildscripts/lfs-build.sh,v  <--  lfs-build.sh
new revision: 1.3; previous revision: 1.2
done
Checking in SPECS/LFS-Bootstrap/bootstrap-bzip2.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-bzip2.spec,v  <--
   bootstrap-bzip2.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-diffutils.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-diffutils.spec,v
   <--  bootstrap-diffutils.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-file.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-file.spec,v  <--
   bootstrap-file.spec
new revision: 1.2; previous revision: 1.1
done
Checking in SPECS/LFS-Bootstrap/bootstrap-fileutils.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-fileutils.spec,v
   <--  bootstrap-fileutils.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-findutils.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-findutils.spec,v
   <--  bootstrap-findutils.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-gcc.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-gcc.spec,v  <--
bootstrap-gcc.spec
new revision: 1.7; previous revision: 1.6
done
Checking in SPECS/LFS-Bootstrap/bootstrap-grep.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-grep.spec,v  <--
   bootstrap-grep.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-gzip.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-gzip.spec,v  <--
   bootstrap-gzip.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-make.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-make.spec,v  <--
   bootstrap-make.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-mawk.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-mawk.spec,v  <--
   bootstrap-mawk.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-patch.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-patch.spec,v  <--
   bootstrap-patch.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-rpm.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-rpm.spec,v  <--
bootstrap-rpm.spec
new revision: 1.7; previous revision: 1.6
done
Checking in SPECS/LFS-Bootstrap/bootstrap-sed.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-sed.spec,v  <--
bootstrap-sed.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-tar.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-tar.spec,v  <--
bootstrap-tar.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-texinfo.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-texinfo.spec,v
<--  bootstrap-texinfo.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-textutils.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-textutils.spec,v
   <--  bootstrap-textutils.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-util-linux.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-util-linux.spec,v
   <--  bootstrap-util-linux.spec
new revision: 1.4; previous revision: 1.3
done
Checking in SPECS/LFS/kernel-headers.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS/kernel-headers.spec,v  <--
kernel-headers.spec
new revision: 1.2; previous revision: 1.1
done
Checking in SPECS/LFS/lfs-bootscripts.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS/lfs-bootscripts.spec,v  <--
lfs-bootscripts.spec
new revision: 1.5; previous revision: 1.4
done
Checking in SPECS/LFS/lfs-filesystem.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS/lfs-filesystem.spec,v  <--
lfs-filesystem.spec
new revision: 1.5; previous revision: 1.4
done
Checking in SPECS/LFS/lfs-passwd.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS/lfs-passwd.spec,v  <--  lfs-passwd.spec
new revision: 1.5; previous revision: 1.4
done
Checking in SPECS/LFS/lfs-rootfiles.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS/lfs-rootfiles.spec,v  <--
lfs-rootfiles.spec
new revision: 1.5; previous revision: 1.4
done
[Finished]

[LvR] To compile from cvs, you will also need this patch

[<mic...@t-...>]

Unfortunately I just found out that our patches are not in cvs.

You will need to put the included patch in the sources dir for rpm to
compile correctly.

Sorry for any inconvenience this might cause!

Michael

[LvR] BuildRequires fixed in CVS

[Jaco G. <ja...@pu...>]

Hi all,

I've just commited the "requires" -> "buildrequires" fix to CVS. Basically,
it works like this:

If your RPM database is not updated installing over a clean LFS Ch 5 or
the bootstraps RPMS are not in the same DB (as per Michael's script),
do a "export LVR_RPM_NONE=1" before doing the builds. This is used to
only check the RPMS that have been installed in Ch 6 (dynamic) already.

Greetings,
Jaco

PS: Haven't tested these yet, hopefully I don't have typos :(
PPS: This means that we will be able to get away from using --nodeps in
the Ch 6 buildscripts as well. 

Re: [LvR] cvs commit

[Jaco G. <ja...@pu...>]

On Fri, 15 Feb 2002 22:00:29 +0100, mic...@t-... (Michael Ring) wrote :
> I just updated the following files to fix the CFLAGS-bug. It took me a 
> while, but now I hope that I have mastered the wonders of cvs

Excelent, I'll give it a sping tonight.

On a sperate front: I typically compile Ch 6 in this order, MAKEDEV,
glibc and the rest. This is to get away from the /dev/null problem. (I
fer not to do a mknod, rather to install everything via rpms, since
MAKDEDEV doesn't need antything special from glibc et al. Comments on
this? Its it a worthwhile change to the order?

Greetings,
Jaco 

[LvR] cvs commit

[<mic...@t-...>]

I just updated the following files to fix the CFLAGS-bug. It took me a 
while, but now I hope that I have mastered the wonders of cvs

Checking in SPECS/LFS-Bootstrap/bootstrap-binutils.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-binutils.spec,v 
<--  bootstrap-binutils.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS-Bootstrap/bootstrap-gcc.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS-Bootstrap/bootstrap-gcc.spec,v  <-- 
bootstrap-gcc.spec
new revision: 1.6; previous revision: 1.5
done
Checking in SPECS/LFS/binutils.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS/binutils.spec,v  <--  binutils.spec
new revision: 1.4; previous revision: 1.3
done
Checking in SPECS/LFS/gcc.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS/gcc.spec,v  <--  gcc.spec
new revision: 1.4; previous revision: 1.3
done
Checking in SPECS/LFS/glibc.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS/glibc.spec,v  <--  glibc.spec
new revision: 1.4; previous revision: 1.3
done
Checking in SPECS/LFS/patch.spec;
/cvsroot/lfs-via-rpm/LvR/SPECS/LFS/patch.spec,v  <--  patch.spec
new revision: 1.4; previous revision: 1.3
done

[Fwd: Re: [LvR] Latest cvs build notes]

[Jaco G. <ja...@pu...>]

Please see the response from Michael.

-------- Original Message --------
Subject: Re: [LvR] Latest cvs build notes
Date: Fri, 15 Feb 2002 09:55:13 +0100
From: Michael Ring <mic...@t-...>
To: jaco <ja...@pu...>
References: <Re: (91)LvR(9...( DDA:RFC-822=ja...@pu...; P=internet; 
  A=viat; C=de )>

Hi Jaco, I am not jet subscribed to the list from work and do not have
the time to do so right now. Could you please post this message to the list?

Sorry to bother you & Thanks!

 >>-*-Everything builds as i586 on my Athlon
 >>
 >
 >
 > Erk. I assume this is for Ch 5? If I'm right, it means that Mandrake
 > possibly does something wrong in their RPM macros since you are using
 > the Mandrake rpm. This is stnage - it always beuild to i686 on my PIII,
 > if it was RedHat, I would expect it to build Ch 5 to i386. Maybe a bit
 > more infor will help in killing this one. Anybody have some ideas?
 >

Mandrake's somehow patching rpm to make i586 the default arch. Looking
at the .srpm should give us a clue

 >
 >
 >>-*-binutils build fails if CFLAGS aren't set
 >>
  >
  >
  > Michael? Have you seen this? I know Michael had some problems yesterday
  > with CFLAGS in gcc and glibc (I think) relating to CFLAGS.
  >

unset is used, if the variable initially is not set, unset returns 1,
which means for rpm that an error has occured.

The cure in tbe SPEC-files is either:

replece unset CFLAGS with

unset CFLAGS ||:

or

CFLAGS=
export CFLAGS

(I prefer plan B)

I have already patched the files at home, but did not get them into cvs
because of valentines day ;-)

 >>-*-rpm wines about /usr/bin/bzip2 when bzip2 is installed in /bin/bzip2
 >>
 >
 >
 > RPM macro issue. I've also had this. I think we are actually missing
 > this in our patch. We need to edit the macro to point it to the actual
 > location of bzip2. (I was lazy previously and just made the links,
 > surely somebody else must have seen this as well?)

Yes, included in my patch, we soon have to put Jason's and my work together!


 >
 >>-*-error: failed to stat /dev/shm: No such file or directory
 >>
 >
 >>when rpm -Uvh invoked in chroot environment

Works as designed (Although I do not understand the design) rpm checks a
lot of directories before actually installing something. This message
does not hurt, simply ignore it.

 >>-*-/dev/null --no such file errors during  kernel.spec
 >>
 >
 >>-*-glibc build fails if CFLAGS aren't set
 >>
 >
 >
 > Yes, Michael picked this up yesterday and has fixed, it has possibly not
 > made it into CVS yet.
 >

See above!


Michael

mi...@pu...

[LvR] TODO's before 3.2-rc2

[Jaco G. <ja...@pu...>]

Hi all,

We've (Jason, Michael and me) been quite naughty lately developing and 
fixing bugs off list. Looking at the list itself, it seems that there 
wasn't that much work going on, yet...

Anyway, enough groveling. I would just like to clear the air and give 
the further milestones needed before we can get to 3.2 rc2 and 
eventually 3.2-final. (I have decided to keep the LFS release-naming 
scheme - it will just make it easier to keep tabs on where we are and 
what we are using as a base.)

This is what we still need to do before 3.2-rc2:

1. Currently the scripts have been wrongly changed to indicate 
"requires" for some packages where they are actually "buildrequires". 
Following the HOWTO, this does not have any impact of the success of the 
build, but is wrong in rpm terms.

2. Further testing and fixing is to be done using Michael's automatic Ch 
5 & 6 building scripts. Building the system via the HOWTO works, but if 
you know what to do, why not do it automagically? (As a first learning 
step, the HOWTO is still the way to go.)

3. The kernel.spec file needs to be split out into kernel-header.spec 
and kernel.spec again. My experiment of using one spec file for the two 
packages doesn't cover all the angles.

4. Update to newest LFS 3.2 CVS version. Following the LFS lists, not 
much has really changed in LFS. Mostly work on the book itself, but all 
scripts needs to be verified again. (This will happen as LFS 3.2-rc2 is 
released, allowing us a day delay in getting LvR 3.2-rc2 out.)

5. Fix all the issues relating to CFLAGS not being set/unset.

6. Actual updating of the lvr-release.spec file to reflect 3.2-rc2. (I 
think we've missed this one in rc1)

7. Incorporate all feedback and bug fixes into the specs.

8. When we build as a user in the buildscript, this user should default 
to "lvr" instead of the current "lfs".

9. Clean up the rpm "hack", allowing us to default the rpms to 
/usr/src/lvr/*.

10. Evaluate the use of furter rpm macros to clean up the specs.

11. Testing, testing, testing...

Possibilities for inclusion, won't delay rc2/final:

1. Automatic kernel building instead of going via the "make menuconfig" 
route. (ie, placing our own .config file for the kernel as part of the 
spec sources.) No work has started on this yet, and it is not the 
highest priority at present, considdering the current audience.

Well, that is more or less what I can think of currently, I might be 
missing one or two points, please shout if I have. I'll open a 
discussion for 3.3/4.0 once 3.2 is out the door. At that point we should 
plot the roadmap, but in brief terms I think a lot of emphasis will be 
placed on the auxiliary packages as well as incorporating feedback from 
Russ to look at all the cross-platform issues.

Greetings,
Jaco

Re: [LvR] Latest cvs build notes

[Jaco G. <ja...@pu...>]

Mike,

Thanks for the feedback, the more we build the more issues we can 
squash. On to your issues:

> I nuked my lfs(accidentally, with no backups of course), 


*grumble* Why does this sound so familiar?

> I was building from Mandrake.  


My setup as well.

> -*-Everything builds as i586 on my Athlon


Erk. I assume this is for Ch 5? If I'm right, it means that Mandrake 
possibly does something wrong in their RPM macros since you are using 
the Mandrake rpm. This is stnage - it always beuild to i686 on my PIII, 
if it was RedHat, I would expect it to build Ch 5 to i386. Maybe a bit 
more infor will help in killing this one. Anybody have some ideas?


> -*-binutils build fails if CFLAGS aren't set


Michael? Have you seen this? I know Michael had some problems yesterday 
with CFLAGS in gcc and glibc (I think) relating to CFLAGS.

 
> #I think rpm issues come from linking on a mandrake box


That is my gut feel as well. You can edit the rpmmacro file a bit to 
determine the output type.


> -*-rpm wines about /usr/bin/bzip2 when bzip2 is installed in /bin/bzip2


RPM macro issue. I've also had this. I think we are actually missing 
this in our patch. We need to edit the macro to point it to the actual 
location of bzip2. (I was lazy previously and just made the links, 
surely somebody else must have seen this as well?)


> -*-/static/usr/var/tmp/rpm-tmp.40708: /usr/lib/rpm/brp-mandrake: 

> No such file or directory  -note, had to copy /usr/lib/rpm/* 

> over to $LFS partition to make it work


Did you install bootstrap-rpm? I haven't had this when building Ch 6 
using the bootstrap rpm. I can understand why you would have it if 
you've actually used Mandrake's rpm binary for Ch 6.


> -*-error: failed to stat /dev/shm: No such file or directory 

> when rpm -Uvh invoked in chroot environment


Out of ideas here.


> -*-/dev/null --no such file errors during  kernel.spec


Will check.


> -*-glibc build fails if CFLAGS aren't set


Yes, Michael picked this up yesterday and has fixed, it has possibly not 
made it into CVS yet.


> I've been somewhat time constrained this week, so I haven't had a 

> chance to delve into root cause issues yet, but i figured I'd get this 

> info out to the list.


If you can help kill these, it would be great :)

Greetings,
Jaco

[LvR] Latest cvs build notes

[Mike B. <mi...@id...>]

Building the latest LvR I ran into a few problems.  I nuked my lfs(accidentally, with no backups of course), so I was building from Mandrake.  The build is still in progress, but I don't expect any further issues.  Here's what I've got.

-*-Everything builds as i586 on my Athlon
-*-binutils build fails if CFLAGS aren't set

#I think rpm issues come from linking on a mandrake box
-*-rpm wines about /usr/bin/bzip2 when bzip2 is installed in /bin/bzip2
-*-/static/usr/var/tmp/rpm-tmp.40708: /usr/lib/rpm/brp-mandrake: No such file or directory  -note, had to copy /usr/lib/rpm/* over to $LFS partition to make it work
-*-error: failed to stat /dev/shm: No such file or directory when rpm -Uvh invoked in chroot environment

-*-/dev/null --no such file errors during  kernel.spec
-*-glibc build fails if CFLAGS aren't set

I've been somewhat time constrained this week, so I haven't had a chance to delve into root cause issues yet, but i figured I'd get this info out to the list.


Mike

[LvR] Re: [Cooker] Buildrequires

[R.I.P. D. <ma...@li...>]

On Thu, 14 Feb 2002, R P Herrold wrote:

> There is a script which walks the rebuild process 
> (forget the name at the moment) and does essentially:
> 
> 1. Build in a chrooted environment from a known base; 
> 	Pre-install any 'BuildRequires hints' in existing 
> 	.spec file
> 2. Auto detect a failed build and install the needed 
> 	BuildDependency
> 3. Repeat until it builds
> 4. Using file, check every changed file access time, 
> 	generating a list
> 5. Using   rpm -qf --qf '%{name}\n'   build a list of all 
> 	owning packages called.
> 6. Sort | uniq | grep -v anything in the absolute minimum base 
> 	install | grep -v 'existing hints'
> 
> What is left is all of the new BuildRequires: of that package
> -- add to .spec file -- restore base build environment to a
> pristine state -- go to next package
> 
> I am working on a variant of of this for the LvR project.

This looks nice, and can be the way to go. But one flaw yet to be
plugged: it has no idea of "optional dependencies". pango is a good
example -- it can build with only glib 1.3.x, yet it can optionally
include external fribidi library. In this way, fribidi library won't be
listed as BuildRequires, since pango can build without it.

Abel

Re: [LvR] Re: Where to put rpm in /usr/src

[R P H. <he...@ow...>]

On Thu, 14 Feb 2002, Jaco Greeff wrote:

> Mediumish, I've also cc'ed Jeff :) (I originally din't want to post this 
> to the rpm-list since it was quite LvR specific but it might have some 
> relevance.)

rpm-list is pretty open minded -- I'd be interested in the 
response in a couple of the grey-beards on the list to my post 
-- but I resisted ...

> I did, and wrote my own for LvR, no offence to the author :)

I doulbt it would offend -- it _is_ crufty, although parts of 
it have to be.
 
> We've had a long debate on this (off lvr-devel) and the bottom-line is: 
> something like /usr/src/RPM/RPMS is not intuitive at all. After 
> shouting, screaming, kicking and sending this mail to you, we've decided 
> on... /usr/src/lvr/*, something you recommend.

Works for me

-------------- new thread element -------------

> >  In hindsight, a good argument could be made for using
> > /root/cvsroot/{RPMS|SOURCES|SRPMS|SPECS|BUILD} as to root's 
> > RPM tree root --- and thus encourage 
> >    ~/cvsroot/{RPMS|SOURCES|SRPMS|SPECS|BUILD}
> 
> > So I went scouting for chrooted, cross-arch porting
> > links; I have a good set of research, and will be trying to
> > write up a HowTo, in support of cross-platform porting of LvR

.. and this is my interest more than immediate gain in
performance -- getting automated cross-platform chrooted
building going, to speed finding breakage in
cross-architecture porting.
  
> That will be excellent! Looking forward to it. (Umm, won't be ablt to 
> lay my hands on a Sparc, but I'm itching for a Mac. Ask no questions and 
> I'll tell you no lies.)

I have a Mac on my bench with 9 and OSX; a PA-RISC; a RS6000;  
a Irix; ...  the list goes on -- getting NFS'd automated cross 
platform porting is my personal goal state with LvR.

-- Russ