Alpine
by Jeremy Sanders
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/
16 years, 7 months
Need help packaging proftpd
by Philip Prindeville
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
16 years, 7 months
Python Egg Draft 3
by Toshio Kuratomi
-----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-----
16 years, 7 months
Python Eggs Draft 2
by Toshio Kuratomi
-----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-----
16 years, 7 months
Review Guidelines simplifications
by Till Maas
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
16 years, 7 months
Use of conflicts in package splitups
by Till Maas
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
16 years, 7 months