Bug#754441: GMastermind Relicensing
Hi Riley, the program comes with a COPYING file, which standard to contain the license used. In thiscase, it contains the GPL v2 or later. In other words: 1) the program headers contain reference to the GPL v2 or later 2) the COPYING file distirbuted with GMastermind contains the GPL v2 or later text 3) only the readme file contains a reference to the program being distributed GPL v2 without the or later clause To me it is clear that the intent is the program to be under GPLv2 or later and that the readme.txt contains a small omission. The source files and the COPYING file have priority! Given this, I already consider all my contributions under the GPL v2 or later clause. Riccardo On 2014-07-22 09:26:48 +0200 Riley Baird bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch wrote: Hi Riccardo, Even if you're not the original author, if you've made any modifications to the work, you own copyright on them. For example, Linus Torvalds is not the only copyright holder of Linux; the other ~5000 contributors all have copyright on it as well. This is why the kernel can't be upgraded to GPL-3, even if Linus wants to. So, having a statement from you would be helpful. (You are only relicensing *your* contributions) Also, what do you mean by the COPYING is the full GPL v2 or later? Riley -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754441: GMastermind Relicensing
Hi Riley, thanks for inquirying. I am not the original author of GMastermind, thus I cannot relicense it, if you need that explicit statement, you need to ask Marko Riedel. I see you put it in CC, I do not know if that email address is current though. We just got permissions to incorporate GMastermind in GAP. I think the original author licensed it under GPLv2+. The README file is misleading and probably written in haste. Not only the header files explicitely say or later, but also the COPYING is the full GPL v2 or later statement. The README file says to refer to gpl.txt, this is probably inaccurate and COPYING was intended. I would say that the original intentions are pretty clear. Just in the case, I corrected the README file and also updated COPYING to the current GPL v2+ file from fsf, it had even the old FSF address. Perhaps that statement should be removed totally and just COPYING should be included. Riccardo Riley Baird wrote: Hi, I'm currently packaging GMastermind for Debian. In the process, it has been discovered that, according to a technical reading of the README, GMastermind is licensed under GPL-2 only (i.e. without or, at your option, any later version). However, according to the headers on the source files, it would appear that the intention was to license under GPL-2 or any later version. If you are fine with releasing your contributions under GPL-2+, please copy the following statement, fill in your name and send it to the email addresses below. (If not, then please send a message anyway so we know.) - I, YOUR NAME, irrevocably give permission to use, redistribute, modify and to distribute modified copies of any and all of my contributions to the program GMastermind under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License, or (should anyone choose to do so) any later version. No warranty, not even the implied warranties of merchantability or fitness for a particular purpose, is given by this license grant. --- Please send this statement to the following email addresses: bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch 754...@bugs.debian.org pkg-gnustep-maintain...@lists.alioth.debian.org gap-dev-disc...@nongnu.org NOTE: If you don't want to be bothered by licensing issues again, send the following statement in instead. I, YOUR NAME, release my contributions to the program GMastermind into the public domain. This applies worldwide. In some countries, this may not be legally possible; if so: I grant anyone the right to use this my contributions to the program GMastermind for any purpose, without any conditions, unless such conditions are required by law. - Thanks in advance, Riley Baird -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726965: workaround
Removing acceleration works, in the sense that I get a usable display. However, the speed is ridiculous, it takes almost a second to move a window... with acceleration the old system was instead quite snappy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#315277: [bug #13593] The windows are drawed slowly on remote displays
Update of bug #13593 (project gnustep): Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.gnu.org/bugs/?13593 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671975: bug related to
This bug is related to: 672986 Please see 667868 for a way to make current base build against gcc 4.7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672986: related to bug 667868
Refer to bug 667868. The patches backport gcc 4.7 compatibility. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667868: patch to fix debian base FTBFS gcc 4.7
Apply this patch, it is a backport from SVN trunk to disable blocks if
the runtime doesn't support it and fix other header imports. It fixes
NSBlock.
I attach also a second patch, needed to link the rest, needed fog gcc
4.6 and 4.7, as per comments.
Riccardo
--- libs/base/trunk/Source/Additions/GSObjCRuntime.m 2011/07/15 13:53:45 33562
+++ libs/base/trunk/Source/Additions/GSObjCRuntime.m 2011/10/15 18:36:51 34005
@@ -136,10 +136,15 @@
return sel_getUid(name);
}
-// FIXME: Hack - need to provide these function declarations
-// for gcc 4.6 libobjc. They're called below, and they're declared
-// in objc-api.h, but we're using runtime.h, so objc-api.h can't be imported.
-#if defined (__GNU_LIBOBJC__)
+#if defined (__GNU_LIBOBJC__) (__GNU_LIBOBJC__ 20110608)
+/* Don't use sel_registerTypedName() ... it's broken when first introduced
+ * into gcc (fails to correctly check for multiple registrations with same
+ * types but different layout info).
+ * Later versions of the runtime should be OK though.
+ * Hack - need to provide these function declarations
+ * for gcc 4.6 libobjc. They're called below, and they're declared
+ * in objc-api.h, but we're using runtime.h, so objc-api.h can't be imported.
+ */
SEL sel_get_any_typed_uid(const char *name);
SEL sel_get_typed_uid(const char *name, const char*);
SEL sel_register_name(const char *name);
@@ -151,13 +156,8 @@
{
#if NeXT_RUNTIME
return sel_getUid(name);
-/* Don't use sel_registerTypedName() ... it's broken when first introduced
- * into gcc (fails to correctly check for multple registrations with same
- * types but different layout info).
- *
-#elif defined (__GNU_LIBOBJC__)
+#elif defined (__GNU_LIBOBJC__) (__GNU_LIBOBJC__ = 20110608)
return sel_registerTypedName(name, types);
- */
#elif defined (__GNUSTEP_RUNTIME__)
return sel_registerTypedName_np(name, types);
#else
--- Source/ObjectiveC2/NSBlocks.m.orig 2012-05-16 12:43:05.0 +0200
+++ Source/ObjectiveC2/NSBlocks.m 2012-05-16 12:55:42.0 +0200
@@ -1,7 +1,26 @@
+#import objc/objc.h
+
+#if defined (__GNU_LIBOBJC__)
+
+#warning Unable to build NSBlocks for this runtime.
+
+/* FIXME ... these let us link, but blocks will be broken.
+ */
+void *_NSConcreteStackBlock;
+BOOL objc_create_block_classes_as_subclasses_of(Class super)
+{
+ return NO;
+}
+
+#else
+
#import objc/objc-api.h
-#import ObjectiveC2/blocks_runtime.h
+#import ObjectiveC2/objc/runtime.h
+
+#import ObjectiveC2/objc/blocks_runtime.h
#include assert.h
+
struct objc_class _NSConcreteGlobalBlock;
struct objc_class _NSConcreteStackBlock;
@@ -59,3 +78,5 @@
NEW_CLASS(_NSBlock, _NSConcreteGlobalBlock);
return YES;
}
+
+#endif /* defined (__GNU_LIBOBJC__) */
Bug#671975: Gorm segfaults
I can confirm the same bug on debian unstable, but x86-32 uname -s -m -o Linux i686 GNU/Linux Program received signal SIGSEGV, Segmentation fault. 0xb75c972e in objc_hash_value_for_key () from /usr/lib/i386-linux-gnu/libobjc.so.4 (gdb) bt #0 0xb75c972e in objc_hash_value_for_key () from /usr/lib/i386-linux-gnu/libobjc.so.4 #1 0xb733e6bc in sel_get_typed_uid () from /usr/lib/i386-linux-gnu/libobjc.so.3 #2 0xb784cc46 in GSSelectorFromNameAndTypes () from /usr/lib/libgnustep-base.so.1.22 #3 0xb784bab6 in ?? () from /usr/lib/libgnustep-base.so.1.22 #4 0xb702c2ab in ?? () from /usr/lib/i386-linux-gnu/libffi.so.5 #5 0xb702c646 in ?? () from /usr/lib/i386-linux-gnu/libffi.so.5 #6 0xb772f1cd in ?? () from /usr/lib/libgnustep-base.so.1.22 #7 0xb772e1a8 in ?? () from /usr/lib/libgnustep-base.so.1.22 #8 0xb772da51 in ?? () from /usr/lib/libgnustep-base.so.1.22 #9 0x0804c478 in _start () -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672986: gnustep-gui-runtime: Multiple libobjc.so version linked due to mix of dependencies
Package: gnustep-gui-runtime Version: 0.20.0-3 Severity: grave Justification: renders package unusable Dear Maintainer, gnustep-base, gnustep-gui and gnustep-back depend on different version of libobjc (libobjc.so.3 and libobjc.so.4 of gcc 4.6 and gcc 4.7 respectively). Since several GNUstep applications do crash, I suppose all recently compiled applications (self-compiled ones but also Gorm, which got recently updated and for which a separate bug is pending). checking with ldd, if libobjc.so.3 comes before .so.4 (old app) the app will work, if .so.4 comes before, the applicationwill crash. I think it is not a good idea that gnustep-core packages (base,gui,back) depend on different libobjc runtimes. I have installed: gnustep-back0.20-cairo 0.20.1-2+b1 libgnustep-base1.22 1.22.1-2+b1 libgnustep-gui0.20 0.20.0-3 it appears that only gui was updated to newer libobjc. This makes gnustep unusable for any new package and for any self-compiled apps for development. A ldd output of a working application: linux-gate.so.1 = (0xb76fe000) libGNUMail.so.1 = /usr/lib/gnumail.app/libGNUMail.so.1 (0xb75b4000) libgnustep-gui.so.0.20 = /usr/lib/libgnustep-gui.so.0.20 (0xb7153000) libgnustep-base.so.1.22 = /usr/lib/libgnustep-base.so.1.22 (0xb6ce7000) libobjc.so.3 = /usr/lib/i386-linux-gnu/libobjc.so.3 (0xb6cc7000) libc.so.6 = /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb6b6a000) libPantomime.so.1.2 = /usr/lib/libPantomime.so.1.2 (0xb6aca000) libAddresses.so.0 = /usr/lib/libAddresses.so.0 (0xb6a9b000) libAddressView.so.0 = /usr/lib/libAddressView.so.0 (0xb6a6e000) libm.so.6 = /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb6a48000) libgcc_s.so.1 = /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6a2b000) libpng12.so.0 = /lib/i386-linux-gnu/libpng12.so.0 (0xb6a0) libgif.so.4 = /usr/lib/libgif.so.4 (0xb69f7000) libtiff.so.4 = /usr/lib/i386-linux-gnu/libtiff.so.4 (0xb6991000) libjpeg.so.8 = /usr/lib/i386-linux-gnu/libjpeg.so.8 (0xb6958000) libobjc.so.4 = /usr/lib/i386-linux-gnu/libobjc.so.4 (0xb694) libpthread.so.0 = /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb692 output of a broken application: linux-gate.so.1 = (0xb777b000) libgnustep-gui.so.0.20 = /usr/lib/libgnustep-gui.so.0.20 (0xb7318000) libgnustep-base.so.1.22 = /usr/lib/libgnustep-base.so.1.22 (0xb6eac000) libpthread.so.0 = /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb6e93000) libobjc.so.4 = /usr/lib/i386-linux-gnu/libobjc.so.4 (0xb6e7b000) libm.so.6 = /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb6e55000) libgcc_s.so.1 = /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6e37000) libc.so.6 = /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb6cda000) libpng12.so.0 = /lib/i386-linux-gnu/libpng12.so.0 (0xb6cb) libgif.so.4 = /usr/lib/libgif.so.4 (0xb6ca7000) libtiff.so.4 = /usr/lib/i386-linux-gnu/libtiff.so.4 (0xb6c41000) libjpeg.so.8 = /usr/lib/i386-linux-gnu/libjpeg.so.8 (0xb6c07000) libobjc.so.3 = /usr/lib/i386-linux-gnu/libobjc.so.3 (0xb6be7000) libavahi-common.so.3 = /usr/lib/i386-linux-gnu/libavahi-common.so.3 (0xb6bd9000) libavahi-client.so.3 = /usr/lib/i386-linux-gnu/libavahi-client.so.3 (0xb6bc6000) libgnutls.so.26 = /usr/lib/i386-linux-gnu/libgnutls.so.26 (0xb6afd000) -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnustep-gui-runtime depends on: ii gnustep-base-runtime 1.22.1-2+b1 ii gnustep-common [gnustep-fslayout-fhs] 2.6.2-2 ii gnustep-gui-common 0.20.0-3 ii libao4 1.1.0-1.1+b1 ii libaspell150.60.7~20110707-1 ii libc6 2.13-32 ii libcups2 1.5.2-11 ii libflite1 1.4-release-4 ii libgcc11:4.7.0-8 ii libgnustep-base1.221.22.1-2+b1 ii libgnustep-gui0.20 0.20.0-3 ii libobjc4 4.7.0-8 ii libsndfile11.0.25-4 gnustep-gui-runtime recommends no packages. gnustep-gui-runtime suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#315277: [bug #13593] The windows are drawed slowly on remote displays
Update of bug #13593 (project gnustep): Status:None = Works For Me ___ Follow-up Comment #2: Adam, does this still happen? I export display and xlib. While it is clearly slower than other non-gnustep apps, I do not experience it so extreme as you describe. I used to experience it that bad on 256 color displays before faster rawing was implemented by some kind soul. ___ Reply to this item at: http://savannah.gnu.org/bugs/?13593 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
