Heads up - Ogre 1.8.1 rawhide
by Martin Preisler
Hi,
I want to push Ogre 1.8.1 into rawhide next week. This will most likely break some packages but we have a lots and lots of time to fix it all up in rawhide. The changes in Ogre API aren't extensive enough for this to be a real risk and we can always revert. The most common break is Ogre::Singleton<..>::ms_Singleton being renamed to Ogre::Singleton<..>::msSingleton.
As I am not a provenpackager I will need some cooperation from maintainers of pkgs depending on Ogre.
--
Martin Preisler
11 years, 4 months
LibRaw: possible license issues
by Debarshi Ray
I came across what looks like a possible licensing issue with LibRaw and
applications that link to it. I am not totally sure that there is a problem,
but I have enough reason to have doubts. I welcome any clarifications and
advice.
LibRaw's License tag was changed from "LGPLv2 or CDDL" to GPLv3 when the two
demosaic packs were added [1]. One of the demosaic packs is GPLv2+ and the
other is GPLv3+.
However, http://www.libraw.org/ mentions LibRaw's license as GPLv2+, while the
source files continue to claim that they are under LGPLv2 or CDDL.
Shotwell, which uses LibRaw, is LGPLv2+. By my reading of the compatibility
matrix [2], it means that Shotwell is now effectively GPLv3. If that is the
case, then has Yorba been notified of that? I doubt they would suddenly want
their code to become GPLv3 instead of LGPLv2+.
Thanks,
Debarshi
[1] https://bugzilla.redhat.com/show_bug.cgi?id=760638
[2] https://fedoraproject.org/wiki/Licensing:Main#GPL_Compatibility_Matrix
--
There are two hard problems in computer science: cache invalidation, naming
things and off-by-one errors.
11 years, 4 months
projectM
by Jameson
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.
Thanks,
=-Jameson
11 years, 4 months
Re: RFC: Feature process improvements
by John Dulaney
I would suggest that we create a clear SOP for fall back planning in case
a feature, especially a crit path feature, is not ready for prime time.
Obviously, if a feature is not %100 by feature freeze, then it needs to be
dropped. I would even venture to suggest that we include in the SOP
something along the lines of "If feature is not 80% by point X (X being two
weeks prior to freeze), then FESCo should at that point evaluate enacting
the fall back."
John.
11 years, 4 months
Yum Package Remove Order
by Mark Bidewell
I have been working on packaging software into RPMs for my company. These
RPMs create directories in %post into which dependent RPMs install
components. If I yum remove the main package it will be erased first by
yum prior to erasing the dependent packages. When the uninstall scripts
for the dependent packages run, they may fail due to files and directories
being missing that they expect from the main package leaving things in an
inconsistent state. Is this a bug or known behavior we need to account for
in some way?
Thanks.
--
Mark Bidewell
http://www.linkedin.com/in/markbidewell
11 years, 4 months