the current xine-lib maintainer speaking. :-)
The Xine project:
has recently released a new major version, version 1.2.0.
Unfortunately, among the list of changes:
there are these new "features":
* Use libavutil-provided implementations for CRC, SHA1 and BASE64 algorithms,
this makes use of libavutil even outside the FFmpeg decoding plugin,
but avoid duplication of algorithms between different plugins.
* Use av_mallocz() when xine_xmalloc_aligned() wouldn't be needed.
* FFmpeg is now required as an external dependency; if you want to build
xine-lib from source, please download a copy of FFmpeg from their SVN
which basically mean that xine-lib now has a global, non-optional dependency
on FFmpeg's libavutil library.
So there are 4 possible ways forward:
(a) Stick with 1.1.x forever. I don't think that's a good idea in the long
run, upstream won't be providing security fixes for the old branch forever.
(b) Package libavutil (and only libavutil) from FFmpeg in Fedora. (I don't
think libavutil, as opposed to libavcodec, is actually patent-encumbered,
though that'd also have to be checked.) The issue there is that FFmpeg
upstream obviously doesn't support this. It would need some more black
packaging magic of the kind already done in xine-lib, and more legal
auditing. I don't think I want to investigate going down that road.
(c) Bundle parts or all of libavutil with xine-lib. Yuck!!!
(d) Move the whole thing (back) to RPM Fusion (where it originally was, before
we started needing xine-lib for Amarok and Phonon, which both no longer
use it). It would go to the Free section, of course.
My proposal is to go with (d).
The following packages currently depend on xine-lib:
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
These packages would have to move to RPM Fusion along with xine-lib.
In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their git
repository, so it will likely have to move to RPM Fusion sooner or later
anyway. This means the affected packages are basically *xine*.
So my plan is to retire (for my packages, resp. have the respective maintainer
retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have the
respective maintainer get) them into RPM Fusion Free instead. (I'd take care
of xine-lib and kaffeine myself, I hope the maintainers of the other packages
will take care of them.)
2011-06-23 : FTBFS not responded to
2010-06-30 : -static packaging bug not responded to
Plus, release 0.89 from 20-May-2011 is available whereas Fedora contains
0.84 from 2010 ( http://sourceforge.net/projects/courier/files/cone/ ).
This looks like somebody with interest in Cone should sign up as
co-maintainer and find out what's up with the current maintainer.
Fedora release 16 (Verne) - Linux 3.1.1-2.fc16.x86_64
loadavg: 0.82 1.09 0.87
I have no more time to support the following packages in the Fedora.
jack-audio-connection-kit -- The Jack Audio Connection Kit
klamav -- Clam Anti-Virus on the KDE Desktop
man-pages-uk -- Ukrainian man pages from the Linux Documentation Project
python-alsa -- Python binding for the ALSA library
qstat -- Real-time Game Server Status for FPS game servers
uniconvertor -- Universal vector graphics translator
With Best Regards,
looks like PyXML package is deprecated since python itself provides xml
When you look deeper,
python's xml provides:
"dom", "parsers", "sax", "etree"
and PyXML provides:
'dom', 'marshal', 'parsers', 'sax', 'schema', 'utils', 'xpath', 'xslt'
So, PyXML duplicates dom, parsers and sax (and looks like python's is in
better shape). Is any package using marshall, schema or any other not in
Deprecate PyXML or just remove duplicated parts?
it seems to be the right time to do an unification/reorganization of
Oracle (Berkeley) DB packages in rawhide. The current situation is that
there are three of them:
compat-db - shipping old libdbs for compatibility (4.5,4.6 and 4.7)
db4 - shipping latest 4.x libdb series (4.8)
libdb - shipping latest libdb release (5.3)
What I'm planning to do is getting rid of db4 package. But before that
I want to clean-up compat-db for a bit.
After fiddling a bit with repoquery nothing seems to be dependent on
libdb-4.5 so if there are no objections I want to remove it.
There was only one package dependent on 4.6 (squidGuard) because it
had compilation problems with 4.7. This package is now built against
5.3 with no problem so 4.6 could go away from compat-db as well.
Only one package (pam_abl-0:0.2.3-8.fc12) was dependent on 4.7
in Fedora 17 but it's already rebuilt in rawhide so 4.7 can go away as
So the plan is:
1) remove 4.5, 4.6 and 4.7 from compat-db
2) put 4.8 to compat-db
3) make db4 a dead package
(db4 package name is not very descriptive any more as we have
The reason I'm sending this to fedora-devel is that I'm unable to
reveal dlopen() or similar deps in packages so if your package
requires older libdb I plan to remove and can not be rebuilt against
newer libdb then please speak up!
Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/
Kdo víno má a nepije, kdo hrozny má a nejí je, kdo ženu má a nelíbá,
kdo zábavě se vyhýbá, na toho vemte bič a hůl, to není člověk, to je vůl.
--- Jan Werich
(Let's try this again, but with less fail!)
Getting source tarballs from github is a nightmare. See
The debian tool doesn't help very much because one still needs revision
garbage in the specfile. Is there any more recent ways to mitigate this?
Perhaps we could "lobby" github to change their ways, at least partially?
Normally top reports CPU line, sy at 0.4% when idle. If I format an external Firewire disk as btrfs and mount it, it remains at 0.4%. If I reformat as XFS and mount it, again top reports sy at 0.4%. However, if I reformat as ext4 and mount it, sy runs at 3.5%. These two processes are now at the top of top's results:
Each uses on average 1.9% CPU. The light on the external drive flashes 4x per second. There are no processes using the disk at all while this is going on. If I umount it, the pulsing stops. If I remount it, the pulsing resumes as does the slightly higher CPU consumption.
This doesn't happen with the same hardware mounted XFS or btrfs or HFS+.
These reveal nothing related to the disk:
lsof | grep sdb
lsof | mapper
If I sift through it unfiltered with the volume mounted and not, I don't really see anything obvious standing out.
who decided that it is a good idea to hide the grub-menu?
most questions on mailing-lists and boards is "how can
i boot a different kernel" and it makes really really tired
to see that no new user is realizing that Fedora has a boot
this results a) in needless questions and b) new users does
learn nothing because they see nothing as default
I was quite depressed how hard it can be for a layman to find a way to install Fedora from LiveCD environment. If you don't recognize the icon in Gnome Shell Overview mode, it can give you quite some work to find it. Since OSS philosophy is "if you don't like it, fix it", I did. In the last two days I have created a Gnome Shell extension that puts a button on the top bar that says "Install to Hard Drive". It has an icon attached, so it's very visible. The graphics and the text is taken from anaconda's .desktop file, so localization should work OOTB. When you click the button, the installation process starts the same way as if you had run it from the overview.
You can see it here:
What do you think? Better than default?
I personally think it's definitely better than default. I'm sure it can be improved in many ways, but this was my first GS extension ever and I'm really lame, so bear with me (patches welcome). The source code is here:
How to try out:
1. boot F17 Beta RC2 Live
2. extract the extension to /usr/share/gnome-shell/extensions/
3. restart gnome-shell (Alt+F2 -> r)
4. install gnome-tweak-tool and enable this extension
Future steps if people like it:
a) find out how to include this just on the livecd, but not on the installed system
b) modify gsettings to have this extension automatically enabled
c) ask anaconda team to include it into their project and maintain it