Bug#360740: [m68k] xfsprogs builds with gcc-4.1
On Tue, Apr 04, 2006 at 07:56:56AM -0500, Stephen R Marenka wrote: Package: xfsprogs Version: 2.7.14-1 Severity: important The ICE in instantiate_virtual_regs_lossage (333536) which persists on m68k in gcc-4.0 is fixed in gcc-4.1. This looks like a clear gcc bug - why is it assigned to xfsprogs? (I guess I need to know how do you expect this to become fixed by any change in xfsprogs?). Do you want a platform-specific dependency on gcc-4.1 or later (is that even possible?). I'm willing to do a binNMU if that would be helpful. I'm not sure what you'd be changing, so not sure how a binary NMU would help the situation? cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360740: [m68k] xfsprogs builds with gcc-4.1
On Tue, Apr 04, 2006 at 08:18:49PM -0500, Stephen R Marenka wrote: On Wed, Apr 05, 2006 at 07:23:29AM +1000, Nathan Scott wrote: ... I'd simply compile the package with gcc-4.1. If you're not planning a sourceful upload any time soon, this would get the package up-to-date and I'd have one less buildd failure for my arch. :) Oh, OK - please, go right ahead. I have a couple of changes in xfsprogs pending - would an upload from me help / hinder you at this stage? cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360428: xfsdump: xfs_fsr leaks memory
On Sun, Apr 02, 2006 at 11:19:25AM +0200, Ralf Hildebrandt wrote: xfs_fsr leaks memory. We talked about this on the XFS list,and you provided a patch which worked OK. I just wanted to file this report as a reminder... Hi Ralf, No need for a reminder :) -- I'm just waiting on an xfsdump fix from Bill at the moment, then I'll upload a new xfsdump package with both changes. cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358786: allow build on *-uclibc
On Mon, Mar 27, 2006 at 12:20:22PM +0200, Pjotr Kourzanov wrote: uclibc is a lightweight alternative to glibc. I am in the process of building a fair amount of Debian packages with it, for e.g. i386-uclibc architecture. Now, both uclibc-dev and libc6-dev provide libc-dev, so attr-like packages should really be hosted on libc-dev rather than libc6-dev. Updated patch to attr attached. Thanks Pjotr. I've merged these changes in (both pkgs), and will upload the new versions soon. cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358786: allow build on *-uclibc
On Tue, Mar 28, 2006 at 08:28:37AM +1000, Nathan Scott wrote: On Mon, Mar 27, 2006 at 12:20:22PM +0200, Pjotr Kourzanov wrote: uclibc is a lightweight alternative to glibc. I am in the process of building a fair amount of Debian packages with it, for e.g. i386-uclibc architecture. Now, both uclibc-dev and libc6-dev provide libc-dev, so attr-like packages should really be hosted on libc-dev rather than libc6-dev. Updated patch to attr attached. FYI - these patches cause the following lintian warning to be produced... N: N: The package declares a depends on a virtual package without listing a N: real package as an alternative first. N: N: A real package should be listed in the first part of the | dependency N: in order for the package to be installable by package management N: programs that can't or won't guess which alternative to select by N: default. In particular, it helps build daemons rebuild the package N: without manual overrides. N: N: Refer to Policy Manual, section 7.4 for details. N: Looks pretty easy to fix up though. cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358786: allow build on *-uclibc
Hi Pjotr, On Fri, Mar 24, 2006 at 12:47:01PM +0100, Pjotr Kourzanov wrote: ... This bug report could use a bit more text explaining what uclibc is all about, for those of us who don't really know. I also have several packages, but patches for only 2, and I'm now wondering if I need these changes in the rest, for example. --- attr-2.4.25/include/builddefs.in 2004-11-28 23:32:55.0 +0100 +++ attr-2.4.25-1.my/include/builddefs.in 2006-03-13 12:16:02.0 +0100 @@ -70,7 +70,7 @@ ECHO = @echo@ SORT = @sort@ LN_S = @LN_S@ -LIBTOOL = @LIBTOOL@ +LIBTOOL = @LIBTOOL@ --tag BINCC I don't understand what this part is for - could you explain it a bit please? Also, why wasn't it needed for the acl package patch (358788)? thanks. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357788: FTBFS (64 bit): conflicting types for '__s64'
On Sun, Mar 19, 2006 at 04:00:24PM +0100, Falk Hueffner wrote: xfsdump doesn't build on alpha and ia64: Ah, this is a build dependency issue - a newer version of the xfslibs-dev package needs to be used - I'll get that fixed up. BTW, is there a reason to build with -O1 instead of -O2 as policy mandates? No good reason, I'll fix that up at the same time, thanks. cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299095: attr-2.4.21-1 to stop using syscalls
On Tue, Feb 21, 2006 at 05:59:10PM +0100, Michael Banck wrote:
tags 299095 +patch
thanks
Hi,
attached is a patch which fixes the compilation of the ioctl syscalls on
hurd-i386 by essentially exempting that file.
OOC, what was the compiler error?
A more elegant fix would be to check whether the *xattr are available in
glibc and use them rather than the syscalls. Not sure how upstream
feels about this.
It would be better to simply exclude syscalls.c from the build on
your platform. From this patch I take it that the Hurd is using
a libc that provides the Linux extended attribute system calls?
That seems a bit odd, but OK.
I can easily fix up the Makefile for you - what is the definition
of PKG_PLATFORM in the generated attr/include/builddefs file from
your build (is it hurd?)
--- libattr/syscalls.c2002-09-06 05:15:41.0 +0200
+++ libattr/syscalls.c.new2006-02-21 17:51:08.0 +0100
@@ -39,6 +39,7 @@
#include errno.h
#include unistd.h
+#ifndef __GNU__
#if defined (__i386__)
# define HAVE_XATTR_SYSCALLS 1
# define __NR_setxattr 226
@@ -272,3 +273,4 @@
{
return SYSCALL(__NR_fremovexattr, filedes, name);
}
+#endif /* __GNU__ */
cheers.
--
Nathan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343414: xfsrq: calls setquota with invalid option -n
On Thu, Dec 15, 2005 at 03:31:54AM +, Malcolm Scott wrote: Version: 2.2.27-1 This was fixed in 2.2.30 (already in the archive). And in 2.2.32 (not yet uploaded), this script will be replaced entirely by the xfs_quota(8) command from recent versions of xfsprogs. cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338207: xfs_db frag command gives segmentation fault
On Tue, Nov 08, 2005 at 08:26:31PM +0100, Martin Steigerwald wrote: Package: xfsprogs Version: 2.6.36-1 Severity: normal Hello Nathan, using the frag command in xfs_db gives a segmentation fault here: Hi Martin, I fixed this a little while ago in XFS CVS, but I've not yet uploaded a new xfsprogs to the Debian archive. I've got a few other changes pending, so hopefully by weeks end I'll do this. thanks. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336350: xfsprogs should use isize=512 by default
On Sat, Oct 29, 2005 at 12:39:34PM -0400, Christopher Martin wrote: I was contemplating creating an XFS partition, and in the process of verifying that XFS works with SELinux, came across this thread: https://www.redhat.com/archives/fedora-selinux-list/2004-October/msg00023.html It indicates that for optimal operation with SELinux, XFS should use an inode size of 512 instead of the default 256. Thus I would suggest that Debian's xfsprogs default to 512 (instead of the normal 256), to ensure that future users of XFS and SELinux have an optimal experience, without having to know about this little quirk. Hi Christopher, The issue is more complex than indicated here, but the news is all good in the end... Changing the default inode size to be larger is not going to happen. While it will (currently) improve extended attribute performance, it has performance implications for everyone not using those (which is most people). However, we recently extended XFS to use a different algorithm for managing the literal area of the inode (after the stat stat, where inline data and attr information is stored) to use a more efficient representation - ultimately, this will mean 256 byte inodes will perform as well as 512 byte inodes in many situations that previously they would not have. This code will first be in the xfsprogs-2.7.x userspace package, and kernels after 2.6.15 (or perhaps 2.6.16). Look for the attr2 mount option. So, I'll close this bug out when I upload a 2.7-based xfsprogs. cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336350: xfsprogs should use isize=512 by default
On Mon, Oct 31, 2005 at 09:46:49AM +1100, Nathan Scott wrote: However, we recently extended XFS to use a different algorithm for managing the literal area of the inode (after the stat stat, where stat data, even. :) cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330596: acl: French translation update
On Wed, Sep 28, 2005 at 10:30:47PM +0200, Sylvain Archenault wrote: Please find attached the french debconf templates update, proofread by the debian-l10n-french mailing list contributors. This file should be put as debian/po/fr.po in your package build tree. Thank you, I've done that - I'll build and upload a new package soon. cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.
Hi there, Revisiting this one, again. Firstly, since we've had no other people reporting having hit this issue, I plan to downgrade this from a critical bug... I assume if it was happening to everyone the arm port would be unusable, certainly that would be critical; and we'd probably have made a bit of progress figuring it out by now. :( On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote: ... I've just upgraded my system from woody to sarge. Among other upgrade problems I noticed that programmes like cp, mv and install were occasionally segfaulting (and the packages that were invoking them failing to get installed), leaving register dumps like this in my logs: pc : [400278ac]lr : [4002a348]Not tainted sp : b4f4 ip : 40049cf8 fp : b780 r10: 400333bc r9 : ba38 r8 : b548 r7 : b561 r6 : r5 : 0001c324 r4 : b50c r3 : 0004 r2 : r1 : 9d6b r0 : b508 Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user Control: 1C14917D Table: 1C14917D DAC: 0015 So, its just dawned on me - you're saying these dumps are in your system log? That would suggest this is a kernel panic, or am I misunderstanding you there? The above trace does look like it may be the start of a kernel panic trace - was there anything else in the log? (eg. just prior, or a stack trace following the above?). I'm not at all familiar with how a kernel panic is reported on arm though. On i386, however, a kernel panic will result in something like the above being dumped (cpu register contents), followed by a stack trace, and the userspace program will typically get a SEGV (similar to what you described)... the kernel struggles on (basically, sounds exactly likely what you described). cheers. -- Nathan
Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.
On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote: ... Recompiling libacl1 (itself an awkward task since the package itself segfaults in the middle when it is doing something to the postinst script) and installing the recompiled version fixes the problem. Given this statement, and the various others that suggest this may alternatively be a kernel ABI issue, I have no reason to believe theres actually anything wrong in the libacl package itself, nor is there likely to any workaround that could be put into libacl. As such, this bug is languishing assigned to libacl -- does anyone have any suggestions as to where/how further progress could be made on this bug? Is there a generic arm-port pseudo-package I could reassign to? Should I just close it stating a different compiler has resolved this (what compiler version was used above, Jonathan?)? Any advice/suggestions, anyone? thanks! -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.
On Mon, Aug 22, 2005 at 12:30:01AM -0700, Steve Langasek wrote: On Mon, Aug 22, 2005 at 03:29:54PM +1000, Nathan Scott wrote: ... Recompiling libacl1 (itself an awkward task since the package itself segfaults in the middle when it is doing something to the postinst script) and installing the recompiled version fixes the problem. Any advice/suggestions, anyone? If it *is* a kernel ABI issue, it would be appropriate for the current libacl1 package in sarge to include a preinst check for the running Yep, OK. I guess I'm not following how a kernel ABI issue could be resolved by a re-compile though (not to say it is not an ABI issue, just that I don't understand how). kernel version to avoid installing a known-broken combination. Please see the libc6 preinst for an example of this. Will certainly do that if we think it will work.. thanks Steve. -- Nathan pgpLE54gtcUUP.pgp Description: PGP signature
Bug#320081: xfsprogs: superblock offset overflows in verify_set_primary_sb
On Tue, Jul 26, 2005 at 05:26:09PM -0400, Chris Zubrzycki wrote: A bug was also filed with the xfs developers and should be fixed in cvs promptly. This bug causes xfs_repair to fail on certain configurations. I'll update the package once the fix is committed to CVS, thanks. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318088: xfsdump: xfsrq doesn't work with setquota
On Wed, Jul 13, 2005 at 01:42:34PM +0200, Kim Hansen wrote: It looks like xfsrq is written to another version of setquota. I changed Thanks, I'll get these merged upstream and a new upload a new version of xfsdump soon. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.
Hi there, On Fri, Jun 10, 2005 at 04:39:26PM -0700, Steve Langasek wrote: On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote: I've just upgraded my system from woody to sarge. Among other upgrade problems I noticed that programmes like cp, mv and install were occasionally segfaulting (and the packages that were invoking them failing to get Could you try running cp (or getfacl, might be easier) via gdb and getting a gdb stack trace from one of these segfaults? That might give some more clues as to where the problem lies. Since I've not seen this on any other platform, including the more widely-used ones like i386, I'm guessing theres going to be something about the arm platform thats triggering this - maybe an endian issue, or a 32/64 bit sort of issue. libacl.so.1 = /lib/libacl.so.1 (0x40026000) libc.so.6 = /lib/libc.so.6 (0x40034000) libattr.so.1 = /lib/libattr.so.1 (0x40159000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x40164000) Recompiling libacl1 (itself an awkward task since the package itself segfaults in the middle when it is doing something to the postinst script) Hmm, its not doing anything special there, so I guess we're probably just seeing the same problem again - calls to cp or mv in the scripts segfaulting. and installing the recompiled version fixes the problem. Oh, that is interesting. Maybe this is a gcc-arm problem, i.e. it could have something to do with the version of gcc in use on the build machine when this was built. So, this may in fact be a compiler problem...? In fact, if recompiling makes the problem go away, I think by definition the problem cannot be in the acl/libacl1 packages, right? Maybe I'm overlooking something though. Do you know if upgrading to the 2.4 kernel version available in sarge makes a difference here? Anything specific you're looking for there Steve? I know the ACL kernel patches fairly well, and nothing has changed for years now so I'd be surprised if a kernel upgrade changed anything. Also, the 2.4 kernels don't tend to have ACL support, although I guess we may have patched our 2.4 kernels to include that, not sure. cheers. -- Nathan pgpyZtTmuOZJB.pgp Description: PGP signature
Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.
On Mon, Jun 13, 2005 at 07:56:13PM -0700, Steve Langasek wrote: On Tue, Jun 14, 2005 at 11:58:02AM +1000, Nathan Scott wrote: Anything specific you're looking for there Steve? + arm: upgrade doesn't work with 2.2, but can work with 2.4.24 or above. (perhaps also with older versions, currently unknown) (details: glibc vs kernel, source: kylem, tested on netwinder) [*] I know the ACL kernel patches fairly well, and nothing has changed for years now so I'd be surprised if a kernel upgrade changed anything. On the contrary, libacl works sanely on kernels lacking any ACL kernel support whatsoever -- this architecture-specific failure more likely points to a kernel ABI issue specific to ARM. Hmmm, it was interesting that a libacl recompile made the problem go away though, that seemed to me to point toward a compiler type issue rather than a kernel/glibc issue. cheers. -- Nathan pgpaZmr0K1Yhh.pgp Description: PGP signature
Bug#305055: dmapi: FTBFS: parse error in xfs/xfs_fs.h
On Sun, Apr 17, 2005 at 02:37:10PM -0700, Steve Langasek wrote: reassign 305055 dmapi,xfslibs-dev tags 305055 sid thanks On Sun, Apr 17, 2005 at 07:24:37PM +0200, Roland Stigge wrote: Package: dmapi Version: 2.2.0-1 Severity: serious building the package dmapi in a clean sid build environment (with pbuilder) on i386 results in: This looks to me like a broken header in the new version of xfslibs-dev; reassigned to both packages for further tracking. This was actually some dodgey source in DMAPI, including internal XFS headers directly that weren't intended for use that way. I'd expect a current version of libdm0 would compile correctly, so we can most easily fix this by simply using a more recent dmapi source package. 2.2.0 looks like its one version too old, I'll upload the 2.2.1 version shortly. Current versions of dmapi/libdm/dm_handle.c include: #include xfs/libxfs.h #include xfs/handle.h and _not_ xfs/xfs_fs.h This will compile correctly for any xfslibs version, and is the documented interface. cheers. -- Nathan pgplu3agsG3Ul.pgp Description: PGP signature
Bug#288710: setfacl with many files at cmdline - Too many open files
On Tue, Apr 05, 2005 at 10:32:49AM +0200, Xavier Hienne wrote: Nathan Scott a écrit : Let's reassign this bug to glibc, and ask those folks to take a look at the problem. Maybe should this bug be untagged upstream then ? Since its working on other versions of glibc (ie SLES9), odds are its an upstream bug anyway (maybe not, but probably). At this stage, I think we should leave it for the glibc guys to determine. cheers. -- Nathan
Bug#288710: setfacl with many files at cmdline - Too many open files
On Mon, Apr 04, 2005 at 10:58:45PM +0200, Xavier Hienne wrote: Hi, I too am encountering the very same bug on a 1900+ entry /home directory. The bug is easily reproducible : Yep, just tried it and it is indeed easy to hit with that test case, thanks. I've also tried this on a SLES9 machine I had handy, and the same getfacl code doesn't fail there, so I guess you're right in suggesting this is a glibc problem. Let's reassign this bug to glibc, and ask those folks to take a look at the problem. thanks. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300544: xfsprogs: FTBFS (amd64/gcc-4.0): array type has incomplete element type
Hi Andreas, On Tue, Mar 29, 2005 at 11:12:51AM +1000, Nathan Scott wrote: On Tue, Mar 29, 2005 at 10:17:35AM +1000, Nathan Scott wrote: OK, this should fix that (on top of the earlier patch). Any further failures? From a quick review of the other sources, looks like dquot.c may also cause you trouble - if so, let me know - I guess this patch will resolve that if it does. I plan to upload another xfsprogs shortly, could you let me know how the gcc4 compile went here, and if OK, I'll include these changes in the new version for you. thanks! -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300544: xfsprogs: FTBFS (amd64/gcc-4.0): array type has incomplete element type
On Thu, Mar 24, 2005 at 09:41:56AM +0100, Andreas Jochens wrote: On 05-Mar-24 12:13, Nathan Scott wrote: Could you try a gcc-4 compile with this patch please Andreas? I applied the patch, but compilation with gcc-4.0 still leads to the following error: In file included from agi.c:34: agi.h:33: error: array type has incomplete element type agi.h:34: error: array type has incomplete element type make[2]: *** [agi.o] Error 1 make[1]: *** [default] Error 2 make[1]: Leaving directory `/srv/dbuild/tmp/xfsprogs-2.6.26' make: *** [built] Error 2 OK, this should fix that (on top of the earlier patch). Any further failures? thanks. -- Nathan === Index: xfsprogs/db/agi.c === --- a/xfsprogs/db/agi.c 2005-03-29 08:16:54.0 +1000 +++ b/xfsprogs/db/agi.c 2005-03-29 08:15:16.0 +1000 @@ -31,7 +31,6 @@ */ #include xfs/libxfs.h -#include agi.h #include command.h #include type.h #include faddr.h @@ -41,6 +40,7 @@ #include bit.h #include output.h #include init.h +#include agi.h static int agi_f(int argc, char **argv); static void agi_help(void); -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300544: xfsprogs: FTBFS (amd64/gcc-4.0): array type has incomplete element type
On Tue, Mar 29, 2005 at 10:17:35AM +1000, Nathan Scott wrote: OK, this should fix that (on top of the earlier patch). Any further failures? From a quick review of the other sources, looks like dquot.c may also cause you trouble - if so, let me know - I guess this patch will resolve that if it does. thanks. -- Nathan === Index: xfsprogs/db/dquot.c === --- a/xfsprogs/db/dquot.c 2005-03-29 10:14:17.0 +1000 +++ b/xfsprogs/db/dquot.c 2005-03-29 10:12:30.0 +1000 @@ -34,7 +34,6 @@ #include bit.h #include bmap.h #include command.h -#include dquot.h #include type.h #include faddr.h #include fprint.h @@ -43,6 +42,7 @@ #include io.h #include init.h #include output.h +#include dquot.h static int dquot_f(int argc, char **argv); static voiddquot_help(void);
Bug#301252: xfsprogs - not compiled on unstable
On Thu, Mar 24, 2005 at 03:07:33PM -0800, Steve Langasek wrote: On Thu, Mar 24, 2005 at 06:58:30PM +0100, Bastian Blank wrote: Package: xfsprogs Version: 2.6.26-1 Severity: grave This package seems to be not built on unstable, libhandle requests executable stack, while a unstable build does not do that. I've uploaded recompile-only binNMUs for each of attr, acl, and xfsprogs on i386, which is the only architecture that should be affected. Thanks Steve. Not sure it worked out for xfsprogs, there was already a subsequent version queued. I have recompiled latest xfsprogs with the currente gcc, which I had to install by hand (apt-get upgrade wouldn't get it)... must be some interdependency issue with some packages here?, cos even this morning I'm seeing gcc being held back via apt-get upgrade: Reading Package Lists... Done Building Dependency Tree... Done The following packages have been kept back: abiword abiword-common base-config build-essential bzflag bzflag-server chbg cpp debconf debconf-utils debianutils dialog dmsetup dnsutils docbook-xml dpkg e2fsprogs enlightenment eog fetchmail file fileutils fontconfig g++ gcc gdk-imlib1 gdm gimp1.2 gnome-core gnome-panel gnome-panel-data gnome-session gnome-terminal gnumeric gnupg gs ibritish icewm imlib1 ispell libarchive-tar-perl libcupsys2 libfnlib0 libgdk-pixbuf-gnome2 libgdk-pixbuf2 libgnomeprint-bin libgnomeprint-data libgnomeprint15 libgtk2.0-0 libgtkxmhtml1 libimlib2 libkrb53 libldap2 libmail-audit-perl libnspr4 libnss3 libpam-modules libpaper1 libpaperg libpng2 libsasl7 libscrollkeeper0 libxslt1 lilo lintian lsof-2.2 ltp-disc-test lvm2 mailx mount mozilla mozilla-browser mozilla-mailnews mozilla-psm mutt nautilus netbase nfs-common po-debconf python quota rep-gtk reportbug samba-common sawfish scrollkeeper sendmail sgml-data shellutils sodipodi sox sysklogd sysvinit tasksel tcpdump textutils util-linux uucp wenglish whiptail xbase-clients xchat xchat-common xlibmesa3 0 upgraded, 0 newly installed, 0 to remove and 104 not upgraded. Nathan, please be sure to build your binaries against current unstable systems (chroot or otherwise) in the future when uploading to unstable; otherwise, we end up with binary packages that are not reproducible using current tools. I do follow unstable quite closely, and usually will have done an apt-get upgrade before building/installing/testing the current xfs tools -- I got thwarted by the above issue though. I'll upload a new xfsprogs shortly, I've confirmed the execute bit is not set on the stack segment via objdump with libhandle built using the latest unstable gcc. cheers. -- Nathan pgpDDCZ1o4oma.pgp Description: PGP signature
Bug#300544: xfsprogs: FTBFS (amd64/gcc-4.0): array type has incomplete element type
On Wed, Mar 23, 2005 at 08:25:07AM +0100, Andreas Jochens wrote: On 05-Mar-23 15:20, Nathan Scott wrote: thank you for your fast reply to my bug report. No problem. This issue has been discussed on the gcc list. The new error message 'array type has incomplete element type' was introduced intentionally to mark invalid C code. The construct 'extern struct s a[];' is not allowed by the C standard if 'struct s' has not been defined, i.e. if the size of 'struct s' is not known in that context. As far as I understand, there is no intention to disable this error message in later versions of gcc-4.0 again. OK, discussed with some of the other XFS guys, and a fix will follow shortly (slightly different to yours though). thanks Andreas. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300544: xfsprogs: FTBFS (amd64/gcc-4.0): array type has incomplete element type
On Tue, Mar 22, 2005 at 07:50:59PM +0100, Andreas Jochens wrote: I attached the wrong patch to my bug report, sorry. The correct patch is the following one. Could you try a gcc-4 compile with this patch please Andreas? thanks. -- Nathan === Index: xfsprogs/db/agf.c === --- a/xfsprogs/db/agf.c 2005-03-24 12:16:36.0 +1100 +++ b/xfsprogs/db/agf.c 2005-03-24 12:07:12.0 +1100 @@ -31,7 +31,6 @@ */ #include xfs/libxfs.h -#include agf.h #include command.h #include type.h #include faddr.h @@ -41,6 +40,7 @@ #include bit.h #include output.h #include init.h +#include agf.h static int agf_f(int argc, char **argv); static void agf_help(void); === Index: xfsprogs/db/agf.h === --- a/xfsprogs/db/agf.h 2005-03-24 12:16:36.0 +1100 +++ b/xfsprogs/db/agf.h 2005-03-24 12:05:18.0 +1100 @@ -30,8 +30,6 @@ * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ */ -struct field; - extern const struct field agf_flds[]; extern const struct field agf_hfld[]; === Index: xfsprogs/db/agfl.c === --- a/xfsprogs/db/agfl.c2005-03-24 12:16:36.0 +1100 +++ b/xfsprogs/db/agfl.c2005-03-24 12:12:34.0 +1100 @@ -31,7 +31,6 @@ */ #include xfs/libxfs.h -#include agfl.h #include command.h #include type.h #include faddr.h @@ -41,6 +40,7 @@ #include bit.h #include output.h #include init.h +#include agfl.h static int agfl_bno_size(void *obj, int startoff); static int agfl_f(int argc, char **argv); === Index: xfsprogs/db/agfl.h === --- a/xfsprogs/db/agfl.h2005-03-24 12:16:36.0 +1100 +++ b/xfsprogs/db/agfl.h2005-03-24 12:10:51.0 +1100 @@ -30,8 +30,6 @@ * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ */ -struct field; - extern const struct field agfl_flds[]; extern const struct field agfl_hfld[]; === Index: xfsprogs/db/agi.h === --- a/xfsprogs/db/agi.h 2005-03-24 12:16:36.0 +1100 +++ b/xfsprogs/db/agi.h 2005-03-24 12:05:27.0 +1100 @@ -30,8 +30,6 @@ * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ */ -struct field; - extern const struct field agi_flds[]; extern const struct field agi_hfld[]; === Index: xfsprogs/db/bmapbt.h === --- a/xfsprogs/db/bmapbt.h 2005-03-24 12:16:36.0 +1100 +++ b/xfsprogs/db/bmapbt.h 2005-03-24 12:10:58.0 +1100 @@ -30,8 +30,6 @@ * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ */ -struct field; - extern const struct field bmapbta_flds[]; extern const struct field bmapbta_hfld[]; extern const struct field bmapbta_key_flds[]; === Index: xfsprogs/db/bmroot.h === --- a/xfsprogs/db/bmroot.h 2005-03-24 12:16:36.0 +1100 +++ b/xfsprogs/db/bmroot.h 2005-03-24 12:11:01.0 +1100 @@ -30,8 +30,6 @@ * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ */ -struct field; - extern const struct field bmroota_flds[]; extern const struct field bmroota_key_flds[]; extern const struct field bmrootd_flds[]; === Index: xfsprogs/db/bnobt.h === --- a/xfsprogs/db/bnobt.h 2005-03-24 12:16:36.0 +1100 +++ b/xfsprogs/db/bnobt.h 2005-03-24 12:11:04.0 +1100 @@ -30,8 +30,6 @@ * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ */ -struct field; - extern const struct field bnobt_flds[]; extern const struct field bnobt_hfld[]; extern const struct field bnobt_key_flds[]; === Index: xfsprogs/db/cntbt.h === --- a/xfsprogs/db/cntbt.h 2005-03-24 12:16:36.0 +1100 +++ b/xfsprogs/db/cntbt.h 2005-03-24 12:11:07.0 +1100 @@ -30,8 +30,6 @@ *
Bug#300544: xfsprogs: FTBFS (amd64/gcc-4.0): array type has incomplete element type
On Tue, Mar 22, 2005 at 07:50:59PM +0100, Andreas Jochens wrote: I attached the wrong patch to my bug report, sorry. The correct patch is the following one. ... -struct field; - -extern const struct fieldagf_flds[]; -extern const struct fieldagf_hfld[]; ... Andreas, this really looks like a compiler bug to me; have you discussed this one with the gcc folks? Seems certain that they will suddenly start failing to compile a number of programs due to this, so I'd be surprised if they don't fix this behaviour.. so I'm hesitant to change XFS source for this one, since the code is not wrong AFAICT. cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297876: xfsprogs: FTBFS (amd64/gcc-4.0): static declaration of 'progname' follows non-static declaration
On Tue, Mar 08, 2005 at 08:00:47AM +0100, Andreas Jochens wrote: On 05-Mar-08 14:09, Nathan Scott wrote: -Build-Depends: uuid-dev, autoconf, debhelper, gettext, libtool, libreadline4-dev +Build-Depends: uuid-dev, autoconf, debhelper, gettext, libtool, libreadline5-dev This part of the patch seems unrelated to the problem you've reported here, Andreas - what needs this version change? This version change is not really necessary and has nothing to do with the rest of the patch. I forgot to remove it before I sent the report, sorry. However, it would qualify for a separate 'wishlist' report to cleanup the distribution. Looks like xfsprogs compiles works fine with that version - I'll fix the buld-depends up with the next upload. thanks. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298407: xfsdump: FTBFS (amd64/gcc-4.0): static declaration of 'progname' follows non-static declaration
On Mon, Mar 07, 2005 at 01:10:25PM +0100, Andreas Jochens wrote: -static char *progname; +char *progname; Thanks. This is some silly namespace pollution, but simplest to just fix this way -- I've used a similar fix in xfsprogs, rather than the global replace you used there. I'll upload fixed packages soon. thanks. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297876: xfsprogs: FTBFS (amd64/gcc-4.0): static declaration of 'progname' follows non-static declaration
On Thu, Mar 03, 2005 at 01:03:31PM +0100, Andreas Jochens wrote: Package: xfsprogs Severity: normal Tags: patch ... diff -urN ../tmp-orig/xfsprogs-2.6.20/debian/control ./debian/control --- ../tmp-orig/xfsprogs-2.6.20/debian/control2004-05-19 07:00:19.0 +0200 +++ ./debian/control 2005-03-03 11:23:47.0 +0100 @@ -2,7 +2,7 @@ Section: admin Priority: optional Maintainer: Nathan Scott [EMAIL PROTECTED] -Build-Depends: uuid-dev, autoconf, debhelper, gettext, libtool, libreadline4-dev +Build-Depends: uuid-dev, autoconf, debhelper, gettext, libtool, libreadline5-dev This part of the patch seems unrelated to the problem you've reported here, Andreas - what needs this version change? thanks. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295397: xfsprogs: xfs_check manual page incorrect
The manual should probably read: Any output from xfs_check that was not due to the VERBOSE flag means that the filesystem has an inconsistency. Thanks, I'll fix this up in the next version of xfsprogs. cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#144876: if it's native, the version number is wrong
On Wed, Feb 02, 2005 at 07:45:19AM +0100, Marc Haber wrote: Please consider either changing to a really native package (without debian-version in the version number) I guess I would consider a patch to do this if I was sent one, but as I said I've never found a need to do this, and have not been shown any concrete example of a build problem resulting from this, I have no intention of doing it myself. It would also have to not break any of my own build processes of course... :) Marc, even packaging his own software as non-native package because having a .diff.gz is _very_ convenient. *shrug* -- for me, it would be quite inconvenient, as I said before (3 years ago now!). cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293276: xfsprogs: xfs_check in /usr, making xfs_check /usr impossible
On Wed, Feb 02, 2005 at 07:50:01AM +0100, Marc Haber wrote: Hi, xfs_check is in /usr, which means that /usr needs to be mounted to execute xfs_check, which means that /usr cannot be xfschecked at all if it is an xfs itselt. You can run xfs_repair -n in this situation. xfs_check is really not an overly useful tool to have in the stand-alone environment, and it'll possibly be deprecated at some point in the distant future (any new work to improve scalability is likely to be done on xfs_repair). cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293275: xfsprogs: no-op fsck.xfs doesn't allow to explicitly check with shutdown -F
On Wed, Feb 02, 2005 at 07:48:55AM +0100, Marc Haber wrote: When I run shutdown -F, I expect my file systems to be checked on bootup, regardless whether the file system is journaling or not. I I really wouldn't expect that, myself. might have enountered strange fs behavior and would like to be sure. Run xfs_repair -n on just the specific filesystem then, not all, and not during bootup. This doesn't work with xfs since fsck.xfs is a no-op. There are of course other ways to achieve the same thing. I don't particularly like the idea of doing things like this on boot - it is indiscriminately applied to all filesystems, which is problematic as filesystem sizes increase (for any one filesystem). The current record, to give an idea, for one filesystem (many terabytes, many millions of inodes) was ~1 week to repair... cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289665: xfsprogs: xfs_repair requires unholy amounts of memory
On Mon, Jan 10, 2005 at 02:10:09PM +0100, Peter Palfrader wrote: I have a filesystem that stores (a backup) of my maildir with about 900k files. This filesystem somehow (bad disk most likely) got corrupted a bit so I tried to xfs_repair it. Hi Peter, Can you tell me how many inodes in this filesystem, and also its size? Output from df -h /mnt/foo df -hi /mnt/foo would do the trick, thanks. It seems that it tries to store the entire tree in RAM? Maybe this could be changed to not require that much ram. *nod* cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
