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?
19 years, 10 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!
19 years, 10 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
19 years, 10 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
19 years, 10 months
BitTorrent enabled downloads & updates
by Elijah P Newren
Sorry for the cross-posting. I originally posted this idea on #fedora
at irc.freenode.net and Anvil suggested I email these two lists with
this idea. My idea was the following:
Have apt-get/yum/up2date/<insert favorite packaging system here>
use BitTorrent for file downloads.
This would have the following benefits:
Users would get a much faster download rate (at least, that's
been my experience for the downloads I've done with
BitTorrent).
It would alleviate the 'which mirror should I use' problem.
Anyone could easily become a mirror.
It should keep any specific mirror from getting overloaded.
I figured this made so much sense that someone else has already thought
of it and perhaps already implemented it. Anyone know if that's the
case? If not, does that idea sound interesting to others?
Elijah
19 years, 10 months
new package
by Pádraig Brady
Hi,
I noticed with great interest the
announcement of the more open
development model for rhl, and with
that in mind I'm wondering about the
process to follow for the possible
inclusion of:
http://www.pixelbeat.org/fslint
cheers,
Pádraig.
19 years, 10 months
Re: cipe
by Tom Callaway
Moving this to the appropriate list:
On Mon, 2003-07-21 at 23:27, Chris Ricker wrote:
> With cipe-1.5.4, if you do
>
> ./configure --enable-protocol=3 (or just ./configure)
>
> you get the exact same protocol in 1.5 that you get in 1.4. That
> interoperates with the cipe-1.4.x stuff RH ships currently
>
> If you do
>
> ./configure --enable-protocol=4
>
> you get the new protocol with all the new features. That doesn't
> interoperate.
Its a little more complicated than that in implementation. Specifically,
the following is true:
Cipe 1.5.4 has two different crypto algorithms (Blowfish and IDEA). They
are mutually exclusive in the code. In addition, the two protocol types
(3 and 4) are mutually exclusive in the code.
This means, to add it to the Red Hat Linux kernel as is, there would
need to be 4 directories with virtually identical code, simply to
account for all 4 possible modules. Headers cannot be shared in current
state.
In order to clean this up (one source tree generates 4 modules in full
build mode), the code would need a fairly massive rewrite (IMHO).
I came across all of this while dealing with Aurora. The big question
is: how does the RH kernel team feel about adding four new directories
to drivers/addon:
cipe3-bf/ cipe3-idea/ cipe4-bf/ cipe4-idea/
If they don't have a problem with doing that (I was planning on
encapsulating them within a single "cipe" directory), the patches I'm
doing for Aurora should work with RHL.
~spot
---
Tom "spot" Callaway <tcallawa(a)redhat*com> SAIR LCA, RHCE
Red Hat Enterprise Architect :: http://www.redhat.com
Project Leader for Aurora Sparc Linux :: http://auroralinux.org
GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260
The words and opinions reflected in this message do not necessarily
reflect those of my employer, Red Hat, and belong solely to me.
"Immature poets borrow, mature poets steal." --- T. S. Eliot
19 years, 10 months
[jjneely@pams.ncsu.edu: Re: gdm and missing home directories]
by Jack Neely
This didn't seem to make it the first time...
----- Forwarded message from Jack Neely <jjneely(a)pams.ncsu.edu> -----
Date: Mon, 28 Jul 2003 22:46:06 -0400
From: Jack Neely <jjneely(a)pams.ncsu.edu>
To: rhl-devel-list(a)redhat.com
Subject: Re: gdm and missing home directories
I don't think I'm getting as far as starting Gnome. Looking at slave.c
I don't see off hand what cases my session to end almost instantly. I
put gdm in debug mode and get the same thing if I click on Yes or No.
The following is what gets logged with me using the Yes option to log me
in with / == HOME.
Jack
Jul 28 22:23:09 narsil gdm(pam_unix)[4100]: session opened for user slack by (uid=0)
Jul 28 22:23:09 narsil gdm[4100]: gdm_slave_wait_for_login: end verify for 'slack'
Jul 28 22:23:09 narsil gdm[4100]: gdm_slave_wait_for_login: got_login for 'slack'
Jul 28 22:23:09 narsil gdm[4100]: Sending LOGGED_IN == 1 for slave 4100
Jul 28 22:23:09 narsil gdm[4100]: Sending LOGGED_IN 4100 1
Jul 28 22:23:09 narsil gdm[4051]: Handling message: 'LOGGED_IN 4100 1'
Jul 28 22:23:09 narsil gdm[4051]: Got logged in == TRUE
Jul 28 22:23:09 narsil gdm[4051]: (child 4100) gdm_slave_usr2_handler: :0 got USR2 signal
Jul 28 22:23:09 narsil gdm[4100]: Sending LOGIN == slack for slave 4100
Jul 28 22:23:09 narsil gdm[4100]: Sending LOGIN 4100 slack
Jul 28 22:23:09 narsil gdm[4051]: Handling message: 'LOGIN 4100 slack'
Jul 28 22:23:09 narsil gdm[4051]: Got LOGIN == slack
Jul 28 22:23:09 narsil gdm[4051]: (child 4100) gdm_slave_usr2_handler: :0 got USR2 signal
Jul 28 22:23:09 narsil gdm[4100]: gdm_slave_session_start: Attempting session for user 'slack'
Jul 28 22:23:09 narsil gdm[4100]: gdm_slave_session_start: Home directory for slack: '/home/slack' does not exist!
Jul 28 22:23:12 narsil gdm(pam_unix)[4100]: session closed for user slack
Jul 28 22:23:12 narsil gdm[4051]: (child 4100) gdm_slave_child_handler
Jul 28 22:23:12 narsil gdm[4100]: Sending LOGGED_IN == 0 for slave 4100
Jul 28 22:23:12 narsil gdm[4100]: Sending LOGGED_IN 4100 0
Jul 28 22:23:12 narsil gdm[4051]: Handling message: 'LOGGED_IN 4100 0'
Jul 28 22:23:12 narsil gdm[4051]: Got logged in == FALSE
Jul 28 22:23:12 narsil gdm[4051]: (child 4100) gdm_slave_usr2_handler: :0 got USR2 signal
Jul 28 22:23:12 narsil gdm[4100]: Sending LOGIN == for slave 4100
Jul 28 22:23:12 narsil gdm[4100]: Sending LOGIN 4100
Jul 28 22:23:12 narsil gdm[4051]: Handling message: 'LOGIN 4100 '
Jul 28 22:23:12 narsil gdm[4051]: Got LOGIN ==
Jul 28 22:23:12 narsil gdm[4051]: (child 4100) gdm_slave_usr2_handler: :0 got USR2 signal
Jul 28 22:23:12 narsil gdm[4100]: gdm_slave_wait_for_login: In loop
--
Jack Neely <slack(a)quackmaster.net>
Linux Realm Kit Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
----- End forwarded message -----
--
Jack Neely <slack(a)quackmaster.net>
Linux Realm Kit Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
19 years, 10 months
RPM building section of RHL's developer guide
by Matthias Saou
Hi,
I've got a few minor remarks regarding the example spec file given here:
http://rhl.redhat.com/participate/developers-guide/ch-rpm-building.html
- Summary: "The foo package does foo": Having redundancy ("the package
foo") in the summary is useless IMHO, and shouldn't be encouraged.
- Summary: I'd like to see an official suggestion as to whether a trailing
dot should be added or omitted. If would be prettier when all go by at
install time :-)
- Requires vs. PreReq: AFAIK, both are now handled identically and using
PreReq shouldn't be needed anymore. Jeff can correct me if I'm wrong.
For explicit requirements of the %pre/%post scriplets, should the
"Requires(pre):" way be suggested from now on or not?
- BuildPreReq vs. BuildRequires: Same thing, and it seems even more
useless to have any kind of distinction for source packages.
- %description and %prep shouldn't be stuck together for readability and
section separation.
- %makeinstall should probably not be separated from the rest of the
%install section as it's just a macro, not a separate section.
- The $1, 0 and 1 from the scriplets should either be all or none quoted
to keep consistent. AFAIK, $1 is always present and is an integer, so
quoting is not required.
- The %defattr could show the default directory mode too, by using
%defattr(-, root, root, 0755) instead (or replace 0755 with - maybe)
as directories might get mode 775 depending on the user's umask.
- The n-e-v-r should maybe be added at the end of the first line of each
%changelog entry. I don't do it myself (email address too long ;-)),
but I've noticed it has become common practise inside Red Hat.
It's a nice introduction page to what a spec file is, the descriptions
below are short and clear. Good work!
Now about the guidelines... ;-)
5) "The package may obsolete itself"... I really don't get that one!
6) "If a file from the package conflicts with a file from another package
in the Red Hat Linux project, the package must use Conflicts: to
specify it in the spec file."
Should this be "Conflicts:" with the file or the package name?
12) s/specified/specify/ typo.
13) "If a newer RPM does not have a binary package that the older SRPMS
produced, the binary package not produced anymore must be specified
with the Obsoletes: option in the new spec file."
I would also add something about encouraging to always use versions
with "Obsoletes:" in order to avoid many kind of future issues when
re-introducing packages for example.
Also, there is no mention of "Epoch:" usage, not even a quick note to
suggest not introducing any apart from when it's really the last resort. I
guess people may want to stay out of the endless discussion for as long as
possible ;-)
IIRC, I think I read someone mentioning somewhere that a list of current
packages with full "n-e-v-r" would be maintained. With the current
implementation of epoch handling in rpm >= 4.2.1, this will become a
necessity when depending on specific versions of certain packages.
Long mail, hopefully not just useless talk, or else, well... "sorry" ;-)
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Raw Hide 20030718 running Linux kernel 2.4.20-20.1.2013.nptl
Load : 0.24 0.27 0.26
19 years, 10 months
Re: %configure and RPM_OPT_FLAGS
by Elliot Lee
On 29 Jul 2003, Harald Hoyer wrote:
> I wanted to modify CXXFLAGS and stumbled across the %configure
> definition...
> CFLAGS="${CFLAGS:-%optflags}"
> CXXFLAGS="${CXXFLAGS:-%optflags}"
> FFLAGS="${FFLAGS:-%optflags}"
>
>
> Wouldn't it be better to have this in /usr/lib/rpm/redhat/macros:
>
> RPM_OPT_FLAGS="%{optflags}"
This part already happens automatically and is unnecessary.
> CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}"
> CXXFLAGS="${CXXFLAGS:-${RPM_OPT_FLAGS}}"
> FFLAGS="${FFLAGS:-${RPM_OPT_FLAGS}}"
>
> so that I can modify RPM_OPT_FLAGS prior to calling %configure??
If it is safe to assume that $RPM_OPT_FLAGS is only ever used in %build,
then please commit the change to redhat-rpm-config in devel CVS, and build
the update into dist-3.0E and dist-10.
-- Elliot
Humpty Dumpty was pushed.
19 years, 10 months
