[PATCH] extended attributes support
Hello, to all!
We have already discussed the support of extended attributes. I did not
wait for "concrete plans and code." And try to make it by myself.
xattrs manifest file in DEBIAN dir. you can dump xattr to this file by
getfattr -d. When dpkg install deb packet it parse this file(if exist)
and set
appropriate attr.
In the project I'm quite new, so I welcome your suggestions and kommentriev.
From ddfda13ff80d609b39d5845faa39a2fdfcf63476 Mon Sep 17 00:00:00 2001
From: Dmitry Falko
Date: Tue, 11 Nov 2014 13:40:20 +0300
Subject: [PATCH] Extended attributes support
add ability to set extended attributes to files when installing,
xattrs stored in xattr file in DEBIAN dir, file format is getfattr -d
text format
---
configure.ac | 1 +
lib/dpkg/dpkg-db.h | 13 +
lib/dpkg/dpkg.h| 1 +
m4/dpkg-libs.m4| 14 +
src/Makefile.am| 4 +-
src/archives.c | 47 +++
src/archives.h | 1 +
src/unpack.c | 166
+
8 files changed, 245 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index ded48fd..72b5a6e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -65,6 +65,7 @@ DPKG_LIB_ZLIB
DPKG_LIB_BZ2
DPKG_LIB_LZMA
DPKG_LIB_SELINUX
+DPKG_LIB_XATTR
if test "x$build_dselect" = "xyes"; then
DPKG_LIB_CURSES
fi
diff --git a/lib/dpkg/dpkg-db.h b/lib/dpkg/dpkg-db.h
index 2dfe264..d393820 100644
--- a/lib/dpkg/dpkg-db.h
+++ b/lib/dpkg/dpkg-db.h
@@ -92,6 +92,18 @@ struct filedetails {
const char *md5sum;
};
+struct extattrvalue {
+ struct extattrvalue *next;
+ char *name;
+ char *value;
+};
+
+struct extattr {
+ struct extattr *next;
+ char *filename;
+ struct extattrvalue *attrs;
+};
+
enum pkgmultiarch {
PKG_MULTIARCH_NO,
PKG_MULTIARCH_SAME,
@@ -122,6 +134,7 @@ struct pkgbin {
struct dpkg_version version;
struct conffile *conffiles;
struct arbitraryfield *arbs;
+ struct extattr *xattrs;
};
/**
diff --git a/lib/dpkg/dpkg.h b/lib/dpkg/dpkg.h
index 1dfef96..1ea2269 100644
--- a/lib/dpkg/dpkg.h
+++ b/lib/dpkg/dpkg.h
@@ -74,6 +74,7 @@ DPKG_BEGIN_DECLS
#define PRERMFILE "prerm"
#define POSTRMFILE "postrm"
#define TRIGGERSCIFILE "triggers"
+#define XATTRSFILE "xattrs"
#define STATUSFILE"status"
#define AVAILFILE "available"
diff --git a/m4/dpkg-libs.m4 b/m4/dpkg-libs.m4
index 5c45b0f..caa5ccb 100644
--- a/m4/dpkg-libs.m4
+++ b/m4/dpkg-libs.m4
@@ -144,3 +144,17 @@ AC_DEFUN([DPKG_LIB_SSD],
AC_CHECK_LIB([ps], [proc_stat_list_create],
[SSD_LIBS="${SSD_LIBS:+$SSD_LIBS }-lps"])
AC_CHECK_LIB([kvm], [kvm_openfiles], [SSD_LIBS="${SSD_LIBS:+$SSD_LIBS
}-lkvm"])
])# DPKG_LIB_SSD
+
+# DPKG_LIB_XATTR
+#
+# Check for start-stop-daemon libraries.
+AC_DEFUN([DPKG_LIB_XATTR],
+[AC_ARG_VAR([XATTR_LIBS], [linker flags for xattrs support])dnl
+AC_ARG_WITH(xattr,
+ AS_HELP_STRING([--with-xattr],
+ [use xattr library to set extended attributes]))
+if test "x$with_xattr" = "xyes"; then
+ AC_CHECK_LIB([attr], [attr_copy_action],
[XATTR_LIBS="${XATTR_LIBS:+$XATTR_LIBS }-lattr"])
+ AC_DEFINE(WITH_XATTRS, 1, [define to support xattrs])
+fi
+])# DPKG_LIB_XATTR
diff --git a/src/Makefile.am b/src/Makefile.am
index 2382d75..7cce3b4 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -13,7 +13,6 @@ LDADD = \
../lib/dpkg/libdpkg.la \
$(LIBINTL)
-
EXTRA_DIST = \
$(test_scripts) \
$(nil)
@@ -59,7 +58,8 @@ dpkg_SOURCES = \
dpkg_LDADD = \
$(LDADD) \
-$(SELINUX_LIBS)
+$(SELINUX_LIBS) \
+$(XATTR_LIBS)
dpkg_divert_SOURCES = \
filesdb.c \
diff --git a/src/archives.c b/src/archives.c
index 8f6b4cf..fc16a98 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -63,6 +63,11 @@
#include
#endif
+#ifdef WITH_XATTRS
+#include
+#include
+#endif
+
#include "filesdb.h"
#include "main.h"
#include "archives.h"
@@ -260,6 +265,42 @@ tarobject_skip_padding(struct tarcontext *tc,
struct tar_entry *te)
}
static void
+tarobject_set_xattrs(struct tarcontext *tc, const char *path)
+{
+#ifdef WITH_XATTRS
+ struct extattr *attrs;
+ struct extattrvalue *values;
+ /*
+ * current filesystem can return ENOTSUP or, in that case user or packet
+ * should have information about what to do in than case
+ */
+ debug(dbg_general,"tarobject_set_xattrs file=%s", path);
+ if(tc->pkg->available.xattrs == NULL)
+return;
+
+ attrs = tc->pkg->available.xattrs;
+
+ /*search filename in list*/
+ while(attrs != NULL) {
+if(attrs->filename != NULL && memcmp(attrs->filename, path,
strlen(attrs->filename)) == 0) {
+ break;
+}
+attrs = attrs->next;
+ }
+
+ if(attrs != NULL) { /*if finded */
+values = attrs->attrs;
+
+while(values != NULL) {
+ setxattr(path, values->name, values->value,
strlen(values->value), 0);
+ debug(dbg_general,"setting '%.255s'='%.255s' for '%.255s'",
values->name, values->value, path);
+ values = values->next;
+
1.17.21 on OS X
Hey all, Hopefully this email reaches the group, the Debian spam filter can be a little overzealous at the best of times. I'm trying to compile the latest dpkg, 1.17.21 on OS X, but keep running into this persistent error. It could be expected given the relative newness of this release, but thought I'd kick the configure process upstream for a better insight. Using a patch to fix the Perl location on OS X, and the MD5/SHA1/SHA256 tool use, but nothing that should halt or interfere drastically with compile as far as I can see. The error seems to be unrelated. Shall attach the build process and the patch, both of which are hopefully some use. If anyone is particularly jumpy about email attachments, the error is: CC fdio.lo fdio.c:113:36: error: expected ';' after expression rc = fcntl(fd, F_PREALLOCATE, &fs) ^ ; fdio.c:118:37: error: expected ';' after expression rc = fcntl(fd, F_PREALLOCATE, &fs) ^ ; 2 errors generated. make[4]: *** [fdio.lo] Error 1 make[4]: *** Waiting for unfinished jobs CC file.lo make[3]: *** [all-recursive] Error 1 Cheers, Dom -- Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. ==> Downloading https://mirrors.kernel.org/debian/pool/main/d/dpkg/dpkg_1.17.21.tar.xz Already downloaded: /Library/Caches/Homebrew/dpkg-1.17.21.tar.xz ==> Verifying dpkg-1.17.21.tar.xz checksum /usr/local/opt/xz/bin/xz -dc "/Library/Caches/Homebrew/dpkg-1.17.21.tar.xz" | tar xf - ==> Downloading https://raw.githubusercontent.com/DomT4/scripts/master/Homebrew_Resources/dpkg/dpkgosx.diff Already downloaded: /Library/Caches/Homebrew/dpkg--patch-b74e5a0738bd4f6e8244d49b04ed9cb44bf5de6e.diff ==> Verifying dpkg--patch-b74e5a0738bd4f6e8244d49b04ed9cb44bf5de6e.diff checksum ==> Patching /usr/bin/patch -g 0 -f -d /private/tmp/dpkg-scXdQM/dpkg-1.17.21 -p1 -i /private/tmp/dpkg--patch-VeDcrO/dpkgosx.diff patching file configure patching file scripts/Dpkg/Checksums.pm patching file scripts/Dpkg/Source/Archive.pm patching file scripts/Makefile.am patching file scripts/Makefile.in ==> ./configure --disable-dependency-tracking --prefix=/usr/local/Cellar/dpkg/1.17.21 --disable-dselect --disable-linker-optimisations --disable-start-stop-daemon --disable-update-alternatives checking for gcc... clang checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether clang accepts -g... yes checking for clang option to accept ISO C89... none needed checking whether clang understands -c and -o together... yes checking how to run the C preprocessor... clang -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... build-aux/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking whether make supports nested variables... yes checking dependency style of clang... none checking whether make supports nested variables... (cached) yes checking whether NLS is requested... yes checking for msgfmt... no checking for gmsgfmt... : checking for xgettext... no checking for msgmerge... no checking build system type... x86_64-apple-darwin14.0.0 checking host system type... x86_64-apple-darwin14.0.0 checking for ld used by clang... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no checking for shared library run path origin... done checking for CFPreferencesCopyAppValue... yes checking for CFLocaleCopyCurrent... yes checking for GNU gettext in libc... no che
Re: 1.17.21 on OS X
Hello Dominyk! Dominyk Tiller (2014-11-11): > Hey all, > > Hopefully this email reaches the group, the Debian spam filter can be a > little overzealous at the best of times. > > I'm trying to compile the latest dpkg, 1.17.21 on OS X, but keep running > into this persistent error. It could be expected given the relative > newness of this release, but thought I'd kick the configure process > upstream for a better insight. > > Using a patch to fix the Perl location on OS X, and the MD5/SHA1/SHA256 > tool use, but nothing that should halt or interfere drastically with > compile as far as I can see. The error seems to be unrelated. > > Shall attach the build process and the patch, both of which are > hopefully some use. > > If anyone is particularly jumpy about email attachments, the error is: > > > CC fdio.lo > fdio.c:113:36: error: expected ';' after expression > rc = fcntl(fd, F_PREALLOCATE, &fs) > ^ > ; > fdio.c:118:37: error: expected ';' after expression > rc = fcntl(fd, F_PREALLOCATE, &fs) > ^ > ; > 2 errors generated. > make[4]: *** [fdio.lo] Error 1 > make[4]: *** Waiting for unfinished jobs > CC file.lo > make[3]: *** [all-recursive] Error 1 > There's a ";" character missing at the end of the line indeed; introduced in this commit: | commit 87b0b20b86407baf1deb4e91b3fd839e01228ac8 | Author: Guillem Jover | Date: Tue Jul 15 21:00:52 2014 +0200 | | dpkg: Try to preallocate the disk size for extracted files | | This might help in avoiding filesystem fragmentation, and possibly | improve performance on some filesystems. | | We use the system specific methods if available, and only use | posix_fallocate() if nothing else is available, because on some systems | its semantics are counter to what we want to obtain here, as the libc | library will fallback to manually writing '\0' to each block to force | the preallocation, instead of just failing and leaving the application | to do so if desired. Adding one should help you get further. ;) Mraw, KiBi. signature.asc Description: Digital signature
Re: [PATCH] extended attributes support
Hi! On Tue, 2014-11-11 at 14:33:00 +0300, Dmitry Falko wrote: > We have already discussed the support of extended attributes. I did > not wait for "concrete plans and code." And try to make it by myself. > xattrs manifest file in DEBIAN dir. you can dump xattr to this file by > getfattr -d. When dpkg install deb packet it parse this file(if exist) > and set appropriate attr. > In the project I'm quite new, so I welcome your suggestions and kommentriev. Sorry for not getting back to you, but I got entangled in tasks related to the impending Debian release, and the fallout from the dpkg 1.17.14 release. I expect that after 1.17.22 (or 1.17.23 if that needs to happen) I'll have to the time and mental bandwidth to review and discuss this. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112000730.ga14...@gaara.hadrons.org
Re: 1.17.21 on OS X
Hi! On Tue, 2014-11-11 at 23:12:48 +, Dominyk Tiller wrote: > I'm trying to compile the latest dpkg, 1.17.21 on OS X, but keep running > into this persistent error. It could be expected given the relative > newness of this release, but thought I'd kick the configure process > upstream for a better insight. Yes, this is a problem in the code that I've fixed now locally, will be included in 1.17.22. I try to support other Unices that I don't have access to, from documentation, but that has this kind of risk. :) I've looked for free access from time to time to porter boxes or automated build systems for at least: Mac OS X Solaris, OpenSolaris, etc AIX HP-UX to at least make sure the thing still builds, but ideally to not port blindly. I'd appreciate information if someone knows about such access. (And actually also for OpenBSD, NetBSD and DragonFlyBSD systems, as I don't have space for so many VMs locally.) > Using a patch to fix the Perl location on OS X, and the MD5/SHA1/SHA256 > tool use, but nothing that should halt or interfere drastically with > compile as far as I can see. The error seems to be unrelated. > Shall attach the build process and the patch, both of which are > hopefully some use. Thanks for both. I was aware of some of the things that need to be fixed from the BSD port collections, the Fink project, OpenSolaris ports, etc, which I regularly scan, but did not have time yet to integrate fixes in a generic way; I'd like to do that for 1.18.x, so that a pristine dpkg can be used on other systems out of the box. But this usually requires others to test stuff and report back which gets the iterations cycles a bit long. For example there's a reported test suite failure on Fink that I'd like to fix, but having access to such a system would make things much easier. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112003228.gb14...@gaara.hadrons.org
Re: 1.17.21 on OS X
Hi Cyril, Thanks for the speedy reply, Appreciate that. That did indeed seem to be the trick. I wondered why the build process was suggesting ';' were missing, but I shrugged it off as being too simple a fix, heh. "My bad" on that. That does indeed get me further, although I've run into a new error on the same fdio function: CCLD dpkg-deb Undefined symbols for architecture x86_64: "_fs_preallocate_setup", referenced from: _fd_allocate_size in libdpkg.a(fdio.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [dpkg-deb] Error 1 make[1]: *** [all-recursive] Error 1 Dom Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. On 11/11/2014 23:38, Cyril Brulebois wrote: > Hello Dominyk! > > Dominyk Tiller (2014-11-11): >> Hey all, >> >> Hopefully this email reaches the group, the Debian spam filter can be a >> little overzealous at the best of times. >> >> I'm trying to compile the latest dpkg, 1.17.21 on OS X, but keep running >> into this persistent error. It could be expected given the relative >> newness of this release, but thought I'd kick the configure process >> upstream for a better insight. >> >> Using a patch to fix the Perl location on OS X, and the MD5/SHA1/SHA256 >> tool use, but nothing that should halt or interfere drastically with >> compile as far as I can see. The error seems to be unrelated. >> >> Shall attach the build process and the patch, both of which are >> hopefully some use. >> >> If anyone is particularly jumpy about email attachments, the error is: >> >> >> CC fdio.lo >> fdio.c:113:36: error: expected ';' after expression >> rc = fcntl(fd, F_PREALLOCATE, &fs) >> ^ >> ; >> fdio.c:118:37: error: expected ';' after expression >> rc = fcntl(fd, F_PREALLOCATE, &fs) >> ^ >> ; >> 2 errors generated. >> make[4]: *** [fdio.lo] Error 1 >> make[4]: *** Waiting for unfinished jobs >> CC file.lo >> make[3]: *** [all-recursive] Error 1 >> > > There's a ";" character missing at the end of the line indeed; > introduced in this commit: > | commit 87b0b20b86407baf1deb4e91b3fd839e01228ac8 > | Author: Guillem Jover > | Date: Tue Jul 15 21:00:52 2014 +0200 > | > | dpkg: Try to preallocate the disk size for extracted files > | > | This might help in avoiding filesystem fragmentation, and possibly > | improve performance on some filesystems. > | > | We use the system specific methods if available, and only use > | posix_fallocate() if nothing else is available, because on some systems > | its semantics are counter to what we want to obtain here, as the libc > | library will fallback to manually writing '\0' to each block to force > | the preallocation, instead of just failing and leaving the application > | to do so if desired. > > Adding one should help you get further. ;) > > Mraw, > KiBi. > signature.asc Description: OpenPGP digital signature
Re: 1.17.21 on OS X
On Wed, 2014-11-12 at 00:36:42 +, Dominyk Tiller wrote: > That did indeed seem to be the trick. I wondered why the build process > was suggesting ';' were missing, but I shrugged it off as being too > simple a fix, heh. "My bad" on that. > > That does indeed get me further, although I've run into a new error on > the same fdio function: > > CCLD dpkg-deb > Undefined symbols for architecture x86_64: > "_fs_preallocate_setup", referenced from: > _fd_allocate_size in libdpkg.a(fdio.o) > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make[2]: *** [dpkg-deb] Error 1 > make[1]: *** [all-recursive] Error 1 > Buh. :/ Just rename fs_preallocate_setup() calls to fd_preallocate_setup(), I think it was a leftover from a refactoring, and let's see from there. I've squashed that in the previous commit locally. In any case, please do keep reporting any such problems on other non-GNU systems, it's much appreciated. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112004912.ga20...@gaara.hadrons.org
Re: 1.17.21 on OS X
Hi Guillem, It's not as perfect as having access to actual physical or full virtual machines, and it seems to mandate using Github which is a pain for some, but Travis is fairly useful for cross-platform testing. Travis can handle multiple Linux Distros and offer comprehensive OS X support, It may or may not be useful for you: http://docs.travis-ci.com/user/getting-started/ http://docs.travis-ci.com/user/osx-ci-environment/ Dom Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. On 12/11/2014 00:32, Guillem Jover wrote: > Hi! > > On Tue, 2014-11-11 at 23:12:48 +, Dominyk Tiller wrote: >> I'm trying to compile the latest dpkg, 1.17.21 on OS X, but keep running >> into this persistent error. It could be expected given the relative >> newness of this release, but thought I'd kick the configure process >> upstream for a better insight. > > Yes, this is a problem in the code that I've fixed now locally, will > be included in 1.17.22. I try to support other Unices that I don't have > access to, from documentation, but that has this kind of risk. :) > > I've looked for free access from time to time to porter boxes or > automated build systems for at least: > > Mac OS X > Solaris, OpenSolaris, etc > AIX > HP-UX > > to at least make sure the thing still builds, but ideally to not port > blindly. I'd appreciate information if someone knows about such > access. > > (And actually also for OpenBSD, NetBSD and DragonFlyBSD systems, as I > don't have space for so many VMs locally.) > >> Using a patch to fix the Perl location on OS X, and the MD5/SHA1/SHA256 >> tool use, but nothing that should halt or interfere drastically with >> compile as far as I can see. The error seems to be unrelated. > >> Shall attach the build process and the patch, both of which are >> hopefully some use. > > Thanks for both. I was aware of some of the things that need to be > fixed from the BSD port collections, the Fink project, OpenSolaris > ports, etc, which I regularly scan, but did not have time yet to > integrate fixes in a generic way; I'd like to do that for 1.18.x, so > that a pristine dpkg can be used on other systems out of the box. But > this usually requires others to test stuff and report back which gets > the iterations cycles a bit long. For example there's a reported test > suite failure on Fink that I'd like to fix, but having access to such > a system would make things much easier. > > Thanks, > Guillem > -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5462ae48.6050...@gmail.com
Re: 1.17.21 on OS X
Hi! On Wed, 2014-11-12 at 00:48:08 +, Dominyk Tiller wrote: > It's not as perfect as having access to actual physical or full virtual > machines, and it seems to mandate using Github which is a pain for some, > but Travis is fairly useful for cross-platform testing. Travis can > handle multiple Linux Distros and offer comprehensive OS X support, It > may or may not be useful for you: Ah thanks! When I checked it at the time, the Mac OS X support seemed to be an implementation detail of the Objective-C environment (AFAIR), it seems to be now selectable standalone, I'll try that out. And I already use Travis but only because it allows to run the Coverity client binary blob for dpkg on their system, so I don't have to trust it locally, which was a nice find when Coverity stopped running it on their own servers. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112012208.ga21...@gaara.hadrons.org
Re: 1.17.21 on OS X
Bingo. That did the trick. Compile is successful on OS X with 1.17.21 again now. Big thanks for the hasty replies and fixes, really appreciate those! I run a permanent Debian Virtualbox, so I guess the desire to compile dpkg on OS X for packaging is horribly lazy of me really heh. Bug reporting & fixing on Debian is so much more pleasant than OS X though, that's for sure. Thanks again, Dom Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. On 12/11/2014 00:49, Guillem Jover wrote: > On Wed, 2014-11-12 at 00:36:42 +, Dominyk Tiller wrote: >> That did indeed seem to be the trick. I wondered why the build process >> was suggesting ';' were missing, but I shrugged it off as being too >> simple a fix, heh. "My bad" on that. >> >> That does indeed get me further, although I've run into a new error on >> the same fdio function: > >> >> CCLD dpkg-deb >> Undefined symbols for architecture x86_64: >> "_fs_preallocate_setup", referenced from: >> _fd_allocate_size in libdpkg.a(fdio.o) >> ld: symbol(s) not found for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> make[2]: *** [dpkg-deb] Error 1 >> make[1]: *** [all-recursive] Error 1 >> > > Buh. :/ Just rename fs_preallocate_setup() calls to > fd_preallocate_setup(), I think it was a leftover from a refactoring, > and let's see from there. I've squashed that in the previous commit > locally. > > In any case, please do keep reporting any such problems on other non-GNU > systems, it's much appreciated. > > Thanks, > Guillem > -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5462b332.8060...@gmail.com
