packaging March 2007

packaging@lists.fedoraproject.org

38 participants
30 discussions

Tcl packaging guidelines proposal
by Michael Thomas 03 Jan '08

03 Jan '08

I sent this proposal to f-m-l about a week ago to gather comments, and there were no serious disagreements with the proposal which have not yet been addressed (thanks to Tibbs and Toshio for their feedback). Basically, I want to establish a set of guidelines for packaging Tcl extensions, as we already have guidelines for other popular scripting languages. In addition to making Tcl packages more consistent with each other, it will also help work toward fixing my pet-peeve bug (bz #226893) http://fedoraproject.org/wiki/PackagingDrafts/Tcl Please let me know if I need to do anything to help get these draft guidelines adopted. Thanks, --Wart

4 10

license for concurrent package
by Permaine Cheung 05 Apr '07

05 Apr '07

Hi, The concurrent package in core has stated the following (under the Notes section of its URL http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.…) 'All classes are released to the public domain and may be used for any purpose whatsoever without permission or acknowledgment. Portions of the CopyOnWriteArrayList and ConcurrentReaderHashMap classes are adapted from Sun JDK source code. These are copyright of Sun Microsystems, Inc, and are used with their kind permission,' (link is http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/sun-u.c.license.p…) And further down from that page it states: 'Do I need a license to use it? Can I get one? No!' Is this okay? Thanks, Permaine

3 3

Is this license okay for a fedora package?
by Jarod Wilson 03 Apr '07

03 Apr '07

I'd like to package up Maia Mailguard, and the license appears to be original BSD (advertising clause included) with a branding extension added. Thoughts? http://www.maiamailguard.org/license.php -- Jarod Wilson jwilson(a)redhat.com

5 13

[DRAFT] Post Release Naming/Tags
by Tom Callaway 01 Apr '07

01 Apr '07

I have added a draft for handling Post Release packages. http://fedoraproject.org/wiki/PackagingDrafts/PostRelease Comments are always welcomed. ~spot

10 21

Building a set of packages where some BuildRequire others
by Mary Ellen Foster 30 Mar '07

30 Mar '07

I'm currently trying to create Fedora-compliant packages of the Internet Communications Engine (Ice) -- object-oriented middleware, see http://www.zeroc.com/ for details. They used to provide a yum repository for Fedora, but with the new version they've stopped. I'm now working on adapt their SRPMS to Fedora packaging standards. (If anyone else has done / is doing this, let me know!) I've managed to create a few packages, in the process learning a lot more about RPM tricks and so on. One issue I'm having -- and I'm pretty sure it's unavoidable -- is that many of the packages have build-time requirements on other packages. For example, the tool to translate ice interfaces into Java code is called "slice2java" and is part of the ice-java-devel package; this tool is then needed to build the ice-java runtime package. What's the accepted way of building something with this type of constraints in mock? Should I just build temporary versions of the necessary tools as needed (e.g., let ice-java compile its own version of "slice2java" just for use in the build process)? I'd rather not do that, but if it's necessary I can do things that way. Thanks for any suggestions! MEF -- Mary Ellen Foster http://homepages.inf.ed.ac.uk/mef/

6 9

Licensing issue in mantis
by Gianluca Sforna 30 Mar '07

30 Mar '07

sorry for the duplicate post, but I am afraid fedora-extras-list was not the best place for this... ---------- Forwarded message ---------- From: Gianluca Sforna <giallu(a)gmail.com> Date: Mar 30, 2007 10:41 AM Subject: Licensing issue in mantis To: Discussion related to Fedora Extras <fedora-extras-list(a)redhat.com> Mantis (php) codebase includes a module which comes from a 3rd party project and is licensed with a "free for non commercial use" style clause which is, AFAICT, incompatible with the GPL. Is removing the offending file from the rpm package during %install enough? Is upstream compelled to remove it as well?

3 6

FESCO responses to PC drafts 2007-03-29
by Jason L Tibbitts III 30 Mar '07

30 Mar '07

I figure it's worth writing this up. PackagingDrafts/PostRelease FESCO approves, but Warren would like a comment added to the effect that packagers should document in the specfile any weird upstream versioning conventions which they're trying to massage into a sortable RPM EVR. I indicated that I did not believe that the PC would have any issue with adding such a comment. PackagingDrafts/ExtraDistTagConditionalMacros FESCO is onboard here, but the issue is down to implementation. And of course there's an ongoing thread in fedora-devel. PackagingDrafts/Utf8Filenames FESCO approves. - J<

2 1

Packaging of ruby gems
by David Lutterkort 30 Mar '07

30 Mar '07

At long last, I wrote up a guideline [1] for packaging ruby gems, ruby's own packaging format; since almost any ruby library is packaged as a gem, and some of them provide no other way of installation, it becomes increasingly important to enable packaging of gems for Fedora. At the same time, it is fairly easy to automate most of this process[2], which hopefully means that lots of people will submit packages of ruby gems. You can find some examples of ruby gems packaged as rpm's on my people page [3] - look for specfiles called 'rubygem-*' David [1] http://fedoraproject.org/wiki/PackagingDrafts/RubyGems [2] http://people.redhat.com/dlutter/gem2spec.html [3] http://people.redhat.com/dlutter/yum/spec/

2 2

Missing meeting on 2007-04-02
by David Lutterkort 30 Mar '07

30 Mar '07

Hi guys, I will have to miss the next meeting since I will be locked all day in a conference room somewhere. sorry, David

1 0

to fuse- prefix or not to fuse- preifx
by Thorsten Leemhuis 28 Mar '07

28 Mar '07

Hi, I searched for a fuse solution for ftp/gmail today and noticed that we have four fuse files systems with fuse- prefix in Fedora: $ yum list fuse-* [...] fuse-convmvfs.i386 0.2.3-2.fc7 fuse-encfs.i386 1.3.1-3.fc6 fuse-smb.i386 0.8.5-5.fc7 fuse-sshfs.i386 1.7-2.fc6 [...] And at least two without: $ yum list ntfs-3g curlftpfs [...] curlftpfs.i386 0.9-3.fc7 ntfs-3g.i386 2:1.0-1.fc7 [...] :-( Do we care about that mismatch? Should we rename the two latter in the long term just to be consistent? I tend to say "yes", so users that search like I did (yum list fuse-*) don't get taken into the wrong direction. Yes, it's just a small detail, but having some package with prefix and some without is IMHO just confusing. CU thl

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging March 2007