pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] pan 0.143 crashes as Arch Linux


From: Duncan
Subject: Re: [Pan-users] pan 0.143 crashes as Arch Linux
Date: Tue, 2 Jan 2018 09:56:46 +0000 (UTC)
User-agent: Pan/0.144 (Time is the enemy; 28ab3baf7)

arnuld posted on Tue, 02 Jan 2018 08:39:00 +0530 as excerpted:

>> On Tue, Jan 2, 2018 at 8:15 AM, Duncan
>> <address@hidden> wrote:
>> Patch available in git as:
>> commit f6061b309
>> Tue Dec 12 01:05:27 2017 +0100
>> Require GMime 3.0 to be explicitly enabled, don't fallback to it
> 
> How to enable it.

... Oh! <light dawns>

I believe you read the comment wrong.  It's _not_ saying "require gmime 
3", it's saying don't enable gmime 3.0 by default even if installed, 
require enabling it to actually get it (because as I said it's still 
broken, but people might want to specifically enable it for testing 
anyway).

IOW, you do *NOT* want to enable gmime3 if you want a working pan, you 
want it disabled!!

Which it is according to the below output, so you're good to go. =:^)

> I checked out all the config options but found nothing
> for gmime3:
> 
> address@hidden pan2]$ ./autogen.sh --prefix="/usr" --with-gtkspell
> --with-gtk3 --with-webkit --enable-libnotify --with-gnutls
> --enable-manual --with-gmime-crypto
> 
> Configuration:
> 
>         Prefix:                 /usr
>         Source code location:   .
>         Compiler:               g++
>         With D-Bus:             no
>         With GMime 3.0:         no
>         With GMime crypto:      yes
>         With GtkSpell:          yes
>         With GTK+ 3:            yes >= 3.0.0
>         With WebKitGTK+:        yes
>         With GnuTLS:            yes (3.5.16)
>         With libnotify:         yes
>         With password storage:  no
>         With yelp-tools:        yes
>         With user manual:       yes
> 
> Now type 'make' to compile Pan address@hidden pan2]$

However, even if you actually want it disabled and it already is, so you 
should be good to go, the question remains a valid one, because it's 
often useful knowing how to hard-enable or hard-disable things and not 
just depend on automatic detection and defaults.  Certainly, gentoo users 
at least don't want "automagic" detection and strongly prefer hard-
enabling or hard-disabling (generally controlled on gentoo via USE 
flags), because otherwise the package manager doesn't track the 
dependency and can uninstall a depended library and break the package.  
So gentooers at least have a strong interest in being able to hard-enable 
or hard-disable options, and indeed, a good part of gentoo's maintainer 
patching is often adding or unbreaking options to hard-enable or hard-
disable various deps, where the upstream option is either missing or 
broken.

And other distro users doing their own builds will likely have similar 
wants/needs, tho they may not be as strong if they're doing builds 
manually anyway.

So the question remains worth finding an answer to.

Note that I consider myself /far/ from an expert in autotools or pre-
build configuration in general.  Never-the-less, between reading the 
configure help output, checking what the existing gentoo ebuilds do for 
existing options, and reading git log and git show and/or patches 
directly when I need to trace a known change, I can often-to-usually get 
the config I want/need after a bit of experimentation...

OK, seeing the output above, and noting for example --with-gnutls 
corresponds to With Gnutls: yes, while --enable-libnotify corresponds to 
With libnotify: yes, and being familiar with both patterns, at first 
guess I'd say try variants of --with-gmime-3.0=yes and --enable-gmime-30 
(or --without-gmime3 or --with-gmime-3.0=no and --disable-gmime3 to hard 
disable it) and see if one of them works.

But since we know the commit to check we can do better than first-guess 
by simply seeing which variant it uses, and what its defaults are.  And 
we see this in the patch/commit (lines wrapped and separated with 
vertical space):

+AC_ARG_WITH([gmime30],

+  AS_HELP_STRING([--with-gmime30],[enable GMime 3.0 support 
(experimental, normally: no)]), [want_gmime30=$withval], 
[want_gmime30=no])

+if test "x$want_gmime30" = "xyes" ; then


See that --with-gmime30 ?

So I'd try --with-gmime30 or --with-gmime30=yes to hard-enable, and
--without-gmime30 or --with-gmime30=no to hard-disable.  Now we know it's 
the --with variant, and it's gmime30, not gmime3 or gmime-3.0 or the 
like.  But as I said I'm not an expert, and I don't remember nor do I see 
it easily visible in the patch so I'd have to look it up or (easier) 
actually try it to see whether it's the --with-gmime30=yes/no variant, or 
the --with/without-gmime30 variant.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]