Am I getting the warning below because there is a period in the lib name?
mygui-devel.i686: E: invalid-soname /usr/lib/libMyGUI.OgrePlatform.so
If so, is it really an error?
I'm starting to take a look at the heimdal package review:
https://bugzilla.redhat.com/show_bug.cgi?id=613001
heimdal is an alternative kerberos implementation to MIT-Kerberos. I'm
assuming we will want to explore the use of alternative to allow coexistence.
One trick part it for EL6 support. I'm assuming that there really is no way
we'll get alternatives support into the RHEL6 krb5 package. In that case is
it acceptable to fall back to the /usr/heimdal/ prefix for the package?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
My upstream source contains .gif files that are not essential. If I delete
these file and never use them, can I use this tarball as my pristine source,
or must I resource?
Thank You.
P.S. there are a lot of complicated rules to create a package.
--
Paul Elliott 1(512)837-1096
pelliott(a)BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
Here are the changes to the Fedora Packaging Guidelines for this week:
---
The Packaging:PHP guidelines have been updated to reflect that PEAR
documentation provided by upstream are installed in %{pear_docdir},
should stay there, and must be marked as %doc.
Additionally, the definition of pear_docdir has been defined as
%{_docdir}/pear.
https://fedoraproject.org/wiki/Packaging:PHP
---
The Java guidelines have been updated to add information and sample
template for Maven 3 (Fedora 15+).
https://fedoraproject.org/wiki/Packaging:Java
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Remi Collet, Stanislav Ochotnicky, and all of the members
of the FPC, for assisting in drafting, refining, and passing these
guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~spot
Here are the latest set of changes to the Fedora Packaging Guidelines:
---
The Emacs packaging guidelines were updated to handle cases where a
package's principal functionality does not require (X)Emacs, but the
package also includes some auxiliary Elisp files to provide support for
the package in (X)Emacs.
https://fedoraproject.org/wiki/Packaging:Emacs
---
The Scriptlet Snippets section dealing with the order that scriptlets
are invoked has been updated to include %trigger scripts.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Orderi…
---
A subsection was added to the Packaging Guidelines section on Filesystem
Layout in which it is made explicit that binaries in /bin or /sbin must
NOT depend on any libraries in /usr/lib or /usr/lib64.
https://fedoraproject.org/wiki/Packaging:Guidelines#Binaries_in_.2Fbin_and_…
---
The section on Epochs was improved, and clarifying language about Epoch
use in Requires was added to the Packaging Guidelines.
https://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_Epochshttps://fedoraproject.org/wiki/Packaging:Guidelines#Requires
---
New guidelines were added covering the packaging of Ada programs.
https://fedoraproject.org/wiki/Packaging:Ada
---
The section on Boostrapping in the Treatment of Bundled Libraries page
in the Packaging Guidelines has been amended to add the following:
Packages which are built in such a bootstrapping mode must not be tagged
for a final release (or pushed as an update for any stable release). FPC
will track the progress of approved bootstrapping exceptions via the
ticket requesting the bootstrap bundling exception.
https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries#Boo…
---
Macro forms of system executables (such as %{__rm}) should not be used
except when there is a need to allow the location of those executables
to be configurable.
https://fedoraproject.org/wiki/Packaging:Guidelines#Macros
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Hans Niedermann, Jonathan Underwood, Pavel Zhukov, and
all of the members of the FPC, for assisting in drafting, refining, and
passing these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~spot
Hi all,
Juha Tuomala (IRC: Tuju) and I were wondering if we should get
MySQL-python renamed. The rationale is that these days we sometimes have
several Python stacks on the same release, and it would be nice to be
easily able to see which packages have been rebuilt or not (e.g.
python26-PKG, python-PKG, python3-PKG).
MySQLdb (current name: MySQL-python) seems to get its name from the
released tarball. Juha wants to package a python26 build of MySQLdb but
prefers a python26- prefix. Question:
1) should it go ahead, with the main MySQLdb package not renamed, or
should the python26 package name always correspond to its "default
Python" counterpart?
2) if we are renaming, should it be to python*-MySQLdb? that's what the
Python module is called. or to python*-mysql ?
Thanks,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
I have a question regarding the use of ExclusiveArch.
At https://fedoraproject.org/wiki/Architectures#ExcludeArch_.26_ExclusiveArch
it says that only packages which are exclusively architecture-specific should
use ExclusiveArch. Is it appropriate to extend this to packages which aren't
architecture-specific themselves, but which depend on a package that is
available only on some architectures?
The reason why I'm asking is that some packages with Ada code which I maintain
can't be built on architectures where Gnat, the Ada compiler, is unavailable,
and apparently this annoys the people who work on secondary architectures. The
proposed workaround is to add ExclusiveArch entries to the Ada packages,
listing the architectures where the gcc-gnat package is available, and then
update those entries when someone manages to bootstrap Gnat on a new
architecture. I'd like to know if this use of ExclusiveArch is acceptable, or
if I'll run the risk of being told that it's against the rules and must be
removed.
Björn Persson
I raised a very old practice about PEAR doc files
Please, read https://fedorahosted.org/fpc/ticket/69
Regards,
Remi.
P.S. keeping doc files in standard %{pear_docdir} will make spec files
cleaner / simpler.
The draft page has been updated to only reflect guidelines for new services
so that FPC can try to work on and vote on it and then work on and vote on
migration separately if necessary.
The scriptlets are on
https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft
Some idea for testing are on:
https://fedoraproject.org/wiki/User:Toshio/Testing_systemd
The top few test cases are written out step by step with expected output...
But there's really a whole matrix of tests and many of the tests that should
be run are just mentioned as "Do the same as above but change this one
aspect". If you run those tests and record how you did them it will make it
easier to test the scriptlets again when we add the migration portions.
-Toshio