Bug#1056147: midge possibly contains non-DFSG-free examples
Control: tag -1 patch I have now uploaded a possible repackaged .orig.tar.bz2: http://users.am-1.org/~ivan/src/sfn.2xNKGoveuNoRGASEQosuADUES3vYQfQmWVeMuitdtLI.tar.bz2 It was produced with the following shell command (where 39 blocks starting with 180 cover the entirety of midge-0.2.41 /examples/covers/ directory in the Tar file.) $ (zcat | (dd count=180 ; dd count=39 > /dev/null ; dd) | bzip2 -4c) \ < midge_0.2.41.orig.tar.gz > midge_0.2.41+dfsg1.orig.tar.bz2 -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1056147: midge possibly contains non-DFSG-free examples
Source: midge Version: 0.2.41-4 Severity: serious Justification: possible DFSG violation [Please do not Cc: me, as I’m “on the list,” so to say, and I prefer to reserve my inbox for private communication only. I’d have set up Mail-Followup-To:, but there doesn’t seem to be a way to make it point to the report being filed.] The source currently contains a number of covers/*.mg files that are, so far as I can tell, derivatives of songs for which there’re no indication of being out of copyright or ever released under a DFSG-compliant license. In particular, a cursory look at Wikipedia articles (below) do not seem to mention anything related to possible free culture status of the songs transcribed in paranoid.mg & wish_you_were_here.mg. http://en.wikipedia.org/wiki/Paranoid_(Black_Sabbath_album) http://en.wikipedia.org/wiki/Wish_You_Were_Here_(Pink_Floyd_song) I believe the source needs to be repackaged so to exclude the examples/covers/ directory entirely. -- FSF associate member #7257 np. The Last Refugee — Roger Waters
Bug#1056146: xsok possibly contains non-DFSG-free data files
Source: xsok
Version: 1.02-19
Severity: serious
Justification: possible DFSG violation
[Please do not Cc: me, as I’m “on the list,” so to say, and
I prefer to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem
to be a way to make it point to the report being filed.]
The xsok debian/copyright file seems to suggest that xsok
was created solely by Michael Bischoff:
$ tar --xz -xO -- debian/copyright < xsok_1.02-19.debian.tar.xz
This is Debian GNU/Linux's prepackaged version of xsok.
xsok was written by Michael Bischoff .
The upstream source was downloaded from
ftp://ftp.io.com/pub/mirror/FreeBSD/ports/distfiles/xsok-1.02-src.tar.gz
The current Debian maintainer is Peter Samuelson .
Much of the packaging work was done by previous Debian maintainers
Sven Rudolph and Joel Rosdahl.
Copyright (c) 1994 by Michael Bischoff (m...@mo.math.nat.tu-bs.de)
[GNU GPL 2+ notice follows.]
There’re two issues with this. First, xsok includes
doc/cyberbox.doc, authored by Doug Beeferman (I presume
lib/Cyberbox/ files are also derivatives rather than
original xsok work.) The .doc file (quoted below) appears
to allow verbatim redistribution of the respective game,
but there’s no indication that ‘modifications and derived
works’ are allowed (as DFSG requires) as well:
S O R T A F R E E W A R E N O T I C E
This game can be distributed freely and played free of charge. If you like
it, however, I wouldn't mind a small donation for the effort I put into
writing the program and (ughh!) in making the levels. I say "ughh!" because
making the levels was by far the more time-consuming of the two projects.
Neither is there any such indication on http://dougb.com/ .
(I intend to contact the author of Cyberbox shortly to comment
on this issue and (or) possibly re-release at least the
portions of xsok derived from the original game in DFSG-
compliant fashion.)
Worse still, the ‘screens’ (= maps, levels) included in
lib/Sokoban/ appear to mostly come from the original,
proprietary version(s) of Soko-Ban. Consider, e. g.:
http://web.archive.org/web/2023/https://www.mobygames.com/game/1715/soko-ban/
http://web.archive.org/web/20230407165659im_/https://cdn.mobygames.com/8e54fc3c-bee0-11ed-9c42-02420a000140.webp
http://web.archive.org/web/20230407165658im_/https://cdn.mobygames.com/0b7522d4-c204-11ed-ab6b-02420a000194.webp
The first Soko-Ban screen, identical to lib/Sokoban/screen.01 .
http://web.archive.org/web/20230407165658im_/https://cdn.mobygames.com/058c7f98-ab6b-11ed-aaf5-02420a00019c.webp
The second Soko-Ban screen, identical to lib/Sokoban/screen.02 .
Moreover, taking a look at an earlier curses-based implementation
of the game from [1], which (according to its README.v2, as
quoted below) borrows screens from ‘the PC-version’, we find
out that likely /all/ levels from 1 to 50 inclusive are taken
from other software, while several other levels (86‒88) are
derived from the same.
I’m not aware of any evidence to suggest that the original
Soko-Ban might be out of copyright or ever released as free
software, from whence I conclude it’s likely proprietary,
including the level designs.
The first thing I have to say is that I don't have the sources for SOKOBAN
under MS-DOS. I believe that this program is copyrighted. I took only the
idea and the screens of the PC-version.
[1] http://ibiblio.org/pub/linux/games/strategy/sokoban-src.tar.gz
bash$ diff -dbuF^\; -- \
<((tar -zxOv --wildcards -- \*/screen.\? < sokoban-src.tar.gz ; \
tar -zxOv --wildcards -- \*/screen.\?\? < sokoban-src.tar.gz) \
2>&1 | sed -e "s,^sokoban.*\\.,;LEVEL ,;") \
share/games/xsok/Sokoban.def | head -n23
--- /dev/fd/63
+++ share/games/xsok/Sokoban.def2019-01-05 12:10:54 +
@@ -1,3 +1,14 @@
+;WALLS
+12 f f ff 0 standard floor
+. 13 f f ff 4 target field
+#0 0 00 0 walls
+
+;OBJECTS
+@0 f 0101 2011 0 player
+$1 f 0100 02 1000 heavy box
+
+;MAXLEVEL 88
+;ATOP *$.
;LEVEL 1
#
# #
@@ -759,3 +770,521 @@ ;LEVEL 50
# ### ## #
# # ###
##
+;LEVEL 51
+#
--
FSF associate member #7257 http://am-1.org/~ivan/
Bug#737921: [TLS1.2] gnutls only likes SHA1 and SHA256 certificates
Ivan Shmakov i...@siamics.net writes: I’ve built the patched gnutls26 (now as of 2.12.20-8+deb7u2) package with pbuilder and briefly tested Exim (as of 4.80-7) with the resulting libgnutls26, and seen no issues so far. The resulting packages, both source (signed) and binary (along with signed .changes files) are available from the following location. (Should you decide to use these, /please take care/ to check .dsc and .changes signatures against my public key, and binary packages against the .changes files.) ⋯✂⋯ /etc/apt/sources.list.d/99-am-1.org-1gray-test.list ⋯✂⋯ […] Just noticed that I’ve made a silly mistake in my previous message; the correct (as in: s/-test/-misc/) sources.list.d/ file is as follows. ⋯✂⋯ /etc/apt/sources.list.d/99-am-1.org-1gray-misc.list ⋯✂⋯ deb http://am-1.org/~ivan/mini-dinstall/ 1gray-misc/$(ARCH)/ deb http://am-1.org/~ivan/mini-dinstall/ 1gray-misc/all/ deb-src http://am-1.org/~ivan/mini-dinstall/ 1gray-misc/source/ ⋯✂⋯ /etc/apt/sources.list.d/99-am-1.org-1gray-misc.list ⋯✂⋯ -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737921: [TLS1.2] gnutls only likes SHA1 and SHA256 certificates
I’ve built the patched gnutls26 (now as of 2.12.20-8+deb7u2)
package with pbuilder and briefly tested Exim (as of 4.80-7)
with the resulting libgnutls26, and seen no issues so far.
The resulting packages, both source (signed) and binary (along
with signed .changes files) are available from the following
location. (Should you decide to use these, /please take care/
to check .dsc and .changes signatures against my public key, and
binary packages against the .changes files.)
⋯✂⋯ /etc/apt/sources.list.d/99-am-1.org-1gray-test.list ⋯✂⋯
deb http://am-1.org/~ivan/mini-dinstall/ 1gray-test/$(ARCH)/
deb http://am-1.org/~ivan/mini-dinstall/ 1gray-test/all/
deb-src http://am-1.org/~ivan/mini-dinstall/ 1gray-test/source/
⋯✂⋯ /etc/apt/sources.list.d/99-am-1.org-1gray-test.list ⋯✂⋯
For the sake of completeness, the changes are also MIMEd.
--
FSF associate member #7257 http://boycottsystemd.org/
Public key fingerprint: 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
diff -dru -- a/debian/changelog b/debian/changelog
--- a/debian/changelog 2014-05-31 14:28:44.0 +
+++ b/debian/changelog 2014-07-29 18:48:51.0 +
@@ -1,3 +1,13 @@
+gnutls26 (2.12.20-8+deb7u2.0+is.2) 1gray-misc; urgency=medium
+
+ * 12_no_sign_algo.diff: adapted from 1a02ec18e9e3 by Nikos
+Mavrogiannopoulos. Closes: #737921, #740160
+ * 42_no-more-gets.diff: do not assume that gets () is declared
+by the libc; adapted from
+https://lists.gnu.org/archive/html/bug-gnulib/2012-03/msg00186.html
+
+ -- Ivan Shmakov i...@siamics.net Tue, 29 Jul 2014 18:48:51 +
+
gnutls26 (2.12.20-8+deb7u2) wheezy-security; urgency=high
* 39_Prevent-memory-corruption.diff from upstream GIT. Fix memory corruption
Only in b/debian/patches: 12_no_sign_algo.diff
Only in b/debian/patches: 42_no-more-gets.diff
diff -dru -- a/debian/patches/series b/debian/patches/series
--- a/debian/patches/series 2014-05-31 14:27:28.0 +
+++ b/debian/patches/series 2014-07-29 18:57:21.0 +
@@ -1,3 +1,4 @@
+12_no_sign_algo.diff
14_version_gettextcat.diff
16_unnecessarydep.diff
17_ignoretestsuitteerrors.diff
@@ -13,3 +14,4 @@
37_fix_rejection-of-v1-intermedi.diff
38_CVE-2014-0092.diff
39_Prevent-memory-corruption.diff
+42_no-more-gets.diff
This is an adaptation of the change made in 1a02ec18e9e3 and
subsequently amended (with regards to GNUTLS_CRT_OPENPGP.)
commit 6e4e6b0aa30acc8db68fcc19a9406abcfe44ae9c
Author: Nikos Mavrogiannopoulos n...@gnutls.org
Date: Thu Apr 21 00:21:56 2011 +0200
commit 1a02ec18e9e39f82cee7f9cff74e1f1574bac472
Author: Nikos Mavrogiannopoulos n...@gnutls.org
Date: Wed Apr 20 19:45:20 2011 +0200
Eliminated the need for sign_algo in gnutls_pcert_st. This means
that we don't follow RFC5246 by letter, but there wasn't any other
implementation using the sign_algorithm part of the certificate
selection, and this helps reduce complexity.
diff --git a/lib/auth/cert.c b/lib/auth/cert.c
index 275e9bf..39cf8ed 100644
--- a/lib/auth_cert.c
+++ b/lib/auth_cert.c
@@ -,29 +,18 @@ _gnutls_proc_x509_server_certificate (gnutls_session_t session,
if ((ret =
_gnutls_x509_raw_cert_to_gcert (peer_certificate_list
[j], tmp,
CERT_ONLY_EXTENSIONS)) 0)
{
gnutls_assert ();
goto cleanup;
}
- /* check if signature algorithm is supported */
- ret =
-_gnutls_session_sign_algo_enabled (session,
- peer_certificate_list
- [j].sign_algo);
- if (ret 0)
-{
- gnutls_assert ();
- goto cleanup;
-}
-
p += len;
}
if ((ret =
_gnutls_copy_certificate_auth_info (info,
peer_certificate_list,
peer_certificate_list_size)) 0)
{
@@ -2092,26 +2081,18 @@ _gnutls_server_select_cert (gnutls_session_t session,
*/
if (requested_algo == GNUTLS_PK_ANY ||
requested_algo == cred-cert_list[i][0].subject_pk_algorithm)
{
/* if cert type and signature algorithm matches
*/
/* *INDENT-OFF* */
if (session-security_parameters.cert_type
- == cred-cert_list[i][0].cert_type
- (cred-cert_list[i][0].cert_type == GNUTLS_CRT_OPENPGP
- || /* FIXME: make this a check for certificate
- type capabilities */
- !_gnutls_version_has_selectable_sighash
- (gnutls_protocol_get_version (session))
- ||
- _gnutls_session_sign_algo_requested
- (session, cred-cert_list[i][0].sign_algo) == 0))
+ == cred-cert_list[i][0].cert_type)
{
idx = i;
break;
}
/* *INDENT-ON* */
}
}
/* store the certificate pointer
Bug#614948: rt-mailgate(1) doesn't support IPv6, too
One more program that is affected by this bug is rt-mailgate from rt3.8-clients: # echo test \ | (cd / su www-data -c '/usr/bin/rt-mailgate \ --debug --action=correspond \ --queue=General \ --url=https://ipv6.google.com/rt/;') /usr/bin/rt-mailgate: temp file is '/tmp/1q919srzpU' /usr/bin/rt-mailgate: connecting to https://ipv6.google.com/rt//REST/1.0/NoAuth/mail-gateway An Error Occurred = 500 Can't connect to ipv6.google.com:443 (Bad hostname 'ipv6.google.com') /usr/bin/rt-mailgate: undefined server error # A similar error is signalled should https://[::1]/rt/ (i. e., ip6-localhost) be used for an URI. Strangely enough, https://ip6-localhost/rt/ works, yet Apache's access.log shows that rt-mailgate(1) connects over IPv4 instead of IPv6. -- FSF associate member #7257 pgpzyN8lGBlfP.pgp Description: PGP signature
Bug#544567: current state of IPv6 support in Debian
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.ipv6 as well. IS == Ivan Shmakov oneing...@gmail.com writes: [...] IS portmap -- lacks IPv6 support, necessary for NFS over IPv6 to work IS (Bug#515128); Well, a trivial change (below) has seemingly made rpcbind installable and Bug#544567 be worked-around. But I still have no clue what should be the proper fix? [...] diff -u rpcbind-0.2.0/debian/rules rpcbind-0.2.0/debian/rules --- rpcbind-0.2.0/debian/rules +++ rpcbind-0.2.0/debian/rules @@ -51,6 +51,8 @@ # Add here commands to install the package into debian/rpcbind. $(MAKE) DESTDIR=$(CURDIR)/debian/rpcbind install + mv -- debian/rpcbind/usr/bin/rpcinfo \ + debian/rpcbind/usr/bin/rpcinfo.rpcbind # Build architecture-independent files here. @@ -79,6 +81,8 @@ dh_link dh_strip dh_compress + mv -- debian/rpcbind/usr/share/man/man8/rpcinfo.8.gz \ + debian/rpcbind/usr/share/man/man8/rpcinfo.rpcbind.8.gz dh_fixperms # dh_perl # dh_makeshlibs diff -u rpcbind-0.2.0/debian/changelog rpcbind-0.2.0/debian/changelog --- rpcbind-0.2.0/debian/changelog +++ rpcbind-0.2.0/debian/changelog @@ -1,3 +1,21 @@ +rpcbind (0.2.0-1.is+0.3) unstable; urgency=low + + * Fixed one more time. + + -- Ivan Shmakov i...@main.uusia.org Sat, 19 Sep 2009 13:45:05 +0700 + +rpcbind (0.2.0-1.is+0.2) unstable; urgency=low + + * Renamed rpcinfo.8, too. + + -- Ivan Shmakov i...@main.uusia.org Sat, 19 Sep 2009 13:42:30 +0700 + +rpcbind (0.2.0-1.is+0.1) unstable; urgency=low + + * Renamed rpcinfo to rpcinfo.rpcbind (closes: #544567) + + -- Ivan Shmakov i...@main.uusia.org Sat, 19 Sep 2009 11:13:49 +0700 + rpcbind (0.2.0-1) unstable; urgency=low * Initial release -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545270: SDreaddata () fails on an amd64 system
Package: libhdf4g
Version: 4.1r4-22
Severity: grave
[Hopefully not a false positive.]
Apparently, SDreaddata () is broken on amd64. Consider, e. g.:
$ ncdump-hdf -h \
e4ftl01u.ecs.nasa.gov/MODIS_Composites/MOTA/MCD43B3.005/2006.08.29/MCD43B3.A2006241.h23v03.005.2008108002817.hdf
| head
netcdf MCD43B3.A2006241.h23v03.005.2008108002817 {
dimensions:
YDim_MOD_Grid_BRDF = 1200 ;
XDim_MOD_Grid_BRDF = 1200 ;
variables:
short Albedo_BSA_Band1(YDim_MOD_Grid_BRDF, XDim_MOD_Grid_BRDF) ;
Albedo_BSA_Band1:long_name = Albedo_BSA_Band1 ;
Albedo_BSA_Band1:units = albedo, no units ;
Albedo_BSA_Band1:valid_range = 0s, 32766s ;
$ hdp dumpsds -d \
-n Albedo_BSA_Band1 \
e4ftl01u.ecs.nasa.gov/MODIS_Composites/MOTA/MCD43B3.005/2006.08.29/MCD43B3.A2006241.h23v03.005.2008108002817.hdf
HDP ERROR in sdsdumpfull: SDreaddata failed for sds_id(262144).
HDP ERROR in printSD_ASCII: sdsdumpfull failed for 0'th SDS.
HDP ERROR in dsd: printSD_ASCII failed for file
e4ftl01u.ecs.nasa.gov/MODIS_Composites/MOTA/MCD43B3.005/2006.08.29/MCD43B3.A2006241.h23v03.005.2008108002817.hdf
$
It looks like that the ncvarget () interface still works:
$ hdfdump -T \
e4ftl01u.ecs.nasa.gov/MODIS_Composites/MOTA/MCD43B3.005/2006.08.29/MCD43B3.A2006241.h23v03.005.2008108002817.hdf
\
Albedo_BSA_Band1 | head
0.062
0.06
0.057
0.059
0.056
0.052
0.051
0.05
0.05
0.054
$
The file used in the example could be downloaded (24.9 MiB)
using anonymous FTP, like:
$ wget
ftp://e4ftl01u.ecs.nasa.gov/MODIS_Composites/MOTA/MCD43B3.005/2006.08.29/MCD43B3.A2006241.h23v03.005.2008108002817.hdf
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545270: SDreaddata () fails on an amd64 system
Upgrading to the version currently in Debian Lenny (4.2r4-5) seems to resolve the problem. Thanks. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
