Bug 249365 - (alpine) Review Request: alpine - UW Alpine mail user agent
Review Request: alpine - UW Alpine mail user agent
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-07-23 19:49 EDT by Joshua Daniel Franklin
Modified: 2014-07-28 15:15 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-07 16:55:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rdieter: fedora‑review+
limburgher: fedora‑cvs+

Attachments (Terms of Use)

  None (edit)
Description Joshua Daniel Franklin 2007-07-23 19:49:05 EDT
Spec URL: http://staff.washington.edu/joshuadf/alpine/alpine.spec
SRPM URL: http://staff.washington.edu/joshuadf/alpine/alpine-0.999-2.src.rpm
Description: This is my first Fedora package, and I am seeking a sponsor.

Alpine is a tool for reading, sending, and managing
electronic messages.  Alpine is the successor to Pine and was
developed by Computing & Communications at the University of
  Though originally designed for inexperienced email users,
Alpine supports many advanced features, and an ever-growing number of
configuration and personal-preference options.
Changes and enhancements over pine:
  * Released under a new license, the Apache License, Version 2.0.
  * Internationalization built around new internal Unicode support.
  * Ground-up reorganization of source code around new "pith/" core routine library.
  * Ground-up reorganization of build and install procedure based on GNU Build System's autotools.
