<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.lfs.automated">
    <title>gmane.linux.lfs.automated</title>
    <link>http://blog.gmane.org/gmane.linux.lfs.automated</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7143"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7137"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7133"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7131"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7128"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7126"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7120"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7117"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7113"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7107"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7105"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7103"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7099"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7097"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7096"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7092"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7089"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7078"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7076"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.automated/7075"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7143">
    <title>jhalfs permission problem</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7143</link>
    <description>&lt;pre&gt;Hi

 

After going through LFS stable and LFS current development by the book, I
wanted to try jhalfs. But I'm stuck at the beginning with permission
problems.

I already posted this to LQ, but didn't get any replies.

 

I get the following shortly after fetching the book:

 

###

You are going to log into the user account lfs

sudo requires a password

.bashrc: line 8: /mnt/lfs/jhalfs/envars: Permission denied

make[1]: *** [mk_LUSER] Error 1

make[1]: Leaving directory `/mnt/lfs/jhalfs'

 

&amp;lt;jhalfs 2.3.2&amp;gt; exit

 

make: *** [all] Error 2

###

 

I did edit the sudoers file to include

 

###

[username]    ALL=(ALL) NOPASSWD: ALL

###

 

for the host and lfs users and I also added

 

###

alias su='sudo su'

###

 

To all the users' .profile, none of this helped. It does not matter if I use
jhalfs 2.3.2 or svn version.

 

I'm using a compliant host based on an up-to-date Debian.

 

Does anyone have an idea, where the problem lies?

 

Thanks in advance!

 

Cheers,

Oliver

&lt;/pre&gt;</description>
    <dc:creator>lich000king</dc:creator>
    <dc:date>2012-05-03T08:54:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7137">
    <title>jhalfs not deal with the Chapter 9 of lfs</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7137</link>
    <description>&lt;pre&gt;and the ownership of /etc/lfs-release is not root
&lt;/pre&gt;</description>
    <dc:creator>xinglp</dc:creator>
    <dc:date>2012-05-12T20:11:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7133">
    <title>Can I use jhalfs with an already exist "tools"?</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7133</link>
    <description>&lt;pre&gt;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.
&lt;/pre&gt;</description>
    <dc:creator>xinglp</dc:creator>
    <dc:date>2012-05-07T13:23:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7131">
    <title>host system requirements</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7131</link>
    <description>&lt;pre&gt;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




&lt;/pre&gt;</description>
    <dc:creator>Pierre Labastie</dc:creator>
    <dc:date>2012-03-28T11:56:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7128">
    <title>Should we strip all symbols in .so libraries when doing ICA?</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7128</link>
    <description>&lt;pre&gt;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
&lt;/pre&gt;</description>
    <dc:creator>Pierre Labastie</dc:creator>
    <dc:date>2012-03-17T12:58:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7126">
    <title>jhalfs lost a endef</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7126</link>
    <description>&lt;pre&gt;lost a endef
svn di svn://svn.linuxfromscratch.org/ALFS/jhalfs/trunk -r3602:3603
&lt;/pre&gt;</description>
    <dc:creator>xinglp</dc:creator>
    <dc:date>2012-03-15T10:27:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7120">
    <title>bug, but good...</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7120</link>
    <description>&lt;pre&gt;Hi,

In jhalfs, there is a supposed guard against the possibility of using
a partially or totally populated $LFS system, unless we ask to
rebuild the Makefile or to clean $LFS:
----------------
if [[ "$REBUILD_MAKEFILE" = "n" ]] ; then

   # If $BUILDDIR has subdirectories like tools/ or bin/, stop the run
   # and notify the user about that.
   if [ -d $BUILDDIR/tools -o -d $BUILDDIR/bin ] &amp;amp;&amp;amp; [ -z $CLEAN ] ; then
     eval "$no_empty_builddir"
   fi
---------------
However "no_empty_builddir" is a function (defined in 
common/common-functions),
so that this guard does nothing. Seems to date back r3087, when jhalfs 
was imported
from experimental.

Actually, I am happy that it does not work. It allows me to restart a 
build after
a failure, just at the point where it failed, after modifying something 
which is not
necessary just Makefile.

So I wanted to ask:
Do we correct the bug, or do we suppress the guard

Regards,
Pierre



&lt;/pre&gt;</description>
    <dc:creator>Pierre Labastie</dc:creator>
    <dc:date>2012-02-27T11:28:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7117">
    <title>jhalfs and the book xml</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7117</link>
    <description>&lt;pre&gt;I'm just moving this to a new thread.
On 25 February 2012 14:11, Pierre Labastie &amp;lt;pierre.labastie&amp;lt; at &amp;gt;neuf.fr&amp;gt; wrote:
Long text below covers that :o)
Git is like a database that contains the whole development history of
a project. You can tell git to go back to earlier commits of other
developers etc. because you've got all that in your local repository.
If the online copy gets lost you can use your local copy to restore
that repository up to the state where you did your last fetch. It does
not stay updated automatically though.
SVN (so I believe) just syncs your current directory with the
repository without pulling all that metadata.
In both cases you can:
svn co / git clone
to get the initial download
svn up /git remote fetch
to bring your data up to date.
if you can ignore all the metadata, don't modify in the directory you
work on, the result is effectively the same.
My point is in reference to the SVN feature in jhalfs. Most people
want the snapshot of the data, they don't plan to do development work.
If yo&lt;/pre&gt;</description>
    <dc:creator>Peter Palmer</dc:creator>
    <dc:date>2012-02-25T18:54:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7113">
    <title>Automated BLFS tool</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7113</link>
    <description>&lt;pre&gt;Hi,

Many more tests are needed, but I think the new
BLFS tools are usable (alpha state). The repo is ablfs
(automated blfs). Just type:

svn co svn://svn.linuxfromscratch.org/ALFS/jhalfs/branches/ablfs

The instructions are in README and README.BLFS. Please
let me know if anything is confusing (well, I expect to receive
a lot of messages;-) .

I have been able to build X (not tried to run it yet), but you need to
apply the attached patch to the blfs book. (ticket #3282). There
are also some options change to mesalib configure to avoid
trying to build the nouveau driver (or add it to libdrm).
Also llvm needs a 'source /etc/bash_profile' at the end.
AFAICT, all those come from book defects (or features :-) )
rather than from the tool. Note that there are no meta
packages, as in the former version of the tools. Just tick
Xorg Server, and it builds all the required dependencies.

Built also subversion, openssl, python. Please have a try for
other packages.
Contrary to the former tools, you can select as many ta&lt;/pre&gt;</description>
    <dc:creator>Pierre Labastie</dc:creator>
    <dc:date>2012-02-24T17:21:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7107">
    <title>SBU report</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7107</link>
    <description>&lt;pre&gt;Hi,

here a tiny fist patch (from myself) to fix the SBU report that wasn't
running (current jhalfs svn and CLFS-1.2). I'm new to lfs/jhalfs
development so I hope the format and everything is right and usable.

Schedule of changes:

1. Variables needed initailising as perl was tipping over trying to
substract without that, i.e.:
INSTALLMB=`perl -e 'printf "%.3f" , ('$DU1MB' - '$DU1MBPREV')';`

2. The other change affects the selection of the very first entry of
the $LOGS directory. In CLFS this was a script that run in fractions
of a second... SBU is supposed to be based on the compilation time of
binutils though.

Any feedback appreciated.

Cheers,

Peter


#################################################
diff --git a/common/create-sbu_du-report.sh b/common/create-sbu_du-report.sh
index 115d95d..24ed5a6 100755
--- a/common/create-sbu_du-report.sh
+++ b/common/create-sbu_du-report.sh
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -5,7 +5,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; set -e

 LOGSDIR=$1
 VERSION=$2
-
+DU1PREV=0
+DU1MBPREV=0
 LINE="============================================&lt;/pre&gt;</description>
    <dc:creator>Peter Palmer</dc:creator>
    <dc:date>2012-02-23T22:19:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7105">
    <title>Branching for new BLFS tool</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7105</link>
    <description>&lt;pre&gt;Hi,

I have a new BLFS tool for jhalfs almost ready.
As already advertised, it seems to deal very well
with circular dependencies (with user input: your
distro, your rules...). Needs
just a few more tests for initialization. Of course it is
in alpha state! Almost all modifications are within BLFS
directory, but I have to slightly modify a few other
files in jhalfs tree, which I do not want to do on trunk.
So I propose to create a branch for some time, so
that adventurous people can test the new tool,
without modifying the usual behavior of trunk jhalfs.

Any thought?

Pierre




&lt;/pre&gt;</description>
    <dc:creator>Pierre Labastie</dc:creator>
    <dc:date>2012-02-22T12:58:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7103">
    <title>patch for downloading LFS tags version &gt;6.x</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7103</link>
    <description>&lt;pre&gt;Hi
Here is what I propose. I'll commit tomorrow if no
comment.
Regards,
Pierre

&lt;/pre&gt;</description>
    <dc:creator>Pierre Labastie</dc:creator>
    <dc:date>2012-02-21T08:10:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7099">
    <title>About subversion properties</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7099</link>
    <description>&lt;pre&gt;Well,
I just added the subversion property 'svn:keywords Id' to a few
files, some of which have been there much before I became
involved in jhalfs (in 'custom' dir). The result is that my name
appears as the Id, which was not the purpose. I guess Manuel
and/or George wrote them, and that their names should appear
instead. I suggest to add a line in the comments:
# Written by Manuel Esparcia and George Boudreau.
But maybe somebody has a better idea.

Regards
Pierre
&lt;/pre&gt;</description>
    <dc:creator>Pierre Labastie</dc:creator>
    <dc:date>2012-02-19T11:20:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7097">
    <title>RFC: Is there a use for blfs-tool?</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7097</link>
    <description>&lt;pre&gt;Hi,

When configuring jhalfs, the user is given the possibility
of choosing "Beyond Linux From Scratch" in the
"Use BOOK" menu. That basically disables all the settings you
have when running jhalfs, except the choice of
the Release and of a few directories needed for
blfs-tools. Then `blfs-tool' is run instead of
`jhalfs'. Basically, `blfs-tool' performs a few
checks, and sets up a "blfs_root" directory in
users's $HOME. It then launches make in that
directory.
All the preceding supposes that LFS is already
installed (with the BLFS dependencies, DocBook,
Lynx and friends). It does not much more than
what jhalfs does when ticking "Add blfs-tool support".
The only part which is missing after jhalfs is
moving "blfs_root" to user's $HOME, which is
not mandatory actually.
Furthermore, choosing blindly "Beyond Linux From Scratch" in the
"Use BOOK" menu on a non LFS system is potentially harmfull,
since you might end up installing BLFS packages on your
host system!
So my proposition is to remove altogether the
"Bey&lt;/pre&gt;</description>
    <dc:creator>Pierre Labastie</dc:creator>
    <dc:date>2012-02-18T11:41:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7096">
    <title>patch for avoiding warnings</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7096</link>
    <description>&lt;pre&gt;Following discussion on lfs-dev, here
