Re: Man and Groff - Author Feedbacks - UTF-8 Comments

Jim Gifford wrote: (many thanks to Jim for contacting the authors) Here is a response from the Man maintainer on UTF-8 Federico Lucifredi wrote: Hello Jim, Man will not be UTF-8 problematic soon - the timeframe is march. So, hold on to your horses, we are working on it and it targeted to be

Re: Subversion Upgrade

Jeremy Huntwork wrote: > And the work begins now. Please consider all repositories as frozen > until further notice. And the work ends now. Subversion is up and the repositories are available and ready for commits. If you encounter any trouble please send a message to the server-admin list. Thank

Re: Subversion Upgrade

Jeremy Huntwork wrote: > Hello, > > The Subversion upgrade will be happening as planned this evening. It > will begin in approximately 2 hours 7:00pm EST (12:00am GMT). At that > time all the repositories will be offline. If this schedule doesn't work > for you, you have until then to notify me.

Subversion Upgrade

Hello, The Subversion upgrade will be happening as planned this evening. It will begin in approximately 2 hours 7:00pm EST (12:00am GMT). At that time all the repositories will be offline. If this schedule doesn't work for you, you have until then to notify me. Thanks. -- JH -- http://linuxfrom

Re: Man and Groff - Author Feedbacks - UTF-8 Comments

Jim Gifford wrote: [Man and groff UTF-8-ready by March, according to their respective maintainers.] > Both also expressed and interest for us > to assist in testing. Great! I'll try to help with some testing on LFS and LFS-like systems. I don't claim to know as much as e.g. Alexander about these t

Re: Perl security vulnerability

On 1/19/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > > It will only be for the stable book. I'll put the actual patch into LFS > trunk later tonight. Also, in case you haven't submitted a patch for the > website before, do it this way, please: > > svn co svn://svn.linuxfromscratch.org/www2/html

Re: Mozilla NSPR/NSS

On 1/19/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: > > Recently we had a discussion about using the Mozilla NSPR/NSS package > as a stand-alone package for BLFS. This would allow Firefox, Thunderbird > and the Mozilla suite to share the system-installed copies of these > libraries and interface

Re: Mozilla NSPR/NSS

On 1/19/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Hi all, > > Recently we had a discussion about using the Mozilla NSPR/NSS package > as a stand-alone package for BLFS. This would allow Firefox, Thunderbird > and the Mozilla suite to share the system-installed copies of these > libraries and

Re: Perl security vulnerability

Dan Nicholson wrote: On 1/19/06, Chris Staub <[EMAIL PROTECTED]> wrote: The patch is already in LFS patches and already used in HLFS. http://www.linuxfromscratch.org/patches/downloads/perl/perl-5.8.7-sprintf_vulnerability-1.patch Awesome. If no one else volunteers now, I'll write a patch t

Re: Perl security vulnerability

On 1/19/06, Chris Staub <[EMAIL PROTECTED]> wrote: > The patch is already in LFS patches and already used in HLFS. > > http://www.linuxfromscratch.org/patches/downloads/perl/perl-5.8.7-sprintf_vulnerability-1.patch Could one of the LFS editors add this to the SVN book? -- Dan -- http://linuxfroms

Re: Perl security vulnerability

On 1/19/06, Chris Staub <[EMAIL PROTECTED]> wrote: > The patch is already in LFS patches and already used in HLFS. > > http://www.linuxfromscratch.org/patches/downloads/perl/perl-5.8.7-sprintf_vulnerability-1.patch Awesome. If no one else volunteers now, I'll write a patch to the erratas tonight.

Mozilla NSPR/NSS

Hi all, Recently we had a discussion about using the Mozilla NSPR/NSS package as a stand-alone package for BLFS. This would allow Firefox, Thunderbird and the Mozilla suite to share the system-installed copies of these libraries and interface headers, as well as having them installed in /usr for a

Man and Groff - Author Feedbacks - UTF-8 Comments

