packaging February 2009

packaging@lists.fedoraproject.org

45 participants
27 discussions

Aperi Storage Management Project for Fedora
by Kiran Patil 09 Feb '09

09 Feb '09

Hello Friends, 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. -- Kind Regards, --------------------------------------- Kiran T Patil (Director) Green Turtles Technologies direct: +91-80-41728133 www.greenturtles.in

1 0

Reviewer needed
by Henrique Junior 06 Feb '09

06 Feb '09

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?!"

1 0

Re: Too many unowned directories
by Nicolas Mailhot 04 Feb '09

04 Feb '09

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

1 0

ExplicitRequires/Commenting Drafts
by Toshio Kuratomi 03 Feb '09

03 Feb '09

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

1 0

Stupid question
by Jeroen van Meeuwen 03 Feb '09

03 Feb '09

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

4 5

gfortran modules directory owning?
by Patrice Dumas 03 Feb '09

03 Feb '09

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

2 2

Remove "Encoding=UTF-8" from sample desktop file
by Milos Jakubicek 02 Feb '09

02 Feb '09

Hi, 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: Encoding=UTF-8 which is deprecated according to: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-late… 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? Regards, Milos Jakubicek

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2009