is a patch which avoids most of the warnings in 000masterscript.log
There are still the last two warnings about packageManager.xml.
Maybe copy a dummy packageManager.xml to $JHALFSDIR when
not using package management.

Regards
Pierre


&lt;/pre&gt;</description>
    <dc:creator>Pierre Labastie</dc:creator>
    <dc:date>2012-02-17T22:39:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7092">
    <title>jhalfs's error log</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7092</link>
    <description>&lt;pre&gt;This is the log produced by jhalfs, some errors in it, but it worked
well when build lfs.
&lt;/pre&gt;</description>
    <dc:creator>xinglp</dc:creator>
    <dc:date>2012-02-17T06:37:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7089">
    <title>RFC: Remove GETKERNEL parameter</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7089</link>
    <description>&lt;pre&gt;Hi all,

The kernel package has been required since LFS-6.3.  LFS-6.2 was
released 5.5 years ago, which was the last release when the kernel
package wasn't required until chapter 8.  As such, the attached patch
removes the ability to choose whether or not to download the kernel
package.

Regards,

Matt.
&lt;/pre&gt;</description>
    <dc:creator>Matt Burgess</dc:creator>
    <dc:date>2012-02-10T20:42:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7078">
    <title>Catching GMP test failures</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7078</link>
    <description>&lt;pre&gt;Hi,

