Alexander E. Patrakov wrote:
Jim Gifford wrote:
3) Patch glibc to fix the issue triggered by openSSH
Still doesn't work all archictectures, some people are thinking it's
a issue in ssh itself.
It is not an issue in the ssh itself. Testcase:
gcc -o test -ldl test.c
rm -rf /tmp/foobar;
Greg Schafer wrote:
Yes. This whole problem adds even more weight to the theory that labeling
LFS "releases" with version numbers is not a good idea.
I supported this theory until the errata page appeared. My basis was:
frozen releases without future bugfixes are not "stable releases", but
j
Jim Gifford wrote:
3) Patch glibc to fix the issue triggered by openSSH
Still doesn't work all archictectures, some people are thinking it's a
issue in ssh itself.
It is not an issue in the ssh itself. Testcase:
gcc -o test -ldl test.c
rm -rf /tmp/foobar; mkdir /tmp/foobar
./test
where te
Jeremy Huntwork wrote:
Matthew Burgess wrote:
If we do release a 6.1.1, I think the approach we should adopt is:
1) Apply security patches to texinfo, util-linux, bzip2 and vim.
Needed.
2) Upgrade perl and zlib to fix their respective security
vulnerabilities
Needed
3) Patch glibc t
Alexander E. Patrakov wrote:
> This is from the current development LFS LiveCD, not FC4, but I assume
> the problem is the same:
> ../../binutils-2.15.94.0.2.2/gas/config/tc-i386.h:443: error: array type
> has incomplete element type
> make[3]: *** [app.o] Error 1
Ok, thanks for clarifying.
Matthew Burgess wrote:
> 1) Apply security patches to texinfo, util-linux, bzip2 and vim.
> 2) Upgrade perl and zlib to fix their respective security vulnerabilities
> 3) Patch glibc to fix the issue triggered by openSSH
> 4) Do something with the udev configuration vs. /etc/group conflict
> repor
Matthew Burgess wrote:
If we do release a 6.1.1, I think the approach we should adopt is:
1) Apply security patches to texinfo, util-linux, bzip2 and vim.
2) Upgrade perl and zlib to fix their respective security vulnerabilities
3) Patch glibc to fix the issue triggered by openSSH
4) Do somethi
Frans Verstegen wrote:
In the silo installation the compile instruction is as follows:
make CROSS_COMPILE="sparc64-unknown-linux-gnu-"
Couldn't/shouldn't this be written as :
make CROSS_COMPILE=${LFS_TARGET}-
as for the kernel ?
You're probably right, however, I don't think it matters too
In the silo installation the compile instruction is as follows:
make CROSS_COMPILE="sparc64-unknown-linux-gnu-"
Couldn't/shouldn't this be written as :
make CROSS_COMPILE=${LFS_TARGET}-
as for the kernel ?
Frans
Greg Schafer wrote:
Alexander E. Patrakov wrote:
5) Blacklist Fedora Core 4 since it can't build binutils.
Huh? Stable or development LFS?
Stable, i.e. 6.1
> Could you please supply details of the problem?
This is from the current development LFS LiveCD, not FC4, but I assume
the probl
Alexander E. Patrakov wrote:
> 5) Blacklist Fedora Core 4 since it can't build binutils.
Huh? Stable or development LFS? Could you please supply details of the
problem? Does passing --disable-werror help? Or maybe we just need to add
the required GCC4 patches to the Binutils version used in stabl
11 matches
Mail list logo
