[BUG] gpgme_data_new_from_filepart() broken since gpgme 0.4.5

[Albrecht Dreß]

The real world problem (of which the test app is a heavyly stripped down  
example) *is* indeed balsa.

The situation is that balsa needs gpgme 0.4.3 or above. People upgraded a  
debian sid package from 0.4.3 to 0.4.5 (apparently 0.4.4 is not  
available), resulting in the described problems. This is of course against  
the whole philosophy of package management. The increase in the patchlevel  
id is a little small to indicate *what* might go wrong here! So maybe move  
gpgme 0.4.5 to 0.5.0?

Even worse, recompiling did not help. So the statement in NEWS that LFS  
support is commonplace for Gtk+-2.0 seems to be wrong (I must admit that I  
ignored this section due to this... shame on me!).

Adding largefile support to balsa *may* be an option, but as it is a  
complex project, I have no idea if it breaks other things. Maybe it's  
better to try finding a workaround for lfs functions...

Thanks,

	Albrecht.


P.S.: I asked the list about a problem with non-blocking gpgme_wait() a  
few days ago. Any ideas about that? Again ignoring the obvious? ;-))



Am 22.03.04 21:38 schrieb(en) Marcus Brinkmann:
> At Mon, 22 Mar 2004 19:54:02 +0100,
> > The problem occurs at least with YellowDog Linux (kernel 2.4.25) and
> with
> > Debian Sid. Is this related to the largefile patch introduced with
> 0.4.5,
> > which would be an EXTREMELY bad thing as it's appparently plain
> unusable
> > out of the box? Or any ideas???
> 
> Likely the LFS change.  Read the NEWS entry carefully, it explains all
> the details.
> 
> If you are compiling a GPGME program against 0.4.5, you MUST use
> largefile support.
> 
> I disagree that this is "EXTREMELY bad".  Some programs that used LFS
> were broken with GPGME 0.4.x where x <= 4.  This was now fixed in
> 0.4.5.  However, in return, now some programs that were not compiled
> with LFS are broken now.  "Some programs" means all programs that use
> one of the GPGME interfaces that use off_t, in this case
> gpgme_data_new_from_filepart.  Supporting both types of programs is
> very, very difficult.  We figured that the majority of applications
> already use LFS, and that the number of program using the off_t using
> interfaces is small anyway.
> 
> If this is just a theoretical situation, I am not going to worry about
> it.  However, I suspect that you did not find this problem by
> exploring corner conditions.  If there is an actual application which
> you found was broken after an update to GPGME 0.4.5, you just need to
> recompile it with largefile support.  For applications like balsa this
> is already be the case, isn't it?
> 
> For distributions, which sometimes have to worry about upgrades and
> compatibility, I have reserved a special soname that can easily be
> activated to let both versions of the library coexist during the
> transition.
> 
> Without knowing more about the real world problem you are facing,
> that's all I can say.  It's all in the NEWS entry, too, with some more
> details.
> 
> Thanks,
> Marcus
>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Albrecht Dreß  -  Johanna-Kirchner-Straße 13  -  D-53123 Bonn (Germany)
       Phone (+49) 228 6199571  -  mailto:albrecht.dress at arcor.de
_________________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20040322/342a4d51/attachment.bin