Currently, jhalfs copies the exact command for invoking GMP's tests:

make check 2&amp;gt;&amp;amp;1 | tee gmp-check-log &amp;gt;&amp;gt; $TEST_LOG 2&amp;gt;&amp;amp;1

The problem with this is that the exit status of 'make check' is lost;
the exit status of 'tee' is what will cause the script to fail or not,
and that's pretty much never going to fail to run.

The attached patch changes the command to:

make check 2&amp;gt;&amp;amp;1 | tee gmp-check-log &amp;gt;&amp;gt; $TEST_LOG 2&amp;gt;&amp;amp;1 &amp;amp;&amp;amp; exit
$PIPESTATUS

I'm doing a full build now to test it, but it at least generates what I
think is the correct command line.

Regards,

Matt.
&lt;/pre&gt;</description>
    <dc:creator>Matt Burgess</dc:creator>
    <dc:date>2012-02-09T20:16:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7076">
    <title>JHALFS</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7076</link>
    <description>&lt;pre&gt;Hi guys,

It has been a while but it is nice to see the old JHALFS still has some 
users.

Nice work Pierre. The code is pretty convoluted for bash and even I 
would get lost on occasion and I wrote it --along with Manuel Esparcia--.

George Boudreau
&lt;/pre&gt;</description>
    <dc:creator>George Boudreau</dc:creator>
    <dc:date>2012-02-09T17:47:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7075">
    <title>Changing the logic of 'rebuild files'</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7075</link>
    <description>&lt;pre&gt;Hi,

When you tick 'rebuild files' and the build dir is empty, jhalfs exits
with an error. In the attached patch, I modify this logic.
The behavior remains the same if the directory is not empty.
When it is empty (or just contains "lost+found"),
the clean stage is skipped.

The patch contains also some cosmetic and corrects a typo.

Regards,
Pierre

&lt;/pre&gt;</description>
    <dc:creator>Pierre Labastie</dc:creator>
    <dc:date>2012-02-09T17:04:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.automated/7074">
    <title>patch for avoiding warnings when building mconf</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.automated/7074</link>
    <description>&lt;pre&gt;Hi,

Here is a patch, which modifies the code for the menu of jhalfs,
and avoids warnings when compiling.

Tested (no big changes, and actually cleaner code, I think).

Regards,
Pierre

&lt;/pre&gt;</description>
    <dc:creator>Pierre Labastie</dc:creator>
    <dc:date>2012-02-09T16:22:19</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.lfs.automated">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.lfs.automated</link>
  </textinput>
</rdf:RDF>

