Moving xine-lib and dependent apps to RPM Fusion Free for F17?
by Kevin Kofler
Hi,
the current xine-lib maintainer speaking. :-)
The Xine project:
http://www.xine-project.org/home
has recently released a new major version, version 1.2.0.
Unfortunately, among the list of changes:
http://sourceforge.net/projects/xine/files/xine-lib/1.2.0/README.txt.asc/...
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
server.
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:
* gxine
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
* oxine
* xine-plugin
* xine-ui
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.)
Comments? Objections?
Kevin Kofler
7 years, 5 months
orphan most of my packages
by Andy Shevchenko
Hello,
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,
Andy Shevchenko
8 years, 6 months
PyXML package - deprecate it?
by Roman Rakus
Hi all,
looks like PyXML package is deprecated since python itself provides xml
mechanisms.
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
python itself?
Deprecate PyXML or just remove duplicated parts?
RR
8 years, 8 months
why is gurb-menu hidden as default?
by Reindl Harald
hi
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
manager
this results a) in needless questions and b) new users does
learn nothing because they see nothing as default
8 years, 10 months
How can we make F17 be able to boot on Macs (with or without reFit)
by Chris Murphy
Volume 2
CSM-BIOS boot notes:
Apple hardware tested:
mbp41 = MacBookPro 4,1 (2008), Nvidia Geforce8600M GT.
mbp82 = MacBookPro 8,2 (2011), Intel HD Graphics 3000 and AMD Radeon HD 6750M.
All notes based on booting with the Apple-EFI option-key startup menu to choose how to boot, not rEFIt.
1. After default install using any installation type, and reboot, neither model loads GRUB2 (and thus does not boot) by default. Pre or post-install work is needed.
2. Both models CAN boot and startup Fedora to a GUI login with pre- or post-install work.
a. 'nogpt' kernel parameter for Fedora only installs produces a bootable system without post-install work.
b. In dual-boot (Mac OS + Fedora) anaconda isn't creating a hybrid MBR post-install, therefore Apple's EFI startup disk menu doesn't see the F16 installation. Further, creating the hybrid MBR in advance is useless as parted wipes out the hybrid MBR in favor of a protective MBR just prior to installation. (See 3 below for additional fallout of this behavior.)
c. Triple boot (Mac OS, Fedora, Windows) is possible, but there are more ways this won't work, than will work. And more ways that will work, but aren't good partition schemes (invitations for data loss) since there really isn't such a thing as a safe hybrid MBR + GPT. I have found one or two that I think are about as "safe" as they can get, and it means that the user needs to install Mac OS, Windows, Fedora, in that order, but located on the disk in order: Mac OS, Fedora, Windows.
3. Anaconda + parted consistently remove pre-existing hybrid MBRs, replacing them with protective MBRs. The hybrid MBR will exist in a case where Windows has already been installed (using Apple's Bootcamp application). If removed in favor of a protective MBR, Windows is no longer bootable. So not only is Fedora not bootable, a previously bootable Windows is no longer bootable. This happens with either EFI or BIOS mode installs of Fedora.
So either anaconda needs to proceed no further upon discovery of a hybrid MBR, or it needs to become pretty good at sorting out hybrid MBR and GPT schemes that are "safe".
4. gptsycnc: I don't think gptsync has such a sophisticated heuristic for creating such hybrid MBRs - I regularly see it produce very linear MBRs while suggesting huge percentages of the disk are empty. Any MBR only aware tool would see these areas as fair game - what I call an invitation for data loss and probably not a good idea.
5. If all requirements are met, Apple's startup disk menu (option-key at startup chime) will present a single "Windows" disk icon which if selected will load GRUB2 and its menu. That "Windows" label is apparently hard coded in Apple's EFI for any foreign OS requiring legacy CSM-BIOS booting.
Additional EFI boot notes:
1. By default EFI//EFI/redhat/grub.efi isn't found by Apple's EFI and install a choosable option. If it and the .conf are moved to EFI//EFI/BOOT/BOOTX64.efi and .conf, both models have an "EFI Boot" labeled disk icon in the option-key startup menu. I'm guessing like the "Windows" equivalent, that "EFI Boot" is hardwired.
This is being addressed by this:
https://bugzilla.redhat.com/show_bug.cgi?id=755093
2. GRUB-EFI (legacy) regularly just hangs are loading the kernel and initramfs, on mbp41. I don't have this problem with GRUB2-EFI but I still have other problems mentioned in the previous email.
Chris Murphy
8 years, 11 months
F16: Kernel bug with USB disks ?
by Terry Barnaby
Hi,
I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having
problems with a MicroSD card connected to a USB card reader. This has
been working fine until recently (at least in F14 on the same hardware).
The problem is that "umount" does not appear to be working correctly.
I have an ext3 file system on the card. I can mount it, and I can copy
files to it. However when I use the "umount ..." command it returns
instantly (should sync the files to the card). The system says the card
is unmounted (at least it is not listed with mount, df etc).
However if I run sync, there is a lot of disk activity to the card ...
Also if I try and run "mkfs" it says the device in in use ...
If I mount a blank card it lists the files present on the previous card ...
This sounds like a nasty kernel bug ...
Anyone else seen this ?
Cheers
Terry
8 years, 11 months
RFC: Primary architecture promotion requirements
by Matthew Garrett
This is very much a draft, but I'd like to start a discussion regarding
what we expect from primary architectures. Feedback not only welcome,
but actively desired.
-------------------------------------------------------------------------
Secondary architectures in Fedora are subject to looser constraints than
primary architectures for two primary reasons:
1) To make it easier to bootstrap an architecture without the overhead
of the primary architecture release engineering process
2) To avoid primary architecture development being held up by poorly
developed or niche architectures
Promoting an architecture to primary architecture status is a
significant responsibility. It implies that the port is sufficiently
mature that little in the way of further architecture-specific changes
or rebuilds will be required, and also that it has enough development
effort to avoid it delaying the development of other primary
architectures. Further, it means that the architecture becomes part of
the overall Fedora brand. Fedora is an integrated Linux distribution
rather than a technology collection, and as such there are various
expectations that the overall Fedora experience will be consistent over
all primary architectures.
In order to ensure that these expectations are met, secondary
architectures must meet various criteria before they can be promoted:
1) There must be adequate representation for the architecture on the
Fedora infrastructure and release engineering teams.
2) All builds must occur on Fedora-maintained build servers.
3) Where technically possible, all supported hardware targets must be
supported via Anaconda. Exceptions are limited to highly resource
constrained devices or hardware which provides no means for simultaneous
support of install and target media.
4) All supported platforms must have kernels built from the Fedora
kernel SRPM and enabled by default in the spec file. Each kernel must be
built in a timely manner for every SRPM upload.
5) Sufficient developer resources must be available to fix any
architecture-specific issues in such a way that they do not delay
overall Fedora development.
6) It must be possible for maintainers of critical-path hardware
dependent packages to have direct access to supported hardware in order
to rectify any release-blocking issues. For example, X maintainers must
have direct access to any hardware with graphics capabilities.
7) The port must not rely on sourceless binaries unless they fall under
the generic firmware exemption. Where source and toolchain are
available, the binaries must be built in the Fedora build
infrastructure.
As such, promotion to primary architecture status will require agreement
from the Fedora infrastructure, release engineering, kernel and
installer teams and is subject to overall approval by the Fedora
Steering Committee.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
8 years, 11 months
