I just had to setup a new machine, and new ssh keys.
I chose my new id_rsa.pub to upload.
But I get:
git push --verbose
Pushing to ssh://firstname.lastname@example.org/mercurial
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
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.)
Unfortunately, I'm no longer in a position to maintain the projectM
packages (libprojectM, libprojectM-qt, projectM-jack,
projectM-libvisual, and projectM-pulseaudio), so I will need to orphan
these. If anyone would like to pick these up, feel free to come to me
with questions, or help.
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,
Please be aware that since the most recent systemd uploads /tmp is now
in tmpfs by default in Rawhide/F18.
For details please see this feature page:
If you have an explicit /tmp entry in fstab things should continue to
work the same as before. If you don't then you will now get a tmpfs on
/tmp by default.
This will most likely lead to a problem or two with software that isn't
happy about /tmp being small. We have created a tracker bug to keep
track of this:
If you have identified a bug that is triggered by /tmp being on tmpfs
now, please add it to this tracker bug!
For a bit of background on all of this and recommendations for
developers, please see:
Lennart Poettering - Red Hat, Inc.
In Fedora 17, when you install grub2 and generate a fresh config file, that
config is produced by grub2-mkconfig. However, when you install a kernel
update, the kernel's entry is added to the grub2 boot menu by grubby.
This produces messy grub boot menus. The entries added by grubby read
something like "Fedora (%kernel_version)". grub2-mkconfig, on the other
hand, only displays one "Fedora Linux" boot option and places the other
kernels and their recovery mode environments in a submenu called "Advanced
Now, I never really liked seeing three kernels on the main menu to begin
with, and I think the new grub2 approach of hiding the other kernels in a
submenu is nice. But then as soon as I start installing updates the submenu
becomes incomplete (and eventually useless, as the new kernels won't be
listed there) and the grubby options take over the menu.
It seems to me that we should make the boot menu more consistent somehow. I
feel like the simplest solution is just to run grub2-mkconfig at every
kernel update, and stop using grubby for this. Then everything would look
consistent- the "Fedora Linux" boot option would have the latest kernel
and all kernels would always be listed under the submenu. (As far as I
know, this would just be a change to the kernel specfile, right?).
Alternatively, if Fedora does want boot menus that look like the ones
produced by grubby, then the grub2 default configuration should be changed
to reflect that, so the boot menu will always look consistent.
I should add that I did see a reference to possibly replacing grubby with a
"grub-updconf" (though I'm not aware of such a program) on the wiki-
http://fedoraproject.org/wiki/Features/Grub2 - so possibly there are
already plans for this?