[Pkg-gnupg-maint] Bug#714107: R: Re: Processed: reassign 714107 to gnupg

[NIIBE Yutaka]

On 2013-07-15 at 20:38 +0200, virtualdj wrote:
> OK, so you're saying that the 2.6.33.2 kernel is not compatible.

I suggested so, but let me rephrase.

Specifically, I believe that kernel you are using is incompatible.  I
don't think standard 2.6.33.2 kernel is incompatible.

  (4) When system call is not available, kernel returns ENOSYS.
      Standard 2.6.33.2 kernel does so.  There is a fallback in glibc
      to call 32-bit version of setrlimit in this case.  Because of
      this fallback, setrlimit64 works fine with older kernels.

  (5) However, if there were some incompatible change to the kernel,
      the fallback mechanism wouldn't work well.  As it was around the
      last entry of system call table, system call with number 340
      would be used for other purpose (of incompatible extension).  In
      fact, when prlimit64 was introduced it was not 340 but 338 in
      the original patch.

  (6) We saw EFAULT (Bad address) for system call 340.  System call
      340 in the kernel must be used for other purpose than prlimit64.

> But here's my question: what's changed from squeeze to wheezy that
> prevented gpg to run?
> 
> I cannot find a "system requirements" page for wheezy that consider a
> v3.0 Linux kernel mandatory.

I'd understand your complaint.  As explained above, I think that it
just works fine usually.  In the specific cases of incompatible
kernel, it won't work well.

> So wheezy cannot run on systems with older kernel?

It works (in most cases).  It doesn't work with incompatible kernel.
I'm sorry that my explanation in the previous mail was not enough.

> I'm not saying this is a bug, but what can I do to circumvent this
> issue?

I think that you can use compatible kernel, that is, older kernels with
340 not implemented, or newer kernels with 340 properly implemented.
--