alpine is an alternativly licensed pine and the successor[1]. pine development has been frozen. the chappa-all patchset for pine does not support utf-8 very well. alpine incorporates the iconv() patch[2] and so all locals supported by glibc are working. for every pine user this may be a good alternative choice. [1] http://en.wikipedia.org/wiki/Pine_(e-mail_client)#Alpine [2] http://www.suse.de/~bk/pine/FAQ.html
Created attachment 118029 [details] alpine-0.98.ebuild first ebuild for alpine-0.98
There is a new version released yesterday(May 2) so the SRC_URI is outdated. Also you should have use-conditional code for all those docs. Attaching a patch to fix both problems
Created attachment 118055 [details, diff] Patch for SRC_URI and doc use-conditional code I have also tested it on amd64, so there is ~amd64 in KEYWORDS.
(In reply to comment #3) > Patch for SRC_URI and doc use-conditional code > > I have also tested it on amd64, so there is ~amd64 in KEYWORDS. thanks for testing and corrections. will send apline-0.99.ebuild soon...
Created attachment 118128 [details] alpine-0.99.ebuild new ebuild with version bump to 0.99, ~amd64 keyword, suggested corrections with doc in IUSE and condtitional doc installation. I'm unsure: The Apache License 2.0[1] says under section 4.d that the file NOTICE should be included, so it is, regardless of doc USE-flag. and a fix in $myconf spell-case. [1] http://www.apache.org/licenses/LICENSE-2.0
Well, the apache license is included in /usr/portage/licenses so I would assume you don't need to since it is in that directory. http://devmanual.gentoo.org/general-concepts/licenses/index.html
(In reply to comment #6) > Well, the apache license is included in /usr/portage/licenses so I would assume > you don't need to since it is in that directory. > > http://devmanual.gentoo.org/general-concepts/licenses/index.html thanks. but I won't include the license it self, but the project specific (here alpine) NOTICE file. this is what the license want (I think).
Web Alpine depends on tcl so you need a use flag for that too. The configure flag is --without-tcl. Possibly, you have to specify the tcl library (depends on it being versioned or not).
Created attachment 118842 [details] alpine-0.99-r1 new revison: removed implicit system dependency virtual/libc, added --without-tcl to configure options (thanks to Anders Hellgren), this disables build of Web alpine and from this it follows that emake install can be used again. added -c to aspell elog-info. If I understand it right, Web alpine needs a webserver and dev-lang/tcl as dependency. And you need a IMAP-Server somewere for your users. For now I have no time/need to test this.
What's the reason to block all versions of uw-mailutils? uw-mailutils is required by uw-imap (which already specifies the minimum version it expects). This alpine ebuild seems to work fine when the block is removed from it. (I have ebuilds for uw-imap and uw-mailutils (both 2006g) installed from /usr/local/portage)
(In reply to comment #10) > What's the reason to block all versions of uw-mailutils? uw-mailutils is > required by uw-imap (which already specifies the minimum version it expects). > This alpine ebuild seems to work fine when the block is removed from it. the reason was, that I've copyed the pine-ebuild which has a RDEPEND on net-mail/uw-mailutils. alpine (and pine too???) comes with its own version of mailutil and mtest. Because "make install" does not install mailutil and mtest, it can't be a realy needed RDEP. I've never used this tools and so I thought it would be better to ship with its own versions. May be the RDEP on net-mail/uw-mailutils should be removed.
Created attachment 119849 [details] alpine-0.99-r2.ebuild alpine-0.99-r2.ebuild: removed RDEPEND="net-mail/uw-mailutils" ; don't install mailutil and mtest from alpine distribution (hopefully runs without it)
Yes, alpine will run without it. uw-mailutils is part of c-client which is the core of both uw-imap and (al)pine. The package got split out so as to avoid file collisions. Please see bug 53499 and bug 105313. You also want to add the chappa-all patch; otherwise there will be no maildir support.
(In reply to comment #0) > alpine is an alternativly licensed pine and the successor[1]. pine development > has been frozen. the chappa-all patchset for pine does not support utf-8 very > well. alpine incorporates the iconv() patch[2] and so all locals supported by > glibc are working. for every pine user this may be a good alternative choice. > > [1] http://en.wikipedia.org/wiki/Pine_(e-mail_client)#Alpine > [2] http://www.suse.de/~bk/pine/FAQ.html > Two corrections: The chappa-all patch never intended to support utf-8. There was no code in that patch to support that. Bernhard Kaindl created a merged version of all.patch with the utf-8 patch and he distributed in SuSe. The implementation of utf-8 in alpine does not use iconv. It uses internal libraries in alpine. Finally, there is chappa-all patch, which includes most of the patches in Pine in chappa-all, at http://staff.washington.edu/chappa/alpine/ Thanks, -- Eduardo
(In reply to comment #13) > file collisions. Please see bug 53499 and bug 105313. You also want to add the if I understand this right, then mailutil is needed for CLI mailhandling only. it has nothing to do with (al)pine's moving mails from one collection to an other. If this is the case, then the user who wants CLI-handling of mailboxes can install net-mail/uw-mailutils by hand and not by (al)pine via RDEP? Would this be ok?
(In reply to comment #14) > Two corrections: > ... thank you for your corrections.
Created attachment 119986 [details] alpine-0.99-r3.ebuild added BLOCK on app-editors/pico; added chappa-all patch (thanks to Anders and Eduardo for pointing out); copyed maildir_warn from pine ebuild
When I build this with the chappa-all patch, I can't seem to navigate to subfolders of local MIX mailboxes. I assume this is an upstream ossie, but I don't see comments on Eduardo's pages. Other than that, the revised ebuild works O.K.
please refetch all.patch.gz and rebuild. Eduardo fixed somthing in the fillpara patch: http://staff.washington.edu/chappa/alpine/info/fillpara.html
(In reply to comment #18) > When I build this with the chappa-all patch, I can't seem to navigate to > subfolders of local MIX mailboxes. I assume this is an upstream ossie, but I > don't see comments on Eduardo's pages. Other than that, the revised ebuild > works O.K. Thank you very much for this report. Indeed, there was a problem. It even prevented subfolder of maildir folders to be listed. Now c-client provides a very nice solution for this problem and is implemented in the new maildir driver, as well as in all.patch.
Cheers, Eduardo. The new patch works well.
FYI: alpine-0.999 is out. ebuild follows as soon as Eduardo's patchset is available.
Created attachment 123871 [details] alpine-0.999.ebuild alpine-0.999: version bump; added ~x86-fbsd keyword; introduced chappa USE-flag to control whether to use Eduardo's patch or not (as of now patch not available so don't try to enable it)
FYI: Eduardo's released all.patch for alpine version 0.999. Please don't forget to refetch. quoting Eduardo: ... If you try it, please let me know how it works for you. Thank you. happy USE="chappa". works for me :)
*** Bug 188508 has been marked as a duplicate of this bug. ***
Created attachment 129792 [details] alpine-0.9999.ebuild * alpine-0.9999.ebuild: - version bump - added DEP on autotools don't forget to refetch all.patch.gz (chappa)
Nov 08, 2007 - Alpine 0.99999 is released to the Alpine alpha testers. this time no changes in the ebuild. please rename -0.9999 to -0.99999. don't forget to refetch all.patch.gz (chappa).
alpine 0.999999 (six nines) was released today. (Versionbump and refetching the patch should work) According to the release notes, it should be the final prerelease before 1.0. Regarding maintianer-needed, will alpine replace pine in portage? I think it definitely should. If so, these ebuilds it should be maintained by the same people (i.e. mail herd) that do pine, right?
Created attachment 137958 [details] alpine-0.999999.ebuild configure complains about not finding /etc/ssl/factory.pem. so diff is: src_compile() { local myconf="--without-tcl" if use ssl; then - myconf="${myconf} --with-ssl-certs-dir=/etc/ssl" + myconf="${myconf} --with-ssl-certs-dir=/etc/ssl/certs" else myconf="${myconf} --without-ssl" fi
Dec 20, 2007 Alpine 1.00 has been released. renaming alpine-0.999999.ebuild to alpine-1.00.ebuild and refetching all.patch.gz works for me. the note about alpine being alpha software is obsolete.
Created attachment 139459 [details] alpine-1.00.ebuild (only-alpine flag) I've attached a version of the ebuild (for 1.00) with an "alpineonly" USE flag, which makes it not conflict with pico or pine by not installing anything other alpine (and its own documentation). This is useful for people who aren't quite willing to give up pine before testing alpine. We should probably also do a patch to make the maildir support (if included) use the Gentoo-default location as the default, since the pine ebuilds did this and it's annoyingly not-obvious to specify the location of a maildir INBOX, since the third option in the config file looks like the right thing but can't be made to work.
Created attachment 141381 [details] alpine-1.00 + passfile useflag I have uploaded alpine-1.00-r1.ebuild which allows using a password file via a passfile use flag, disabled by default. We used to have it in pine. No other changes. And BTW: seems to work well here on x86 stable.
Anyone have an idea when Alpine will make it into Portage?
Created attachment 146474 [details] alpine-1.10.ebuild alpine 1.10 was released. ebuild has nothing realy new: removed autotools inheritance, libtoolize call in src_compile(), added configure options for system-wide configs (pine.conf, pine.conf.fixed).
In bug 215881, I requested a 'topal' ebuild. Topal is a `glue' program that links GnuPG and Pine/Alpine. It offers facilities to encrypt, decrypt, sign and verify emails. I would like to ask here if it is possible to include the topal-patch (see <http://homepage.ntlworld.com/phil.brooke/topal/>) for alpine in the alpine ebuild and add a 'topal' use flag that selects this patch and (if/when it gets created) depends on that 'topal' ebuild. If there are better tools for including pgp-functionality in alpine, this request may be moot. However, I've looked around, and found topal to be the only up-to-date tool.
created topal ebuild, please add a useflag
Hey, i just changed the topal ebuild to install the patches to /usr/share/topal/patch feel free to grab it from there and then patch alpine
Created attachment 149814 [details] alpine-1.10-r1.ebuild by popular request: alpine-1.10 with patches from topal-57 and new USE="topal". topal-57 is for alpine-1.00, however I made two extra patches (quick'n'dirty) to work with alpine-1.10. Feel free to test it, I havn't so far.
Created attachment 149815 [details, diff] files/alpine-1.10-topal-57.patch patch 1 to make topal-57 work with alpine
Created attachment 149816 [details, diff] files/topal-57-conf-hack.patch patch 2 to make topal-57 work with alpine-1.10
There is a small bug in the latest alpine-1.10.ebuild. Due to a typo, passfile support can never actually be enabled. Also, I suggest changing the default passfile to .pinepw, which duplicates the file name in the original pine ebuilds. The very short diff is as follows: --- 84,85c84,85 < if user passfile; then < myconf="${myconf} --with-passfile=.pinepwd" --- > if use passfile; then > myconf="${myconf} --with-passfile=.pinepw"
Hi When will Alpine make it into Portage? Looking forward. Works flawlessly on my Gentoo-Box when compiled from source. Thank you for your Feedback. Best Zeno
(In reply to comment #42) > When will Alpine make it into Portage? Looking forward. Works flawlessly on my > Gentoo-Box when compiled from source. Agreed, works for me as well.
When I try to install alpine-1.10 using this ebuild, it appears that the alpine-1.10.tar.bz2 file that gets downloaded and put in /usr/portage/disfiles/ is actually a webpage. tar/bzip2 fail on decompression, naturally. (file shows it as an ASCII text file, and I can cat it and see all the HTML...)
(In reply to comment #44) > alpine-1.10.tar.bz2 file that gets downloaded and put in /usr/portage/disfiles/ > is actually a webpage. tar/bzip2 fail on decompression, naturally. (file shows > it as an ASCII text file, and I can cat it and see all the HTML...) I've checked $SRC_URI for changes, but for me every thing is correct. Please try to view the contents of the HTML file you received with less/mcview or a browser. Is it a autogenerated proxy/webserver message?
Sascha, are you interested in proxy-maintainance?
(In reply to comment #46) > Sascha, are you interested in proxy-maintainance? yes I am. please guide me what to do next.
Created attachment 162535 [details] alpine-1.10-r2.ebuild just a cleanup and an update for topal users (bug #215881). else nothing new.
Created attachment 163869 [details] alpine-2.00.ebuild version bump to alpine-2.00. Don't forget to refetch the chappa-patch if you use it. You may be interested in reading http://www.washington.edu/alpine/changes/1.10-to-2.00.html. topal does not work with this version atm. therefore experimental smime support ships with alpine-2.00.
Neither this one nor the old 1.10 ebuild work for me any longer, apparently since pam now does not get linked in correctly any more. I suspect that this has been the case since I rebuilt pam with --as-needed (on by default) and alpine's way of adding its own libraries to the link chain is wrong. (will people ever learn how a linker works?) make[4]: Entering directory `/var/tmp/portage/mail-client/alpine-2.00/work/alpine-2.00/alpine' /bin/sh ../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -std=gnu99 -g -pthread -pipe -march=pentium4 -mfpmath=sse -O2 -fomit-frame-pointer `cat ../c-client/LDFLAGS` -L/usr/lib -Wl,-O1,--as-needed,-z,now -o alpine addrbook.o adrbkcmd.o after.o alpine.o arg.o busy.o colorconf.o confscroll.o context.o dispfilt.o flagmaint.o folder.o help.o imap.o init.o kblock.o keymenu.o ldapconf.o listsel.o mailcmd.o mailindx.o mailpart.o mailview.o newuser.o pattern.o pipe.o print.o radio.o remote.o reply.o roleconf.o send.o setup.o signal.o status.o takeaddr.o titlebar.o smime.o date.o ../pico/libpico.a ../pico/osdep/libpicoosd.a ../pith/libpith.a ../pith/osdep/libpithosd.a ../pith/charconv/libpithcc.a osdep/libpineosd.a ../c-client/c-client.a -lssl -lncurses -lssl i686-pc-linux-gnu-gcc -std=gnu99 -g -pthread -pipe -march=pentium4 -mfpmath=sse -O2 -fomit-frame-pointer -Wl,-O1 -Wl,--as-needed -Wl,-z -Wl,now -o alpine addrbook.o adrbkcmd.o after.o alpine.o arg.o busy.o colorconf.o confscroll.o context.o dispfilt.o flagmaint.o folder.o help.o imap.o init.o kblock.o keymenu.o ldapconf.o listsel.o mailcmd.o mailindx.o mailpart.o mailview.o newuser.o pattern.o pipe.o print.o radio.o remote.o reply.o roleconf.o send.o setup.o signal.o status.o takeaddr.o titlebar.o smime.o date.o -lpam -ldl -L/usr/lib -lcrypto ../pico/libpico.a ../pico/osdep/libpicoosd.a ../pith/libpith.a ../pith/osdep/libpithosd.a ../pith/charconv/libpithcc.a osdep/libpineosd.a ../c-client/c-client.a -lncurses -lssl ../c-client/c-client.a(osdep.o): In function `ssl_onceonlyinit': /var/tmp/portage/mail-client/alpine-2.00/work/alpine-2.00/imap/c-client/osdep.c:337: warning: the use of `tmpnam' is dangerous, better use `mkstemp' ../c-client/c-client.a(osdep.o): In function `checkpw_cleanup': osdep.c:(.text+0x13b6): undefined reference to `pam_setcred' osdep.c:(.text+0x13c6): undefined reference to `pam_end' ../c-client/c-client.a(osdep.o): In function `checkpw': osdep.c:(.text+0x6821): undefined reference to `pam_start' osdep.c:(.text+0x6888): undefined reference to `pam_set_item' osdep.c:(.text+0x689f): undefined reference to `pam_authenticate' osdep.c:(.text+0x68b6): undefined reference to `pam_acct_mgmt' osdep.c:(.text+0x68d1): undefined reference to `pam_setcred' collect2: ld returned 1 exit status make[4]: *** [alpine] Error 1 Adding -lpam to the end of the executable rules (after $(LIBS)) in alpine/Makefile "fixes" this, like so: alpine$(EXEEXT): $(alpine_OBJECTS) $(alpine_DEPENDENCIES) @rm -f alpine$(EXEEXT) $(LINK) $(alpine_OBJECTS) $(alpine_LDADD) $(LIBS) -lpam Same for the other executables. Obviously the right way to fix this would be to rearrange $(LIBS) correctly, I just wanted to show what's going wrong.
Um, you're welcome to provide a patch...
(In reply to comment #50) > > [...] alpine's way of adding its own libraries to the link chain is wrong. Can you report this upstream? (http://www.washington.edu/alpine/commentform.html, comp.mail.pine, or the alpine-info mailing list http://www.washington.edu/alpine/alpine-info/). The developers are usually very helpful and respond favorably to politely formulated bug reports. @ Sacha and net-mail devs: This ebuild will get much wider testing if it manages to get into portage (or an overlay at least); as the direct successor to pine, it would allow the pine ebuild to be removed (eventually).
I can offer to act as proxy maintainer (not much more, I'm not using alpine) - I'll try to take a look at the ebuild this week.
Created attachment 163928 [details] updated alpine ebuild with quick fix for --as-needed After much messing around with the very wtf alpine build I had to surrender and whack the LDFLAGS that are passed in so that --as-needed is not used. I tried to use filter-ldflags but couldn't make it work; if anybody knows how to whack --as-needed out of a more complex LDFLAGS argument (see ebuild comment) please advise. I know the sed hammer is gross but works. This ebuild also properly aborts instead of eating an existing installation when compilation fails. To top it all off, the resulting executable even works.
(In reply to comment #54) > > To top it all off, the resulting executable even works. I can confirm that.
It would be realy nice if the proxy maintainership offerd by Torsten and/or Tobias comes true. As you can read in the GMN: it's bugday on October 4. 2008. So please every one in CC here: step in #gentoo-bugs on irc.freenode.net and try to convince the devs that pine is obsolete an alpine should make its way into portage. Either I or someone else can take maintenance. Please keep us informed in this bug here.
(In reply to comment #56) > Please keep us informed in this bug here. good news: Torsten got in touch with me. First alpine will make its way into an official overlay. If everything is fine, it will be moved into the tree. PS: ATM there's no need anymore to make noise on #gentoo-bugs :-).
(In reply to comment #54) > Created an attachment (id=163928) [edit] "File ~/.pinepw will be used for this.": note that "~/.pinepwd" is actually used.
(In reply to comment #58) > "File ~/.pinepw will be used for this.": > note that "~/.pinepwd" is actually used. thanks for noting this. I just wondered, why I had to run "alpine -passfile ~/.pinepw" :-). Will be fixed in the next release.
Created attachment 169432 [details] Updated ebuild with RESTRICT="nomirror" to avoid hitting Gentoo mirrors for nonexisting package Added an updated ebuild for 2.00 with RESTRICT="nomirror" to avoid hitting Gentoo mirrors for a non-existant package.
The ebuild is now in the Sunrise overlay. You can find it from http://overlays.gentoo.org/svn/proj/sunrise/reviewed/mail-client/alpine/
alpine is the "official" replacement for the now aging pine, and is also the default mail program in at least one distro (Scientific Linux). IMO, it doesn't belong in an overlay, but should be available in gentoo proper. Seeing it in an overlay is good, but it does NOT solve the problem, especially not for those who don't want any of the OTHER changes that are or may be coming in that overlay.
(In reply to comment #62) > IMO, it doesn't belong in an overlay, but should be available in gentoo proper. I agree that it should go into portage. I've been using the alpine from the ebuilds in this bug report and then from the overlay without troubles. It is as stable as pine ever was, has had enough testing and should therefore be included. (And fast-tracked to stable... ;-)). Together with topal (which is ideally included with the ebuild and available via a use-flag), it can replace pine+pinpgp. Note that a topal release compatible with alpine 2.00 is available (http://homepage.ntlworld.com/phil.brooke/topal/). Erik
Torsten and I are working on getting alpine into official portage. For proxy-maintainance the ebuilds are now at http://git.overlays.gentoo.org/gitweb/?p=proj/net-mail.git;a=tree;h=refs/heads/alpine;hb=refs/heads/alpine They will be reviewed and hopefully imported soon. But please be patient, or become a gentoo dev and take maintainance. volunteers welcome :-)
(In reply to comment #64) > Torsten and I are working on getting alpine into official portage. For > proxy-maintainance the ebuilds are now at > http://git.overlays.gentoo.org/gitweb/?p=proj/net-mail.git;a=tree;h=refs/heads/alpine;hb=refs/heads/alpine Will this overlay be available from layman?
Please note that alpine bundles imap/libc-client source code, please make sure CVE-2008-5514 is resolved if the ebuild goes into the Portage tree See this bug for reference: https://bugzilla.redhat.com/show_bug.cgi?id=477227
(In reply to comment #64) > > They will be reviewed and hopefully imported soon. But please be patient, or > become a gentoo dev and take maintainance. volunteers welcome :-) > This slowly becomes a tempting suggestion. More netadmin than programming experience here, and no idea about the workload involved, but feel free to contact me if you really need a novice...
(In reply to comment #66) > Please note that alpine bundles imap/libc-client source code, please make sure > CVE-2008-5514 is resolved if the ebuild goes into the Portage tree > See this bug for reference: https://bugzilla.redhat.com/show_bug.cgi?id=477227 thanks. I think CVE-2008-5514 does not effect¹ alpine. Or please correct me if I'm wrong. [1] http://www.washington.edu/alpine/tmailbug.html
Finally in the tree. @tommy: It is in gentoo-x86. You can remove it from sunrise (and the patch from your home directory). @sascha: (In reply to comment #68) > (In reply to comment #66) > > Please note that alpine bundles imap/libc-client source code, please make sure > > CVE-2008-5514 is resolved if the ebuild goes into the Portage tree > > See this bug for reference: https://bugzilla.redhat.com/show_bug.cgi?id=477227 > > thanks. I think CVE-2008-5514 does not effect¹ alpine. Or please correct me if > I'm wrong. > > [1] http://www.washington.edu/alpine/tmailbug.html the tmailbug was fixed in imap-2007d while CVE-2008-5514 was fixed in imap-2007e. So i've applied the patch.
amd64 as well plz!
(In reply to comment #69) > Finally in the tree. > > @tommy: > It is in gentoo-x86. You can remove it from sunrise (and the patch from your > home directory). removed from sunrise, thanks for notifying.
Maybe this bug could be closed now that alpine is in the tree...
the ebuild is borked now because the patch was deleted: >>> Downloading 'http://dev.gentooexperimental.org/~tommy/distfiles/chappa-alpine-2.00.patch.gz' --19:50:35-- http://dev.gentooexperimental.org/~tommy/distfiles/chappa-alpine-2.00.patch.gz => `/usr/portage/distfiles/chappa-alpine-2.00.patch.gz' Resolving dev.gentooexperimental.org... 81.93.240.53 Connecting to dev.gentooexperimental.org|81.93.240.53|:80... connected. HTTP request sent, awaiting response... 404 Not Found 19:50:36 ERROR 404: Not Found. !!! Couldn't download 'chappa-alpine-2.00.patch.gz'. Aborting. * Fetch failed for 'mail-client/alpine-2.00', Log file: * '/var/tmp/portage/mail-client/alpine-2.00/temp/build.log' >>> Failed to emerge mail-client/alpine-2.00, Log file: >>> '/var/tmp/portage/mail-client/alpine-2.00/temp/build.log'
Please ignore comment #73. I didn't notice the sunrise ebuild was overriding the main one.
(In reply to comment #72) > Maybe this bug could be closed now that alpine is in the tree... > Indeed, and then wait to see whether we should request a re-alpine ebuild ;-)
