packaging July 2009

packaging@lists.fedoraproject.org

45 participants
32 discussions

Feedback on documentation
by Bruno Wolff III 14 Jul '09

14 Jul '09

I am a new packager following: http://fedoraproject.org/wiki/PackageMaintainers/Join And read the following note: Running ssh-add before doing any cvs operations is a very good idea. It will save you from having to type your key password for every operation. You only have to run ssh-add once per session, it will remember it until you log out or reboot. If "ssh-add" reports "Could not open a connection to your authentication agent.", start a new shell under it using "exec ssh-agent bash". However I was never asked for a password. I assume that my Fedora cert is just being picked up. Did I do something odd or is this note out of date?

2 1

EclipsePlugins guideline need a one line modification
by alcapcom 13 Jul '09

13 Jul '09

Hi there, Can you please apply the attached patch to the EclipsePlugins guideline - It only modify eclipse-mylyn link. Thanks, Alphonse

1 0

/srv usage
by Philippe Makowski 10 Jul '09

10 Jul '09

Hi, I would like to know if there is any rule about using /srv ? Firebird package need a place to store databases files, and reading the FHS rules, it seems that it is the right place for that instead of /var/lib

5 9

Version name for prerelease when upstream used date based versions
by Bruno Wolff III 10 Jul '09

10 Jul '09

I am looking a the suggested version name for a prerelease when upstream uses dates for their versions. I am close to having a package (colossus) ready, but one sticking point is that upstream is probably a week or two away from putting up a new public build (essentially a snapshot they want to recommend to general users). The code has changed a lot since their last public release, so that a snapshot now is really much more of a prerelease package than a post release. Some things have changed from the last public build to make it more suitable for packaging in Fedora, so packaging that version isn't very practical. Upstream is considering changing to more normal version names, but probably won't make such a change before the next public build. I could hold off on putting the package into rawhide until after they make the next public build making the issue moot. (I wasn't going to put the package into a released version of Fedora until then in any case.) I could also use a current date for the version of the package, but that won't correspond to any actual release made by the upstream. I could also use the date of the last public build even though the code has diverged since then. (I am not sure if the interface has changed much since then since for my own use I have been running current svn check outs for over a year and don't use the public build versions.)

4 5

Packaging RPM workflow
by Shakthi Kannan 08 Jul '09

08 Jul '09

Hi, I have tried to put a very brief, to the point documentation on packaging RPM work-flow to be used for newbie packagers: http://shakthimaan.com/downloads/glv/howtos/packaging-rpm-workflow.html I'd appreciate any feedback on the same -- something that I have missed, or that needs to be added, modified, or fixed in the documentation. Thanks! SK -- Shakthi Kannan http://www.shakthimaan.com

5 7

Fwd: Python package distribution standards
by Jon Stanley 07 Jul '09

07 Jul '09

If you are interested in Python packaging standards and not subscribed to the distributions list (where cross-distro collaboration happens), now would be a good time to do so :) ---------- Forwarded message ---------- From: Ben Finney <ben+freedesktop(a)benfinney.id.au> Date: Tue, Jul 7, 2009 at 9:21 AM Subject: Python package distribution standards To: distributions(a)lists.freedesktop.org Cc: Distutils-Sig(a)python.org Howdy all, I'm cross-posting between the Python distutils discussion forum and the Freedesktop distributions discussion forum. If you think any OS-specific discussion forums need to be involved, please ask a representative to join one or more of these forums so the discussion doesn't get too attenuated. For a number of weeks now, the Python package distribution standards have been undergoing intensive scrutiny in the wake of much face-to-face discussion at Pycon 2009. Many goals are being juggled in an attempt to get a beneficial result for everyone affected by these standards. The discussion has reached a point of some “open questions” <URL:http://article.gmane.org/gmane.comp.python.devel/105237> on the current draft of PEP 376 <URL:http://www.python.org/dev/peps/pep-0376/>, which has re-raised the issue of how Python distribution standards could be improved with regard to OS distribution packaging requirements. I've made a case for metadata that would be beneficial to OS packagers <URL:http://thread.gmane.org/gmane.comp.python.devel/105237/focus=105270>, but I am not very cognizant of the needs of specific OS packaging systems. We need input from others who know and care about how Python packages should fit into specific operating system package management systems. If you feel you have constructive input on how Python's package distribution metadata can be improved for the needs of OS packagers (along with other needs being targeted by such metadata), please read the standards drafts, join this discussion, and weigh in now while the topic is hot. -- \ “The industrial system is profoundly dependent on commercial | `\ television and could not exist in its present form without it.” | _o__) —John Kenneth Galbraith, _The New Industrial State_, 1967 | Ben Finney _______________________________________________ Distributions mailing list Distributions(a)lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/distributions

1 0

Use of optimization flags
by Susi Lehtola 07 Jul '09

07 Jul '09

Hi, atlas is not using %{optflags} at the moment [1], which results among other things in empty debuginfo files. Should this issue be raised with FeSCo? [1] https://bugzilla.redhat.com/show_bug.cgi?id=509813 -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

3 2

Should Scintilla be package as a shared library ?
by Remi Collet 06 Jul '09

06 Jul '09

Hi, http://www.scintilla.org/ is a free source code editing component. Upstream provides only a makefile for a static library. Of course, it's quite easy to create a shared library, but without versionning as upstream doesn't handle this. At least scite (in fedora repo) use this library, but probably other projects (I have no way to detect this). I'm working in MySQL Workbench, which also use it (and some other bundled libraries, as curl, boost, ..., more easy to remove) What sould I do ? - package scintilla as a shared lib (this will imply rebuilding all applications on scintilla update and probably issue with applications using different version) or - package MySQL Workbench with the bundled scintilla (the simple solution, but against good pratices) Thanks for your comment on this. Remi.

4 4

License reference for additional, non-essential example files of a package
by Federico Hernandez 06 Jul '09

06 Jul '09

Hi! The upstream project has some additional, non essential files (in this case vim syntax files which the upstream project "make install"s under the docdir). How should these reference to a license information? Do they have to include a license information? I ask as Bram Moolenaar has asked the upstream project to not have any license reference in the syntax files (the upstream project has submitted them to be included in the vim distribution). Would a reference to the license in a corresponding README file be enough? /Federico

2 1

Re: About my proposal of moving the stage to expand gem files
by Jeroen van Meeuwen 03 Jul '09

03 Jul '09

On Sat, 04 Jul 2009 02:32:49 +0900, Mamoru Tasaka <mtasaka(a)ioa.s.u-tokyo.ac.jp> wrote: > Hello, all: > > Two weeks ago I wrote the proposal to move the stage to expand > rubygem files from %install to %prep as: > > https://www.redhat.com/archives/fedora-packaging/2009-June/msg00069.html > https://fedoraproject.org/wiki/PackagingDrafts/Gem_expand_stage_change > > I would appreciate it if you would write some opinion for my proposal > on fedora-packaging mailing list. > In my opinion, the guidelines requiring the use of the .gem instead of the .zip/.tar.gz is the root cause of the problem. If only we are allowed to use the .zip/.tar.gz, then in most cases we could extract the .zip/.tar.gz in %prep, apply patches in %prep, build the .gem in %build (if needed), do additional compiling in %build, and properly install in %install. I've never really understood the requirement to use the .gem anyway, so maybe that's what I'm missing. --Jeroen

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2009