Hi Faidon,
On 3/17/23 13:21, Faidon Liambotis wrote:
Friendly bump on this! I'd just like to agree on next steps while we
have this in our recent memory :)
Ok, let's summarize.
Because we don't know in advance how libev it built (with or without 64-bit
offsets), we:
- can't enable
Hi Helge,
On Mon, Feb 27, 2023 at 11:08:23PM +0200, Faidon Liambotis wrote:
> What would you like to do with this bug? Would you like to file a bug
> against libev and mark this bug as blocked by the libev one? Or
> alternatively I can mark as wontfix and resolve?
Friendly bump on this! I'd just
On Mon, Feb 27, 2023 at 09:20:05PM +0100, Helge Deller wrote:
> Yes, you seem to be right. I missed the stat() calls.
> I wonder - do you know which files are monitored with the stat() calls?
> Could it be that those are just files from /dev or /proc, or are other
> standard files monitored too?
Hello Faidon,
On 2/27/23 18:36, Faidon Liambotis wrote:
2) the stat() calls, via ev_stat_init etc., in the mon and extfile plugins.
...
However, (2) is not self-contained, with stat structures crossing an ABI
boundary (libev's). Hence why the test suite (legitimately) fails when
building with
Hi Helge,
On Sun, Feb 26, 2023 at 01:06:16PM +0100, Helge Deller wrote:
> > So, from what I can tell, this is not something that I can fix locally
> > within gdnsd right now. AIUI what would need to happen is that libev
> > would need to be build with LFS support first, which would mean
> >
Hello Faidon,
On 2/20/23 09:38, Faidon Liambotis wrote:
On Sat, Feb 11, 2023 at 08:43:07PM +0100, Helge Deller wrote:
Actually, most packages already enable LFS by default (e.g by checking and
using the _FILE_OFFSET_BITS=64 possibility, or by using future=+lfs), so there
are not so many
On Sat, Feb 11, 2023 at 08:43:07PM +0100, Helge Deller wrote:
> Actually, most packages already enable LFS by default (e.g by checking and
> using the _FILE_OFFSET_BITS=64 possibility, or by using future=+lfs), so there
> are not so many packages left
OK, so I made some tests in order to
Does this mean that a bug needs to be filed and
d/rules to be adjusted for every package that uses readdir()? That's a
pretty massive MBF and I don't think it would scale very well :)
Yes, correct.
Actually, most packages already enable LFS by default (e.g by checking and
using the
On 2/11/23 19:21, Faidon Liambotis wrote:
On Sat, Feb 11, 2023 at 06:53:16PM +0100, Helge Deller wrote:
I'm not very familiar with the LFS work; could you help me understand a
bit better the need for adding this flag? Is this an MBF or something
specific to gdnsd? Why would this need to be
On Sat, Feb 11, 2023 at 06:53:16PM +0100, Helge Deller wrote:
> > I'm not very familiar with the LFS work; could you help me understand a
> > bit better the need for adding this flag? Is this an MBF or something
> > specific to gdnsd? Why would this need to be tuned at the package level?
>
>
Hi Faidon,
On 2/11/23 18:15, Faidon Liambotis wrote:
On Fri, Feb 10, 2023 at 08:48:37AM +0100, Helge Deller wrote:
On 32-bit platforms this package may fail to build when running on large discs.
One example is visible in log from the hppa platform:
Hi Helge,
On Fri, Feb 10, 2023 at 08:48:37AM +0100, Helge Deller wrote:
> On 32-bit platforms this package may fail to build when running on large
> discs.
> One example is visible in log from the hppa platform:
> https://buildd.debian.org/status/fetch.php?pkg=gdnsd=hppa=3.8.0-1=1676009104=0
>
Package: gdnsd
Tags: ftbfs, hppa, lfs
Version: 3.5.2-1
On 32-bit platforms this package may fail to build when running on large discs.
One example is visible in log from the hppa platform:
https://buildd.debian.org/status/fetch.php?pkg=gdnsd=hppa=3.8.0-1=1676009104=0
which reports
error:
13 matches
Mail list logo
