Bug#923609: proposed solution
On Sun, Mar 10, 2019 at 07:12:43PM +, Dmitry Bogatov wrote: > Good. Try this version of patch, please. It seems to works for me in my > i386 chroot. Works for me too, and light testing didn't reveal any problems. > > It would make sense to limit this to 32-bit architectures as I believe the > > 64-bit architectures always have LFS support no matter the build flags. > > I'd leave it as-is. Yes, it may be redundant on 64 bit platforms, but it > will go away rather soon anyway. I'd rather not complicate `debian/rules'. Whatever, just seems strange to me to ship a -nolfs binary that's actually LFS enabled just like the normal one. > > Shipping these -nolfs binaries and including instructions for upgrading > > databases in the Buster release notes would be an acceptable fix for > > this issue IMO. > By the way, should I file bug aganist release.debian.org now, or when we > are settled on solution? I'm fine with either, and I think we're pretty much settled now :) Thanks for your work, -- Niko
Bug#923609: proposed solution
[2019-03-08 22:40] Niko Tyni > On Fri, Mar 08, 2019 at 02:39:53PM +, Dmitry Bogatov wrote: > > > I believe this patch would somewhat solve issue. Dear submitter, can you > > please apply this patch, build package and check, that `gdbm_load-nolfs' > > binary from created bin:gdbmtool does sensible thing? > > Thanks. It doesn't quite work as-is, because 'future=+all' in > DEB_BUILD_MAINT_OPTIONS still pulls the LFS flags in the build. But if > I take that away, it works at least for my trivial databases (both GDBM > and NDBM). I'll try to test a bit more later. Good. Try this version of patch, please. It seems to works for me in my i386 chroot. > It would make sense to limit this to 32-bit architectures as I believe the > 64-bit architectures always have LFS support no matter the build flags. I'd leave it as-is. Yes, it may be redundant on 64 bit platforms, but it will go away rather soon anyway. I'd rather not complicate `debian/rules'. > Shipping these -nolfs binaries and including instructions for upgrading > databases in the Buster release notes would be an acceptable fix for > this issue IMO. Good. By the way, should I file bug aganist release.debian.org now, or when we are settled on solution? From 8a76aafea8096d71a72ee16596c3cfaa12e0f291 Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Thu, 7 Mar 2019 20:19:11 + Subject: [PATCH] Provide version with LFS support disabled --- debian/rules | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/debian/rules b/debian/rules index fce1572..78eeb73 100755 --- a/debian/rules +++ b/debian/rules @@ -1,6 +1,6 @@ #!/usr/bin/make -f export LC_ALL = C -export DEB_BUILD_MAINT_OPTIONS = hardening=+all future=+all reproducible=+all +export DEB_BUILD_MAINT_OPTIONS = hardening=+all reproducible=+all include /usr/share/dpkg/default.mk # Upstream source code in src/version.c uses __DATE__ and __TIME__ @@ -35,21 +35,26 @@ ifeq ($(HAVE_DIETLIBC),yes) --libdir $(DIET_LIBDIR) \ --disable-shared \ --enable-static \ + --enable-largefile \ --enable-memory-mapped-io=no \ CC='diet gcc' CPPFLAGS='-UHAVE_MMAP' endif - dh_auto_configure -B glibc-build -- --enable-libgdbm-compat + dh_auto_configure -B glibc-build -- --enable-libgdbm-compat --enable-largefile + dh_auto_configure -B glibc-nolfs-build -- \ + CFLAGS='-static' --program-suffix=-nolfs --disable-largefile override_dh_auto_build: ifeq ($(HAVE_DIETLIBC),yes) dh_auto_build -B diet-build endif dh_auto_build -B glibc-build + dh_auto_build -B glibc-nolfs-build override_dh_auto_install: ifeq ($(HAVE_DIETLIBC),yes) dh_auto_install -B diet-build endif + dh_auto_install -B glibc-nolfs-build dh_auto_install -B glibc-build ifeq ($(HAVE_DIETLIBC),yes) -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#923609: proposed solution
On Fri, Mar 08, 2019 at 02:39:53PM +, Dmitry Bogatov wrote: > I believe this patch would somewhat solve issue. Dear submitter, can you > please apply this patch, build package and check, that `gdbm_load-nolfs' > binary from created bin:gdbmtool does sensible thing? Thanks. It doesn't quite work as-is, because 'future=+all' in DEB_BUILD_MAINT_OPTIONS still pulls the LFS flags in the build. But if I take that away, it works at least for my trivial databases (both GDBM and NDBM). I'll try to test a bit more later. It would make sense to limit this to 32-bit architectures as I believe the 64-bit architectures always have LFS support no matter the build flags. Shipping these -nolfs binaries and including instructions for upgrading databases in the Buster release notes would be an acceptable fix for this issue IMO. > By the way, can I somehow help to make autopkgtests on !amd64 happen? I don't know; the debian-ci@ldo list is probably the best contact for that. Thanks again, -- Niko
Bug#923609: proposed solution
I believe this patch would somewhat solve issue. Dear submitter, can you please apply this patch, build package and check, that `gdbm_load-nolfs' binary from created bin:gdbmtool does sensible thing? By the way, can I somehow help to make autopkgtests on !amd64 happen? From dbbe906795dd977ed16cccaa7b0385ce8654c8a5 Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Thu, 7 Mar 2019 20:19:11 + Subject: [PATCH] Provide version with LFS support disabled --- debian/rules | 4 1 file changed, 4 insertions(+) diff --git a/debian/rules b/debian/rules index fce1572..03b6242 100755 --- a/debian/rules +++ b/debian/rules @@ -39,17 +39,21 @@ ifeq ($(HAVE_DIETLIBC),yes) CC='diet gcc' CPPFLAGS='-UHAVE_MMAP' endif dh_auto_configure -B glibc-build -- --enable-libgdbm-compat + dh_auto_configure -B glibc-nolfs-build -- \ + CFLAGS='-static' --program-suffix=-nolfs --disable-largefile override_dh_auto_build: ifeq ($(HAVE_DIETLIBC),yes) dh_auto_build -B diet-build endif dh_auto_build -B glibc-build + dh_auto_build -B glibc-nolfs-build override_dh_auto_install: ifeq ($(HAVE_DIETLIBC),yes) dh_auto_install -B diet-build endif + dh_auto_install -B glibc-nolfs-build dh_auto_install -B glibc-build ifeq ($(HAVE_DIETLIBC),yes) -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgpmOxYXdMFMr.pgp Description: PGP signature