Comment 1 manuel wolfshant 2007-07-23 20:23:56 EDT
Quick glance over the spec:
- Ditch the vendor and packager tags; fedora build system will fill in the
correct values. See Packaging/Guidelines#tags for details
- Is the Conflict tag really needed? couldn't it be replaced with a proper
versioned Obsoletes?
- Are you sure that the Description tag needs the second and third paragraph?
For most users, those pieces of info will tell nothing
- Ditch the '[ "$RPM_BUILD_ROOT" != "/" ] &&' part from %clean and %install. It
is no longer needed for ages.
- It would be wiser to use the 4 arguments form of %defattr
- I have to recheck that, but I think Applications/Mail does not seem to be a
standard group
- Apache 2.0 does not seem to be the proper value for the license tag (according
to http://www.opensource.org/licenses/apache2.0.php I guess it should be "Apache
License, Version 2.0")
- last but not least, mock build fails with:
checking for make... /usr/bin/make
checking for setupterm in -ltinfo... no
checking for setupterm in -lncurses... no
checking for tgetent in -ltermlib... no
checking for tgetent in -ltermcap... no
configure: error: Terminfo/termcap not found
error: Bad exit status from /var/tmp/rpm-tmp.76610 (%build)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.76610 (%build)

Comment 2 Joshua Daniel Franklin 2007-07-24 14:34:35 EDT
Thanks very much for taking a look. I began with the SPEC provided at the
alpine download site, and will try to get the changes upstream. That's
also why this is release 2 instead of 1.

> - Is the Conflict tag really needed? couldn't it be replaced with a proper
> versioned Obsoletes?

I used the Conflicts tag instead of Obsoletes because there are important
differences between pine and alpine. For example, non-ASCII encoded saved
passwords will break because of the change to Unicode.  There are also many
patches to pine floating around that for political/technical reasons will
not be integrated into alpine. (I'd like to stay out of it... just search
"Mark Crispin maildir" for the gory details.) Since licensing prevents a
Fedora pine package, I have no idea what configuration users might have
and so want to warn them instead of automatically replacing their pine
install with an alpine that could break their configuration. (It is also
possible to run pine and alpine concurrently, but the names of /usr/bin/pico
and /usr/bin/pilot conflict.)

> Quick glance over the spec:
> - Ditch the vendor and packager tags; fedora build system will fill in the


> - Are you sure that the Description tag needs the second and third paragraph?

Well, I don't think a little more description hurts anything. The 2nd paragraph
is for non-technical users, and the 3rd for technical. I see that mutt has a
description similar to the 2nd paragraph:
"You should install mutt if you have used it in the past and you prefer
it, or if you are new to mail programs and have not decided which one
you are going to use."

> - Ditch the '[ "$RPM_BUILD_ROOT" != "/" ] &&' part from %clean and %install. It


> - It would be wiser to use the 4 arguments form of %defattr

OK, done.

> - I have to recheck that, but I think Applications/Mail does not seem to be a
> standard group

I changed it to "Applications/Internet" which is the same at mutt.

> - Apache 2.0 does not seem to be the proper value for the license tag (according
> to http://www.opensource.org/licenses/apache2.0.php I guess it should be "Apache
> License, Version 2.0")

I looks like it's been standardized on "Apache Software License":
I guess you only have to specify version if it's 1.1 or 1.0.

Here's a couple examples I found:
rpm -qi httpd tomcat5-jsp-2.0-api|grep License
Size        : 2572641                          License: Apache Software License
Size        : 143766                           License: Apache Software License

> - last but not least, mock build fails with:

OK, fixed. I was building on my existing RHEL4 build system which doesn't
have mock (yet?), but now I set up a Fedora 7 build system and used mock.
Building the autocache is wicked slow, maybe that could be mirrored.

New SPEC and SRPM are at the same places:

spec URL: http://staff.washington.edu/joshuadf/alpine/alpine.spec
SRPM URL: http://staff.washington.edu/joshuadf/alpine/alpine-0.999-2.src.rpm
Comment 3 Jima 2007-07-24 17:03:34 EDT
 I guess I should have publicized my (in-my-spare-time) efforts at packaging
Alpine more widely than in #fedora-devel and the alpine-alpha mailing list. :-P

 It looks like you caught most of the snags I did, but if you want to eyeball my
spec, see:


 Your rpdoc.patch and my alpine-manpages.patch are effectively identical, I see,
aside from the directory name being in mine (necessitating -p1 instead of -p0,
big whup).  I still hadn't made up my mind about whether the
s/%{version}/%{version}-%{release}/ is a good idea.

 I'd be happy to comaintain Alpine with you, although I can't sponsor you (as
I'm not a sponsor). :-(

 Also, you might want to fix your SRPM link to reflect the dist tag. ;-)
Comment 4 Jima 2007-07-24 17:54:31 EDT
 Once I got that out, I sat down to actually look over the differences between
our specs.

 My first and foremost concern is that your tarball still contains a file that a
number of Fedora developers have agreed is of fairly serious concern, namely,
pico/cc5.sol, due to this:

#       The copyright notice above does not evidence any
#       actual or intended publication of such source code.

 Steve Hubert from upstream said it'd be removed, but until it is, it's legally
dicey for us to even distribute it in the SRPM.  I've re-rolled my tarball to
reflect that.

 Beyond that, I have the following BRs you don't:

aspell-devel inews openldap-devel passwd sendmail

 My aspell-devel BR may in fact be the erroneous way to go about it; I was
merely going with the default, possibly autopilot, method to satisfy the
configure script's search for a spellchecker.  Your
--with-spellcheck-prog=aspell may well take care of that better than my
solution.  (Err, yeah, I think my BR didn't even help anything.  So you win
there. :-)
 The inews BR was simply to fulfill another "not found" in the configure script.
 Ditto on passwd and sendmail.  Your BR on /usr/sbin/sendmail will actually
probably cause exim to get pulled into the build chroot, due to it being the
shortest-named package providing that file.  I'm not sure if that actually
causes any problems.  Your Require on /usr/sbin/sendmail is another good thing I
didn't think of.
 I do believe, however, that my openldap-devel BR does enable LDAP functionality
in Alpine.  You may want to add that.

 I included /etc/pine.conf and /etc/pine.conf.fixed in my package.  The former
was actually generated from `alpine -conf` in the %install section, the latter
is just a placeholder with some explanatory text.

 I think I caught some things you didn't, but you definitely caught some I
flat-out screwed up on.  Yay for open source collaboration. :-)
 I'm throwing your package into mock to see what comes out.  Oh, done already. 
Nice.  Here we go:

W: alpine no-version-in-last-changelog
W: alpine-debuginfo no-version-in-last-changelog

-- you need to put the EVR of the package (without the dist tag -- in this case,
0.999-2) somewhere in the changelog entry, in one of the three formats.

W: alpine-debuginfo spurious-executable-perm
W: alpine-debuginfo spurious-executable-perm /usr/src/debug/alpine-0.999/pico/main.c

 Oh yeah, I forgot about them.  I had this in my %prep:

chmod -x alpine/arg.c pico/main.c

 Upstream said they'd fix that, IIRC.

 There was also (at some point) some oddness about mlock being included, but
I'll need to rebuild my package to verify that.
 Gotta go for now, but nice job with this package! :-)
