Bug 249365 (alpine)

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)

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

Done.

> - 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

Done.

> - 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":
http://www.redhat.com/archives/fedora-advisory-board/2006-June/msg00072.html
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

 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:

http://beer.tclug.org/fedora-extras/alpine/alpine.spec

 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. ;-)

 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:

#       THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T
#       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

 See
http://fedoraproject.org/wiki/Packaging/Guidelines#head-b7d622f4bb245300199c6a33128acce5fb453213
-- 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
/usr/src/debug/alpine-0.999/alpine/arg.c
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! :-)

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

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.

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,
maildir).

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.

As the livna pine maintainer, I promise to commit to any compatibility needs
that are required.

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.

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'.

What are the current outstanding issues?

> 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
comaintainer).

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...

MUST: +Requires: mailcap 
alpine makes use of /etc/mailcap, /etc/mime.types 

MUST: make ... EXTRACFLAGS="$RPM_OPT_FLAGS"
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:
http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/alpine/devel/

Implement at least the MUST items, and I'll approve this.  everything else looks
pretty good.

Joshua, in the meantime, continue with steps outlined in
http://fedoraproject.org/wiki/PackageMaintainers/Join
in particular, get the ball rolling on Step "9. Get a Fedora Account"

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*

Joshua, ping?

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.

Follow-through on
http://fedoraproject.org/wiki/PackageMaintainers/Join#head-a601c13b0950a89568deafa65f505b4b58ee869b
In particular, request membership in the cvsextras Group, and I will sponsor 
you.

oh, and let me/us know your Fedora Account System username, so I know who 
exactly to sponsor... :)

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. 

http://staff.washington.edu/joshuadf/alpine/alpine-0.999-3.fc7.src.rpm
http://staff.washington.edu/joshuadf/alpine/alpine.spec

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:

http://staff.washington.edu/joshuadf/alpine/alpine-0.9999-2.fc7.src.rpm
http://staff.washington.edu/joshuadf/alpine/alpine.spec

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.

OK, proceed with requesting cvs branches... and then import.  Good work.  (and
then folks interesting in comaintaining, like jima and I, can request additional
access).

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
InitialCC: 
Cvsextras Commits: yes

cvs done.

OK, devel built successfully:
http://koji.fedoraproject.org/koji/buildinfo?buildID=18087

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
configurations.

Closing with NEXTRELEASE.

Package Change Request
======================
Package Name: alpine
New Branches: epel7
Owners: pwouters

Git done (by process-git-requests).