[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] Pan git version
From: |
Duncan |
Subject: |
Re: [Pan-users] Pan git version |
Date: |
Wed, 16 Oct 2013 04:46:55 +0000 (UTC) |
User-agent: |
Pan/0.140 (Chocolate Salty Balls; GIT 6e6fd84 /usr/src/portage/src/egit-src/pan2) |
Rhialto posted on Wed, 16 Oct 2013 00:37:37 +0200 as excerpted:
> On Wed 16 Oct 2013 at 00:12:07 +0200, Rhialto wrote:
>> On Tue 15 Oct 2013 at 23:53:44 +0200, Rhialto wrote:
>> > I just did my quarterly software update, and with it I built a pan
>> > from git (from git://git.gnome.org/pan2) and I noticed some
>> > unfortunate differences with 0.139 (which I had apparently used
>> > before).
>>
>> Correction: I must have used a git version, probably from about 6
>> months ago (compiled on 3 April 2013, it seems). I just noticed that
>> there was no download meter any more in the 0.139, and the info popups
>> in the task window were not turn-offable.
>
> More correction: the latest git version was compiled with gtk 3.
> I re-built it with gtk 2 and the obvious signs of trouble were gone
> again.
> Hooray!
=:^)
Some points for further reference:
1) Whenever you report on the git version, please mention the git commit
ID. If you're posting with pan (as I am, via gmane) it's in the headers
(user agent string), but you're posting with mutt, and that tells nothing
about the pan git commit you're running unless you manually tell us in
the message body itself.
Anything close to current pan should have that information in the pan
about dialog, too, so you don't have to go fiddling with git to find it.
=:^)
Of course assuming current master/HEAD, it's often possible to figure out
what git commit simply based on when you posted, since pan development
isn't /that/ fast and furious. But even then, for those like me who run
git but who may well have last rebuilt a week ago, it's useful to know
for sure whether we're now behind or not, without having to actually go
do another pull to check.
2) While AFAIK some distros are shipping pan built against gtk3, I
believe a gtk2 build is still recommended as the most likely to be stable
and least buggy, tho from hints Heinrich has dropped he may actually be
running a gtk3-based pan there, in which case the freshest commits may
well be only gtk3-tested.
But I run a gtk2-based git-pan here and keep relatively current, usually
within a week, almost certainly within 10 days or so. Gentoo policy for
gtk-based packages that can build against one or the other but not both
is package maintainer selects the best choice tho they can expose the
choice as a USE flag if they wish as well, and gentoo's pan is still gtk2
based. Even if it weren't, I'd probably stay with a gtk2-based ebuild
here (sticking it in my personal overlay), as I'm generally kde based and
don't even have gtk3 installed. And I prefer to keep it that way until
firefox and claws-mail upgrade to gtk3, so as not to have to build both
versions. And I just checked the upstream firefox gtk3 status bug, and
as of its last update in June, firefox was building and running against
gtk3, but with some rendering bugs still, and NPAPI support was missing
so gtk3-based-firefox is still a definite no-go for anyone caring about
servantware flash plugin support, which doesn't include me but does
include enough people that gtk2-based firefox isn't going anywhere for
the time being in any mainline distro, which means gtk2 itself isn't yet
in any serious danger of deprecation and removal either. So I think it's
safe to say a gtk2-based-pan has little to worry about for the time
being, tho I imagine I'll be looking into it again in about a year. =:^)
3) You reported gmime-2.4 which shouldn't be an issue, but do be aware of
the fact that gmime-2.6.16 thru 2.6.18 trigger a serious threading bug in
pan. You may want to take a look at the relevant threads if you're not
already tracking them. With the help of Dave here on this list pointing
me at gmime, I tracked down the bug and affected versions and reported an
upstream gmime bug, which is already fixed upstream so 2.6.19 should be
fine. And gentoo's gmime-2.6.18-r1 has the patch (and a couple others as
well), and Dave says freebsd, which he uses, has the fix in current as
well. You'd have to check netbsd's version, however, if you upgraded to
gmime 2.6.16-2.6.18, tho as I said, 2.6.19 should be fixed upstream, when
it comes out.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman