TeXLive 2008 in F10?
by Vasile Gaburici
Are there any plans to include TeXLive 2008 in F10? Currently a
preview is available, which is essentially a release candidate. I
works fine for me on F9, but I have not packaged it.
I understand that the new TeXLive 2008 installer and packaging system
is a lot of work to deal with, but TeXLive includes LuaTeX, which is
the designated successor to pdfTeX, being developed by the same people
that maintain pdfTeX, which won't get any signifiicant new features.
So, for all practical purposes LuaTeX is the "new TeX".
LuaTeX can already use OpenType fonts (towards which Fedora is
moving), although not for math for which there are no usable *free*
Unicode fonts available right now (the only usable one being Cambria
Math from MS). There is no OpenType support planned for pdfTeX, so
it's important to get users exposed to LuaTeX as early as possible,
and Fedora is a good way of doing this :)
The entire TeXLive 2008 system uses a new kpathsea replacement written
in Lua, which is *many* times faster the original. This results in
major speed improvements for all TeX programs.
The "packetization" of TeXLive, plus the support in LuaTeX for
OpenType fonts should make the TeX fonts mess (bug 456580) a more
tractable problem, even though it won't solve it right away.
Also, TeXLive 2008 includes lcdf-typetools, which I was planning to
package separately - the package has been orphaned around FC6 or so.
The main issue that I see is how to deal with 1Gb+ of TeXLive 2008
packages (over 1000). Perhaps something similar to cpan2rpm is in
order?
15 years, 10 months
ANNOUNCE: rpmgrok - a web-based tool for tracking a full distribution of RPMs
by David Malcolm
I've been working on a new web-based tool for analyzing Fedora: rpmgrok
It digests built RPMs, analysing the metadata and payload, and stores
the results in a database. There's a web UI for viewing the data, an
XML-RPC interface for querying it, and a command-line tool for using the
XML-RPC interface.
I've got a prototype running on:
http://publictest7.fedoraproject.org/rpmgrok
More info (e.g. source code) can be seen at
https://fedorahosted.org/rpmgrok
The idea is to provide a new way for Fedora developers, testers, and
other enthusiasts to track various things across the entire
distribution, without having to have a full tree installed. It's
probably usable by other Linux distributions.
rpmgrok is Free/Open Source software (licensed under the LGPLv2.1)
== What does it track? ==
- all symbols in binaries/libraries, and the dependencies between
them, so that you can see e.g. exactly what calls a particular function.
This can also be used to locate instances of static linkage. See e.g.
http://publictest7.fedoraproject.org/rpmgrok/elffile/258085 (details
of /lib/libexpat.so.1.5.2 from a built RPM)
- manifests of all RPMs, so that you can browse the files in packages
via a web UI. See http://publictest7.fedoraproject.org/rpmgrok/files
The file view is only interesting at the moment for ELF files (binaries)
and for .desktop files.
- all shared objects names, and the dependencies between them. See
e.g.
- http://publictest7.fedoraproject.org/rpmgrok/sonames (browsable
view of all sonames in the distro)
- http://publictest7.fedoraproject.org/rpmgrok/elffile/739167
(details of /usr/lib/libxml2.so.2.6.32 from within a built libxml2 rpm)
- Everything implementing or linking against libpcre.so.0 down to
the level of individual binaries:
http://publictest7.fedoraproject.org/rpmgrok/soname/libpcre.so.0
- results of rpmlint of all rpms. See
http://publictest7.fedoraproject.org/rpmgrok/rpmlint_messages for a UI
to browse by error message, and e.g.
http://publictest7.fedoraproject.org/rpmgrok/rpmlint/dangerous-command-in... for an example of all error messages of a particular kind. It may be worth fixing some rpmlint errors (though others look like false positives, and others are probably not worth it)
- all .desktop files and their fields so that you can e.g. find
applications that can handle PDF files. See e.g.
http://publictest7.fedoraproject.org/rpmgrok/mimetype/application/pdf
for a view of all desktop files that can handle "application/pdf", and
e.g. http://publictest7.fedoraproject.org/rpmgrok/desktopfile/253580
showing a specific desktop file
- SLOCcount stats (see http://www.dwheeler.com/sloccount/ ) for
prepped source trees (e.g "what % of Fedora is in C/C++/Python?" etc).
Don't have the data prepped yet.
- any other kind of thing we want to add (provided there's a sane way
to gather it in a script and slurp it into the database, of course...)
- sizes of packages; why is package foo so big?
- report on all fonts in the distro, and what packages provide them
etc
Note that due to my poor css there are lots of links that don't show up
as such in the various table views. You may need to explore with the
mouse to find all of the cross-referencing that the web UI has.
== What's it currently showing? ==
I queued up an analysis of all of rawhide as of 2008-07-25 on i386; a
little over 10000 built packages. It took about a week to process, and
about 200 of these jobs failed for one reason or another. See
https://fedorahosted.org/rpmgrok/ticket/9 for more info.
So the db is currently just showing a snapshot in time of rawhide two
weeks ago, on one architecture (and missing 2% of the packages due to
errors).
Ultimately I want to build things up so that we can show time-based
trend reports e.g. the size of a minimal install over time (or
whatever).
== Help Needed! ==
Hopefully this looks of interest to people.
I need help with coding, with sysadmin work, with making the UI better,
and with things I probably haven't thought of yet etc. I hope this can
be a useful tool for Fedora.
If you're interested in hacking on rpmgrok, get in touch. The README
file is hopefully of interest; see
http://git.fedorahosted.org/git/rpmgrok.git?p=rpmgrok.git;a=blob_plain;f=... README.txt
It's implemented using TurboGears and SQLAlchemy (specifically,
sqlalchemy 0.4, since it uses polymorphic inheritance features from that
version).
It also has a somewhat general-purpose task scheduler, used to control a
pool of worker hosts that do the actual analysis. It ought to be
pluggable to do other types of task.
== Source Code ==
Git URLS are:
git://git.fedorahosted.org/rpmgrok.git
ssh://git.fedorahosted.org/git/rpmgrok.git
http://git.fedorahosted.org/git/rpmgrok.git
(you need to be in the gitrpmgrok of the Fedora Accounts System to have
git push privileges; talk to me if you want to get involved)
== Related work ==
Inspiration includes
- the OpenGrok project (see
http://opensolaris.org/os/project/opengrok/ though that appears to focus
on source trees, whereas rpmgrok focuses on built packages)
- the Debian project's Lintian tool (see http://lintian.debian.org )
Enjoy!
Dave
15 years, 10 months
Features that would be great for Fedora 10
by Valent Turkovic
Here are just few features that I believe would be great for Fedora 10 to have:
1. RFE: Add desktop folder with examples of what "fedora thing" can do :)
https://bugzilla.redhat.com/show_bug.cgi?id=315171
Lisa gets Fedora 10 Live CD from her Joe (her geeky boyfriend) and
puts it in her laptop. After she gets presented with a different
looking desktop that
she is usually presented she doesn't know what this "fedora thing"
actually does and can do. Joe gives her a CD version of Ubuntu, after
loosing temper with trying to explain what fedora can actually do.
Lisa puts Ubuntu CD in and after few minutes she clicks through a few
examples on her new desktop and sees that this "Ubuntu thing" does
more that that "Fedora thing" like plays music & videos, shows nice
spreadsheets and other documents.
It would be great for Fedora to add directory on desktop with some
nice examples what Fedora and OSS can do. There are great videos on
redhat magazine page and I'm sure there are other great resources -
new users need to be exposed to them in this way. Also there is a
initiative for contriburots to make screencasts and this feature would
be a great match with it if they merged together.
2. RFE: Desktop shortcut for joining Fedora IRC (aka "Get Live Help"):
https://bugzilla.redhat.com/show_bug.cgi?id=430217 and
https://bugzilla.redhat.com/show_bug.cgi?id=179703
Fedora is about freedom+communication, right? Why not make this
statement more that just a nice slogan. If you installed sabayon linux
you could experienced for yourself what this really means. I as a new
user to gentoo (sabayon is based on gentoo) was really blown away with
this feature. It is really, really simple to implement and gives a
real meaning to a communication friendly linux distro.
In sabayon link to their IRC chat has a simple name "Get Live Help"
and it work fabulous! I didn't have any Portage experience so I poped
in IRC chat room and was on my way after I got quick help. Whis kind
of help was precious to me and would love to see it in fedora as one
of it's main features and not just as a slogan.
screenshot: http://www.flickr.com/photo_zoom.gne?id=382063978&size=l
3. Add abillity to define ntfs mount points in anaconda
https://bugzilla.redhat.com/show_bug.cgi?id=430084
We can define ext3, reiserfs, xfs and vfat partition mount points in
anaconda during the install but just ntfs.
Cheers,
Valent.
--
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic
15 years, 10 months
python-nss feature
by John Dennis
Paul Fields graciously has brought to my attention some concerns
expressed here as to whether python-nss is truly a feature or just mere
packaging. The feature page was probably deficient in explaining why
this is a feature. Previously there were no python bindings for NSS. NSS
is our preferred cryptographic library for SSL/TLS and certificate
management (largely because of it's FIP 140 certification, plus a
variety of other issues). Python is widely used in Fedora. The absence
of Python bindings for NSS has been a developmental liability for many
Fedora projects. Due to the complexity of NSS and the desire to produce
a binding which was "pythonic" it was not possible to produce a binding
via automated tools (e.g. swig). Instead the binding was written by hand
with Red Hat investing many man months of engineering in the effort. If
the binding had been easy to produce one would have existed already, but
it's been missing for years. This is why it's a feature. It's not "just
packaging" because that implies the binding already existed and we just
packaged it up, something which would have been just a fraction of the
effort actually invested. To my mind a feature is something which did
not exist previously and brings significant new functionality to the
release, I believe python-nss fulfils that criteria.
I will update the features page with this information.
--
John Dennis <jdennis(a)redhat.com>
15 years, 10 months
Does your app use LIRC?
by Bastien Nocera
If your app uses liblirc_client, it would be nice if you could follow
the instructions, and the two examples at:
https://fedoraproject.org/wiki/Features/BetterLIRCSupport#User_Experience
to make your application work out-of-the-box in Fedora 10.
Elisa, Totem and Rhythmbox are already fixed.
I'd have had a nice list using repoquery, but it just seems to hang
there doing nothing (and then gives me useless answers, might just be
me...).
Let me know if you have any questions about the setup.
Cheers
15 years, 10 months
Re: Broken dependencies in Fedora 9 - 2008-08-08
by Haïkel Guémar
Hi,
This package has no more active upstream for almost 2 years and is now
too broken to be maintained in Package collection.
I am looking for removing it from repositories.
Best regards.
H.
15 years, 10 months
[PATCH-ACPI]: Fix broken EC Object on some Acer notebooks
by Joshua C.
I have an Acer which has a borken Bios. Actually the DSDT has a
nonexisting Method which gives a kernel panic. Bugs 10237 and 8953 on
bugzilla.kernel.org were filed about this problem and Yakui Zhao made
a patch for this. I don't know when this is going to end in the
mainstream kernel but till then we can have it in the fedora kernel.
Any objections?
The patch (I've tested this with current FC8 and FC9 - works well):
----------------------
Subject:ACPI: Ignore AE_NOT_FOUND error of EC _REG method and continue
to initialize EC
From: Zhao Yakui <yakui.zhao(a)intel.com>
On some broken BIOS the ACPI object in EC _REG method can't be found in
ACPI namespace, which causes that the AE_NOT_FOUND status code is returned by
the EC _REG object. In such case the EC device can't be initialized correctly,
which causes that battery/AC adapter can't work normally. As the EC address
space handler is not removed and the memory pointed by its input argument is
already free, sometimes the kernel will also be panic when EC internal register
is still accessed. But the windows can work well on such broken BIOS.
Maybe it will be reasonable that OS ignores the AE_NOT_FOUND error
returned by the EC _REG object and continues to initialize EC device
for some broken BIOS. Of course the warning message will be printed.
For example: the ACPI object in EC _REG method can't be found and status error
code is AE_NOT_FOUND.
http://bugzilla.kernel.org/show_bug.cgi?id=8953
http://bugzilla.kernel.org/show_bug.cgi?id=10237
Signed-off-by: Zhao Yakui <yakui.zhao(a)intel.com>
Signed-off-by: Lin Ming <ming.m.lin(a)intel.com>
---
drivers/acpi/ec.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
Index: linux-2.6/drivers/acpi/ec.c
===================================================================
--- linux-2.6.orig/drivers/acpi/ec.c
+++ linux-2.6/drivers/acpi/ec.c
@@ -835,8 +835,19 @@ static int ec_install_handlers(struct ac
&acpi_ec_space_handler,
NULL, ec);
if (ACPI_FAILURE(status)) {
- acpi_remove_gpe_handler(NULL, ec->gpe, &acpi_ec_gpe_handler);
- return -ENODEV;
+ if (status == AE_NOT_FOUND) {
+ /*
+ * Maybe OS fails in evaluating the _REG object.
+ * The AE_NOT_FOUND error will be ignored and OS
+ * continue to initialize EC.
+ */
+ printk(KERN_ERR "Fail in evaluating _REG object."
+ " It is broken BIOS.\n");
+ } else {
+ acpi_remove_gpe_handler(NULL, ec->gpe,
+ &acpi_ec_gpe_handler);
+ return -ENODEV;
+ }
}
ec->handlers_installed = 1;
15 years, 10 months