[bug #23876] gnustep-base does not build in a chrooted environment

Follow-up Comment #10, bug #23876 (project gnustep): The macro definition is in config/procfs.m4. I don't know where it came from, but definitely not Autoconf. The test being performed there is going to fail in chroots that do not mount /proc. FWIW, it doesn't fail on Debian autobuilders; from

[bug #23876] gnustep-base does not build in a chrooted environment

Follow-up Comment #11, bug #23876 (project gnustep): I just tried in a pbuilder chroot (which mounts /proc) -- the `mount' command outputs nothing. The attached trivial patch should be equally reliable and should DTRT in such chroots. Funda Wang, does it work for you if you apply it and then ru

[bug #24109] gnustep-gui 0.14.0 does not build with LDFLAGS="-Wl, --as-needed -Wl, --no-undefined"

Follow-up Comment #3, bug #24109 (project gnustep): It's not GNUstep Make's fault. It is the developer's responsibility to ensure that LIBRARIES_DEPEND_UPON contains all the libraries the built library has to link with; gnustep-make does not add anything by default (and that's how it should be,

[bug #24109] gnustep-gui 0.14.0 does not build with LDFLAGS="-Wl, --as-needed -Wl, --no-undefined"

Follow-up Comment #6, bug #24109 (project gnustep): I can't speak for this particular case, but... As per Debian Policy it is a bug if a program or a library has unresolved symbols; this is to ensure that the shlibs system works properly and all dependencies for the package are computed correctl

[bug #24083] Offset issues with the xmonad WM; blank windows with the cairo backend

Follow-up Comment #9, bug #24083 (project gnustep): Many thanks... The OP confirmed that the NSBezierPath.m patch resolves the problem with cairo, so this bug remains for the (minor) xmonad issue. ___ Reply to this item at:

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

URL: Summary: Crash on x86_64 when a program is started with argument that is invalid property list Project: GNUstep Submitted by: yavor Submitted on: Sat Oct 11 00:07:44 2008 Categor

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

Follow-up Comment #2, bug #24526 (project gnustep): It was reproduced by the original bug reporter with gnustep-startup-0.20, but I also asked him to try with Base SVN trunk -- same result. I assume that you cannot reproduce on x86_64, right?

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

Follow-up Comment #4, bug #24526 (project gnustep): Thanks. If the `signal' implementation on that system is broken, I suspect there would be other severe problems in Emacs that would occur before byte-compiling the Emacs Lisp files. We'll investigate. _

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

Follow-up Comment #5, bug #24526 (project gnustep): A friend who is an official Debian Developer managed to reproduce this on Debian GNU/Linux amd64 (sid), using the debian gnustep-base package (version 1.16.3), installed specifically for this test. Attached are two files with backtraces -- one

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

Follow-up Comment #7, bug #24526 (project gnustep): > but then a gdb backtrace of something different, not of the core > image dumped. Correct, but in fact it is a crash while executing this preciese command from the make recipe. I can ask him to run gdb on the core, if it helps. It has nothi

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

Follow-up Comment #8, bug #24526 (project gnustep): One more thing. Another person could not reproduce this on Debian Etch, amd64, Base version 1.13.0. The test program exited with code 1 and zero when NOHANDLE is defined, as expected. This (old) version of GNUstep Base does not have the speci

[bug #24785] Application not quitting properly on some platforms.

Follow-up Comment #1, bug #24785 (project gnustep): I can confirm this behavior with Preferences on GNU/kFreeBSD, GUI version 0.14.0. ___ Reply to this item at:

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

Follow-up Comment #10, bug #24526 (project gnustep): Sorry for replying so late. I can't reproduce with Base 1.18.0 on x86_64-linux-gnu; I even managed to bootstrap Emacs without other errors, which was quite surprising. Please close the bug, thanks. ___

[bug #24083] Offset issues with the xmonad WM

Follow-up Comment #17, bug #24083 (project gnustep): Fred -- sorry for the delay. The OP reports this is fixed in 0.16.0, so please close. Thanks! ___ Reply to this item at: _

[bug #26895] NSFontDescriptor.h not included from AppKit.h

URL: Summary: NSFontDescriptor.h not included from AppKit.h Project: GNUstep Submitted by: yavor Submitted on: Fri Jun 26 12:52:23 2009 Category: Gui/AppKit Severity:

[bug #27099] Incomplete implementation of -[NSFontDescriptor matchingFontDescriptorsWithMandatoryKeys:]

URL: Summary: Incomplete implementation of -[NSFontDescriptor matchingFontDescriptorsWithMandatoryKeys:] Project: GNUstep Submitted by: yavor Submitted on: Fri 24 Jul 2009 05:57:38 PM EEST

[bug #27222] By default binaries should be built with '-g -O2'

URL: Summary: By default binaries should be built with '-g -O2' Project: GNUstep Submitted by: yavor Submitted on: Tue 11 Aug 2009 12:02:16 AM EEST Category: Makefiles

[bug #27222] By default binaries should be built with '-g -O2'

Follow-up Comment #2, bug #27222 (project gnustep): I think there are still plenty of bugs on some targets with -O3 and higher, so this seems risky. I think this is most natural: * debug=yes (default): -g -O2 * debug=no: -O2 If a developer/user wants unoptimized build for better debugging, `ma

[bug #29208] NSCalendarDate's format does not support the %k conversion specifier

URL: Summary: NSCalendarDate's format does not support the %k conversion specifier Project: GNUstep Submitted by: yavor Submitted on: Fri 12 Mar 2010 03:41:18 PM EET Category: Base/Fo

[bug #29208] NSCalendarDate's format does not support the %k conversion specifier

Follow-up Comment #2, bug #29208 (project gnustep): Thanks. Here is my attemt; I'd appreciate a thorough review. The leading space is important for sorting/alignment -- I see that %e omits it (contrary to what the documentation says); probably to match Cocoa behavior? Tested with the attached

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

URL: Summary: FTBFS on GNU/Hurd with -Wl,--no-undefined Project: GNUstep Submitted by: yavor Submitted on: Mon May 10 11:27:13 2010 Category: Base/Foundation Severity:

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

Follow-up Comment #3, bug #29845 (project gnustep): No news, unfortunately. I'd be glad to provide a patch if I only knew what would be the correct fix... It seems that all platforms which use the GS_FAKE_MAIN hack are affected; on GNU/Linux you can reproduce the problem with ./configure --e

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

Follow-up Comment #5, bug #29845 (project gnustep): > Ah ... so '-Wl,-z,defs -Wl,--as-needed' has a similar effect to '-Wl,--no-undefined' Almost; -Wl,-z,defs is another way of writing -Wl,--no-undefined. > the fake main mechanism requires the gnustep_base_user_main() function to be > undefine

[bug #30094] (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared

URL: Summary: (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared Project: GNUstep Submitted by: yavor Submitted on: Wed Jun 9 14:38:36 2010 Ca

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

Follow-up Comment #8, bug #29845 (project gnustep): Seems to be working fine. Thank you very much. ___ Reply to this item at: ___ Message sent via/by

[bug #30094] (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared

Follow-up Comment #3, bug #30094 (project gnustep): On which Solaris version/machine? __GLIBC__ should have zero effect on any non-GNU platform... Does it help if you use AC_USE_SYSTEM_EXTENSIONS and remove all manually crafted defines? (This is the autoconf (almost) bullet-proof way for deali

[bug #30094] (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared

Follow-up Comment #5, bug #30094 (project gnustep): Strange, but if that works, OK. There are 3 more places where this condition needs to be changed, could you please do that? GSPThread.h, NSLock.m, NSZone.m ___ Reply to this item at:

[bug #30094] (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared

Follow-up Comment #9, bug #30094 (project gnustep): Unfortunately I won't be able to confirm that the failure is fixed on GNU/kFreeBSD until gnustep-base 1.20.x is uploaded to Debian (either with the upstream fix, or the same as a Debian patch). It's like a chicken and egg problem for us... So

[bug #28014] [GWorkspace] Does not build *with* sqlite3

Follow-up Comment #4, bug #28014 (project gnustep): config.log should contain details about why this AC_CHECK_LIB test was unsuccessful. Could you please look and post the relevant output? ___ Reply to this item at:

[bug #30094] (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared

Follow-up Comment #11, bug #30094 (project gnustep): Just mentioning that 1.20.1 built successfully on Debian's kfreebsd-i386 and kfreebsd-amd64 autobuilders. ___ Reply to this item at: ___

[bug #30285] Compile issue on Solaris9/SPARC64

Follow-up Comment #2, bug #30285 (project gnustep): The Autoconf manual (node `Header Portability') says: `inttypes.h' vs. `stdint.h' The C99 standard says that `inttypes.h' includes `stdint.h', so there's no need to include `stdint.h' separately in a standard environment. Some i

[bug #30299] Renaissance needs to link against needed libraries

URL: Summary: Renaissance needs to link against needed libraries Project: GNUstep Submitted by: yavor Submitted on: Wed 30 Jun 2010 10:13:52 AM EEST Category: Libraries

[bug #30427] Please port to native Avahi

URL: Summary: Please port to native Avahi Project: GNUstep Submitted by: yavor Submitted on: Tue 13 Jul 2010 10:42:37 AM EEST Category: Base/Foundation Severity: 3 - N

[bug #30427] Please port to native Avahi

Follow-up Comment #2, bug #30427 (project gnustep): Aha, I remember now (it is amazing how quickly I tend to forget these days): http://thread.gmane.org/gmane.comp.lib.gnustep.devel/8770 Given the comments were positive, maybe it's worth including it right now in trunk to allow some testing befo

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

URL: Summary: Serious problems on hppa -- all programs abort with malloc assertion failure Project: GNUstep Submitted by: yavor Submitted on: Fri 13 Aug 2010 12:41:01 PM EEST Category

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #2, bug #30766 (project gnustep): This happens with all programs (gdnc, pl2link, etc...) It was discovered while building gnustep-gui which invokes the just built make_services during the build process. > Could you please run this program under valgrind? Valgrind is not avail

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #4, bug #30766 (project gnustep): > The later two could be ruled out by running a non GNUstep > Objective-C program compile don this machine. Base 1.19.3 runs fine, so I guess they can be ruled out right away. > Next you should check which of the different cases for argument

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #5, bug #30766 (project gnustep): Here is some information about this architecture, in case it can be of help. Type size: short 2 int 4 long 4 long long 8 float 4 double8 long double 8 data pointer 4 endianness: big unaligned

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #8, bug #30766 (project gnustep): >> Base 1.19.3 runs fine, so I guess they can be ruled out right >> away. > Unfortunately not as it's perfectly possible for some code to > trigger bugs in the compiler or runtime that other code does > not trigger. Right, I was thinking alon

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #9, bug #30766 (project gnustep): FYI: I asked the original bug reporter to try 1.20.0; it still fails in the same way. I'll wait for my tests with a debianized gcc before doing anything else. ___ Reply to this item at:

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #10, bug #30766 (project gnustep): I could not reproduce with gcc-4.4.4 + Debian patches, but that was on a Debian Lenny machine. Apparently only modern systems (new glibc, etc.) are affected. FYI, the following tests were performed on paer.debian.org, in a Debian unstable chr

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #11, bug #30766 (project gnustep): Here is another backtrace from a different program (test3.m) that doesn't use NSProcessInfo: Program received signal SIGABRT, Aborted. 0x40fc98ac in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 67 ../nptl/sysdeps/unix

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #13, bug #30766 (project gnustep): I asked the bug reporter to commence the bisection procedure, starting from the tip (just in case), then narrowing between the last "good" r28586 (1.19.3) and "bad" r30325 (1.20.0). I'll followup here with the results as soon as I have them.

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #14, bug #30766 (project gnustep): First results from the bisect operation: r28600 good, r28700 bad. ___ Reply to this item at: ___ M

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #15, bug #30766 (project gnustep): Further narrowed down to -r28600:r28625 (continuing). I asked on debian-hppa about some information for the switch from Linuxthreads to NPTL on hppa -- I remember it was very hard, and there were some odd details. It may turn out to be a glib

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #16, bug #30766 (project gnustep): Final results: - r28611 is ok - r28612 didn't compile [1] - r28613 exposes the bug [1] NSLock.m: In function ‘-[NSCondition lockBeforeDate:]’: NSLock.m:247: warning: passing argument 1 of ‘pthread_mutex_trylock’ from incompatible pointer type

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #17, bug #30766 (project gnustep): Looking at the diff, the only thing that comes to (my) mind is some oddity with hiding the pthread stuff (hppa has the largest size of pthread_mutex_t -- 48 -- but this shouldn't be a problem AFAICS), or the NSRunLoop change. Should I ask to r

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #18, bug #30766 (project gnustep): FWIW, link to the discussion that lead to this particular change: http://thread.gmane.org/gmane.comp.lib.gnustep.general/33167 ___ Reply to this item at:

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #19, bug #30766 (project gnustep): I asked Carlos O'Donnel, the author of the glibc NPTL code for hppa if there's something wrong in the approach of hiding pthread internals with opaque types of the same size. He said: "Yes, you don't take into account the alignment requiremen

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #21, bug #30766 (project gnustep): Yes, I'm glad to confirm this fixes the problem. It was not tested on the official autobilders yet, but I doubt there will be any problems (and if there are, they would be entirely my fault when incorporating the patch). Thanks very much!

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #23, bug #30766 (project gnustep): How does it fail exactly? Can you post the relevant portions from config.log? ___ Reply to this item at: __

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

Follow-up Comment #25, bug #30766 (project gnustep): Looks like pthread.h is not included in the test program. See if the attached patch helps. (file #21281) ___ Additional Item Attachment: File name: AC_CHECK_ALIGNOF.patch Size:

[bug #42410] gdomap does not support IPv6

URL: Summary: gdomap does not support IPv6 Project: GNUstep Submitted by: yavor Submitted on: Fri 23 May 2014 07:43:54 PM EEST Category: Base/Foundation Severity: 3 - N

[bug #42411] gdomap chroots to /tmp

URL: Summary: gdomap chroots to /tmp Project: GNUstep Submitted by: yavor Submitted on: Fri 23 May 2014 07:54:06 PM EEST Category: Base/Foundation Severity: 3 - Normal

[bug #42423] base.make errouneously pollutes CONFIG_SYSTEM_* variables

URL: Summary: base.make errouneously pollutes CONFIG_SYSTEM_* variables Project: GNUstep Submitted by: yavor Submitted on: Mon 26 May 2014 01:38:46 AM EEST Category: Base/Foundation

[bug #42433] [cairo] FTBFS with -Wl,--no-undefined

URL: Summary: [cairo] FTBFS with -Wl,--no-undefined Project: GNUstep Submitted by: yavor Submitted on: Tue 27 May 2014 01:29:47 AM EEST Category: Backend Severity: 3 -

[bug #42606] libopal: unfortunate library name

URL: Summary: libopal: unfortunate library name Project: GNUstep Submitted by: yavor Submitted on: Tue 24 Jun 2014 05:28:14 PM EEST Category: Libraries Severity: 3 - No

[bug #42640] GNUstep Make does not honor CFLAGS

URL: Summary: GNUstep Make does not honor CFLAGS Project: GNUstep Submitted by: yavor Submitted on: Sun 29 Jun 2014 02:05:00 PM EEST Category: Makefiles Severity: 3 - N

[bug #42641] Use makeinfo --html to generate HTML manuals from .texi documents

URL: Summary: Use makeinfo --html to generate HTML manuals from .texi documents Project: GNUstep Submitted by: yavor Submitted on: Sun 29 Jun 2014 07:08:06 PM EEST Category: Makefiles

[bug #42642] Use -include directive for deb.make

URL: Summary: Use -include directive for deb.make Project: GNUstep Submitted by: yavor Submitted on: Sun 29 Jun 2014 07:27:24 PM EEST Category: Base/Foundation Severity

[bug #42645] Use libgcrypt only if needed

URL: Summary: Use libgcrypt only if needed Project: GNUstep Submitted by: yavor Submitted on: Sun 29 Jun 2014 09:36:19 PM EEST Category: Base/Foundation Severity: 3 - N

[bug #24109] gnustep-gui 0.14.0 does not build with LDFLAGS="-Wl, --as-needed -Wl, --no-undefined"

Follow-up Comment #8, bug #24109 (project gnustep): Nicola wrote: > libgnustep-gui is not linked against libobjc. > That is done on purpose (eg see #9920). It is not clear from that bug *why* it is done on purpose... > So ... what advantages would this change bring ? It's the other way aroun

[bug #42648] Manual page for gnustep-tests

URL: Summary: Manual page for gnustep-tests Project: GNUstep Submitted by: yavor Submitted on: Sun 29 Jun 2014 11:10:58 PM EEST Category: Makefiles Severity: 3 - Normal

[bug #42649] Bootstrapping issue with the documentation

URL: Summary: Bootstrapping issue with the documentation Project: GNUstep Submitted by: yavor Submitted on: Mon 30 Jun 2014 01:17:49 AM EEST Category: Base/Foundation S

[bug #42650] Tools are linked with unnecessary libraries

URL: Summary: Tools are linked with unnecessary libraries Project: GNUstep Submitted by: yavor Submitted on: Mon 30 Jun 2014 01:53:23 AM EEST Category: Base/Foundation

[bug #29730] Build attempt when typing 'make distclean' twice

Follow-up Comment #3, bug #29730 (project gnustep): Here is a proposed patch to fix this issue. While here, I also fixed clean/distclean so that all generated files are deleted. The comments are probably more verbose than needed, feel free to trim them. P.S. Tests/base/NSInvocationOperation/GNU

[bug #42693] Fix build on mips64(el) with GCC

URL: Summary: Fix build on mips64(el) with GCC Project: GNUstep Submitted by: yavor Submitted on: Mon 07 Jul 2014 05:48:44 AM EEST Category: Base/Foundation Severity: 3

[bug #42698] Recommended future steps for gnustep-dl2 debian package maintenance

Follow-up Comment #4, bug #42698 (project gnustep): I am not sure it was in the same discussion. Anyway. The dependency on Renaissance is not a problem at all. > I even made the case that libEOModeler could be > shipped with DBModeler here It is exactly what we are doing. Perhaps we should

[bug #42698] Recommended future steps for gnustep-dl2 debian package maintenance

Follow-up Comment #2, bug #42698 (project gnustep): We can try to ship both apps with a bit of effort. EOModeler is distributed as a private library in Debian, because David Ayers once told us it was going to undergo major changes. Is the current split what he meant back then? What are the adva

[bug #42698] Recommended future steps for gnustep-dl2 debian package maintenance

Follow-up Comment #5, bug #42698 (project gnustep): > (MySQL+Postgres in one package) Of course I meant SQLite, not MySQL. ___ Reply to this item at: ___

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

URL: Summary: Crash in -[NSBox(Private) calcSizesAllowingNegative:] Project: GNUstep Submitted by: yavor Submitted on: Wed 09 Jul 2014 04:48:17 PM EEST Category: Gui/AppKit

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #2, bug #42717 (project gnustep): Yep, I noticed that dubious aFlag too. It looks like it is exactly the same problem that was reported in 2013. If I put a break on -[NSBox setBorderType:], aType is garbage (10-digit number) instead of the expected value of 3. Going further ba

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #3, bug #42717 (project gnustep): When built with -O1, -calcSizesAllowingNegative: doesn't crash when called from -setBorderType: (aType there is 3 as expected) but from -setTitlePosition: Breakpoint 1, -[NSBox setTitlePosition:] (self=0x921f6b0, _cmd=0xb7edb618 <_OBJC_SEL

[bug #42729] [DBusKit] Unnecessary libtool usage

URL: Summary: [DBusKit] Unnecessary libtool usage Project: GNUstep Submitted by: yavor Submitted on: Fri 11 Jul 2014 04:26:11 PM EEST Category: Libraries Severity: 3 -

[bug #42730] [DBusKit] Misc texinfo formatting fixes

URL: Summary: [DBusKit] Misc texinfo formatting fixes Project: GNUstep Submitted by: yavor Submitted on: Fri 11 Jul 2014 06:06:44 PM EEST Category: Libraries Severity:

[bug #42732] [Performance] Uses Base but doesn't link with it

URL: Summary: [Performance] Uses Base but doesn't link with it Project: GNUstep Submitted by: yavor Submitted on: Fri 11 Jul 2014 07:55:19 PM EEST Category: Libraries S

[bug #42733] [SQLClient] Uses Base but doesn't link with it

URL: Summary: [SQLClient] Uses Base but doesn't link with it Project: GNUstep Submitted by: yavor Submitted on: Fri 11 Jul 2014 08:21:59 PM EEST Category: Libraries Sev

[bug #42734] [SQLClient] Unused config.{sub,guess}

URL: Summary: [SQLClient] Unused config.{sub,guess} Project: GNUstep Submitted by: yavor Submitted on: Fri 11 Jul 2014 09:01:32 PM EEST Category: Libraries Severity: 3

[bug #42740] Some tests inevitably fail in a chroot

URL: Summary: Some tests inevitably fail in a chroot Project: GNUstep Submitted by: yavor Submitted on: Sat 12 Jul 2014 02:09:54 PM EEST Category: Base/Foundation Sever

[bug #42411] gdomap chroots to /tmp

Follow-up Comment #2, bug #42411 (project gnustep): I don't know either, I'll ask the original bug submitter. > is there a debian specific standard for this which > could be conditionally compliled when building on a > debian system? I don't think so. I believe this was not caught by an automat

[bug #42423] base.make errouneously pollutes CONFIG_SYSTEM_* variables

Follow-up Comment #2, bug #42423 (project gnustep): > That change was to avoid conflicting library versions > being linked into base and gui ... I see. The way to address this problem is to take care to relink all reverse dependencies of the library. Which I agreee is a bit tedious and even er

[bug #42762] Large file support

URL: Summary: Large file support Project: GNUstep Submitted by: yavor Submitted on: Sun 13 Jul 2014 05:05:46 PM EEST Category: Base/Foundation Severity: 3 - Normal

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #4, bug #42717 (project gnustep): As I ran out of ideas I made a binary search. The "bad" commit is r34050. It's not easy for me to spot what's wrong, though... ___ Reply to this item at:

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #5, bug #42717 (project gnustep): Moving the NSTitleCell decoding at the beginning as in the attached patch makes Cenon load with 0.24.0. -calcSizesAllowingNegative: accesses _cell so at first glance it looks like the correct change. However, if I apply the patch against trunk

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #7, bug #42717 (project gnustep): I was sure I mentioned it was the Main.xib file, but apparently missed that. Sorry. I tried --GNU-Debug=XIB as soon as I found out the crash happens when loading the XIB file, but was completely lost in the data it spits. Attached is the compr

[bug #42778] Frameworks with different SONAME cannot coexist

URL: Summary: Frameworks with different SONAME cannot coexist Project: GNUstep Submitted by: yavor Submitted on: Tue 15 Jul 2014 08:28:37 PM EEST Category: Makefiles Se

[bug #42782] Crash when loading a gorm file

URL: Summary: Crash when loading a gorm file Project: GNUstep Submitted by: yavor Submitted on: Wed 16 Jul 2014 03:22:11 PM EEST Category: Gui/AppKit Severity: 3 - Norm

[bug #42782] Crash when loading a gorm file

Follow-up Comment #2, bug #42782 (project gnustep): GNUstep Base is built with detached debugging symbols and the -dbg package is installed. The stack gets seriously messed up or destroyed. ___ Reply to this item at:

[bug #42789] [SQLClient] Two versions of the library cannot coexist peacefully

URL: Summary: [SQLClient] Two versions of the library cannot coexist peacefully Project: GNUstep Submitted by: yavor Submitted on: Thu 17 Jul 2014 11:32:46 AM EEST Category: Libraries

[bug #42804] Dubious configure test for -fexec-charset

URL: Summary: Dubious configure test for -fexec-charset Project: GNUstep Submitted by: yavor Submitted on: Fri 18 Jul 2014 03:46:49 PM EEST Category: Base/Foundation Se

[bug #42804] Dubious configure test for -fexec-charset

Follow-up Comment #1, bug #42804 (project gnustep): Just another confirmation: $ locale LANG=en_US.ISO-8859-1 LANGUAGE= LC_CTYPE="en_US.ISO-8859-1" LC_NUMERIC="en_US.ISO-8859-1" LC_TIME="en_US.ISO-8859-1" LC_COLLATE="en_US.ISO-8859-1" LC_MONETARY="en_US.ISO-8859-1" LC_MESSAGES="en_US.ISO-8859-1"

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #9, bug #42717 (project gnustep): Here's the valgrind output: $ valgrind Cenon ==14425== Memcheck, a memory error detector ==14425== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==14425== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==1442

[bug #42782] Crash when loading a gorm file

Follow-up Comment #4, bug #42782 (project gnustep): ==15741== Command: Gorm /tmp/viewpdf.app-0.2dfsg1/English.lproj/Document.gorm/ ==15741== 2014-07-20 19:27:38.764 Gorm[15741] Tiff Error (GSTiffReadData) Not a TIFF or MDI file, bad magic number 20039 (0x4e47) 2014-07-20 19:27:42.187 Gorm[15741]

[bug #42782] Crash when loading a gorm file

Follow-up Comment #6, bug #42782 (project gnustep): Gorm doesn't crash now but it doesn't load the file either. An alert panel is shown with title "Alert" and "No information" as message. The "image" file is, oddly enough, data.info. Here's the backtrace when this method is reached: Breakpoint

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #11, bug #42717 (project gnustep): No crash if I apply your changes in r38003. If it is a compiler bug, most probably it is present in earlier versions as this bug was reported last year when 4.9 was not released yet. However, it may be that GCC is taking advantage of the "unde

[bug #42778] Frameworks with different SONAME cannot coexist

Follow-up Comment #1, bug #42778 (project gnustep): Actually, it is even more serious than that. Installing a new version of the framework will wipe out the old one completely, so there will only be one Version, with Current pointing to it. This is done unconditionally as the first command of th

[bug #42782] Crash when loading a gorm file

Follow-up Comment #8, bug #42782 (project gnustep): Yes, the "info" type is there and the array is quite large: (gdb) po [NSImage imageFileTypes] (tiff, tif, pnm, ppm, gif, jpeg, jpg, png, icns, 3fr, a, aai, ai, art, arw, avi, avs, b, bgr, bgra, bie, bmp, bmp2, bmp3, brf, c, cal, cals, canvas, ca

[bug #42782] Crash when loading a gorm file

Follow-up Comment #9, bug #42782 (project gnustep): FYI, the bug is reproducible if I rebuild GUI with --disable-imagemagick (the image file types are just "tiff, tif, pnm, ppm, gif, jpeg, jpg, png, icns" in that case). The gdb backtrace is meaningless again and the valgrind output is: ==8543==

[bug #42782] Crash when loading a gorm file

Follow-up Comment #11, bug #42782 (project gnustep): Yes, I used Gorm 1.2.20 + your latest changes. Most probably it is not an issue with Gorm at all. I'd really wish to provide more information... Perhaps I could put breakpoints at some places and step through from there, this would at least g

[bug #42782] Crash when loading a gorm file

Follow-up Comment #13, bug #42782 (project gnustep): I think this should be reproducible with GCC 4.8 as well, it's the architecture that matters. As x86 is gradually being replaced with x86_64 it's not a big surprise that the majority of users do not encounter these bugs. I'll try to reproduce

<    1   2   3   >