Comment 5 Joshua Daniel Franklin 2007-07-24 19:22:40 EDT
Nice, I'd love to have a comaintainer, or you're even welcome to it
if you were excited about it. I've mostly done RHEL (see 
http://www.google.com/search?q=Joshua+Daniel+Franklin+site:redhat.com )
but I've maintained a few custom RPMs including pine for local users.
I just decided to package alpine since I didn't see why not since
it's now nearing 1.0. I turned off the alpine-alpha list after the
maildir issue came up again.

It's a good idea to include all functionality, I missed LDAP and
inews since I'm not using them, but I'm sure someone is. I can't
take credit for "/usr/sbin/sendmail" I copied from mutt's spec. :)
That's really all that's required, it can be really be exim or 
sendmail or whatever.

I don't think uw-imap-utils is required, mlock is a file-locking
program that shouldn't be needed at all on Linux and definitely 
not by alpine.

OK, I just added the changes, rebuilt and rsync'ed the updates.

Thanks for catching the SRPM distag issue, I symlinked the old URL 
but here are the links which match the mock-produced SRPM filename:

spec URL: http://staff.washington.edu/joshuadf/alpine/alpine.spec
SRPM URL: http://staff.washington.edu/joshuadf/alpine/alpine-0.999-2.fc7.src.rpm
Comment 6 Stephen John Smoogen 2007-07-25 16:51:43 EDT
Hmmm I was wondering if we could put this into 3 packages but I realized that it
might be hard to get them to work together ...

alpine       -- contains alpine
alpine-utils -- contains pico/pilot Conflicts with pine
                 for 80% solution I would look at the livna or rpmforge versions
                 of pine .
