Are you planning to package "Aperi Storage Management Project" in Fedora ?
Project website: http://www.eclipse.org/aperi/
Let me know, how can I help in this regard.
Kiran T Patil (Director)
Green Turtles Technologies
I need a benevolent reviewer for this package . Could someone help me?
pdumpfs is a simple daily backup system similar to Plan9's dumpfs which
> preserves every daily snapshot. pdumpfs is written in Ruby. You can
> access the past snapshots at any time for retrieving a certain day's
> file. Let's backup your home directory with pdumpfs!
 - https://bugzilla.redhat.com/show_bug.cgi?id=480857
Henrique "LonelySpooky" Junior
"In a world without walls and fences, who needs windows and gates?!"
Just to be clear: the directory ownership page says something like "if
you have multiple packages that use the same directory and do not depend
on a common package that owns it they can all own this directory in
But with fonts we have cases where
1. the common package exists for other reasons, or
2 it's only there to own the common directory.
In case 2. the guidelines clearly allow dropping common and using
multiple ownership. My problem is case 1.: is it ok for each subpackage
to own the directory it installs fonts to, even though it depends on a
common package that already owns it for other reasons (for example, to
put core fonts indexes in it)?
Because making the font subpackage macro auto-own the font dir in all
cases is trivial, would simplify the templates and avoid packaging
errors, but detecting the presence of a common subpackage to avoid the
auto-owning in that case is *not* trivial at all.
NB: in all this discussion the "common" subpackage is created from the
same srpm and never shared with subpackages from another srpm
Since we passed this again with minor changes but one of FESCo's
comments seemed to be that they thought the two changes were being
proposed as a whole, I'm going to split this into two pages. Explicit
Requires will keep the :MUST: and the == Explicit Requires == section.
The new, Non-obvious spec file items will have the :Should: and ==
Non-Obvious Items in Spec Files == section.
The text of both sections will remain unchanged. (spot has already
updated for the FHS removal).
Holler at me if you think this violates our rules.
I've taken over the ruby package, which basically is the first
core-component piece of software on my relatively small list of packages.
Attached is a patch that was in ruby-1.8.6, and that I rebased to
ruby-1.8.7. Since it's a really simple patch, I wonder why it's not
I'm not sure what this fixes, in that ruby will build without the patch
as well. I've searched through the logs to see if there's some kind of
warning related to socket.c, but there is none from what I can tell.
I'd love to learn what this patch does and then try and get upstream to
accept it (so that I have less work to do). Can someone on this list
help me with this?
Thanks in advance,
Jeroen van Meeuwen
Some time ago a guideline for gfortran modules directory was accepted:
First I think this should be in the guidelines, %_fmoddir is in since
Second, there is an issue with directory ownership. The directories
in that proposal, for .mod files, are not owned by any package:
One possibility could be to have libgfortran own them, that way
libraries dynamically linked whould bring in libgfortran and the
directories. However for libraries linked statically, this doesn't work
since they don't depend explicitly on libgortran, but they depend on
gcc-gfortran adding the right link information when doing the link.
The guideline is not to require the compiler for -devel packages, unless
I am missing something. As a side note, since gcc-gfortran is not in
the minimal buildroot it has to be a BauildRequires, though.
I see 2 possibilities to solve that issue:
* put %_libdir/gfortan %_libdir/gfortan/modules in filesystem
* do an addition to the guideline PackagingDrafts/FortranModulesDir to
have library linked statically by gfortran and installing .mod files
have an explicit dependency on gcc-gfortran.
What's your opinion?
A bugzilla for directory ownership issue:
yesterday when reviewing a package I noticed that although we have a
MUST: follow the desktop-entry-spec in the Guidelines, the example on
that page includes a line with:
which is deprecated according to:
We should get rid of that line, as some people (including me) are taking
that sample as a basis when creating new desktop files, shouldn't we?