Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 784266 - net-nntp/pan: Last Rites
Summary: net-nntp/pan: Last Rites
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords: PMASKED
Depends on:
Blocks: 672852 713032 740858 756004 756010 769290 784110
  Show dependency tree
 
Reported: 2021-04-19 21:15 UTC by Matt Turner
Modified: 2021-09-09 19:40 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
pan-glib-2.68.patch (pan-glib-2.68.patch,15.19 KB, patch)
2021-04-25 17:30 UTC, Samuel Bauer
Details | Diff
live-git pan-9999.ebuild (pan-9999.ebuild,1.75 KB, text/plain)
2021-09-08 08:00 UTC, Duncan
Details
The missing icon_layout_6.png (icon_layout_6.png,317 bytes, image/png)
2021-09-08 21:59 UTC, Duncan
Details
patch for the compare pointer to int compile failure (fix-compare-error.patch,1.38 KB, patch)
2021-09-09 19:40 UTC, Jack
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Turner gentoo-dev 2021-04-19 21:15:38 UTC
Needs a lot of work upstream and it's not happening.
Comment 1 Larry the Git Cow gentoo-dev 2021-04-19 21:16:41 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0fd3f9843338b045498cd0ae0f466cd6338ea0fa

commit 0fd3f9843338b045498cd0ae0f466cd6338ea0fa
Author:     Matt Turner <mattst88@gentoo.org>
AuthorDate: 2021-04-19 21:16:06 +0000
Commit:     Matt Turner <mattst88@gentoo.org>
CommitDate: 2021-04-19 21:16:29 +0000

    profiles: Mask net-nntp/pan for removal
    
    Bug: https://bugs.gentoo.org/784266
    Signed-off-by: Matt Turner <mattst88@gentoo.org>

 profiles/package.mask | 5 +++++
 1 file changed, 5 insertions(+)
