Simon McVittie wrote:
> The wontfix tag was because upstream are not willing to add pkg-config
> metadata
It was. Now, it has been changed.
In the next version of libgpg-error (1.33), we will offer gpg-error.pc
(if nothing is going wrong). I believe this change helps
cross-compiling other pack
Control: tags -1 - wontfix
On Tue, 16 Oct 2018 at 10:00:03 +0900, NIIBE Yutaka wrote:
> Simon McVittie wrote:
> > The wontfix tag was because upstream are not willing to add pkg-config
> > metadata
>
> It was. Now, it has been changed.
Removing the tag, then. Thanks!
> In the next version of
Hello,
Thanks for your explanation. I learn.
Let me explain from GnuPG development side. We care traditional UNIXen
and unusual OSes. (minimum version of) GnuPG should be able to be built
and installed in early stage of development.
Simon McVittie wrote:
> Control: tags -1 - wontfix
OK.
>
Control: close 643341 1.33-3
hi all--
libgpg-error 1.33 is now in unstable, and it ships a pkg-config file.
Thanks to NIIBE for all his work on this!
as of 1.33-3, i'vem also added an autopkgtest that uses the pkg-config
file to ensure that a simple build works as expected.
Could any of the fo
On 09/03/2014 01:28 PM, Colin Watson wrote:
> That said, the problem hasn't gone away entirely as we'll encounter it
> as soon as we have something like a package that needs to build both
> build and host architecture versions of a package linked against
> libgpg-error.
Can you point to such a pac
On Wed, Sep 03, 2014 at 03:58:59PM -0400, Daniel Kahn Gillmor wrote:
> I'm unaware of any package that needs this particular requirement, and
> it seems to me that any -dev package currently in the archive would have
> the same issue, no?
I do not know about the situation Colin has in mind, but th
On 09/03/2014 04:25 PM, Helmut Grohne wrote:
> One thing that libgpg-error can do nonetheless is to move
> /usr/include/gpg-error.h to /usr/include//gpg-error.h. This
> avoids accidental inclusion of a wrong-architecture header. Refer to
> <20140829095214.gv19...@stoneboat.aleph1.co.uk> section 3.4
On Wed 2014-09-03 17:30:30 -0400, Daniel Kahn Gillmor wrote:
> On 09/03/2014 04:25 PM, Helmut Grohne wrote:
>> One thing that libgpg-error can do nonetheless is to move
>> /usr/include/gpg-error.h to /usr/include//gpg-error.h. This
>> avoids accidental inclusion of a wrong-architecture header. Refe
On Mon, Sep 15, 2014 at 05:17:06PM -0400, Daniel Kahn Gillmor wrote:
> we would need to move /usr/include/gpg-error.h to
> /usr/include/$ARCH/gpg-error.h (since that file varies by architecture).
This move has benefits on its own. See
https://lists.debian.org/debian-devel-announce/2014/08/msg00013
On 09/16/2014 02:49 AM, Helmut Grohne wrote:
> On Mon, Sep 15, 2014 at 05:17:06PM -0400, Daniel Kahn Gillmor wrote:
>> we would need to move /usr/include/gpg-error.h to
>> /usr/include/$ARCH/gpg-error.h (since that file varies by architecture).
>
> This move has benefits on its own. See
> https://
On Thu, Sep 18, 2014 at 12:09:03PM -0400, Daniel Kahn Gillmor wrote:
> On 09/16/2014 02:49 AM, Helmut Grohne wrote:
> > On Mon, Sep 15, 2014 at 05:17:06PM -0400, Daniel Kahn Gillmor wrote:
> >> we would need to move /usr/include/gpg-error.h to
> >> /usr/include/$ARCH/gpg-error.h (since that file va
11 matches
Mail list logo
