Reviewer needed
by Henrique Junior
Hello, everybody,
I need a benevolent reviewer for this package [1]. 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!
>
>
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=480857
Thanks
--
Henrique "LonelySpooky" Junior
http://www.lonelyspooky.com
-------------------------------------------------------------
"In a world without walls and fences, who needs windows and gates?!"
15 years, 2 months
Re: Too many unowned directories
by Nicolas Mailhot
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
parallel".
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
--
Nicolas Mailhot
15 years, 2 months
ExplicitRequires/Commenting Drafts
by Toshio Kuratomi
Hey guys,
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.
-Toshio
15 years, 2 months
Stupid question
by Jeroen van Meeuwen
Hey there,
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
upstream.
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,
Kind regards,
Jeroen van Meeuwen
-kanarip
15 years, 2 months
gfortran modules directory owning?
by Patrice Dumas
Hello,
Some time ago a guideline for gfortran modules directory was accepted:
http://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
First I think this should be in the guidelines, %_fmoddir is in since
F10.
Second, there is an issue with directory ownership. The directories
in that proposal, for .mod files, are not owned by any package:
%_libdir/gfortan
%_libdir/gfortan/modules
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:
https://bugzilla.redhat.com/show_bug.cgi?id=483469
--
Pat
15 years, 2 months
