On Thu, Jan 28, 2010 at 09:19:05AM +0200, David Juran wrote:
> On Wed, 2010-01-27 at 17:03 -0800, Jesse Keating wrote:
> > It's that time of the release cycle again, to purge the orphans before
> > we get to feature freeze. Any unblocked orphans will be purged by the
> > feature freeze. A list of unblocked orphans and the broken deps they
> > would cause is at the end of this email.
> > Unblocked orphan gnome-common
> > Unblocked orphan gtk-sharp
> Was gnome-common and gtk-sharp really intended to be orphaned? Removing
> them seem to break quite a lot (large parts of gnome and e.g. f-spot,
gnome-common was intended to be orphaned although mclasen said he'd find
someone to maintain it since pieces of gnome depend on it. It's not a high
maintainance package; most anyone can do it... it's just no use to me any
longer so I'm not a good maintainer anymore.
Is there some reason we don't have a iwl5150-firmware package? Or
that /lib/firmware/iwlwifi-5150-2.ucode isn't included in
Just asking because I was helping someone on #fedora get their Intel
5150ABN working, and it seems that this missing firmware was the reason
it wasn't. The firmware is available from
if you are an OpenModelica user, you might know that we do not have any
rpms available for fedora.
This might be due to the buildsystem.
I have started converting MetaModelica to autootols to boot-bootstrap
the omc build process.
Building the rml compiler and the related libraries was easy, but now I
could need some help and advice on how to build the testcases.
In the original buildsystem from
https://openmodelica.ida.liu.se/svn/MetaModelica there are some examples
with own makefiles, but those refer to the buildsystem itself.
I am not sure how to handle this with automake (obviously it would
require to build the compiler before the tests).
So currently I am wondering if the examples should have a build system
that requires the compiler to be installed, any thoughts?
On the other hand, there are some "style" questions, I'd like to be
This package builds three slightly different libraries in three differen
flavors: called (librml_plain|librml_mask|librml_diff)(_g|_p|).so
Those flavors only differ by the CFLAGS set upon compilation (_p means
-p, _g -g).
Upstream told me, they require them all, but would this be acceptable?
Is the name rml ok for a library in /usr/lib or shall I
use /usr/lib/rml/ by default? (Same for headers)
What with the name? Is MetaModelica even a good name, if the main binary
The package builds a compiler driver, essentially a shell script, by
copying some configuration variables into a shell template (mainly how
to invoke cc). Would this be fine as a /usr/bin script?
Feel free to demand any changes, I will discuss this with upstream.
There was an outage starting at 2010-01-28 16:40:00 UTC, which is ongoing.
Resolution time is not yet known.
To convert UTC to your local time, take a look at
date -d '2010-01-28 16:40:00 UTC'
CVS / Source Control
Fedora Account System
Fedora Package Database
Reason for Outage:
We are seeing a 25% packet loss to PHX2. This also is impacting
non-fedora systems like bugzilla and RHN.
Please join #fedora-admin in irc.freenode.net or respond to this email to
the status of this outage.
devel-announce mailing list
Some Red Hat employees are opening new merge review tickets for packages
which were in extras long before the big core-extras merge. It looks
like all of these packages are so old that the reviews predate the use
of Red Hat's bugzilla for the purpose, and so those reviews were either
done on the old mailing list or in the old fedora.us bugzilla (which I
believe has been lost).
No Fedora policy requires that these packages be re-reviewed. The
evidence seems to point to some Red Hat policy requiring review tickets
for these packages, although I can't seem to get a proper answer from
someone who actually knows. Given that the reviewers are currently
overburdened and are barely able to keep up with existing submissions,
plus the fact that we still have a few hundred of the original merge
review tickets still open, I don't think that adding more to the pile is
going to be remotely helpful. If there's a Red Hat policy which
requires this, then Red Hat should be taking care of this instead of
leaving it to the overburdened Fedora community. The fact that there's
been no communication about it only adds insult to injury.
I propose that the 'Product' on these tickets be changed to something
other than 'Fedora' so that they don't appear to be part of any Fedora
process. I'm happy to do that if someone can tell me which component to
Note that I don't necessarily think it's a bad idea that old packages be
revisited at some point, but we just don't have the manpower to do that
It is a application that lets you minimize any app to the system tray
and is compatible with GNOME, Xfce, KDE etc. It has a dormant upstream
and I haven't had time to look into all the crash reports from Abrt. If
noone picks it up, I will orphan it in a week.
$ yum info alltray
Loaded plugins: presto, refresh-packagekit
Name : alltray
Arch : i686
Version : 0.70
Release : 4.fc12
Size : 62 k
Repo : fedora
Summary : Dock any application in the tray
URL : http://alltray.sourceforge.net/
License : GPLv2+
We currently ship xdvik as a package separate to texlive (for a
variety of reasons). Looking forward to when we ship texlive-2009,
it'll be built as part of the texlive package build once more.
However, even better would be to drop it entirely, for the following
1) It's a legacy piece of software which is barely maintained - a
couple of times a year releases are made with small bugfixes, but
there's no actual development
2) We patch it heavily to bodge in japanese support using a separate
upstream patch from http://sourceforge.jp/projects/xdvi/, but this
patch isn't actively maintained either, and rebasing that patch is a
3) The need to incoorporate the japanese patch, and also the desire to
build against the system installed kpathsea shared lib rather than
link statically means we end up hacing the autotools scripts and have
to run autotools during package building, and worse, we have to use
old autotools as the scripts are so crusty.
4) It's one of the few users of the Xaw(3d) toolkit in the repo, and
also requires legacy font support (IIRC).
However, it's not clear to me if okular and evince-dvi provide
equivalent functionality that we're yet in a position to drop xdvik.
Comments? If you use xdvik because other viewers don't give some
particular functionality, it would be helpful if you stated what that
Jesse Keating wrote:
> Unblocked orphan gtk-qt-engine
This one was basically retired by rdieter (kcm-gtk Obsoletes it, though it
contains only the KCM part, the theme engine was unstable and is dead
upstream), I guess the retiring process was just not completed properly. So
I guess this one can just die.
> Unblocked orphan qtoctave
I'll pick this one up, it's useful (a Free Software equivalent to the MATLAB
GUI), it's in my area of expertise (Mathematics tool, and Qt-based, even),
there's AFAIK no obvious replacement and upstream seems active.