Your message dated Sat, 18 Mar 2023 14:34:46 +0200
with message-id <[email protected]>
and subject line Re: Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on
hppa
has caused the Debian Bug report #1030983,
regarding gdnsd may FTBFS on 32-bit platforms, e.g. on hppa
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1030983: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030983
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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&arch=hppa&ver=3.8.0-1&stamp=1676009104&raw=0
which reports
error: rfc1035:
readdir(/<<PKGBUILDDIR>>/t/testout/027tcp_control_055tcp_control_chal/etc/zones/)
failed: Value too large for defined data type
Please add "future=+lfs" to DEB_BUILD_MAINT_OPTIONS in the debian/rules file to
overcome this issue, e.g.:
export DEB_BUILD_MAINT_OPTIONS = hardening=+all future=+lfs
This doesn't fix all tests in the testcase, but avoids at least this specific
(basic and important) issue.
I will analyze the other issues too...
Thanks,
Helge
--- End Message ---
--- Begin Message ---
Dear Helge,
On Fri, Mar 17, 2023 at 03:42:15PM +0100, Helge Deller wrote:
> 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 future=+lfs, and
> - can't enable AC_SYS_LARGEFILE
> otherwise it breaks libev.
> So, we have to uncouple gdnsd from libev.
>
> My suggestion:
> The attached patch switches gdnsd to use 64-bit functions unconditionally.
> It works for me, but of course doesn't fix all corner cases unless libev
> is built with 64-bit offsets as well.
> Anyway, it's a step forward.
The libev uses are not corner cases but core gdnsd features including as
I mentioned in my last email, the way its config files are read and
state files are written. As such, I don't think that your patch makes
sense.
Either:
1) libev is built with LFS support (future=+lfs etc.), in which case
gdnsd will also need to be build with future=+lfs (given the stat
structures cross the ABI boundary), in which case all of the issues will
go away, no patches necessary; or
2) libev is not built with LFS support, and thus gdnsd does not -and
cannot- have LFS support, no matter how much we patch it.
Basically, I don't see the value of patching the source code as things
stand -- we gain nothing from it.
I think the next step would be for you to convince the libev maintainers
to build with future=+lfs, and handle this as a transition for all of
its reverse dependencies.
As such, while this is technically a gdnsd bug indeed, it's just one of
out of hundreds of bugs that need to be filled for this transition and
it cannot be resolved independently. Therefore I am resolving this for
the time being. If you do end up coordinating a transition and MBF, feel
free to reopen and tag it appropriately.
Sorry to not have a better resolution and to not be of more help.
Regards,
Faidon
--- End Message ---
