Red Hat Linux Arabic Localization Project
by Sherif Abdelgawad
With the help of Linux-ME.org (Linux Middle East), Linux-Egypt.org (LUG),
and ITI (Information Technology Institute)in Egypt (http://www.iti.gov.eg ),
a project for providing Arabic Support to RHL.
The aim of this project is to collect the efforts and contribute in RHL
to solve the issues and problems wrt full arabic support in RHL (right-to-left,
fotns, rendering ...etc).
An initial page for the project, with call for participation is located at:
http://www.linux-me.org/
This effort also includes proper translation, validate the already translation
efforts and provide standard good translation as well as put the efforts to
solve the technical issues wrt to Arabic.
Cheers,
-Sherif
20 years, 1 month
Including new OT Fonts
by Jamil Ahmed
Hi,
May I know who is in charge of Font management of RH linux? We
[http://www.bengalinux.org/] are working for Bengali/Bangla translation. We
have already submitted a request to include Bangla OTF thru bugzilla. But I
think, that request is not closed yet.
We are hoping that Bangla language will be included in the next release
of RH distro. Please let me know asap what should we do? Cause there is not
enough time.
BTW, we have already submited translated versions of the required
packages in i18n's cvs server.
Thanks,
`Jamil
20 years, 1 month
getting new driver into kernel, boot.iso
by David Kewley
Hi all,
I support a couple of machines with an Asus P4P800 motherboard. I
anticipate building more machines with this board, and want it to be
well-supported by Red Hat Linux in the future. The main problem I've run
into so far is the on-board network interface. This board (and its sister
the P4C800) have a 3Com 3C940 Gigabit ethernet chip onboard, which I want
to use both to do a network kickstart and for normal operation, but there
are no drivers for this chip in the RH kernels.
If you go to the Asus website, they give you a driver to download, which
appears to be a 3Com-hacked version of an old sk98lin driver from
SysConnect. (It appears that the logic on the 3C940 is licensed from
SysConnect.) The sk98lin in the kernel.org kernel, and in the RH kernel,
do not support the 3C940. However, SysKonnect has since provided newer
versions of sk98lin on their website which do support the 3C940:
http://www.syskonnect.com/syskonnect/support/driver/htm/sk98lin.htm
SysKonnect offers a patch for 2.4.21, 2.2.25, and 2.6.0. They also offer an
install package that has a script that attempts to produce sk98lin.o for
your currently-installed kernel. None of these seem appropriate for my
needs (using the latest RHL 9 kernel), although I'm willing to hear
suggestions.
There is a RH Bugzilla bug regarding related issues:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89680
I want to see the latest sk98lin integrated into the Red Hat kernel (for RHL
9, and for the beta or the next release). I'm willing to do work on this
myself. Once I have something that works to my satisfaction, I'll offer it
on my website for others to use. I'll also offer my work to RH, if they're
interested.
My goal is to integrate the latest sk98lin in a way that adheres to RH's
practices and which promotes maintainability and portability to future
kernel releases (until the latest sk98lin gets officially incorporated).
But I need some guidance to arrive at this destination.
I've already made a boot.iso which I can use to kickstart the P4P800. But I
made it in an ugly, unmaintainable way (by hacking the initrd). I think
I've figured out something close to the proper way to do it, but I have
questions.
It appears that what I want to do is to make a patch that can be
incorporated into the kernel src.rpm. Then BOOT, i386, i686, athlon etc.
kernels can be made from this. I have a few questions about how to produce
this patch.
First of all, it appears that I need to pick an appropriate patch serial
number for the specfile. What should I use?
Second, if my patch is applied midway through the patching process, I need
to be careful how I produce the patch, so as not to interfere with later
patches. How do I do this?
Third, I expect that I'll have to pick a custom build string until and
unless RH accepts my patch or builds their own. I suppose if I start with
e.g. kernel-2.4.20-18.9, I could make mine by kernel-2.4.20-18.9.dk.1. Is
that appropriate?
Once I have a patch that applies cleanly, I expect a rebuild of the kernel
packages from the kernel src.rpm will result in all desired kernel
packages, including a BOOT kernel to put on the boot.iso. This leaves one
more question, however: How is the initrd for the boot.iso produced? It
looks like you have to specify each and every driver in the BOOT kernel to
mkinitrd, but I'm not sure that's correct. Surely someone at RH knows
exactly how to do this; I can't find it in the distrubution or on the web,
however.
Thanks very much for any help,
David
20 years, 1 month
FSDB
by Florin Andrei
"Hewlett-Packard, IBM, RSA Security, InstallShield Software, and Sun
Microsystems are also involved in the File Signature Database (FSDB)
effort. The repository will store metadata about individual files
created by each of the vendors, such as the file's name, a ‘born-on’
date and its digital hash values."
http://www.techworld.com/news/index.cfm?fuseaction=displaynews&NewsID=349
Any plans to do that with Red Hat as well?
--
Florin Andrei
"Never send a human to do a machine's job." - Agent Smith
20 years, 1 month
USB storage hotplug code.
by Konstantin Ryabitsev
Hey, all:
I thought I'd share this little bit of code that I've written to handle
usb-pen/thumbdrive devices that seem to be pretty popular these days
(certainly beats floppies). It is pretty simplistic and will work in 99%
of cases, by my estimates.
Benefits:
1. Automatically create /dev/diskonkey pointing to the correct device.
2. Automatically create /mnt/diskonkey if missing.
3. Automatically add fstab entries if missing.
4. Automatically set ownership to the console user (if anyone is logged
in -- if not, then the ownership will be set by the /mnt/diskonkey* rule
in /etc/security/console.perms).
Drawbacks:
1. Currently only supports one thumbdrive device at a time, though
support for more should be easy to add (I only have one to play with.
:)).
2. No way to tell nautilus to re-read /etc/fstab to add diskonkey to the
list of mountable devices in rightclick->disks (they claim it's fixed in
the newer version of nautilus, but that doesn't help. Currently sending
killall -$(anysignal) nautilus will kill it, though theoretically a -HUP
should tell it to reread the config). A workaround -- tell your users to
plug in the device before they log in.
3. If partition info changes on the device, then things go screwey, as
devlabel gets confused (e.g. someone deletes /dev/sda1 and decides to
use the entire /dev/sda device instead). This rarely, if ever, happens.
4. This hasn't been overly extensively tested.
Installation instructions are in the file itself. I would love to hear
any feedback on this.
Regards,
--
Konstantin ("Icon") Riabitsev
Duke Physics Sysadmin, RHCE
20 years, 1 month
acpi confusion
by seth vidal
Hi all,
So I have an ibm x23 laptop. nothing terribly fancy. With severn I
noticed that the sound played far too slowly. Meaning - when I played an
ogg it sounded like it was being played at the wrong speed if it were a
record.
So I filed a bug about it b/c the sound worked under rhl 9 just fine.
The suggestion was to disable acpi and see if that fixed it.
it did. the sound works as expected now. However, the laptop runs a lot
hotter than it used to.
So I was wondering if someone could explain the acpi stuff in more
details. It was proposed to me by someone on #rhl-devel that maybe
someone here could give an uncensored summary of the acpi stuff in the
kernel and it's relative stability level, etc.
Thanks
-sv
20 years, 1 month
GNOME 2.4 in Cambridge
by Jonathan Blandford
After a bit of discussion, we[1] agreed that it makes sense to try to
put GNOME 2.4 in Cambridge. Given the stability of the 2.3.x releases
it seems to be a minimally risky proposition. Additionally, GNOME
appears to be right on schedule. We may have to push out the Cambridge
release date a little, but it's looking very good in general. Alex and
I will be rebuilding and upgrading the packages in rawhide over the next
week or so.
Thanks,
-Jonathan
[1] Those of us on the desktop team, anyway.
20 years, 1 month
acpi confusion, redux
by seth vidal
So if the release notes are accurate then acpi is only on for device
enumeration, hence my problems. That must mean that the heat was either
1. coincidental
2. all in my head
3. something very bizarre.
does anyone else have an Xseries ibm laptop and would like to confirm
this?
Thanks
-sv
20 years, 1 month
Automated Testing
by Paul Nasrat
I was just wondering if anyone does any automated testing/continuous
integration with package trees and wondered what system setup you use.
Theoretically you could pull rawhide, cvs ( cvsup for jbj ) and kick off
package builds and run some tests. I'm considering writing some
integration tests for one of the projects I work on, and thought I'd see
what other people do before re-inventing the wheel.
Cheers
Paul
20 years, 1 month
Gigabyte 8KNXP Mobo and Severn
by Dave Bevan
Hi,
My rig is working fine - above mobo + Nvidia Quadro FX1000 + P4
3.2+HT/800fsb, but I found this when checking thru dmesg:
[root@togdev1 log]# egrep -i "nvidia|agp" dmesg
1: nvidia: loading NVIDIA Linux x86 nvidia.o Kernel Module 1.0-4496 Wed
Jul 16 19:03:09 PDT 2003
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 941M
agpgart: Unsupported Intel chipset (device id: 2578), you might want to try
agp_try_unsupported=1.
agpgart: no supported devices found.
0: NVRM: AGPGART: unable to retrieve symbol table
[root@togdev1 log]#
I'm using the NVIDIA module, not AGPGART, so the 'Unsupported Intel chipset'
does not bother me, but it might be an issue for someone else.
If reqd, I can supply full dmesg, /proc/pci etc, etc.
-- Dave. BBC TV News,, London, UK.
BBCi at http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system, do
not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received. Further communication will
signify your consent to this.
20 years, 1 month
