On Sat, 19 Jun 2010 17:58:25 -0500, Bruce Dubbs wrote:
> Yesterday I updated -dev to Module-Init-Tools-3.12. I noticed that the
> tarball has a populated directory test/build (about 2.4M, uncompressed)
> that is completely unnecessary.
>
> I am looking for opinions whether we sh
Yesterday I updated -dev to Module-Init-Tools-3.12. I noticed that the
tarball has a populated directory test/build (about 2.4M, uncompressed)
that is completely unnecessary.
I am looking for opinions whether we should remove the extra cruft
before we do the testing:
rm -r tests/build
then
Is it just me or does "make check" for Module-Init-Tools just compile
some stuff then quit without running any tests? There is a "runtests"
script in the "tests" dir that does the testsuite, but apparently this
is not run by "make check" anymore, although
Bruce Dubbs schrieb:
> I don't think saving the space being
> discussed is worth the multiple changes and risks required.
my concern is not space.
i just like to have dynamic libs for security reasons. whenever i update
a package i know to have covered all dependent packages. now libcrypt in
sys
On Mon, Jun 22, 2009 at 6:11 PM, DJ Lucas wrote:
> And I thought that I had been complaining on this long enough so that we
> would never violate the FHS again. ;-) Even as rare as a remote /usr
> mount is now days, libz really must be moved to /lib if anything in /bin
> or /sbin links against it
the modutils package (which require libc and libz to be
>>>> linked static), and sysvinit (libcrypt) where i copy the static
>>>> libraries back during the build.
>>>>
>>>>
>>> that's no more true concerning libz.
>>> On m
and libz to be
>>> linked static), and sysvinit (libcrypt) where i copy the static
>>> libraries back during the build.
>>>
>>>
>> that's no more true concerning libz.
>> On module-init-tools-3.8, there is a new --enable-zlib-dynamic parameter.
>
(libcrypt) where i copy the static
>> libraries back during the build.
>>
> that's no more true concerning libz.
> On module-init-tools-3.8, there is a new --enable-zlib-dynamic parameter.
> insmod,rmmod,modprobe are much smaller without static libz.
should we add this option
Hi all,
Seems I overlooked getting the update of Module-init-tools
into the book. Doing that now.
--
Randy
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Got it working now by changing the module-init-tools commands to be:
sed -e 's/^CFLAGS .*$/& -pie -fpie/' -i Makefile.in
touch modprobe.conf.5
./configure
make check
make distclean
touch modprobe.conf.5
./configure --prefix=/ --enable-zlib
make DOCBOOKTOMAN="&qu
> I'm rebuilding at present with prefix changed back to "" to see if that
> works as expected...
Same problem, module-init-tools stuff being put in /usr/local/ so now I'm
rebuilding with prefix set to "/usr".
--
http://linuxfromscratch.org
Ch.6, module-init-tools has "./configure --prefix=/ --enable-zlib" as per
current SVN version.
I used to have prefix specifed as "" as per an older version of the SVN book.
Looking through the build logs I now see that the module tools are being
installed into /usr/local/b
I must apologise but I cant help it.
Bernard Leak wrote:
Bernard Leak
--
Before they made me, they broke the mould
Does this mean that you *Leaked* out of the mould? :)
--
Shane Shields
Registered LFS Compiler: 7582
To drink the WINE of success you must first seek the sayings of source
Any
Dear List,
I've found the problem: the testsuite simply *assumes*
that '.' is in the path. This is true during the LFS build, but wasn't
when I returned to it with my 'running' set-up. This may be
thought worth a note, as it's easily got wrong and the output is
quite exceptionally u
On Sun, 1 Jan 2006, Bernard Leak wrote:
Dear List,
in what is (or was a few days ago!) the 'live' LFS Book
(LFS-BOOK-SVN-20051223), I can't get the test-suite for
6.50, Module-Init-Utils to run *at all*. Ignoring the test result,
everything seems to build, but I haven't dared ins
Dear List,
in what is (or was a few days ago!) the 'live' LFS Book
(LFS-BOOK-SVN-20051223), I can't get the test-suite for
6.50, Module-Init-Utils to run *at all*. Ignoring the test result,
everything seems to build, but I haven't dared install it on
top of the existing version.
in chapter 6: module-init-tools
"tar -xvf ../module-init-tools-testsuite-3.1.tar.bz2
--strip-path=1 &&"
since tar version 1.15.1, the --strip-path option is
no longer available and replaced with
--strip-components, the command above would return
error stating --stript-path o
Matthew Burgess wrote:
Essentially, if one uses the current '--prefix=""' then the following
ends up in the logs:
Rusty Russell says: 'Hmm. "" is not a valid path, in general. Hard to
see this as a bug, I'm afraid.'
Both the current `./configure --prefix="" --mandir=/usr/share/man` and
t
M.Canales.es wrote:
El Lunes, 21 de Noviembre de 2005 22:22, Matthew Burgess escribió:
3) Change the Makefile to do the following test instead:
if [ "$(prefix)" = / -o "$(prefix)" = "" ];
Try this:
if [ x$(prefix) = x/ ]
That is recommended way to test varaibles when you aren't sure that
Jeremy Byron wrote:
Matthew Burgess wrote:
3) Change the Makefile to do the following test instead:
if [ "$(prefix)" = / -o "$(prefix)" = "" ];
This should still give the 'unary operator expected' message, I would
think.
Nope, for once I did actually test this before proposing it :-)
In
Matthew Burgess wrote:
Hi folks,
There's a minor issue with the Makefile in this version.
Essentially, if one uses the current '--prefix=""' then the following
ends up in the logs:
/bin/sh: line 0: [: =: unary operator expected
That's caused by:
Makefile:71: if [ $(prefix) = / ]
In this c
El Lunes, 21 de Noviembre de 2005 22:22, Matthew Burgess escribió:
> 3) Change the Makefile to do the following test instead:
>
> if [ "$(prefix)" = / -o "$(prefix)" = "" ];
Try this:
if [ x$(prefix) = x/ ]
That is recommended way to test varaibles when you aren't sure that it allways
have an
On Mon, Nov 21, 2005 at 09:22:27PM +, Matthew Burgess wrote:
>
> I've a preference for option 3) in the long-term but put 2) in the book
> for the time being until the patch for 2 is submitted, accepted and in
> an upstream release.
Since option 3, or some other fix decided upon by upstream
Hi folks,
There's a minor issue with the Makefile in this version.
Essentially, if one uses the current '--prefix=""' then the following
ends up in the logs:
/bin/sh: line 0: [: =: unary operator expected
That's caused by:
Makefile:71: if [ $(prefix) = / ]
In this case, $(prefix) will obvi
Hi,
I'm building HLFS and even though I'm not sure, I think there's a bug
in zlib install.
I get errors when trying to build module-init-tools 3.1 with zlib
support: ( I know I should put whole listing but I've booted from LFS
livecd and don't have clipboard... )
/us
Matthew Burgess wrote:
> Greg Schafer wrote:
>> Tushar Teredesai wrote:
>>
>>>The make check in module-init-tools does absolutely nothing since the
>>>testsuite tarball is not downloaded.
>>
>> Correct. It has been noted in the DIY build since near da
Greg Schafer wrote:
Tushar Teredesai wrote:
The make check in module-init-tools does absolutely nothing since the
testsuite tarball is not downloaded.
Correct. It has been noted in the DIY build since near day 1.
So you decided to take the book, do your own thing with it, found at
least
Tushar Teredesai wrote:
> The make check in module-init-tools does absolutely nothing since the
> testsuite tarball is not downloaded.
Correct. It has been noted in the DIY build since near day 1.
> Additionally, running make check messes up the built executables, so the
> testsui
The make check in module-init-tools does absolutely nothing since the
testsuite tarball is not downloaded.
Additionally, running make check messes up the built executables, so
the testsuite has to be run before the normal build:
./configure &&
make check &&
make distclean
On Wed, Jun 15, 2005 at 10:20:18PM -0600, [EMAIL PROTECTED] wrote:
>
> My installation log for the Module-Init-Tools package shows that
> the genksyms, insmod_ksymoops_clean, kallsyms, kernelversion, and ksyms
> programs (links) are not installed.
>
> I'm not sure if I
Just rebuilt module-init-tools 3.1, and did a "touch modprobe.conf.5" right
after I unpacked it. Problem solved. :) Thanks again!
Dave
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
> Apparently the DOCBOOKTOMAN="" doesn't work because it is trying to
> execute:
>
> docbook2man doc/modprobe.conf.sgml
>
> By making it "" we get this:
>
> if [ "" = "docbook2man" ]; then \
> doc/modprobe.conf.sgml > /dev/null 2>&1; \
> else
Archaic wrote:
> I have found that doing a touch modprobe.conf.5 after unpacking sorts it
> out, without need for any arguments to make.
Yes. Been doing it that way for months in the DIY build. It's clearly the
correct fix.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.
Apparently the DOCBOOKTOMAN="" doesn't work because it is trying to
execute:
docbook2man doc/modprobe.conf.sgml
By making it "" we get this:
if [ "" = "docbook2man" ]; then \
doc/modprobe.conf.sgml > /dev/null 2>&1; \
else
On February 21, 2005 05:45 am, Steve Crosby wrote:
> Also, what's the recommended method of obtaining disk usage stats? total
> installed size, including sources? I'm building the full LFS system most
The book lists the disk space used after installation including the
not-yet-removed source tree.
Gerard Beekmans <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> commit. It might take a day or two before there might be time again.
> I'd rather get the package in without updating sizes, SBUs, and
> descriptions, than wait longer to get the update.
>
For what it's worth, here are
90% of the time it doesn't change, but your are right in the instances
it does, we should take care of it.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
I won't dispute what you said. You laid out what the right thing is to do. It
doesn't always get done unfortunately. It's one of those things I mean to
change soon. I include myself in that because often I too am a little low on
time. It takes a few seconds to update a package's version entity,
[This will be my last post on this subject. I've expressed an
opinion, not to disparage, but to encourage technical excellence.
I'll reiterate some points in this post and leave it at that.]
Jeremy Utley wrote these words on 02/20/05 19:37 CST:
> This, IMHO, is a highly optimistic view. For each
Randy McMurchy wrote:
What do you mean a bother? For almost all the packages in the
book that build in just a minute or two, it would take less
than 5 minutes to update the build entities, installed programs
and libraries in the book.
This, IMHO, is a highly optimistic view. For each upgrade,
Gerard Beekmans wrote these words on 02/20/05 18:34 CST:
> On February 20, 2005 03:17 pm, Randy McMurchy wrote:
>
>>Libol and syslog-ng don't have any program descriptions, lists,
>>diskspace used, dependencies or build times. Others that I don't
>>remember off-hand need fixing in these areas as w
On February 20, 2005 03:17 pm, Randy McMurchy wrote:
> Libol and syslog-ng don't have any program descriptions, lists,
> diskspace used, dependencies or build times. Others that I don't
> remember off-hand need fixing in these areas as well.
It's a common thing to happen. Packages are added or upg
Gerard Beekmans wrote these words on 02/20/05 16:04 CST:
> On February 20, 2005 02:53 pm, Randy McMurchy wrote:
>
>>The list of installed programs for the subject-labeled package is
>>not accurate for the version in SVN. This is just a heads-up in
>>case someone wants to update the book.
>
> What
On February 20, 2005 02:53 pm, Randy McMurchy wrote:
> The list of installed programs for the subject-labeled package is
> not accurate for the version in SVN. This is just a heads-up in
> case someone wants to update the book.
What's missing?
--
Gerard Beekmans
/* If Linux doesn't have the solu
The list of installed programs for the subject-labeled package is
not accurate for the version in SVN. This is just a heads-up in
case someone wants to update the book.
--
Randy
rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1]
[GNU C Library 2004-07-01 release version 2.3.4] [Lin
45 matches
Mail list logo
