packaging September 2007

packaging@lists.fedoraproject.org

29 participants
24 discussions

Start a nNew thread

Unable to attend meeting on 9/18
by David Lutterkort 17 Sep '07

17 Sep '07

I won't be able to attend, sorry. David

1 0

Alpine
by Jeremy Sanders 17 Sep '07

17 Sep '07

I see there is source for Alpine 0.9999 available. This is an "alpha" release of a replacement for the text user interface Pine mail client. See http://www.washington.edu/alpine/ and ftp://ftp.cac.washington.edu/alpine/ The advantages of this over the old Pine is that the source code has been reorganised and it now uses the free Apache License (version 2). This could added to Fedora now (unlike the original Pine). I'm not sure how many Fedora users are still addicted to Pine (like me). I wonder whether it would be a good idea to package up soon before it is finally released (they have a source rpm available, but I haven't looked at it yet). I believe it also has a web interface version, which could be interesting. I've been running the text mode client for a bit now and the quality already looks good - it seems at least as good as Pine at the moment. Jeremy -- http://jeremysanders.net/

2 1

Need help packaging proftpd
by Philip Prindeville 15 Sep '07

15 Sep '07

I'm trying to get a .spec polished and checked in for the release of proftpd-1.3.1, but I'm having a few issues with it. If anyone has the time to offer some assistance, I'd appreciate it. I'm not an RPM guru... I've skimmed Maximum RPM a couple of times a year or two ago. I just want to get a more recent build of proftpd into the Fedora distro space, and the way to do that is with a proper .spec file in the source tree. Contact me offline if you can provide some comments/guidance. Thanks, -Philip

2 2

Python Egg Draft 3
by Toshio Kuratomi 13 Sep '07

13 Sep '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs This is the third round of the Python Egg Draft. It contains changes proposed at today's packaging meeting. # Sep 11, 2007 -- Add note that all eggs must be rebuilt from source. * Add summary of egg on-disk formats. * Revise where this information will be placed in the Guidelines. o Make most of it its own page o Add a short checklist of Must/Shoulds to go on Packaging/Python. And from slightly before the meeting: * Make the switch for eggs within distutils be F9 instead of F8 after talking with Jeremy. o Add some mailing list discussions to the links section. o Add a sample README.fedora file. I think I got everything except virtual Provides and virtual Requires. I'd like to make that a separate change to be discussed after we make sure we'll switch distutils egg generation on for F9. My reasoning is this: * Currently python doesn't have virtual provide symbols like perl or php do. * If we turn on egg generation in distutils, practically every python module is going to have egg-info. So if we start now with two separate namespaces python-egg(MODULE) and python(MODULE), by F-9 we could have everything using python-egg(MODULE) and next to nothing using python(). There are some little wrinkles in this and it may also be affected by Panu's work on a python-dependency-extractor for rpm. I'll send out a message on this shortly. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG5xeXX6yAic2E7kgRAmEgAJ0R8LghRVkxT7vW0GZEtqsxU68uCwCeJaTD Mpvw4V80emv4avD2+qbwnyM= =Tg9k -----END PGP SIGNATURE-----

2 4

missing FPC meeting today
by Rex Dieter 11 Sep '07

11 Sep '07

I'll likely not be able to attend today, gotta baby-sit the car in the shop. -- Rex

1 0

Python Eggs Draft 2
by Toshio Kuratomi 10 Sep '07

10 Sep '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Draft 2 of the new Egg guidelines. I'm continuing to test things out so things might change a little. However, these are my current thoughts on how we can best use eggs in the distro and even if they change in specifics of spec file scripts, the general thrust is going to remain the same. http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs The basics are: Support eggs for all distutils and setuptools packages from f8 on. This depends on us reverting to upstream python WRT distutils in python-2.5. Jeremy, I've started testing what this changes but I need your input on whether we can make this change or not. Support for eggs for setuptools and distutils-only-when-required to make other packages work on f7 and below. Support for multi versions through eggs knowing that there's no API within setuptools that is "reliable" for making switching of versions work. A quick and dirty method that hacks the PYTHONPATH and involved method that makes using setuptools mandatory are documented as well as the problems that could occur with pkg_resources.require() and __require__. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG5d6lX6yAic2E7kgRArK5AJkBoBY2CD7m8sBCcS5JhVLyNappSQCfaAob vs5J5Z1+ORHjChflnyIbhkg= =le7v -----END PGP SIGNATURE-----

1 0

Packaging/NamingGuidelines python modules naming
by Till Maas 08 Sep '07

08 Sep '07

Aloas, http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-8756a3bce652c… states: | There is an exception to this rule. If the upstream source has "py" | (or "Py") in its name, you can use that name for the package. Maybe there should be another exception when upstream includes python it its name, e.g. fuse-python[1]. Should this be packaged as python-fuse or can it stay with upstream's name fuse-python? Should it provide python-fuse in case it stays with its upstream name? Regards, Till [1] Review Request: https://bugzilla.redhat.com/show_bug.cgi?id=250904

5 10

Guidelines for packaging PHP addon modules (draft => official)
by Remi Collet 08 Sep '07

08 Sep '07

Since http://fedoraproject.org/wiki/PackagingDrafts/PHP is approved, can someone push section 3&4 to the official page (or give me the right to do the job). Regards, Remi

2 1

Review Guidelines simplifications
by Till Maas 08 Sep '07

08 Sep '07

Aloas, I noticed that it is possible to build local srpm with the koji client on the Fedora buildsystem. Therefore I propose to change and simplify the following items from the Review Guidelines | - MUST: The package must successfully compile and build into binary rpms on | at least one supported architecture. | - SHOULD: The reviewer should test that the package builds in mock. | - SHOULD: The package should compile and build into binary rpms on all | supported architectures. | - MUST: All build dependencies must be listed in BuildRequires, except for | any that are listed in the exceptions section of Packaging Guidelines; | inclusion of those as BuildRequires is optional. Apply common sense. into: - MUST: The package must be build on the Fedora Buildsystem for rawhide with {{{koji build --scratch dist-f8 package-*.src.rpm}}} and the build must succeed for at least one supported architecture. The "dist-f8" parameter has to be changed in the Guidelines each time a newer is created or someone needs to create a rawhide alias tag, if this is possible. The advantages of this approach is that the SHOULD items will be tested without extra work for the reviewer. Also there is no way acceptable way to verify that all needed BuildRequires are listed in the spec. Therefore a successfull build on the Fedora Buildsystem should be enough. I have another change to propose: Change | - SHOULD: Usually, subpackages other than devel should require the base | package using a fully versioned dependency. into: - SHOULD: Usually, subpackages other than devel should require the base package with {{{Requires: %{name} = %{version}-%{release}}}} This makes it easier to copy and paste the required code and is easier to understand. Regards, Till

5 10

Use of conflicts in package splitups
by Till Maas 06 Sep '07

06 Sep '07

Hiyas, http://fedoraproject.org/wiki/Packaging/Conflicts says: | If you find yourself in a situation where you feel that your package has to | conflict with another package (either explicitly or implicitly), but does | not fit the documented accepted cases above, then you need to make your case | to the Fedora Packaging Committee. I guess here is such a case: https://bugzilla.redhat.com/show_bug.cgi?id=266261 knm_new-fonts was split up from fonts-japanese, therefore it conflicts with an older version for fonts-japanese. I have also two review requests (vbetool and radeontool), that are splitups from pm-utils, do they need to conflict with the old version of pm-utils, too? Regards, Till

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging September 2007