Comment 2 Jack 2021-04-19 23:53:14 UTC
Pan builds and runs fine for me with gtk3, changing on line in the ebuild from "--without-gtk3" to "--with-gtk3".  There is an issue (https://gitlab.gnome.org/GNOME/pan/-/issues/116) about the gtk3 build still pulling in files from gkt2, with proposed patch.  I have neither confirmed this nor tested the patch yet.

In addition, there is a two week old issue, with proposed patch, regarding the failure to build with glib-2.68. (https://gitlab.gnome.org/GNOME/pan/-/issues/128)

Is it possible to delay the last-rites for a bit to see if these patches get accepted, or even apply them in Gentoo as an interim step?

(I tried responding to the gentoo-dev posting, but don't think my reply got through.)
Comment 3 Matt Turner gentoo-dev 2021-04-20 02:04:30 UTC
I'd really prefer not to. pan has been unmaintained for quite a while now, so for leio/me to try to patch it constantly really constitutes a downstream fork rather than typical distribution-level packaging.

Here's the nominal maintainer of pan:

https://gitlab.gnome.org/pmkovar

Basically no activity on GNOME in the last year.

So I don't see the pan situation improving.

But if it does and someone begins maintaining it again we can re-add it, but at this point 0.146 is using the dead libgnome-keyring, dead gtk+2, and doesn't build with the latest glib, not to mention the bugs about it failing to compile and it segfaulting.
Comment 4 Jack 2021-04-20 03:19:01 UTC
Unmaintained upstream or within Gentoo?  I seem to be missing something.  Following from the source eix shows (http://pan.rebelbase.com/) there has been more than trivial activity in the past year.  I've been using pan 0.146 for a while with no crashes or other problems, and I just easily compiled against gtk3 with a one line change to the ebuild.  The new glib is still masked in Gentoo, and the fact that there is a new upstream issue on the glib problem two weeks ago doesn't sound like no activity in a year.  My version has -gnome-keyring, so I wonder if that could just be dropped until it uses something more current.  I admit I haven't looked at all the other bugs filed against pan, but I'll start poking into them, to see if they have hope of easily being dealt with.

For now, I'll just start looking through open bugs, and maybe try a new ebuild addressing as many of the outstanding issues as I can figure out.
Comment 5 Matt Turner gentoo-dev 2021-04-20 03:36:55 UTC
(In reply to Jack from comment #4)
> Unmaintained upstream or within Gentoo?  I seem to be missing something.

Upstream.

https://gitlab.gnome.org/GNOME/pan/

See how nothing is going in except translations?

> Following from the source eix shows (http://pan.rebelbase.com/) there has
> been more than trivial activity in the past year.

I have no idea what you see on that website that indicates activity.

Notice how the mailing list is dead too? 

https://lists.nongnu.org/archive/html/pan-devel/

> For now, I'll just start looking through open bugs, and maybe try a new
> ebuild addressing as many of the outstanding issues as I can figure out.

It's not an issue of the ebuild needing updates. The upstream project is unmaintained and has been for a long while now.

I'm confused why you're confused...
Comment 6 Jack 2021-04-20 17:36:30 UTC
Sorry - I see we were looking at different things for activity.  I do see there have been no commits other than translations in a year, but there have been issues raised and discussed, as well as some MRs.  I'll see if I can stir up any updates, and understand I may need to keep my own copy of the ebuild for continued use.
Comment 7 Duncan 2021-04-23 08:29:54 UTC
I'm interested in pan too, tho I've been keeping a pan-9999 running in my local overlay.

If you have followed the pan mailing list for a few years you may remember me from there, tho once gmane's list2news service went down I dropped from the mailing list as I was using gmane via pan for the mailing list, and somehow I never got around to setting up my gmane-followed lists (including the pan and gentoo lists) in a mail client.

While gmane was my primary pan/news usage and I haven't done much with news since gmane's loss, I do have an unexpiring 1-TB block account that could well last my lifetime with my usage, and had been thinking about getting back into it.

I've been following the general glib-2.68 masking and noticed that pan was in the bug-dependency list a few days ago, but figured there'd likely be a fix available by the time a new commit appeared upstream or I otherwise needed to do a pan-9999 rebuild.

Then with tonight's update I see pan masked for tree-cleaning.  While I /am/ running a local pan-9999 overlay copy so the removal wouldn't immediately affect me other than having to stick a pan entry in package.unmask I'm not looking forward to the choice of (1) having to do full maintenance on my own (without the benefit of being able to lean on fixes from reported bugs like this), (2) having to switch to some other news solution, or (3) deciding its finally time to drop news for good like I ultimately dropped MS OSs, never to return.

If pan does end up dropped from the gentoo tree, hopefully it'll find its way into a sunset overlay or something, somewhere.  And/or maybe interested gentooers can do some sort of informal mailing list where we just CC each other on problems and hopefully solutions, and/or maybe the same thing, but on the pan-user's list, being it's already there and is appropriate for such things.

So anyone interested feel free to mail me directly.  Hopefully we can figure out something, should pan actually be tree-cleaned rather than reinstated.

And glad to see patches proposed already.  That's more than I'd yet gotten around to looking for on my own, thus demonstrating the benefits of some sort of continued group maintenance effort even if it does end up out-of-tree.
Comment 8 Samuel Bauer 2021-04-25 12:45:11 UTC
Considering
Comment 9 Samuel Bauer 2021-04-25 17:30:24 UTC
Created attachment 702480 [details, diff]
pan-glib-2.68.patch

1/ Pretty dead.

Pan actually got no active lead dev from what I understood, until that no release I guess.
Taking a look behind
2012/06 -> 2016/04 near 4 years no release
2008/08 -> 2011/02 over 2 years no release

That was never a thing to last rite pan.

2/ Needs GTK+3 port.

There is one, just need to move to --with-gtk3 or drop without line.
The ebuild mention gentoo sticks to fedora choice for 0.145.
I tested 0.146 with gtk3 it works as a charm, as comment 2 says

3/ Doesn't build with glib-2.68.
Here is a patch proposal, I grabbed from comment 2, I still didn't test with glib-2.68, but it applies well.
Comment 10 Samuel Bauer 2021-04-25 17:48:16 UTC
(In reply to Matt Turner from comment #5)

> I have no idea what you see on that website that indicates activity.

The previously attached patch dates from only some weeks, it's still not in the main branch but let's take the time to breath.

Some patches I sent on the gentoo bt took years to be integrated, every project encounters those kind of situation
Comment 11 Jack 2021-04-25 20:14:17 UTC
For me, the question is whether there is someone who will take over the source repository, and whether the previous developer is willing to cede control (or actually become active again.)  I suppose another option would be to create a fork.  This is not really a Gentoo issue, so I'll get more specific on the Pan mailing list.
Comment 12 Larry the Git Cow gentoo-dev 2021-05-23 12:36:51 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f8b299cb0d86ca79cf01b63cd586b319271817dc

commit f8b299cb0d86ca79cf01b63cd586b319271817dc
Author:     Jakov Smolic <jakov.smolic@sartura.hr>
AuthorDate: 2021-05-23 12:35:22 +0000
Commit:     David Seifert <soap@gentoo.org>
CommitDate: 2021-05-23 12:35:22 +0000

    net-nntp/pan: Remove last-rited pkg
    
    Closes: https://bugs.gentoo.org/672852
    Closes: https://bugs.gentoo.org/713032
    Closes: https://bugs.gentoo.org/740858
    Closes: https://bugs.gentoo.org/756004
    Closes: https://bugs.gentoo.org/756010
    Closes: https://bugs.gentoo.org/769290
    Closes: https://bugs.gentoo.org/784110
    Closes: https://bugs.gentoo.org/784266
    Signed-off-by: Jakov Smolic <jakov.smolic@sartura.hr>
    Signed-off-by: David Seifert <soap@gentoo.org>

 net-nntp/pan/Manifest          |  2 --
 net-nntp/pan/metadata.xml      |  8 -------
 net-nntp/pan/pan-0.145.ebuild  | 48 ------------------------------------------
 net-nntp/pan/pan-0.146.ebuild  | 48 ------------------------------------------
 profiles/base/package.use.mask |  4 ----
 profiles/package.mask          |  5 -----
 6 files changed, 115 deletions(-)
Comment 13 Duncan 2021-09-08 08:00:37 UTC
Created attachment 738277 [details]
live-git pan-9999.ebuild

So there have been some encouraging upstream developments...

Dominique Dumont, Debian's pan maintainer, has stepped up as upstream maintainer. =:^)

He has made very good progress with existing PRs/patches, already merging the most critical in terms of getting pan running on gtk3 with current libs and live-git actually builds and runs without patching once again, tho he hasn't caught up on the less critical patches yet and obviously hasn't done a new actually buildable release yet, but it does seem to be coming, now. =:^)

Meanwhile, here's the live-git pan-9999.ebuild that I just successfully rebuilt pan with.  In a quick test it loads and runs, but it may still be buggy -- before this latest patching run, when I was still having to apply patches to build, I could get pan running but it wasn't entirely stable, and I've not yet tested it long enough to know if that has changed, but it hasn't crashed since my latest now-patchless rebuild yet!

Updated depends: gtk+:3, gmime:3.0 and gtkspell:3 .

New USE flag: crypt, matching the flag from gmime:3.0.  I used gmime:3.0[crypt=] but it occurs to me that [crypt?] is more likely all it needs.

USE flags I built with and thus tested:
USE="dbus spell ssl -crypt -gnome-keyring -libnotify"

Note that I'm not entirely sure that the gnome-keyring and libnotify USE flags and their unchanged deps apply with the new gtk3/gmime3 deps as I have them off.

Additionally, older change for me but I believe the last in-tree ebuild was hard-coding the yelp-tools dep.  However it's only needed to build the manual, and while the manual might be nice I'd rather do without the dep (kde desktop with nothing else pulling it in), so it's hard-coded off in this ebuild.

But the ebuild is definitely tested/working, here, so people that have been doing without pan at least have an ebuild they can use now, if they dare do the live-git build anyway.

I imagine once there's a release I'll request an in-tree ebuild again, but I guess it's not worth it until then, particularly since people should be able to find this one pretty easily if they need it badly enough.

Covering the bases for my changes: Signed-off-by: John Duncan
Comment 14 Duncan 2021-09-08 08:33:45 UTC
One more thing.  This was my last gtk2 package so I was able to remove it along with the old gmime and gtkspell (and a couple themes, etc, as well).  And pan still runs, so it's tested gtk2-free now! =:^)
Comment 15 Jack 2021-09-08 14:30:07 UTC
Thanks.  I'll definitely try this.  I've already compiled pan from git head, using gmime3, but haven't been able to test that part yet.  It certainly works fine just for reading news.
Comment 16 Jack 2021-09-08 20:18:54 UTC
Where does icon_layout_6.png come from?  I have no record of it.

This fails to compile for me with gmime3.  The necessary patch has been discussed on the pan mailing list, but it is changing <0 or < 0 to != NULL in two (or four?) places in .../pan/usenet-utils/mime-utils.cc.

I'm not convinced the manual is really good, but I'd prefer the option of building it were still available.

Thanks for the work.
Comment 17 Duncan 2021-09-08 21:57:05 UTC
(In reply to Jack from comment #16)
> Where does icon_layout_6.png come from?  I have no record of it.

The icon_layout_6.png copy line was in the original gentoo pan ebuild, copying it from the package's files dir.  My (default, not thought about until now) assumption was that people on this bug presumably had copied the ebuild and files dir to their overlay when pan was lastrited and this ebuild would be copied there too, so people would already have it (as I did altho I've been running pan-9999 since there was actually an ebuild for it in the tree...).

And of course once it came time to think about it in-tree again, I presumed the gentoo dev would dig the old ebuild (and thus the png) out of the git history, for comparison purposes.

But obviously that's a faulty assumption and if you're doing the rsync tree (I'm doing the git tree here), and don't still have a copy of the old pan either still installed or a binpkg of it to dig the icon out of, it'll be a bit rough getting it.  So I'll attach it shortly.

> This fails to compile for me with gmime3.  The necessary patch has been
> discussed on the pan mailing list, but it is changing <0 or < 0 to != NULL
> in two (or four?) places in .../pan/usenet-utils/mime-utils.cc.

List-message ID info, subject/author/date and (if convenient) message-id?  I believe I've seen it but that'll ensure we're talking about the same thing.

gmime-3.2.7 which seems to be the only gmime3 in-tree?  The only problem I initially had was that pan defaults to crypt, and my initial gmime3 build had it off.  But I rebuilt gmime3 with USE=crypt and pan built against that, so I added IUSE=crypt, the [crypt=] conditional-dep, and the use_with crypt line, and rebuilt gmime3 and pan without crypt and that worked too.

But I /was/ a bit surprised when pan just built against gmime3, as I remembered people saying another patch was necessary and hadn't seen it in the bunch of recent upstream commits.

So what's different?  Several possibilities I can think of:

All gmime USE flags off here.  If you have one or more on, that's one difference.

gcc-11.1.0-r2 here.  That's ~amd64, FWIW.

I think I built pan with gtk/gmime/gtkspell 2/3 both installed, the 2 versions being unmerged afterward, and maybe that affected things?  I'll have to try rebuilding again and see.

> I'm not convinced the manual is really good, but I'd prefer the option of
> building it were still available.

Agreed.  There's some other cleanup to do as well.  But once I got an ebuild with minimal  working-well-for-me changes I wanted to get it up for others to try, and I was running over 24 hours without sleep by that point, so further cleanups got put off.

> Thanks for the work.

Thanks for the testing. =:^)
Comment 18 Duncan 2021-09-08 21:59:31 UTC
Created attachment 738367 [details]
The missing icon_layout_6.png
Comment 19 Jack 2021-09-08 22:45:32 UTC
[this time well see if I can finish the entire reply, before refreshing the page and wiping out my entire reply]

(In reply to Duncan from comment #17)
> (In reply to Jack from comment #16)
> > Where does icon_layout_6.png come from?  I have no record of it.
> [...] So I'll attach it shortly.
Got it.  I had copied the ebuild for 0.146 and it didn't refer to that file, so I didn't copy the file.  In fact, if you look at the layout config in the current Pan, that option is no longer present.  I wonder if you had copied an older ebuild than 0.146.  

> > This fails to compile for me with gmime3.  The necessary patch has been discussed on the pan mailing list, but it is changing <0 or < 0 to != NULL in two (or four?) places in .../pan/usenet-utils/mime-utils.cc.
> List-message ID info, subject/author/date and (if convenient) message-id?  I believe I've seen it but that'll ensure we're talking about the same thing.
https://lists.nongnu.org/archive/html/pan-devel/2021-09/msg00002.html should get you to a reasonable point in that thread.  I'll be glad to attach the patch I'm currently using, I don't think it's actually gotten committed upstream yet.  I suspect it was decided that three vertical panes wasn't really viable for actual use, but we might find a comment in the NEWS or git log.
 
> gmime-3.2.7 which seems to be the only gmime3 in-tree?  The only problem I initially had was that pan defaults to crypt, and my initial gmime3 build had it off.  But I rebuilt gmime3 with USE=crypt and pan built against that, so I added IUSE=crypt, the [crypt=] conditional-dep, and the use_with crypt line, and rebuilt gmime3 and pan without crypt and that worked too.
> 
> But I /was/ a bit surprised when pan just built against gmime3, as I remembered people saying another patch was necessary and hadn't seen it in the bunch of recent upstream commits.
> 
> So what's different?  Several possibilities I can think of:
> 
> All gmime USE flags off here.  If you have one or more on, that's one difference.
If your gmime use flag was off, then it shouldn't have actually built any of the gmime stuff.  Check the list at the end of the ./configure run.
 
> gcc-11.1.0-r2 here.  That's ~amd64, FWIW.
I'm using 11.2.0.

> I think I built pan with gtk/gmime/gtkspell 2/3 both installed, the 2 versions being unmerged afterward, and maybe that affected things?  I'll have to try rebuilding again and see.
The version choice of each of these is independent, as far as I can tell.  Removing -2 won't matter if you compiled against -3.  If you remove the one you compiled against, Pan would likely just fail to run at all.

> > I'm not convinced the manual is really good, but I'd prefer the option of building it were still available.
> Agreed.  There's some other cleanup to do as well.  But once I got an ebuild with minimal  working-well-for-me changes I wanted to get it up for others to try, and I was running over 24 hours without sleep by that point, so
> further cleanups got put off.
No rush.  Sleep is good.
Comment 20 Duncan 2021-09-09 02:20:31 UTC
(In reply to Jack from comment #19)
> > > icon_layout_6.png
> Got it.  I had copied the ebuild for 0.146 and it didn't refer to that file,
> so I didn't copy the file.  In fact, if you look at the layout config in the
> current Pan, that option is no longer present.  I wonder if you had copied
> an older ebuild than 0.146.  

LOL.  As mentioned above I've been running pan-9999 since an ebuild for it was in the tree, I'd guess 0.13x era, and my original copy from the tree to my overlay would have been when the live build was removed from the tree, perhaps late 0.13x era.

I've updated that ebuild of course since then, syncing dep min-versions, etc, with the biggest update surely being the switch to git-r3.eclass, but never realized the png was no longer necessary.

> I suspect it was decided that three vertical panes wasn't
> really viable for actual use, but we might find a comment in the NEWS or git
> log.

You had me confused for a moment as that's talking about the overlay png again, after switching to the gmime error/patch discussion. Probably it got out of order due to a reply revision.  I've had that happen on occasion.

Anyway, as it happens one of my trivial local patches does add back the triple-vert-pane.  I wasn't using it back when it was actually an option but thought I remembered it being there.  Actually thought I must be remembering wrong (and without looking thought the png was for a missing *.desktop file icon) since triple-vert wasn't there any more when I switched monitor layout and needed it, so I hacked it in as a local patch.

Now, due to this icon discussion I actually looked at the icon and realize you are correct, the option must have been there at some point, and I /was/ remembering correctly when I thought I had seen it but could no longer find it.

And turns out my hack, while it sort of works, doesn't actually remember the sizes of the triple vertical panes when I enable that option.  But due to your hint I can now go back in git history and see if the commit removing the option removed a bit more than I hacked back in, that I can add to my hack, or if perhaps the option was was removed because it was /not/ remembering pane sizes and wasn't thought to be worth the trouble to fix, so was simply removed instead.

If the removal does turn out to have a bit more code than my hack, I'll have to figure out then whether I want to keep the fixed patch personal, or submit it upstream, and if I do, whether I think it's worth keeping in the ebuild in the mean time or not.  Based on that I'll either add the patch with the icon, or remove the icon.

As for the gmime error/patch, now pan is failing to build for me too, at the exact same commit as I have already installed.

Given that and the fact that the only changes I'm /aware/ of since the successful build are the removal of the v2 libs, I'm strongly suspecting that, even tho I'd normally agree with you about the low likelihood.

I'll test that theory shortly.  Luckily I have FEATURES=buildpkg set and thus have binpkgs of the libs in question, so I don't have to actually rebuild them to reinstall and test.

FWIW, the failure is really early (so early I thought it was a conflict between a new commit and one of my local patches, until I saw it was the same commit I have merged).  

It's an autoconf failure in the ebuild prepare phase.  Is that what you're seeing?
Comment 21 Duncan 2021-09-09 02:32:26 UTC
(In reply to Duncan from comment #20)
> now pan is failing to build for me too, at the
> exact same commit as I have already installed.
> 
> Given that and the fact that the only changes I'm /aware/ of since the
> successful build are the removal of the v2 libs, I'm strongly suspecting
> that, even tho I'd normally agree with you about the low likelihood.

That's actually it.  With gtk2 remerged pan builds fine once again.

Given the early autoconf failure and the fact pan built with both gtk2/3 installed doesn't actually need gtk2 at runtime, it's likely simply still looking/testing for gtk2 somewhere and needs a patch to check for gtk3 instead/as-well.  I'll have to dive into the logs a bit further to see, and check the patch you mentioned against it too.

Meanwhile, you can try remerging gtk2 and see if pan builds for you with both it and gtk3 merged.  If it does it should run without gtk2, as it did for me.  (gtk2 and the couple theme deps it pulled in was enough.  pan built without gtkspell2 and gmime2, just needing gtk2.)
Comment 22 Duncan 2021-09-09 03:26:37 UTC
(In reply to Jack from comment #19)
> > > This fails to compile for me with gmime3.
> https://lists.nongnu.org/archive/html/pan-devel/2021-09/msg00002.html should
> get you to a reasonable point in that thread.  I'll be glad to attach the
> patch I'm currently using, I don't think it's actually gotten committed
> upstream yet.

Confirmed that's not upstream yet.

And it's not the gtk2/autoconf bug I'm seeing, which happens much earlier than yours.

But looking at the patch it appears to be signing-related, thus USE=crypt related.  If you have USE=crypt that would explain your seeing it and not me, as I have USE=-crypt.

And... confirmed.  I get your error with USE=crypt .  Until upstream processes that patch (or I apply it and update the ebuild), if you don't need crypt in gmime for something else you can turn it off and do without signed-message processing in pan.  Alternatively, dump that patch in /etc/portage/patches/net-nntp/pan/ and let portage auto-apply it.  Either one should work.

But after that 24 awake I only got 8, not further behind but no catch-up either, and I'm fading again, so this is likely my last update tonight.
Comment 23 Jack 2021-09-09 19:37:20 UTC
./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/pan-9999 --htmldir=/usr/share/doc/pan-9999/html --libdir=/usr/lib64 --disable-maintainer-mode --disable-nls --without-yelp-tools --with-gtk3 --with-gmime30 --without-webkit --with-gmime-crypto --with-dbus --disable-gkr --with-gtkspell --enable-libnotify --with-gnutls
checking that generated files are newer than configure... done

is my configure line.  I'm building with gtk3 and gmime3, and with crypto.  In figuring out compile failures, I think you absolutely need to know which version of the libs it's using.  It only needs the one it's using to be installed, and I am pretty sure it looks for one based on the ./configure parameters.  However, no surprise if using different lib versions generates different errors, since much of the code is likely ifdef'd for the library version.

On the layout png, I found something showing there were 5 layouts in 2006, so the sixth one was likely dropped earlier than that, but I don't know what Pan version it was at that time.

On your "new" build failure - it may well relate to any changed USE flags, and thus changes to the ./configure parameters, and use of different lib versions.

Given how things are moving, I personally won't bother trying with the -2 versions, and wouldn't be surprised if they get dropped as options sooner rather than later.
Comment 24 Jack 2021-09-09 19:40:42 UTC
Created attachment 738658 [details, diff]
patch for the compare pointer to int compile failure

This patch changes four lines from >0 or > 0 to != NULL in checking the return value of the function that signs a mime attachment (my paraphrase.)  The upstream patch (which is so far only in the developers personal repository) will probably only change the two lines for gmime3.  I have only tested when compiling against gmime3, so I don't know for sure if the fix is also necessary for gmime2.