Here is a response from the Man maintainer on UTF-8 Federico Lucifredi wrote: Hello Jim, Man will not be UTF-8 problematic soon - the timeframe is march. So, hold on to your horses, we are working on it and ittargeted to be in release 1.6d. Hoipe that will solve your problem -- entirely =)

Re: Perl security vulnerability

Dan Nicholson wrote: On 1/17/06, Tim van der Molen <[EMAIL PROTECTED]> wrote: A while ago I posted on lfs-security about a Perl security vulnerability and a patch that remedies it: I thought the patch should be added

Re: Perl security vulnerability

On 1/17/06, Tim van der Molen <[EMAIL PROTECTED]> wrote: > A while ago I posted on lfs-security about a Perl security vulnerability > and a patch that remedies it: > > > I thought the patch should be added to LFS SVN and

Re: lfs-security list

On 1/19/2006 13:04, Jeremy Huntwork wrote: > Back to topic, have any of you been monitoring the lfs-security list? I've found this list to pretty much always be low noise/high signal. Also various and useful patches appear from time to time. Well worth monitoring. :) ~Jason -- -- http://l

Re: RFC: Implementing Trac [long]

El Jueves, 19 de Enero de 2006 12:41, Jeremy Huntwork escribió: > In my experience only ViewCVS does it this way. Every other different > piece of software I've used shows the file right off. Anyway, I wonder > if there's a way to control this, and I can look into it... Actually I see more logica

Re: lfs-security list

Dan Nicholson wrote: Yeah, he just pinged lfs-dev the other day: http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055355.html BTW, this should definitely be added to the patches/errata/etc. Yeah, agreed. Thanks for the link Dan. I missed that one. -- JH -- http://linuxfromscratch

Re: lfs-security list

On 1/19/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > http://archives.linuxfromscratch.org/mail-archives/lfs-security/2006-January/001429.html > > If someone else brought this up already and I missed it, please ignore. Yeah, he just pinged lfs-dev the other day: http://linuxfromscratch.org/pip

lfs-security list

Hey Guys: I sent a post yesterday, but it seems to have vanished somewhere along the way. Anyway, if it shows up later, sorry in advance for the duplicity. Back to topic, have any of you been monitoring the lfs-security list? I've never bothered to subscribe, but looking at the archives, I se

Overcomplicated? [part 3: kbd, sysklogd]

Hello, there are claims that the current instructions are overly complicated. Below is the third part of the proof that they are in fact needed, but still insufficient for producing a system that works with both UTF-8 based and traditional locales with zero regressions, and anything else is o

Re: Xorg info was [Fwd: Re: Mesa Needs these fixes!]

DJ Lucas wrote: > Bruce Dubbs wrote: > >> >> The /usr/X11 is closer to the traditional location. It just 'feels' >> right to me, but that really isn't a good reason. I could go with /usr >> and optionally /usr/X11 though. >> > I don't see how /usr/X11 is any better than /usr/X11R7 in this case.

Overcomplicated? [part 2: ncurses -- diffutils]

Hello, there are claims that the current instructions are overly complicated. Below is the second part of the proof that they are in fact needed, but still insufficient for producing a system that works with both UTF-8 based and traditional locales with zero regressions, and anything else is

Overcomplicated? [part 1: glibc, coreutils]

Hello, there are claims that the current instructions are overly complicated. Below is the first part of the proof that they are in fact needed, but still insufficient for producing a system that works with both UTF-8 based and traditional locales with zero regressions, and anything else is o

Re: RFC: Implementing Trac [long]

On Wed, Jan 18, 2006 at 11:07:41PM -0600, DJ Lucas wrote: > Furthur, the default view in every webviewer of a repository that I've > seen is to show the revision history and I don't really see a good > reason for change. Not that it's such a problem, it is only one more > click, but it is just

Re: RFC: Implementing Trac [long]

On Wed, Jan 18, 2006 at 09:08:49PM -0700, Archaic wrote: > That implies that joe random shouldn't be able to file a bug. Do we want > this? I personally don't mind as I think people should take their issue > to -support or -dev before filing bogus bugs, but that may just be me. Sorry if this wasn'