Re: Pan 0,145, not assembling binary downloads

Sorry if the question is dumb, but you haven't accidentally switched
the "Action" from "Save attachements" to "Save text" in the download
pop-up? It happened to me once...:-) - and the setting is
semi-persistent, i.e. it keeps the choice until you save with a
different one.

--Per Hedeland

On 2019-04-28 14:17, Dave wrote:
> On Sat, 23 Mar 2019 23:27:52 +0000, Dave wrote:
> 
>> Pan 0.145 is no longer assembling binary parts
>> into files.  If I try to download a binary
>> attachment all I get are many .msg files.
>>
>> If the binary post has an .nzb file, right clicking
>> the nzb post and choosing Save Articles From
>> Selected NZB works fine, so I assume they are using
>> two different methods of getting the data and then
>> "doing stuff" with it.
>>
>> Pan has not changed, so it must be one of the
>> the dependencies causing the problem. (or a
>> dependency of a dependency)
>>
>> Does anyone know which dependency is used for this
>> function?
> 
> Well, I've been busy since I posted this, but I've now tried a few
> things to see if there is a solution.  So far, no luck.
> 
> Pan is still the same version.  FreeBSD is still the same version.
> 
> I tried building against gmime24, 26 and 30 (default is 26) and
> still no solution.  I can't see any other build or runtime
> dependencies which may be relevant.
> 
> I can still download those binaries which include an NZB file as
> per the original post above, but any attempt to simple "Save" a
> binary article results in just the many, many .msg files being
> dumped into the destination directory.
> 
> I'd very much appreciate some pointers as to what to look for or
> guidance on what potential helpers might need to know from me to
> lead to a resolution.
> 
> I generally use FreeBSD with binary package updates but have one
> or two unrelated apps built from ports, Pan being one of them to
> increase the maximum connections per server as per the servers
> rules rather than the default 4 in the source file.  This does of
> course mean that Pan dependencies may be updated/upgraded when Pan
> isn't, ie Pan is "locked" in terms of "pkg upgrade".  To stay in
> sync I also keep the ports system up to date and rebuild Pan as
> required, ie if dependencies are upgraded.
> 
>