Needs a lot of work upstream and it's not happening.
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(+)
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.)
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.
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.
(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...
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.
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.
Considering
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.
(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
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.
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(-)
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
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! =:^)
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.
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.
(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. =:^)
Created attachment 738367 [details] The missing icon_layout_6.png
[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.
(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?
(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.)
(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.
./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.
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.
There has been some update in 2022, 0.150 has Gtk3 as default now. Any chance to get that back into Portage?
(In reply to Massimo Burcheri from comment #25) > There has been some update in 2022, 0.150 has Gtk3 as default now. > Any chance to get that back into Portage? that would be really really good
Created attachment 804343 [details] ebuild pan-0.151 Hello, I have an ebuild that compiles for version 0.151. It's worth what it's worth, it's very perfectible, it must be full of errors but for me it works.
Can we please file a new bug?
(In reply to Matt Turner from comment #28) > Can we please file a new bug? You can tick "don't email me about this bug".
I've added this to GURU. Upstream is in much better shape now. Unless someone else wants to pick it up I'll look at proxy maintaining it in :gentoo next month, it should be in there. My initial commit with 0.154: https://github.com/gentoo/guru/commit/a2389800ee54c63950567ef73586d8541cd4c5c5
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=a2389800ee54c63950567ef73586d8541cd4c5c5 commit a2389800ee54c63950567ef73586d8541cd4c5c5 Author: Joe Kappus <joe@wt.gd> AuthorDate: 2023-01-16 10:40:38 +0000 Commit: Joe Kappus <joe@wt.gd> CommitDate: 2023-01-16 10:40:38 +0000 net-nntp/pan: new package, add 0.154 Bug: https://bugs.gentoo.org/784266 Signed-off-by: Joe Kappus <joe@wt.gd> net-nntp/pan/Manifest | 1 + net-nntp/pan/metadata.xml | 24 +++++++++++++++++++ net-nntp/pan/pan-0.154.ebuild | 55 +++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 80 insertions(+)
