Meanwhile, can you additionally test the attached program, which doesn't
use NSProcessInfo (upstream has some suspicions that's the class where
the bug is)? You can reuse the same GNUmakefile I sent you earlier.
#import
int
main (void)
{
CREATE_AUTORELEASE_POOL (pool);
NSString *foo = @"Te
On Tue, Aug 17, 2010 at 02:16:46PM -0600, dann frazier wrote:
> We should be able to automate the bisection (if we can rely on each
> version being buildable..) If you can point me to the source.. and it
> is in git (or an svn repo I can use w/ git-svn) I can do that pretty
> easily I think.
It's
В 14:17 -0600 на 17.08.2010 (вт), dann frazier написа:
> (sid)da...@paer:~$ ./obj/test
> Test
Good. Please run another test program... If it works, which I hope and
expect so, then the culprit is really NSProcessInfo. In the backtraces
you sent initially, frame #14 is an impossible code path,
dann frazier wrote:
> Attached - though I don't really get anything from the stepping:
Hmm, there seems to be some misunderstanding (probably because of the
confusingly identically named test.m files) -- perform the stepping
with the test.m file I sent you earlier:
> > (http://bugs.debian.org/cgi
On Wed, Aug 18, 2010 at 12:50:39PM -0600, dann frazier wrote:
> _gnu_process_args (argc=1, argv=0x3cb98, env=0x3bd08) at NSProcessInfo.m:233
> 233 NSProcessInfo.m: No such file or directory.
> in NSProcessInfo.m
> 238 in NSProcessInfo.m
> 240 in NSProcessInfo.m
> *__GI_strlen (str=0xfaf
В 15:29 +0200 на 19.08.2010 (чт), Mehdi Dogguy написа:
> I tested on paer. r28700 failed and r28600 worked
Thanks, informing upstream. Can you narrow it down a bit more? Are the
revisions in between non-buildable?
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a sub
В 16:15 +0200 на 19.08.2010 (чт), Mehdi Dogguy написа:
> On 19/08/2010 15:45, Yavor Doganov wrote:
> > Thanks, informing upstream. Can you narrow it down a bit more?
>
> I narrowed it down to r28600:r28625.
That's mostly the NSThread/NSLock redesign. Too bad, one of
Carlos O'Donell wrote:
> Does this code use vfork?
The library uses vfork only in the NSTask class, which means that any
code using -[NSTask launch] uses vfork indirectly. The gdnc daemon is
one such program, but this is never reached with `gdnc --help'. All
the other test programs that were tri
Carlos O'Donell wrote:
> Once we have a backtrace, either via a core dump, or attached gdb,
> then we can talk about the likely cause.
See the bug log -- there are lots of them, but none is really useful.
GNUstep Base uses NSLock extensively to protect critical parts of
code, so there's something
Carlos O'Donell wrote:
> On Thu, Aug 19, 2010 at 1:56 PM, Yavor Doganov wrote:
> > Do you find anything disturbing in this approach, in particular:
>
> Yes, you don't take into account the alignment requirement of the
> structure.
Thanks, that was really helpful.
tags 592751 + pending
thanks
В 17:27 -0600 на 19.08.2010 (чт), dann frazier написа:
> With latest trunk:
> [good]
>
> If I revert back to r31185:
> [bad]
Wonderful, a New Hope for the GNUstep transition.
Many thanks to you all!
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.
Axel Beckert wrote:
> Upgrading gnustep-back-common fails (at least on kfreebsd-i386) in the
> postinst script. Adding a set -x to the script reveals mknfonts as
> cause:
Thanks for the report. Could you please rebuild mknfonts.tool with
"noopt nostrip" and post the gdb backtrace from `mknfonts
/
reassign libgnustep-base1.20 1.20.1-2
retitle 593898 [kfreebsd] NSProcessInfo fails to obtain argument vectors
affects 593898 gnustep-back-common
thanks
Thanks, it is clear where the error lies:
> Error: libkvm does not return arguments for the current process
> this may be due to a bug (undocume
reassign 593898 gnustep-back-common 0.18.0-2
retitle 593898 Arguments passed to mknfonts in postinst may exceed operating
system limit
tags 593898 + pending
thanks
Thanks for performing the test.
Axel Beckert wrote:
> Arguments given: 512
> Error: libkvm does not return arguments for the current
gurkan wrote:
> On Sat, 21 Aug 2010 22:33:53 +0200, Mehdi Dogguy
> wrote:
> > Do you intend to upload gorm.app soon?
>
> yes i have the packages ready, as you can see from the gnustep devel
> mailinglist,
> it's on mentors.debian.org waiting for a sponsor.
Have you contacted potential sponsors?
clone 583006 -1
# The libs are built with -g, but not DBModeler.
retitle -1 gnustep-dl2: (Partially) broken nostrip handling with
gnustep-make/2.4.x
severity -1 important
thanks
В 12:54 +0200 на 23.05.2010 (нд), Federico Gimenez Nieto написа:
> On Mon, 2010-05-17 at 12:46 +0300, Yavor Doga
Federico Gimenez Nieto wrote:
> On Tue, 2010-05-25 at 13:30 +0300, Yavor Doganov wrote:
> > I bet that once you fix the above in the usual way (i.e. conditionally
> > define `debug', not `OPTLFAG'), you'll be able to reproduce it with
> > gnustep-base/1.2
On Wed, May 26, 2010 at 10:03:10PM +0300, Yavor Doganov wrote:
> Federico Gimenez Nieto wrote:
> > but now the docs are not being generated, why might this be
> > happening?
>
> Give me some time to investigate. 99% gnustep-make related.
The API docs are built, only the ma
Federico Gimenez Nieto wrote:
> Thanks, now it is bulding without problems, it is uploaded at
> mentors
IMHO it is useless to make an upload to sid fixing the current RC bug
now, because you'd need a sourceful upload for the transition anyway,
and the GNUstep stack (including gnustep-dl2) is not r
Matt Kraai wrote:
> This bug appears to have been fixed upstream by multiple revisions
> (i.e., at least 31763 and 31765) and, hopefully, in the latest 1.22.0
> release.
That's correct.
> Would it be better to upload the new upstream version or to backport
> the required changes?
The latter; 1.2
tags 624928 + pending
thanks
Matt Kraai wrote:
> I'll try to put together a patch and, if you'd like, perform an NMU.
Please don't bother, it is trivial and done, sorry for not telling you
that in the first place and tagging the bug accordingly.
The only thing preventing an upload of a fixed pac
&file=log&as=raw
For this, you need to preprocess the source on a sparc machine to
figure out what's going on. A more burdensome approach is to examine
carefully the source.
> More seriously, Yavor Doganov is CCed since he may
> want to provide a rational explanation about
Hi Eric,
On Mon, Feb 14, 2011 at 03:05:49PM -0700, Eric Wasylishen wrote:
> It's caused by the thread-local fast_path_cache variable in pixman.c.
> If you make that non-thread-local (a normal static variable) the
> problem will go away.
Yep, or if you set the tls_model to *-exec. But IMO this
Eric Wasylishen wrote:
> I think what led me to say this was, I found that modifying
> GNUstep-gui so it links directly to cairo and pixman made the crash
> disappear.
Interesting. But that's only a workaround, and not really an option
because gnustep-gui is configured with --as-needed in Debian
Federico Giménez Nieto wrote:
> It seems that this may be related to some higher level package, affecting
> [1] too. I'll try to investigate more deeply, cheers
Without investigation: most probably this is related to the new
behavior of GCC 4.5 to bail out immediately if an #include'd header is
no
Package: gazpacho
Version: 0.7.2-2
Severity: grave
$ gazpacho
ERROR: Could not find required directory: /usr/lib/python2.6/site-packages
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (
В 11:56 +0200 на 18.07.2010 (нд), Paul Chany написа:
> when I try to run ProjectCenter I get error messages:
> 2010-07-18 11:30:57.203 ProjectCenter[5618] Exception occured while
> loading model: the volatile domain Hungarian already exists
Hmm. You probably have registered incorrectly some sett
tags 589500 moreinfo unreproducible
thanks
Paul Chany wrote:
> 'defaults read | grep Hungarian'
> gives me no output.
Strange.
> 2010-07-19 17:27:42.934 ProjectCenter[1695] Problem posting
> notification: NAME:NSGenericException
> REASON:Glyph generation with no font. INFO:(nil)
This is diffe
Package: aspell-bg
Version: 3.0-10
Severity: serious
Upgrading from 3.0-9 or simply doing `aptitude reinstall aspell-bg'
results in the removal of the files /var/lib/aspell/bg{,-en}.rws,
making the correspondent symlinks in /usr/lib/aspell dangling.
This makes the package completely unusable.
--
tags 589851 + patch pending
thanks
On Wed, Jul 21, 2010 at 06:56:14PM +0300, Yavor Doganov wrote:
> Upgrading from 3.0-9 or simply doing `aptitude reinstall aspell-bg'
> results in the removal of the files /var/lib/aspell/bg{,-en}.rws,
It seems this is done unconditionally in p
Luca Bruno wrote:
> I'm fine to test and sponsor your patches for #589551.
> As it is a QA RC-fixing upload, I prefer it to contain just minimal
> changes to fix this bug (eg. the current patch) and have it sorted out
> soon, leaving minor cosmetic ones for later.
If I understand correctly, you wa
Cyril Brulebois wrote:
> could you please try and figure out which versions are affected?
> http://snapshot.debian.org/package/pixman/
The first "bad" is 0.18.0-1. With 0.16.4-1 (installed on an
up-to-date sid system) I get
Ink: symbol lookup error: /usr/lib/libcairo.so.2: undefined symbol:
pi
tags 614277 + patch
thanks
Ludovic Brenta wrote:
> We're working on a fix now. Please be patient.
The fix is simple -- replace
#import
in OOCocoa.h and
#import
in OOCPUInfo.h with #include. OOCocoa.h probably also needs
`#include ' as well.
The #import directive should *never* be use
At Sat, 2 Jul 2011 12:09:47 +0200,
Julien Cristau wrote:
> > tags 618184 + pending
>
> That was 3 months ago. When can we expect a fix in sid?
When we have a green light from the release team to carry out the
GNUstep transition (#629477). I prefer a package to FTBFS than to
fail miserably at ru
intrigeri wrote:
> Yavor Doganov wrote (30 Oct 2014 11:59:26 GMT) :
> > An attempt to contact the original authors of GNUMail and LuserNET
> > for request for relicensing under GPL + OpenSSL exception has
> > failed, so the problem will be solved in the library by sw
> Yavor Doganov wrote (05 Nov 2014 08:02:47 GMT) :
> > $ sudo dpkg-reconfigure dhelp
> > Building HTML tree...ArgumentError: invalid byte sequence in UTF-8
> > (/usr/lib/ruby/vendor_ruby/debian.rb:914:in `block in initialize'
>
> I cannot reproduce that in a
Package: gnustep-back0.24-cairo
Version: 0.24.0-3
Severity: grave
Tags: fixed-upstream pending
Justification: renders package unusable
Scrolling either via the mouse wheel or scrollbars garbles the screen
content within the scrolled window, making most apps and open/save
panels unusable.
-- Syste
reopen 768127
notfixed 768127 0.6.21+nmu6
thanks
Thanks for your work, but unfortunately I experience exactly the same
problem with the new version.
$ isutf8 /var/lib/doc-base/documents/*
$ echo $?
0
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubsc
gregor herrmann wrote:
> On Thu, 18 Dec 2014 12:01:02 +0200, Yavor Doganov wrote:
> > Thanks for your work, but unfortunately I experience exactly the
> > same problem with the new version.
>
> I guess it would be helpful if you could try to
> - add a "puts @path&
gregor herrmann wrote:
> > /var/lib/doc-base/documents/xterm-ctlseqs
> > /var/lib/doc-base/documents/xterm-faq
> > ArgumentError: invalid byte sequence in UTF-8
> > (/usr/lib/ruby/vendor_ruby/debian.rb:914:in `block in initialize'
>
> So according to the previous findings, my guess is that
> /var
Daniel Getz wrote:
> Can you run with the attached patch to debian.rb, and see if it will
> show which entry of which file triggers the error?
Thanks; here's the output:
Error parsing file /var/lib/dpkg/available
Contents of info:
Package: ayuda
Priority: extra
Section: misc
Installed-Size: 204
M
gregor herrmann wrote:
> On Thu, 18 Dec 2014 21:02:58 -0100, Daniel Getz wrote:
> > However, the code in question is in ruby-debian, which is a
> > separate library used by other packages. Might not be correct
> > behavior for other users of the library?
>
> Right, cloning+reassigning to ruby-debi
Axel Beckert wrote:
> Yavor: Next time you merge such bugs, please make sure that the
> shown bug is properly titled. TIA!
Apologies; I'll be more careful in the future.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
Package: gorm.app
Version: 1.2.20-1
Severity: grave
Reading symbols from Gorm...Reading symbols from
/usr/lib/debug/.build-id/48/e3ee859cc88db72cf52faf341921febdcd267f.debug...done.
done.
(gdb) r
/usr/lib/GNUstep/Applications/Gorm.app/Resources/English.lproj/Gorm.gorm/
Starting program: /usr/bin
reassign 756852 libpantomime1.2
reassign 756853 libpantomime1.2
merge 756852 756853
retitle 756852 libpantomime1.2: Makes dependant GPL apps undistributable
because of linking with OpenSSL
affects 756852 gnumail.app lusernet.app
tags 756852 + pending
thanks
An attempt to contact the original auth
Package: dhelp
Version: 0.6.21+nmu5
Severity: grave
Justification: renders package unusable
$ dhelp
Starting browser (using local filesystem) ...
w3m: Can't load /usr/share/doc/HTML/index.html.
/usr/bin/sensible-browser: Failed to open /usr/share/doc/HTML/index.html:
Отказано свързване
$ ls /usr/
reassign 835894 libgnustep-gui0.25 0.25.0-2
affects 835894 terminal.app
thanks
Eric Heintzmann wrote:
> Well, it seems that teminal.app doesn't depends on gnustep-back package.
>
> Instead it depends on libgnustep-gui0.25 which doesn't depends on
> gnustep-back.
That's because of the .symbols fi
reassign 656771 ftp.debian.org
retitle 656771 RM: kazehakase -- RoM; RC-buggy, unmaintained upstream, low
popcon, better alternatives available
thanks
At Sat, 21 Jan 2012 17:47:30 +0100,
Moritz Muehlenhoff wrote:
> I propose to remove kazehakase from the archive:
FWIW, I agree.
I have a fixed p
tags 667866 + patch
thanks
Patch attached.
--- cenon.app-3.93.orig/VHFShared/vhfCompatibility.h
+++ cenon.app-3.93/VHFShared/vhfCompatibility.h
@@ -44,7 +44,7 @@
#if defined( GNUSTEP_BASE_VERSION )
#define VHFIsDrawingToScreen() [[NSGraphicsContext currentContext] isDrawingToScreen]
-#
tags 667873 + patch
thanks
Patch attached.
--- gridlock.app-1.10.orig/NSObject+Extensions.m
+++ gridlock.app-1.10/NSObject+Extensions.m
@@ -117,12 +117,12 @@ BOOL EDClassIsSuperclassOfClass(Class aC
{
Class class;
-class = subClass->super_class;
+class = class_getSuperclass(subClas
tags 667874 + patch
thanks
Patch attached.
--- gworkspace-0.8.8.orig/GWorkspace/GWorkspace.m
+++ gworkspace-0.8.8/GWorkspace/GWorkspace.m
@@ -1054,29 +1054,29 @@
{
SEL action = [anItem action];
- if (sel_eq(action, @selector(showRecycler:))) {
+ if (sel_isEqual(action, @selector(showRecyc
tags 667886 + patch
thanks
Patch attached.
--- textedit.app-4.0+20061029.orig/Document.m
+++ textedit.app-4.0+20061029/Document.m
@@ -1361,13 +1361,13 @@ validateToggleItem (NSMenuItem *aCell, B
{
SEL action = [aCell action];
#ifdef GNUSTEP
- const char *sel_name = sel_get_name (action);
+ c
At Sun, 8 Jan 2012 16:24:41 -0600,
Jonathan Nieder wrote:
> Here's a backported patch, just for kicks. Untested. What do you
> think? Does squeeze need a fix, and if so will this work?
I think it does not need a fix for stable, as Charmap runs fine for me
there. The fix you mention is relevant
Jonathan Nieder wrote:
> Should gnustep-gui have something like
>
> Breaks: aclock.app (<< 0.2.3-3.1), charmap.app (<< 0.2-11),
>gnumail.app (<< 1.2.0~pre3+snap20071004-5),
>volumecontrol.app (<< 0.5-3.1)
>
> to prevent problems during partial upgrades?
No, I don't think s
ot include nonexistent header (Closes:
+#618205).
+
+ -- Yavor Doganov Sat, 08 Oct 2011 13:33:05 +0300
+
gorm.app (1.2.10-2) unstable; urgency=low
* Bump standards version to 3.9.1.
only in patch2:
unchanged:
--- gorm.app-1.2.10.orig/GormCore/GormObjectInspector.m
+++ gorm.app-1.2.1
ainer): Fix Gürkan's email address.
+
+ -- Yavor Doganov Sat, 08 Oct 2011 14:18:16 +0300
+
gridlock.app (1.10-3) unstable; urgency=low
* GNUstep transition.
only in patch2:
unchanged:
--- gridlock.app-1.10.orig/EDObjcRuntime.h
+++ gridlock.app-1.10/EDObjcRuntime.h
@@ -44,16 +44,15 @@
#els
kan's email address.
+
+ -- Yavor Doganov Sat, 08 Oct 2011 15:01:32 +0300
+
talksoup.app (1.0alpha-32-g55b4d4e-1.1) unstable; urgency=low
* Non-maintainer upload by sponsor.
diff -u talksoup.app-1.0alpha-32-g55b4d4e/debian/control talksoup.app-1.0alpha-32-g55b4d4e/debian/control
--- ta
l.app-0.9.4+cvs20051125/debian/changelog
+++ terminal.app-0.9.4+cvs20051125/debian/changelog
@@ -1,3 +1,10 @@
+terminal.app (0.9.4+cvs20051125-6.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix FTBFS with gcc-4.6 (Closes: #643973).
+
+ -- Yavor Doganov Sat, 08 Oct 2011 14:41:32
reassign 644868 libgnustep-base1.22
retitle 644868 Programs abort on kfreebsd* when arguments exceed 512
affects 644868 gnustep-back-common
block 629477 with 644868
thanks
On Sun, Oct 09, 2011 at 11:02:25PM +0200, Axel Beckert wrote:
> Package: gnustep-back-common
> Version: 0.20.1-2
> Severity: s
Axel Beckert wrote:
> Yavor Doganov wrote:
> > The only way I see as a workaround is to build gnustep-base with
> > --enable-fake-main, which is already the case on a number of *BSD
> > systems.
>
> The fix from back then doesn't help again respectively anymore
Alexander Kurtz wrote:
> Since both #618046 and #618077 have been fixed for some time now and the
> affected packages build fine[1][2], I'd like to close these bugs in a
> few days. Any objections?
No objections, but AFAICT these bugs are merged/closed, aren't they?
The only reason they appear on
Package: aclock.app
Version: 0.2.3-3+b4
Severity: grave
Justification: renders package unusable
When starting the application, the standard GNUstep icon appears. No
menu, no clock.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'te
Package: biococoa.app
Version: 1.6.0-8+b3
Severity: grave
Justification: renders package unusable
BioCocoa crashes on startup with the following backtrace:
Starting program: /usr/bin/BioCocoa
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0xb7
Package: cenon.app
Version: 3.93-1+b1
Severity: grave
Justification: renders package unusable
Cenon crashes on startup; backtrace below:
Starting program: /usr/bin/Cenon
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0xb76db8f6 in objc_msg_loo
Package: charmap.app
Version: 0.2-10+b2
Severity: grave
Justification: renders package unusable
Starting the applications results in showing the app icon, but no
menu or main window.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 't
Package: gnustep-dl2
Version: 0.12.0-7
Severity: serious
File: /usr/lib/GNUstep/ApplicationSupport/Palettes/GDL2.palette/GDL2
With gnustep-dl2 installed, Gorm aborts on startup with:
Gorm: Uncaught exception NSInvalidArgumentException, reason: Can not
determine type information for +[GDL2CDNSObje
Package: volumecontrol.app
Version: 0.5-3+b4
Severity: grave
Justification: renders package unusable
Only the app icon appears; no menu or main window.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i6
Package: gnumail.app
Version: 1.2.0~pre3+snap20071004-4+b4
Severity: grave
Justification: renders package unusable
GNUMail crashes on startup; unfortunately the backtrace is unusable.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, '
user pkg-gnustep-maintain...@lists.alioth.debian.org
usertags 645923 gnustep-gui0.20-transition gnustep-transition
tags 645923 + patch
thanks
Andreas Tille wrote:
> do you have any hint how to fix this.
Sure, trivial patch attached. (You could simply merge it with the
existing debian/patches/05_
On Thu, Oct 20, 2011 at 10:45:29AM +0200, Andreas Tille wrote:
> after having spend another couple of time into this package I decided
> that it is better if it would go.
> I decided to reassign this bug to ftpmaster for removal of biococoa.app.
Your call, I certainly don't object.
You might wan
tags 645926 + patch
thanks
Here is a trivial patch that fixes this bug.
--- cenon.app-3.93.orig/Cenon_main.m
+++ cenon.app-3.93/Cenon_main.m
@@ -59,7 +59,7 @@
}
app = [appClass sharedApplication];
-[app setApplicationIconImage:[NSImage imageNamed:@"cenon.tiff"]];
+[app setAppli
tags 645921 + patch
thanks
Here is a patch that fixes this issue.
--- aclock.app-0.2.3.orig/main.m
+++ aclock.app-0.2.3/main.m
@@ -1,10 +1,6 @@
#include
-int main(int argc, char **argv)
+int main(int argc, const char **argv)
{
- CREATE_AUTORELEASE_POOL(pool);
- [NSApplication sharedApplicatio
tags 645935 + patch
thanks
Patch attached.
--- volumecontrol.app-0.5.orig/main.m
+++ volumecontrol.app-0.5/main.m
@@ -1,10 +1,6 @@
#include
-int main(int argc, char **argv)
+int main(int argc, const char **argv)
{
- CREATE_AUTORELEASE_POOL(pool);
- [NSApplication sharedApplication];
- [NSApp
tags 620583 + pending
thanks
At Sun, 17 Apr 2011 12:02:25 -0300,
Lisandro Damián Nicanor Pérez Meyer wrote:
> We are getting closer to remove aRts, how is this bug going?
We are a bit stuck with the forced migration away from GNU Arch (due
to the removal of tla-buildpackage), but I'll prepare an
Philipp Kern wrote:
> Source: gnustep-base
> Version: 1.22.1-1
> Severity: serious
> The full build log can be found on [0].
Unfortunately I have access only to kfreebsd-i386. Could you please
send me the relevant portion of config.log (or the whole file)?
Thanks.
--
To UNSUBSCRIBE, email t
Philipp Kern wrote:
> So this is obviously needed for the GNUstep transition. Can you
> please upload it?
I will, hopefully today, but it should be binNMUed on kfreebsd-amd64
when gnustep-base is fixed.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "uns
clone 642162 -1
reassign -1 libffi5
retitle -1 Problem with closures on kfreebsd-amd64
block 642162 with -1
thanks
> 66 ((void(*)(cls_struct_combined)) (code))(g_dbl);
> (gdb)
>
> Program received signal SIGSEGV, Segmentation fault.
> You can ask for access to asdfasdf.debian.net, which is
Petr Salinger wrote:
> I tried the same on my PC,
> testsuite of all available (stable, sid, experimental) libffi passes.
>
> On asdfasdf.d.n they fails.
> Could be this related to CPU ?
> My is "Intel(R) Core(TM)2 Duo CPU E6750"
> asdfasdf's "AMD Sempron(tm) Processor 3000+"
I think so -- li
tags 642928 + patch
thanks
Petr Salinger wrote:
> After changing configure.ac and propagating it into
> configure, the testsuite of 3.0.11~rc1-2 succeeds
> also on asdfasdf.d.n
Excellent, I successfully tested it too. Thanks very much, Petr!
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...
tags 643973 + patch
thanks
GCC 4.6 exposed this bug; trivial patch attached.
--- terminal.app-0.9.4+cvs20051125.orig/TerminalView.m
+++ terminal.app-0.9.4+cvs20051125/TerminalView.m
@@ -28,7 +28,7 @@ stupid but fast character cell display v
# include
# include
#else
-# include
+# include
tags 660430 = patch
thanks
Here's a patch that fixes the problem.
--- textedit.app-4.0+20061029.orig/Document.m
+++ textedit.app-4.0+20061029/Document.m
@@ -124,12 +124,6 @@
[self setViewSize: size];
}
- [[NSNotificationCenter defaultCenter]
- addObserver: self
- selector: @selector (f
At Sat, 26 May 2012 18:42:04 +0200,
gregor herrmann wrote:
> Builds fine for me (i386 and amd64 sid chroot).
Strange that I cannot reproduce it either :/
However, warnings like these are a guaranteed failure at runtime:
Document.m:1364:2: warning: implicit declaration of function ‘sel_get_name’
Andreas Beckmann wrote:
> there are now fewer directories, but there is still something in $HOME:
>
> 0m47.6s ERROR: FAIL: Package purging left files on system:
> /root/GNUstep/ not owned
> /root/GNUstep/Library/ not owned
Yes, this is because mknfonts.tool which is run in postins
block 676229 with 673538
thanks
Wolfgang Sourdeau wrote:
> Package: gnustep-make
> Justification: renders package unusable
Yes, currently it is unusable out of the box in sid/wheezy, at least
on x86 architectures where gcc-4.7 is the default compiler. You can
still build stuff with CC=gcc-4.6.
Mathieu Malaterre wrote:
> I simply cannot install libgnustep-gui-dev. It fails with:
> Setting up gnustep-base-runtime (1.24.0-1) ...
> /etc/init.d/gdomap: 428: /lib/lsb/init-functions: FANCYTTY: parameter not set
> invoke-rc.d: initscript gdomap, action "start" failed.
> dpkg: error processing g
Georgiewskiy Yuriy wrote:
> Package: oolite
> Version: 1.76dfsg-1
> Severity: grave
> Justification: renders package unusable
> oolite silently exit on debian wheezy with the following message:
Are you sure it actually exits? It doesn't for me -- I get the
warning, but the game starts. I'm on i
At Mon, 30 Apr 2012 13:05:23 +0200,
Julien Cristau wrote:
> Source: gnustep-gui
> Version: 0.20.0-3
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> gnustep-gui FTBFS on some buildds, see the logs linked from
> https://buildd.debian.org/status/
reassign 627302 src:gnustep-base
forcemerge 624928 627302
thanks
Asias He wrote:
> Is there any way that I can use gobjc-4.6 with libgnustep-base1.20?
No, not for the time being, sorry.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
reassign 627638 src:gnustep-base
forcemerge 624928 627638
thanks
This is a known issue.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Sat, Apr 26, 2014 at 12:44:45PM +0200, Philipp Kern wrote:
> Yavor, is there any plan to do the transition? #673538 didn't look
> like it was blocking on us.
Please accept my apologies for being MIA for so long.
I have the new GNUstep core packages ready at mentors.d.n (targeted
for experiment
tags 659489 + patch
clone 659489 -1
reassign -1 libpantomime1.2
retitle -1 CWConnection instance may get deallocated while CWService handles
the runloop event
severity -1 serious
affects -1 gnumail.app
tags -1 + patch
block 659489 with -1
thanks
Sorry for not being able to reply earlier.
On Sat,
Federico Giménez Nieto wrote:
> All seems to be working fine, you can take a look here
> http://mentors.debian.net/debian/pool/main/g/gnustep-dl2/gnustep-dl2_0.12.0-11.dsc
Looks good, but why is this deliberate -lc needed? Is it because
lintian reports library-not-linked-with-libc? For the adap
Package: gnustep-make
Version: 2.6.2-2
Severity: serious
Forwarded: http://savannah.gnu.org/bugs/index.php?42778
It turns out that gnustep-make does not support versioned frameworks
which makes library transitions of frameworks nearly impossible.
Slightly embarrassing to discover this after so ma
Package: libgnustep-gui0.24
Version: 0.24.0-2
Severity: serious
Forwarded: http://savannah.gnu.org/bugs/index.php?42782
Control: affects -1 viewpdf.app
Yet another bug which is only reproducible on i386;
viewpdf.app is affected in a way that makes it unusable.
-- System Information:
Debian Relea
Package: lusernet.app
Version: 0.4.2-6+b2
Severity: serious
LuserNET links with OpenSSL via Pantomime and is released under GPL
without the OpenSSL exception.
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architectur
Package: gnumail.app
Version: 1.2.0~pre3+snap20071004-5+b2
Severity: serious
GNUMail links with OpenSSL via Pantomime and is released under GPL
without the OpenSSL exception.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Cyril Brulebois wrote:
> your package no longer builds on powerpc due to undefined reference
> during linking:
I few days ago I sent a give-back request to powerpc@buildd.d.o
(attached). This was due to #756096.
--- Begin Message ---
gb timemon.app_4.1-3 . powerpc
It failed to build due to a bu
tags 756476 + patch
thanks
On Wed, Jul 30, 2014 at 10:37:12AM +0200, Emilio Pozuelo Monfort wrote:
> On 30/07/14 10:10, YunQiang Su wrote:
> > I think this problem is caused by libgtk-3-dev.
> > File /usr/share/aclocal/gtk-3.0.m4, it doesn't work,
>
> /usr/share/aclocal/gtk-3.0.m4 uses pkg-config
tags 728319 + patch
thanks
Yavor Doganov wrote:
> It seems like Preview is not capable of opening images.
Attached is a trivial patch that fixes this. These methods were
removed in 2005 (it's even in the upstream ChangeLog), but apparently
he forgot to remove the code that regis
Package: libgnustep-dl2-0d
Version: 0.12.0-9+nmu1
Severity: grave
It appears that some of the patches (581934.patch specifically, possibly
in combination with others) are broken and/or incomplete and have caused
the package to be entirely unusable.
Trying eoexample from /usr/share/doc/gnustep-dl2
301 - 400 of 426 matches
Mail list logo
