El Viernes, 14 de Octubre de 2005 22:56, Matthew Burgess escribió:
> Yeah, I hit the missing patches.ent file today too. As it's a fairly
> safe change to do (`make validate' and the rendering process that copies
> the patches will catch any inadvertent errors) feel free to backport
> patches.e
Ken Moffat wrote:
On Sun, 9 Oct 2005, Matthew Burgess wrote:
4) Do something with the udev configuration vs. /etc/group conflict
reported in bug 1639.
How about the udev version ? Should we stick with 056 or upgrade it to
070 ? (I seem to remember that something newer than 056 was needed
Matthew Burgess wrote:
> Ken Moffat wrote:
>
>> On Sun, 9 Oct 2005, Matthew Burgess wrote:
>>
>>> 4) Do something with the udev configuration vs. /etc/group conflict
>>> reported in bug 1639.
>>
>>
>> How about the udev version ? Should we stick with 056 or upgrade it
>> to 070 ? (I seem to rem
M.Canales.es wrote:
I was thinking to add jhalfs support for 6.1.1, but noticed that there is no
patches.ent file on that branch.
If jhalfs support is wanted and such type of change is allowed on this
bug-fixes release, I could do the needed edits this weekend.
Yeah, I hit the missing patch
El Viernes, 7 de Octubre de 2005 00:42, Jeremy Huntwork escribió:
> I've heard no recent talk of cutting a testing branch from trunk in
> preparation of a release, and in the meantime, I think we owe it to our
> readers to supply a stable LFS with all these known items fixed.
I was thinking to ad
On Fri, 14 Oct 2005, Matthew Burgess wrote:
Ken Moffat wrote:
On Sun, 9 Oct 2005, Matthew Burgess wrote:
4) Do something with the udev configuration vs. /etc/group conflict
reported in bug 1639.
How about the udev version ? Should we stick with 056 or upgrade it to
070 ? (I seem to reme
Ken Moffat wrote:
On Sun, 9 Oct 2005, Matthew Burgess wrote:
4) Do something with the udev configuration vs. /etc/group conflict
reported in bug 1639.
How about the udev version ? Should we stick with 056 or upgrade it to
070 ? (I seem to remember that something newer than 056 was needed
On Sun, 9 Oct 2005, Matthew Burgess wrote:
4) Do something with the udev configuration vs. /etc/group conflict reported
in bug 1639.
How about the udev version ? Should we stick with 056 or upgrade it to
070 ? (I seem to remember that something newer than 056 was needed for
newer kernels
Ken Moffat wrote:
On Fri, 14 Oct 2005, Jeremy Huntwork wrote:
This one applied fine with an offset, built correctly and is running
smoothly. Openssh-4.2p1 also built on the same system and running well.
In that case, I'd rather go with yours (I think there is a possibility
that my rejec
On Fri, 14 Oct 2005, Jeremy Huntwork wrote:
This one applied fine with an offset, built correctly and is running
smoothly. Openssh-4.2p1 also built on the same system and running well.
In that case, I'd rather go with yours (I think there is a possibility
that my rejection was caused by
Ken Moffat wrote:
Dug out the patch from the libc-hacker archives, but I had to apply it
by hand, I think the line numbers changed a bit too much for patch to
figure it out. Can you confirm this is what you want put in, and can I
stick your name in the 'submitted by' ? I was thinking of cal
On Tue, 11 Oct 2005, Alexander E. Patrakov wrote:
It is not an issue in the ssh itself. Testcase:
gcc -o test -ldl test.c
rm -rf /tmp/foobar; mkdir /tmp/foobar
./test
Dug out the patch from the libc-hacker archives, but I had to apply it
by hand, I think the line numbers changed a bit too m
Jeremy Huntwork wrote:
I would like to make a formal request for a 6.1.1 release of the LFS
Book.
Agreed, let's do this. I'd imagine it'll only need a couple of weeks at
most. I've created the branch (checkout from
svn[+ssh]://linuxfromscratch.org/LFS/branches/6.1.1). I'll be pretty
busy
Jim Gifford wrote:
The test case does not give any errors. at all. In cross-lfs we use the
glibc-snapshot from 20050926, which this problem has been fixed.
You are right, the dlopen-in-chroot problem shouldn't exist in that
snapshot. Do I understand correctly that you meant "there is also som
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
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
Alexander E. Patrakov 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.
2) Upgrade perl and zlib to fix their respective security vulnerabilities
3) Patch glibc to fix the issue trig
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 somethin
Jeremy Huntwork wrote:
I would like to make a formal request for a 6.1.1 release of the LFS
Book.
The glibc/openSSH issue is the only real candidate that would warrant a
6.1.1 release, IMO. The fact that some of our packages contain security
vulnerabilities is nothing new, can't be helped,
Jeremy Huntwork wrote:
Ken Moffat wrote:
I haven't been paying a lot of attention to this thread, but I
thought somebody mentioned a glibc upgrade to 2.3.5 ? Now, that
version worked fine for me (but then, so did 2.3.4, and even openssh
on x86), but I don't think it's been tested in the con
Ken Moffat wrote:
I haven't been paying a lot of attention to this thread, but I thought
somebody mentioned a glibc upgrade to 2.3.5 ? Now, that version worked
fine for me (but then, so did 2.3.4, and even openssh on x86), but I
don't think it's been tested in the context of BLFS-stable ? S
On Sat, 8 Oct 2005, Jeremy Huntwork wrote:
I hadn't meant cut a branch from trunk and call it 'stable' - that would
require a lot more testing. I meant take the current 'stable' book and do
whatever minimally needs to be done to fix each bug and re-release. It really
would be a 6.1.1 in that
Joe Ciccone wrote:
Jeremy Huntwork wrote:
I've heard no recent talk of cutting a testing branch from trunk in
preparation of a release, and in the meantime, I think we owe it to
our readers to supply a stable LFS with all these known items fixed.
I have personaly stopped building stable be
Jeremy Huntwork wrote:
I've heard no recent talk of cutting a testing branch from trunk in
preparation of a release, and in the meantime, I think we owe it to
our readers to supply a stable LFS with all these known items fixed.
I have personaly stopped building stable because stable isn't st
[EMAIL PROTECTED] wrote:
> Hi All,
>
> I would like to make a formal request for a 6.1.1 release of the LFS
> Book.
>
> Comments?
>
> --
> JH
Yeah, for sure I'm with that. :)
Dave
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsub
Jeremy Huntwork wrote:
Hi All,
I would like to make a formal request for a 6.1.1 release of the LFS
Book. After today's discussion concerning the bug pointed to by
Alexander, http://blfs-bugs.linuxfromscratch.org/show_bug.cgi?id=1534,
and after looking at the several known security vulnerib
Jeremy Huntwork wrote:
Hi All,
I would like to make a formal request for a 6.1.1 release of the LFS
Book. After today's discussion concerning the bug pointed to by
Alexander, http://blfs-bugs.linuxfromscratch.org/show_bug.cgi?id=1534,
and after looking at the several known security vulnerib
Hi All,
I would like to make a formal request for a 6.1.1 release of the LFS
Book. After today's discussion concerning the bug pointed to by
Alexander, http://blfs-bugs.linuxfromscratch.org/show_bug.cgi?id=1534,
and after looking at the several known security vulneribilities in the
6.1 book
35 matches
Mail list logo
