I've been looking a bit at the inter-dependencies that exist between the
different tetex packages. F.e. the fact that tetex-xdvi currently needs
tetex (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=11721).
All this is caused because not all files have been moved into the
correct packages. For some files this is rather obvious, for others it's
more tricky to establish to which package they should belong.
My proposal is to move a couple of files from the other tetex packages
(mainly from tetex itself) to tetex-fonts, in essence making tetex-fonts
a kind of tetex-common package. However no name change or split off is
Dependencies would then become as follows:
tetex, tetex-dvips and tetex-afm require tetex-fonts
tetex-xdvi and tetex-latex require tetex-dvips
(doesn't tetex require tetex-dvips? If it does drop dependency on
-fonts, and -latex's dependency on -dvips.)
tetex-latex requires tetex
(need to investigate tetex-afm a little more)
Changes to /usr/share/texmf:
- All fonts, including sources and japanese (from tetex-dvips) fonts to
tetex-fonts (/usr/share/texmf/fonts/*). Sources are needed to generate
font definitions in /var/lib/tex.
- /usr/share/texmf/fontname to tetex-fonts (not really necessary, but as
tetex-fonts is the central package this is probably a good idea).
- /usr/share/texmf/xdvi/XDvi is required by tetex, so can't move to
tetex-xdvi. Move to tetex-fonts so it's available to both tetex and
- Parts of /usr/share/texmf/web2c to tetex-fonts, namely mf-nowin.base,
mf.base, mf.pool, mfw.base, plain.base, mktex.opt, mktexdir,
mktexdir.opt, mktexnam, mktexnam.opt and mktexupd. Necessary for
creation of font definitions in /var/lib/texmf.
- All .cnf and .cfg files to tetex-fonts.
Changes to /usr/bin:
- Move the following binaries to tetex-fonts (all but mfw from tetex):
MakeTeXPK, access (needed by texhash), fmtutil, gftodvi, gftopk, gftype,
gsftopk, inimf, kpsepath, kpsestat, kpsetool, kpsewhich, kpsexpand, mf,
mf-nowin, mft, mfw (from tetex-xdvi), mktexfmt, mktexlsr, mktexmf,
mktexpk, mktextfm, ps2pk, texhash(required by %post scripts) and virmf.
Necessary for creation of font definitions in /var/lib/texmf.
Changes to docs and man pages:
- kpathsea and web2c info to tetex-fonts
- relevant man pages to tetex-fonts
- libkpathsea.a and /usr/include/kpathsea headers to tetex-fonts
(separate tetex-devel package?).
- Cron job to remove unused font definition files to tetex-fonts.
- /usr/share/texmf/ls-R and /var/lib/texmf/ls-R files to tetex-fonts.
The above changes fix xdvi's dependency on tetex. A spec file (for FC 1)
can be found attached to the above bug report. It's quite possible a few
more files need to change packages before this is entirely correct. To
test correctness of this spec file the various /var/lib/texmf/
directories need to be removed so they can be regenerated on (first)
invocation of xdvi (or other programs). Dependencies for tetex-afm might
not yet be satisfied (if they are please let me know).
mount -t life -o ro /dev/dna /genetic/research
> ...and if only bugzilla could be avoided for the submission process,
> replaced by a more comprehensive system, it would help a lot. Or maybe
> just customize it enough to make it unrecognizable? ;-)
Is there any sort of system out there that's already written and comes
even close to doing what is needed? The fact is that learning bugzilla
was daunting for me as a new user, but given the alternatives I must say
it works quite well.
I do know that writing a complete custom app to handle the workflow
would be a pretty significant project to do correctly. Theres no point
in doing it half-ass, as bugzilla at least allows a lot of flexibility.
I think a few automation tools connecting to bugzilla is probably the
ticket to success. Fedora-startqa for instance queries bugzilla, and
automatically finds the most recent SRPMS and MD5Sums and downloads
them. It wouldn't be much harder to write an automated submitter, in
fact I think it's already been done (ESR's tool?).
I would say an automated submitter needs to be coupled with a pretty
strong automated build checking and rpmlint type tool though, in order
to prevent people from just running fedora-submit
"my_lame_non_compliant.src.rpm" and making extra work for QA.
Fedora-startqa has a lot of these automated checks in it, but is
dependant on mach currently.
When we built a package, we can sign it at build time by issuing
rpm -ba --sign file.spec
and it will prompt for something like this:
Enter pass phrase: <passphrase> (Not echoed)
Now on my system I need to build rpm automatically ( without human
intervention)! Is it possible to have my paraphrase being read in a file
rather than me sitting in front of the computer and actually typing it?
I know it's not a very good idea but my rpms need to be generated
automatically daily via cron, and I can't sit behind my pc and type the
paraphrase each time one rpm is being built.
Can I avoid the prompting of the paraphrase if I want to sign my packages
at build-time and everything be done automatically? Thanks.
This is for the purpose of a repository and things like these need to be
automated when dealing with multiple packages.
With kind regards,
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Email: didierbe at sps dot nus dot edu dot sg
On Wed, 2004-06-30 at 18:00, Michael Schwendt wrote:
> On Wed, 30 Jun 2004 14:58:56 +0200, Rudi Chiarito wrote:
> At fedora.us, further QA policy changes are in the queue. One which allows
> for new packages to enter the "unstable" repository after a very basic
> review (in particular the security relevant checks) and then hope that the
> community reports any missing flaws. But even then, the packagers ought to
> make sure their packages build at least on all the target platforms and
> adhere to the packaging guidelines, too. The packagers themselves should
> do a good portion of the QA for their packages. For instance, there is
> documentation on how to use 'fedora-rmdevelrpms' or 'mach' to find missing
> build dependencies. And there are several other packaging topics covered
> in the Wiki, too.
Which btw reminds me, is where can I get a mach configurations for FC2 ?
> > I'll admit that some of the trouble is more imaginary than real:
> > minutes spent copying, pasting and double-checking can easily seem
> > an eternity, when it's actually a mere five minutes... but why waste
> > them, if it can be avoided?
> You cannot avoid human interaction as in setting bugzilla keywords and
> replying to comments. You could only avoid that with ultimately
> package maintainers who get direct access to a build/publish system.
Absolutely true, although I believe the current system is still daunting
for a new packager or reviewer. I'm not sure how to make it less so
without compromising quality other than saying that people need to just
jump in, and ask for help on the list if needed.
Would there be some benefit to having a separate list for Extra's
> No. It's in fedora.us already in the "stable" repository (much to the
> disliking of some people) and the fedora.us build system uses a
> version, http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/
> but that is not an automated build system.
> > Should it be sanctioned as a required tool for packagers?
> No, because it behaves differently than plain rpmbuild.
Nonetheless, we really need to have a build environment that's >easily<
available for prospective packagers and QA testers to build packages on.
I propose mach, but a lot of people don't like it. Redhat has an
internal build system. Are there plans to release it
It's been a couple months since I was last harping on the list for some
feedback from the powers that be at RedHat regarding the official Fedora
Extra's infrastructure. Has there been progress? This issue really needs
to be resolved, even if the resolution is "we will eventually take over
the fedora.us infrastructure as it stands and abide by the policies
decided upon by the fedora.us community" or the other extreme of "we
don't like the idea of an official Fedora Extra's after all, do your own
thing", or more likely something in between.
I just wanted to present an installation system for fedora that
could be used to administrate a whole network of fedora/redhat linux
computers. It uses xslt to generate rpm packages, grub files, kickstart
files and html documentation out of the configuration in xml format.
The generated rpm packages are used to deliver out configuration files
to the hosts.
I would be really interested to hear what other installation and
configuration frameworks there are out there and what is being used.
I'm interested in knowing when GIF support will be re-included into
packages like PHP, ImageMagick and other image processing and
generation tools. GIF, as you might know was covered by patents until
the 20th of June 2004. The patents are now expired worldwide and gif
code could be easily re-activated in libs like GD and PHP. It was
always there, it was just not included into the packages because of the
patent problems. So, are there any plans to include gif libs into any
packages? It would be great if someone could give me some feedback on
In der Wässeri 43
andres(a)petralli.com, +41 43 3218066, +41 78 8353537
ICQ: 4685081, MSN: apetralli(a)msn.com, FAX: +41 43 5349810
1. Michael Damian Tiemann
2. USA, Chapel Hill, North Carolina
3. VP, Open Source Affairs (and former hacker)
4. Red Hat, Inc. (in Raleigh)
5. My goals are to push some extra useful packages that are built for
other or ancient distros into Fedora Extras. These packages are ones
that I believe will greatly expand the relevance of Fedora as a
development platform because of the additional communities they bring
with them. In particular:
* revive blender3d for FC2/Extras (was in FC1/Extras)
* add support for the R language (see http://www.r-project.org/)
* bring GRASS to Fedora (FreeGIS has been funded to do this)
* bring in the latest and greatest free bioinformatics sw
* see if the new eGroupware stuff is ready for FC2/Extras
As for doing QA, I can certainly do sanity checking of packages that
I've built or that others have built but not published to Fedora.
6. Historical qualifications
* A long time ago in a galaxy far away, I was a GCC hacker
* I know C, C++, and can parse bash, perl, and many other languages
* You should trust me because (1) Christian Gafton knows how to find me
(I work in the same building) and (2) Warren Togami brought me macademia
nuts from Hawaii
7. GPG KEYID and fingerprint:
[tiemann@localhost tiemann]$ gpg --keyserver pgp.mit.edu --fingerprint
pub 1024D/EA0AC0E4 2003-08-14 Michael Tiemann (CTO, Red Hat)
Key fingerprint = F0AD 3368 D24A 56CD A2AD 6A12 CAB3 2E89 EA0A
sub 1024g/BB6171EB 2003-08-14 [expires: 2008-08-12]
as will be able to see in todays rawhide, we're experimenting with
adding a patch for gpg-signed kernel modules. The idea behind this is
for the administrator to *optionally*  restrict the set of modules
that can be linked into the kernel. In selinux context one can even
eventually allow different security contexts to load different subsets
of modules, by restricting certain contexts to a predefined gpg keys
The work isn't complete yet by far, this is just a heads up. Input for
creative uses of this infrastructure is welcome :)
Arjan van de Ven
 And I repeat *optionally*.