March 2007 - packaging - Fedora Mailing-Lists

by Michael Thomas

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

16 years, 3 months

4
10
0 / 0

license for concurrent package

by Permaine Cheung

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/intr...): '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...) 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

17 years

3
3
0 / 0

Is this license okay for a fedora package?

by Jarod Wilson

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

17 years

5
13
0 / 0

[DRAFT] Post Release Naming/Tags

by Tom Callaway

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

17 years

10
21
0 / 0

Building a set of packages where some BuildRequire others

by Mary Ellen Foster

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/

17 years, 1 month

6
9
0 / 0

Licensing issue in mantis

by Gianluca Sforna

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?

17 years, 1 month

3
6
0 / 0

FESCO responses to PC drafts 2007-03-29

by Jason L Tibbitts III

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<

17 years, 1 month

2
1
0 / 0

Packaging of ruby gems

by David Lutterkort

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/

17 years, 1 month

2
2
0 / 0

Missing meeting on 2007-04-02

by David Lutterkort

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

17 years, 1 month

1
0
0 / 0

to fuse- prefix or not to fuse- preifx

by Thorsten Leemhuis

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

17 years, 1 month

3
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging March 2007