devel August 2003

devel@lists.fedoraproject.org

93 participants
60 discussions

Opteron / AGP
by Dave Bevan 09 Aug '03

09 Aug '03

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.

1 0

RFE: Other "Everything" installs
by Dax Kelson 07 Aug '03

07 Aug '03

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?

9 13

XFree86-Mesa-libGL packaging (mharris, read this please)
by Peter Backlund 06 Aug '03

06 Aug '03

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

4 4

further development of libuser's LDAP module
by Felipe Alfaro Solana 06 Aug '03

06 Aug '03

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!

2 2

MySQL version in next beta?
by Lenz Grimmer 06 Aug '03

06 Aug '03

-----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-----

2 1

Re: My report on running 2.6.0-test2 on a Dell Inspiron 7000 (possible tty trouble)
by Paul Dickson 06 Aug '03

06 Aug '03

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

2 1

X11 and -nolisten tcp [Re: How do I shut down this ports (fwd)]
by Pekka Savola 06 Aug '03

06 Aug '03

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

1 0

including gnome 2.4 in next red hat release
by Marius Andreiana 04 Aug '03

04 Aug '03

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

11 14

Re: RFC: i18n proposal
by Enrico Scholz 04 Aug '03

04 Aug '03

[ 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

7 27

Perl module rpm dependency problem
by Jos Vos 01 Aug '03

01 Aug '03

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

5 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel August 2003