Dan Nicholson wrote:
LDAP, so much fun. I don't know if these will help, but they probably
have nicer interfaces. One for GNOME, one for KDE. I used the KDE one
briefly and it seemed to work. I've been meaning to install the GNOME
one for a while.
http://dev.mmgsecurity.com/projects/lat/
http:/
On 8/30/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
8) I am very busy now with the classroom. Instead of writing this mail,
I should have spent my time writing a simpler replacement for LDAP
Account Manager that would eliminate errors that account operators make
in 75% of cases, despite
Matthew Burgess wrote:
Alexander, do you have time to submit this upstream and track its
progress? The header says that it "Adjusts installation of manual
pages to meet Man-DB expectations.". I assume it mentions "Man-DB"
specficially, simply because that's our implementation of `man' at th
Alexander E. Patrakov wrote:
>
> Matthew Burgess wrote:
>
Vim Mandir Adjusts location of man pages to meet man-db's
expectations Not submitted, N/A LFS-specific, apparently. I
think the first hunk should go upstream, as it fixes non-compliance with
the FHS. Other than that, maybe we
Ag. Hatzimanikas wrote:
One less patch to worry.
Alexander's vim-7.0-spellfile-1.patch was accepted by Bram (patch 7.0.076).
Thanks, Ag. I've just added vim-7.0-fixes-11.patch to the repository.
When I get a minute or two, I'll update the book to use this instead of
the spellfile patch.
R
On Sun, Aug 06, at 10:16 Matthew Burgess wrote:
One less patch to worry.
Alexander's vim-7.0-spellfile-1.patch was accepted by Bram (patch 7.0.076).
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Matthew Burgess wrote:
Why is a configuration file needed at all? Is this because, IIUC,
man-pages don't store their character encodings anywhere, therefore we
need to tell groff and man what encodings we need to translate between?
Partially correct. Also, one condition that is imposed on the
Alexander E. Patrakov wrote:
Or, better, drop the UTF-8 support completely from LFS. It is
unmaintainable, and in fact not ready in "vanilla upstream". This also
means dropping Nautilus CD Burner from BLFS.
I realise that was in markers, but still, I have to disagree.
Part of my motivation
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
My patch is already in -mm.
And now it is not.
:-( Any ideas why, and how are you tracking its -mm status?
There are automated notifications sent to patch authors. Basically, Alan
Cox wanted me to write a proper solution, i.e. to reqri
Alexander E. Patrakov wrote:
My patch is already in -mm.
And now it is not.
:-( Any ideas why, and how are you tracking its -mm status?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
I wrote:
Alexander E. Patrakov wrote:
Linux UTF-8 Input - Fixes dead keys and copy/paste of non-ASCII
characters in UTF-8 mode on Linux console - Rejected upstream because
it changes the meaning of an existing ioctl - Drop the patch and
replace it with one that looks more likely to be accepted
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
Matthew Burgess wrote:
Coreutils Internationalization Fixes - Fixes various bugs with
multibyte character support
>>
No, no action required. Such big patches should be treated as
"switching to a fork", not as regular patches. Coreutils up
Alexander E. Patrakov wrote:
Linux UTF-8 Input - Fixes dead keys and copy/paste of non-ASCII
characters in UTF-8 mode on Linux console - Rejected upstream because it
changes the meaning of an existing ioctl - Drop the patch and replace it
with one that looks more likely to be accepted upstream.
On 8/6/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
Hi folks.
A recent article on lwn.net discussing LFS
(http://lwn.net/Articles/192904/) attracted the following comment:
"...it's worrying the number of little patches that the LFS instructions
say need applying to the upstream source: why ar
Alexander E. Patrakov wrote:
Matt wrote:
Texinfo Multibyte
A non-hackish solution requires full rewrite of character handling.
Way beyond my abilities. Will submit a bug report, though.
Thanks.
Vim Mandir
This is not LFS-specific. No known version of any Man-like program
searches in the
Alexander E. Patrakov wrote:
Matthew Burgess wrote:
Coreutils Internationalization Fixes - Fixes various bugs with multibyte
character support
>>
No, no action required. Such big patches should be treated as "switching
to a fork", not as regular patches. Coreutils upstream is already aware
I wrote:
Kbd Backspace - Makes Backspace and Delete keys consistent in all i386
keymaps - Not submitted because it's possibly incomplete - Submit
upstream. Complete or otherwise, it's better than nothing and I don't
think we've had any reports of broken keymaps for a while as the patch
hasn't
Matthew Burgess wrote:
http://www.linuxfromscratch.org/~matthew/lfs-patch-status.html.
That page says:
Linux UTF-8 Input - Drop the patch and replace it with one that looks
more likely to be accepted upstream
with the pointer to
http://www.ussg.iu.edu/hypermail/linux/kernel/0608.0/1362.ht
On 8/6/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
Matthew Burgess wrote these words on 08/06/06 16:16 CST:
> A recent article on lwn.net discussing LFS
> (http://lwn.net/Articles/192904/) attracted the following comment:
I'd like to see what they say about Redhat Fedora. They use patches
on
Matthew Burgess wrote these words on 08/06/06 16:16 CST:
> A recent article on lwn.net discussing LFS
> (http://lwn.net/Articles/192904/) attracted the following comment:
>
> "...it's worrying the number of little patches that the LFS instructions
> say need applying to the upstream source: why
Matthew Burgess wrote:
Hi folks.
A recent article on lwn.net discussing LFS
(http://lwn.net/Articles/192904/) attracted the following comment:
"...it's worrying the number of little patches that the LFS
instructions say need applying to the upstream source: why aren't they
included upstream
On Κυρ, Αύγ 06, at 10:16 Matthew Burgess wrote:
Excellent job Matthew and a very good idea.
I believe we all agree with your point,that 17 patches are very high number
for the LFS standards.
By the way,and with this chance.
I believe the LFS projects needs a man (or perhaps better: A very small
Hi folks.
A recent article on lwn.net discussing LFS
(http://lwn.net/Articles/192904/) attracted the following comment:
"...it's worrying the number of little patches that the LFS instructions
say need applying to the upstream source: why aren't they included
upstream already?"
As a result
23 matches
Mail list logo