alpine-web   -- contains web bits.
Comment 7 Joshua Daniel Franklin 2007-07-25 17:40:22 EDT
Perhaps I'm taking the wrong approach, but my philosophy is that since
pine is not a Fedora package I have no way of providing compatibility
for whatever "pine" RPM a user might have installed. The differences
between what patches the RPMforge and Livna packagers decided to 
include is a good demonstration of what could go wrong (for example,

As mentioned in the spec, I disabled "Web Alpine". I am UW staff
so I am sometimes forced to use "WebPine" and it's OK if you
want a CGI frontend slapped onto pine, but isn't very impressive
compared to for example Squirrelmail.
Comment 8 Rex Dieter 2007-07-25 19:10:40 EDT
As the livna pine maintainer, I promise to commit to any compatibility needs
that are required.
Comment 9 Joshua Daniel Franklin 2007-07-26 13:58:46 EDT
Thank you. Your livna pine package is vanilla so 
upgrading should work fine for your users, with
the possible exception of encoded passwords with
non-ASCII characters.
Comment 10 Stephen John Smoogen 2007-08-01 21:31:30 EDT
I would say that we should probably confirm that it deals with the livna and
maybe the old RHL one.. as those would be the most canonical ones. Anything
beyond that would probably just need to be 'oh-well'.
Comment 11 Stephen John Smoogen 2007-08-17 16:57:55 EDT
What are the current outstanding issues?
Comment 12 Rex Dieter 2007-08-24 08:00:39 EDT
> outstanding issues?

probably few, if any, but I'll double-check with a formal review...
and I'll offer to sponsor Joshua (provided we follow-through with jima as
Comment 13 Rex Dieter 2007-08-24 08:51:23 EDT
a few quick things I'd like to see:
* enable PASSFILE
* consider linking against system uw-imap-libs shlib instead of bundled static
copy... if we go this route, you probably ought to become comaintainer for the
uw-imap pkg.
* web alpine.  This will likely require a not insignificant amount of work for
clean, seemless integration, so I'm ok to postponing this work till later.

Joshua, any objections?

now back to nitty-griggy packaging details...
Comment 14 Rex Dieter 2007-08-24 09:49:49 EDT
MUST: +Requires: mailcap 
alpine makes use of /etc/mailcap, /etc/mime.types 

so $RPM_OPT_FLAGS propogate to imap/ too

SHOULD: %configure --with-c-client-target=lfd 
not sure if this is absolutely required, I wasn't sure if it guessed right
without it.

SHOULD: %configure --with-passfile=.alpine.passfile 
(no preference on the name of the passfile, if you like something else.  livna's
pine uses .pine.pwd, which in retrospect, isn't all that good of a choice).

Here's updated sources, alpine.spec, alpine.spec.diff (and srpm) implementing
these recommended changes:

Implement at least the MUST items, and I'll approve this.  everything else looks
pretty good.
Comment 15 Rex Dieter 2007-08-24 09:52:43 EDT
Joshua, in the meantime, continue with steps outlined in
in particular, get the ball rolling on Step "9. Get a Fedora Account"
Comment 16 Jima 2007-08-29 11:15:10 EDT
While this isn't waiting on me, I just thought I'd chime in and say that yes,
I'm willing to co-maintain. :-)

*moves on to other open bugs*
Comment 17 Rex Dieter 2007-09-05 07:32:39 EDT
Joshua, ping?
Comment 18 Joshua Daniel Franklin 2007-09-05 19:57:22 EDT
Sorry, I've been on holiday until yesterday and am now getting caught up on work. It may be several more 
days before I get to this. 

If this is something a co-maintainer can do, Jima, you're welcome to. 

I've also created a Fedora account already and signed the CLA.
Comment 19 Rex Dieter 2007-09-06 07:38:33 EDT
Follow-through on
In particular, request membership in the cvsextras Group, and I will sponsor 
Comment 20 Rex Dieter 2007-09-06 07:40:36 EDT
oh, and let me/us know your Fedora Account System username, so I know who 
exactly to sponsor... :)
Comment 21 Joshua Daniel Franklin 2007-09-06 14:40:59 EDT
OK, my Fedora username is joshuadf and I've send the request.

I implemented the MUST items and enabled passfile, but didn't see
your diff until after I'd typed the changes myself. 

Comment 22 Joshua Daniel Franklin 2007-09-07 13:06:45 EDT
Naturally the alpine team released a new version while I was
working on it. The rpdoc.patch is no longer necessary, and
the problematic file is gone from the tarball:


There is a good chance 0.9999 will become alpine 1.0.
By the way, I have tested an upgrade from livna pine and
everything went smoothly. I have local mbox and remote 
IMAP folders, and my password does not contain any local 
codepage chars.
Comment 23 Rex Dieter 2007-09-07 13:15:43 EDT
OK, proceed with requesting cvs branches... and then import.  Good work.  (and
then folks interesting in comaintaining, like jima and I, can request additional
Comment 24 Joshua Daniel Franklin 2007-09-07 13:48:36 EDT
New Package CVS Request
Package Name: alpine
Short Description: UW Alpine mail user agent
Owners: joshuadf,jima,rdieter
Branches: FC-6 F-7 EL-4 EL-5
Cvsextras Commits: yes
Comment 25 Kevin Fenzi 2007-09-07 14:24:26 EDT
cvs done.
Comment 26 Joshua Daniel Franklin 2007-09-07 16:55:18 EDT
OK, devel built successfully:

Since alpine 1.0 release will be very soon, I wouldn't mind 
waiting to build for other tags. Maybe everyone who was watching
this bug could bang on the binary with their own local (al)pine

Closing with NEXTRELEASE.
Comment 27 Paul Wouters 2014-07-28 14:54:22 EDT
Package Change Request
Package Name: alpine
New Branches: epel7
Owners: pwouters
Comment 28 Jon Ciesla 2014-07-28 15:15:12 EDT
Git done (by process-git-requests).

Note You need to log in before you can comment on or make changes to this bug.