Opteron / AGP
by Dave Bevan
Hi,
I guess this should partly be aimed at Dave Jones (ex. Suse, now Red Hat)
who has maintained AGPGART.
Is support for the AMD AGP Chipset - 8151 complete ? I was reading some
stuff that suggested that on a 'full' dual-Opteron rig (with AMD's AGP 8151,
PCI-X 8131 and IO 8111 controllers all in place), the AGP bus would not
always show up as PCI Device 0.
Any thoughts ?
Rgds,
-- 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, 8 months
RFE: Other "Everything" installs
by Dax Kelson
I typically do Everything installs on my personal workstations.
Simplifies life greatly.
However, it would be nice if there were:
"Everything ONLY English" (ie, no foreign language support)
"Everything NO Development"
Comments?
20 years, 8 months
XFree86-Mesa-libGL packaging (mharris, read this please)
by Peter Backlund
Hi.
Would it be possible to change packaging of XFree86 and XFree86-Mesa-libGL
slightly, so that
/usr/X11R6/lib/modules/extensions/libGLcore.a
and
/usr/X11R6/lib/modules/extensions/libglx.a
could belong to XFree86-Mesa-libGL instead of XFree86? This would make it _so_
much easier to package replacement OpenGL libraries (Nvidia for example). One
would just add a Conflicts: XFree86-Mesa-libGL, and all file conflicts would
go away.
/Peter
20 years, 8 months
further development of libuser's LDAP module
by Felipe Alfaro Solana
Hi!
While using libuser's LDAP module, I think I've found that it's not
complete. The fact is that several operations, like adding users and
groups try to invoke "lu_ldap_set" libuser's function, which in turn,
uses ldap_modify_s().
The problem here is that can't expect ldap_modify_s() to succeed in
creating a user or group account when the underlying LDAP entry does not
exist. The real fact is that I've been unable to use "luseradd" and
"lgroupadd" to add users and groups to my LDAP backend.
Thus, I've modified and redeveloped the LDAP module of libuser a little
bit and I think I've got a 100%, fully functional LDAP backend module
which can be used to add, delete and modify user and group accounts.
Are you interested in me posting a unified diff/patch (or the whole
sources)? Please, say yes ;-) This is a very interesting piece of
software I'm using in a real proyect to migrate a stinking farm of NT4
boxes to Linux + Samba 3.0 and LDAP.
Thanks!
20 years, 8 months
MySQL version in next beta?
by Lenz Grimmer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I must admit that I have not installed "Severn" yet (just downloaded the
ISOs). Can anyone tell me, if you have already moved to MySQL 4.0? Or do
you plan to still ship with 3.23?
Let me know, if there is anything I can help you with regarding MySQL!
Bye,
LenZ
- --
Lenz Grimmer <lenz(a)mysql.com>
Senior Production Engineer
MySQL GmbH, http://www.mysql.de/
Hamburg, Germany
For technical support contracts, visit https://order.mysql.com/?ref=mlgr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/
iD8DBQE/MR+3SVDhKrJykfIRAj77AJoDPrZwF4Ghri/AM/BeswtlE6Y1ggCdEveA
G6WPLAN07Ei7nXQ9c9BrMlg=
=AQGh
-----END PGP SIGNATURE-----
20 years, 8 months
Re: My report on running 2.6.0-test2 on a Dell Inspiron 7000 (possible tty trouble)
by Paul Dickson
On Wed, 6 Aug 2003 13:42:34 +0200, Antonio Vargas wrote:
> On Wed, Aug 06, 2003 at 02:22:56AM -0700, Paul Dickson wrote:
>
> > I built 2.6.0-test2 for my Dell Inspiron 7000 notebook (PII, 300Mhz) with
> > a RH9 distribution. I build the kernel on another system (1.33GHz) using
> > ssh.
> >
> > I was missing some device support, so did a "make menuconfig". The
> > configuration options were shown, I selected "Sound -->" and pressed
> > enter. The terminal went back to text mode and then hung. Gnome-terminal
> > started consuming all unused CPU cycles.
> >
> > I could recover the process by closing the tab or resetting the terminal,
> > but this would only fix the problem for the moment. Frequently, it
> > wouldn't even finish redisplaying the screen before it locked again.
> >
> > This would happen running "make menuconfig" locally or via ssh on another
> > system.
> >
> > This is likely caused by some difference in the tty code in 2.6.0-test2.
> > The problem does not occur under 2.4.20-18.9. If 2.6.0-test2 is correct,
> > then I might need an updated version of gnome-terminal suitable for 2.6.0.
>
> This is a bug in gnome-terminal:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89151
>
This bug is still in the gnome-terminal version included with Severn.
-Paul
20 years, 8 months
X11 and -nolisten tcp [Re: How do I shut down this ports (fwd)]
by Pekka Savola
Just a thought..
Is there any reason '-nolisten tcp' is not the default? I haven't tested
but I think the SSH forwards work nonetheless; only if you use $DISPLAY to
direct output to your screen from remote machines you're likely in for
trouble -- but that should not typically be done anyway.
(only reason I can think of are those funky heavy graphics apps folks
claim are too slow over SSH)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
---------- Forwarded message ----------
Date: Wed, 06 Aug 2003 12:35:09 +0200
From: "shrek-m(a)gmx.de" <shrek-m(a)gmx.de>
Reply-To: rhl-beta-list(a)redhat.com
To: rhl-beta-list(a)redhat.com
Subject: Re: How do I shut down this ports
Michael Kearey wrote:
> Louis Garcia wrote:
>
>> 6000/tcp open X11
>
>
>
> In case you really must, I found in the man page for Xserver the option :
> -nolisten trans-type
> disables a transport type. For example, TCP/IP
> connections can be disabled with -nolisten tcp.
>
>
> The consequences of doing so , and where in the X configuration files
> you might actually put it, I don't yet know... I have been trying to
> find out how to set the option when starting X with xdm/gdm/kdm.
>
> In any case, startx -- -nolisten tcp will do it at commandline and so
> far in Severn it's had no adverse impact for me...
you can try or google for ...
debian:
/etc/X/xinit/xserverrc
rhl ? :
/etc/X11/xdm/Xservers
:0 local /usr/X11R6/bin/X -nolisten tcp
/etc/X11/gdm/gdm.conf
[server-Standard]
name=Standard server
command=/usr/X11R6/bin/X -nolisten tcp
flexible=true
/etc/X11/xdm/kdmrc
--
shrek-m
--
Rhl-beta-list mailing list
Rhl-beta-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/rhl-beta-list
20 years, 8 months
including gnome 2.4 in next red hat release
by Marius Andreiana
Hi
As you know, Gnome 2.4 final should be available on september 10, 5 days
before last
rhl-beta release. There has been a lot of work on HIGification and
usability.
gnome 2.3 bugs:
http://bugzilla.gnome.org/gnome-23-report.html
If red hat developers are able to dedicate some time on crasher bugs, it
will help on making it stable faster.
Please consider including gnome 2.4 in next Red Hat release. It doesn't
bring major new features, but it's more polished.
Mandrake is recognized as the desktop distribution and Suse is getting
more and more sales on enterprise servers, both using KDE. If gnome 2.4
is not included in next red hat, it will delay it's adoption until next
release ( no, it won't be installed separately when it's out. Companies
have time only to apply red hat official updates )
Thanks,
--
Marius Andreiana
Soluţii informatice bazate pe Linux / Linux-based IT solutions
www.galuna.ro
20 years, 8 months
Re: RFC: i18n proposal
by Enrico Scholz
[ f'up2 to rhl-devel; the starting point of this thread is available at
http://www.fedora.us/pipermail/fedora-devel/2003-July/001756.html ]
hp(a)redhat.com (Havoc Pennington) writes:
> On Thu, Jul 24, 2003 at 01:19:11AM +0200, Enrico Scholz wrote:
>>
>> Other thoughts or comments?
>>
>
> Probably works for now (we've been doing it forever), but in the end
> the only right thing has to be that translations are part of the
> package being translated.
I see a problem in the maintenance of these translations. With the
specspo approach, there is one big .po-file which is updated by the
translators. When making the translations a part of the package, there
will be either thousands of small .po-files on the distribution side
(Fedora, Red Hat) or the package author has to maintain his .po files
himself.
IMHO, the latter option will not work because this will result in a
maintainance nightmare: since there are not enough translators, every
translator has to look after several packages, has to communicate
with the author and the author has to release packages with updated
translations very often. And this for every language...
So, there stays only the thousands of small .po-files case where the
translator has to choose one of them. Clicking hundreds of time in the
browser to download the files sounds very annoying and error-prone to
me.
Sure, you can hide this complexity with tools but such tools must be
written first and it will need a lot of work to make them as powerful
like the current solutions (e.g. the Emacs po-mode).
Another advantage of the big .po file is, that common strings
(e.g. group-names) need do be translated once.
> Say you are using redhat-config-packages or another package tool. You
> see a list of packages. You should see nice user friendly names of
> those packages in your own language
Ok; but I do not think that this is a matter of translations. To make
this possible, a new rpm-tag (e.g. 'LongName:' or 'ShortSummary:') which
defaults to the value of 'Name:' must be created. This new tag can be
added to the fields going to be translated.
But I think, only a few packages will profit from this; e.g. consider
the 'docbook-style-*' packages. What will you use for 'LongName:'? When
using e.g. _("docbook tools") the package-tool will present dozens of
_("docbook tools") and user is forced to enable either the raw-view or
to look at 'Summary:' to see which package it is.
> Also you want translated descriptions of course.
>
> I see no way to reliably do this using specspo. You have to somehow
> bundle the translations into the RPM package, and also install them
> when the RPM is installed.
You are right; specpo has disadvantages. E.g. you will have to download
the several mebibytes sized package for every small change in the
translation. There is a time-gap between package- and specspo-release
also.
> Otherwise mixing packages from different sources (including different
> OS versions) *will* break.
IMHO, this is not a big problem. The average user (who wants/needs
translations), will use the big repositories (the upcoming Red Hat
Linux Project, Fedora, Freshrpms, ...) which can provide their
specspo-packages.
There is an issue with rpm that is not easy to "register" such packages;
but for now, this can be solved with some %triggers and Jeff is open for
ideas how it can be improved in "better" ways.
> One approach would add a "PoFilesDir: foo" field to spec files, ...
Very interesting idea. Because I do not like decentralized maintainance
of po-files, I would apply it in the following way:
* The build-hosts of the repositories which are maintaining the translations
are "authoritative" regarding translations. "authoritative" means that
there are global macros like
| %_i18n_update_pofiles 1
| %_i18n_translation_domain fedora-i18n
This i18n domain is maintained in the current way: there is a big .po
file for every language, translators update it through cvs and release
manager compiles it to a .mo-file.
* while doing 'rpmbuild -bs ...' on these hosts, the resulting srpm-package
gets
- a tarball with *.po-files containing the trasnlated strings of the
package
- a tag like 'PoSources: <tarballname>'
non-authoritative hosts will not touch this tarball or tag.
* when doing 'rpmbuild --rebuild ...' for such a prepared srpm, the
operations mentioned by you already (make update-po) will be executed
and rpm creates translated headers by executing
| gettext(header[RPMTAG_SUMMARY/DESCRIPTION/...])
for every supported language.
'rpmbuild --rebuild' will not differ on authoritative and non-authoritative
hosts.
Problems:
* it is not implemented yet
> It might be nice if there were some way to add translation resource
> bundles to an RPM *after* building the RPM,
Yes; you will need to modify the headers (change localized language tags
and increase release) and you will have to update the po-tarball. On the
first glance, this does not look very complicated.
Enrico
20 years, 8 months
Perl module rpm dependency problem
by Jos Vos
Hi,
I'm trying to package the Perl XML-SAX module. I'm using the
Perl __find_{requires,provides} redefines etc. in the spec file.
I end up with a package containing (I've left the docs out of
this list):
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/Base.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/DocumentLocator.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/Exception.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/Intro.pod
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/ParserFactory.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/DTDDecls.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/DebugHandler.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/DocType.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/EncodingDetect.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Exception.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/NoUnicodeExt.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Productions.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Reader.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Reader/NoUnicodeExt.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Reader/Stream.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Reader/String.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Reader/URI.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Reader/UnicodeExt.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/UnicodeExt.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/XMLDecl.pm
/usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/placeholder.pl
The package says to require (I only list the perl(...) entries):
perl(Carp)
perl(Encode)
perl(Exporter)
perl(File::Basename)
perl(File::Spec)
perl(File::Temp)
perl(IO::File)
perl(Symbol)
perl(XML::NamespaceSupport)
perl(XML::SAX)
perl(XML::SAX::Base)
perl(XML::SAX::DocumentLocator)
perl(XML::SAX::Exception)
perl(XML::SAX::ParserFactory)
perl(XML::SAX::PurePerl::DTDDecls)
perl(XML::SAX::PurePerl::DocType)
perl(XML::SAX::PurePerl::EncodingDetect)
perl(XML::SAX::PurePerl::Productions)
perl(XML::SAX::PurePerl::Reader)
perl(XML::SAX::PurePerl::Reader::Stream)
perl(XML::SAX::PurePerl::Reader::String)
perl(XML::SAX::PurePerl::Reader::URI)
perl(XML::SAX::PurePerl::XMLDecl)
perl(constant)
perl(overload)
perl(strict)
perl(utf8)
perl(vars)
But now the problem, it says to provide (I only list perl(...) entries):
perl(XML::SAX) = 0.12
perl(XML::SAX::Base) = 1.04
perl(XML::SAX::Base::NoHandler)
perl(XML::SAX::DocumentLocator)
perl(XML::SAX::Exception) = 1.01
perl(XML::SAX::ParserFactory) = 1.01
perl(XML::SAX::PurePerl)
perl(XML::SAX::PurePerl) = 0.90
perl(XML::SAX::PurePerl::DebugHandler)
perl(XML::SAX::PurePerl::Exception)
perl(XML::SAX::PurePerl::Productions)
perl(XML::SAX::PurePerl::Reader)
perl(XML::SAX::PurePerl::Reader::Stream)
perl(XML::SAX::PurePerl::Reader::String)
perl(XML::SAX::PurePerl::Reader::URI)
So, when I try to install it, it says:
error: Failed dependencies:
perl(XML::SAX::PurePerl::DTDDecls) is needed by perl-XML-SAX-0.12-XOS.1beta1
perl(XML::SAX::PurePerl::DocType) is needed by perl-XML-SAX-0.12-XOS.1beta1
perl(XML::SAX::PurePerl::EncodingDetect) is needed by perl-XML-SAX-0.12-XOS.1beta1
perl(XML::SAX::PurePerl::XMLDecl) is needed by perl-XML-SAX-0.12-XOS.1beta1
But thes things *are* included, but not seen by the find_provides script?
Puzzled...
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
20 years, 9 months