Bug#938940: queries for CNAME do not work as specified in RFC1034 3.6.2
Package: unbound Version: 1.9.0-2 Severity: normal Hi, when I do a "normal" A query unbound correctly follows a CNAME chain. I.e.: $ dig @unbound a sip.k-p.at ; <<>> DiG 9.10.3-P4-Debian <<>> @unbound a sip.k-p.at ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48071 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;sip.k-p.at.IN A ;; ANSWER SECTION: sip.k-p.at. 86328 IN CNAME sipdir.online.lync.com. sipdir.online.lync.com. 30 IN A 52.112.192.139 ;; Query time: 17 msec ;; SERVER: ... ;; WHEN: Fri Aug 30 13:31:04 CEST 2019 ;; MSG SIZE rcvd: 102 On the other hand, if I do a CNAME query on the same name, unbound will ALSO follow the chain, which seems to go against RFC1034. Quoting from https://tools.ietf.org/rfcmarkup?doc=1034#section-3.6.2 If so, the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. The one exception to this rule is that queries which match the CNAME type are not restarted. This usually results in a NOERROR answer: $ dig @unbound cname sip.k-p.at ; <<>> DiG 9.10.3-P4-Debian <<>> @unbound cname sip.k-p.at ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7817 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;sip.k-p.at.IN CNAME ;; AUTHORITY SECTION: online.lync.com.900 IN SOA admin.nsatc.net. dns.level3.net. 1567104145 10800 2700 360 900 ;; Query time: 827 msec ;; SERVER: ... ;; WHEN: Fri Aug 30 14:34:28 CEST 2019 ;; MSG SIZE rcvd: 108 I would expect something like the following (querying a microsoft DNS server, which often, not always, works): $ dig @msdns cname sip.k-p.at ; <<>> DiG 9.10.3-P4-Debian <<>> @msdns cname sip.k-p.at ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44931 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;sip.k-p.at.IN CNAME ;; ANSWER SECTION: sip.k-p.at. 21159 IN CNAME sipdir.online.lync.com. ;; ADDITIONAL SECTION: sipdir.online.lync.com. 30 IN A 52.112.192.75 sipdir.online.lync.com. 29 IN 2603:1027:0:9::b ;; Query time: 775 msec ;; SERVER: ... ;; WHEN: Fri Aug 30 14:43:00 CEST 2019 ;; MSG SIZE rcvd: 119 Thank you for your consideration, -- Robert BihlmeyerASSIST Arrow ECS Internet Security AG A-1100 Wien, Wienerbergstraße 11 Tel: +43 1 370 94 40 Fax: +43 1 370 94 40-333
Bug#921721: broken "Homepage" link
Package: open-infrastructure-apache-tools Version: 20170701-3 Severity: minor The package links to https://open-infrastructure.net/software/service-tools which 404s. I think it wants to linke to https://open-infrastructure.net/software/apache-icons/ instead.
Bug#898155: dead Homepage link
Source: pyacidobasic Version: 2.8-1 Severity: minor The given homepage URL http://outilsphysiques.tuxfamily.org/pmwiki.php/Oppl/Pyacidobasic is non-functional. http://outilsphysiques.tuxfamily.org/wiki/index.php?title=Pyacidobasic seems to work, although pretty bare-bones and only(?) available in French. br, Robert
Bug#858885: tests fail with libcmocka-dev 0.4.1-2
Source: socket-wrapper
Version: 1.1.7-1
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
Preparing a backport of libsocket-wrapper to stable, I noticed that it
won't build with the stated build-dependency of libcmocka-dev
0.4.1. The last lines of the build attempt follow:
/usr/bin/cmake -E cmake_progress_report
.../socket-wrapper-1.1.7/obj/CMakeFiles 3
[ 22%] Building C object
tests/CMakeFiles/test_echo_tcp_bind.dir/test_echo_tcp_bind.c.o
cd .../socket-wrapper-1.1.7/obj/tests && /usr/bin/cc -g -O2
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
-std=gnu99 -Wall -Wextra -Wshadow -Wmissing-prototypes
-Wdeclaration-after-statement -Wunused -Wfloat-equal -Wpointer-arith
-Wwrite-strings -Wformat-security -Wmissing-format-attribute -Wcast-align
-Wcast-qual -Wno-missing-field-initializers -Werror=pointer-arith
-Werror=declaration-after-statement -Werror=implicit-function-declaration
-Werror=write-strings -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast
-fstrict-aliasing -Wstrict-aliasing=2 -fstrict-overflow -Wstrict-overflow=5
-Werror=strict-overflow -D_GNU_SOURCE -fPIC -fstack-protector
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.../socket-wrapper-1.1.7/obj/tests
-I.../socket-wrapper-1.1.7/tests -I.../socket-wrapper-1.1.7/obj
-I.../socket-wrapper-1.1.7/src-o
CMakeFiles/test_echo_tcp_bind.dir/test_echo_tcp_bind.c.o -c
.../socket-wrapper-1.1.7/tests/test_echo_tcp_bind.c
.../socket-wrapper-1.1.7/tests/test_echo_tcp_bind.c: In function ‘main’:
.../socket-wrapper-1.1.7/tests/test_echo_tcp_bind.c:501:26: error: array type
has incomplete element type
const struct CMUnitTest tcp_bind_tests[] = {
^
.../socket-wrapper-1.1.7/tests/test_echo_tcp_bind.c:502:3: error: implicit
declaration of function ‘cmocka_unit_test_setup_teardown’
[-Werror=implicit-function-declaration]
cmocka_unit_test_setup_teardown(test_bind_ipv4,
^
.../socket-wrapper-1.1.7/tests/test_echo_tcp_bind.c:533:2: error: implicit
declaration of function ‘cmocka_run_group_tests’
[-Werror=implicit-function-declaration]
rc = cmocka_run_group_tests(tcp_bind_tests, NULL, NULL);
^
.../socket-wrapper-1.1.7/tests/test_echo_tcp_bind.c:501:26: warning: unused
variable ‘tcp_bind_tests’ [-Wunused-variable]
const struct CMUnitTest tcp_bind_tests[] = {
^
cc1: some warnings being treated as errors
tests/CMakeFiles/test_echo_tcp_bind.dir/build.make:57: recipe for target
'tests/CMakeFiles/test_echo_tcp_bind.dir/test_echo_tcp_bind.c.o' failed
make[3]: *** [tests/CMakeFiles/test_echo_tcp_bind.dir/test_echo_tcp_bind.c.o]
Error 1
Installing libcmocka-dev 1.0.1-2~bpo8+1 fixed the issue so I propose the
attached patch.
--- socket-wrapper-1.1.7/debian/control~ 2016-05-24 22:27:10.0 +0200
+++ socket-wrapper-1.1.7/debian/control 2017-03-28 10:12:35.314128801 +0200
@@ -7,7 +7,7 @@
debhelper (>= 9),
dh-buildinfo,
cmake (>= 2.8.8-3~),
- libcmocka-dev (>= 0.4.1),
+ libcmocka-dev (>= 1.0.1),
asciidoc, libxml2-utils, xsltproc, docbook-xml, docbook-xsl
XS-Testsuite: autopkgtest
Standards-Version: 3.9.8
Bug#855284: please improve the description
Source: autobahn-cpp Version: 0.2.1-1 Severity: wishlist Someone who knows nothing of Autobahn has a hard time understanding what it actually is from the description of these packages. The WAMP acronym is never expanded or explained. I do not know at all what you want to convey with the "Caller", "Callee", ... bullet list. Here's my stab at a long description, based on text from http://autobahn.ws: Autobahn|Cpp provides an implementation of the WebSocket and Web Application Messaging (WAMP) protocols. WebSocket allows bidirectional real-time messaging on the Web and WAMP adds asynchronous Remote Procedure Calls and Publish & Subscribe on top of WebSocket. Autobahn|Cpp is open-source, licensed under the Boost Software License. The API and implementation make use of modern C++ 11 and new asynchronous idioms using (upcoming) features of the standard C++ library, in particular Futures, Continuations and Lambdas.
Bug#855271: misclassified in devel?
Package: sia Version: 1.0.3-1 Severity: minor >From its description, it does not seem like the package belongs in the devel >section.
Bug#851152: undeclared dependency on python-routes >= 2.2
Source: keystone
Version: 2:9.0.0-2~bpo8+1
Severity: serious
Tags: patch
If an older version of python-routes is installed, keystone will not come up.
/var/log/keystone/keystone.log contains:
ERROR keystone ContextualVersionConflict: (Routes 2.0
(/usr/lib/python2.7/dist-packages),
Requirement.parse('Routes!=2.0,!=2.1,>=1.12.3'), set(['keystone']))
Installing python-routes 2.2 fixes it.
I experienced this bug in the backports version, but as of 10.0.0-5
the dependency on python-routes is still unversioned, so I strongly
suspect this version (in testing as I write this) is affected as well.
The attached patch makes the dependency versioned for
python-keystone. It also tags a version onto the build-dependency for
good measure, although I have not tested whether building with an
older python-routes would maybe work. Feel free to ignore this part
(the first hunk) of the patch.
diff -ru keystone-10.0.0/debian/control keystone-10.0.0+/debian/control
--- keystone-10.0.0/debian/control 2016-12-18 11:52:15.0 +0100
+++ keystone-10.0.0+/debian/control 2017-01-12 14:16:26.591877456 +0100
@@ -61,7 +61,7 @@
python-pysaml2 (>= 3.0.0),
python-pysqlite2,
python-requests (>= 2.10.0),
- python-routes,
+ python-routes (>= 2.2),
python-six (>= 1.9.0),
python-sqlalchemy (>= 1.0.10),
python-stevedore (>= 1.16.0),
@@ -124,7 +124,7 @@
python-pymysql,
python-pysaml2 (>= 3.0.0),
python-pysqlite2,
- python-routes,
+ python-routes (>= 2.2),
python-six (>= 1.9.0),
python-sqlalchemy (>= 1.0.10),
python-stevedore (>= 1.16.0),
Bug#837766: wrapped list in long description
Source: haskell-relational-schemas Version: 0.1.3.1-1 Severity: minor Tags: patch The list in the long description comes out garbled due to wrapping. The attached patch /should/ fix this, but is untested. diff -ru haskell-relational-schemas-0.1.3.1/debian/control haskell-relational-schemas-0.1.3.1+/debian/control --- haskell-relational-schemas-0.1.3.1/debian/control 2016-09-08 20:18:07.0 +0200 +++ haskell-relational-schemas-0.1.3.1+/debian/control 2016-09-14 13:26:42.426715063 +0200 @@ -22,12 +22,12 @@ X-Description: RDBMSs' schema templates for relational-query This package contains some RDBMSs' schema structure definitions. Supported RDBMS schemas are below: - + IBM DB2 - + PostgreSQL - + Microsoft SQLServer - + SQLite3 - + Oracle - + MySQL + + IBM DB2 + + PostgreSQL + + Microsoft SQLServer + + SQLite3 + + Oracle + + MySQL Package: libghc-relational-schemas-dev Architecture: any
Bug#836267: typo "reasing" in short description
Package: libzmf-dev Version: 0.0.0-2 Severity: minor Hi Rene, this seems to affect all libzmf* packages. Maybe just s/reasing/reading/ throghout debian/control... br, Robbe
Bug#811676: FTBFS with GCC 6: could not convert a from x to y
Package: fbreader
Followup-For: Bug #811676
Looks legit. Simple fix attached.
diff -ru fbreader-0.12.10dfsg2/fbreader/src/database/booksdb/BooksDB.cpp fbreader-0.12.10dfsg2+/fbreader/src/database/booksdb/BooksDB.cpp
--- fbreader-0.12.10dfsg2/fbreader/src/database/booksdb/BooksDB.cpp 2010-04-01 15:14:24.0 +0200
+++ fbreader-0.12.10dfsg2+/fbreader/src/database/booksdb/BooksDB.cpp 2016-07-01 13:24:36.919070856 +0200
@@ -145,7 +145,7 @@
myFindFileId->setFileName(fileName);
if (!myFindFileId->run()) {
- return false;
+ return 0;
}
((DBIntValue&)*myLoadBook->parameter("@file_id").value()) = myFindFileId->fileId();
shared_ptr reader = myLoadBook->executeReader();
Bug#812013: goffice-0.8: FTBFS with GCC 6: format not a string literal
Source: goffice-0.8
Followup-For: Bug #812013
For the go_format_odf_style_map() issue, the fix is simply to make the format
string
itself constant. Patch attached.
I can't see a way to make g_object_set_property()'s error_template parameter
safe, except
by sanity-checking in the function itself. One would probably have to turn the
warning
off for this file...
diff -ru goffice-0.8-0.8.17/goffice/utils/go-format.c goffice-0.8-0.8.17+/goffice/utils/go-format.c
--- goffice-0.8-0.8.17/goffice/utils/go-format.c 2011-06-17 00:46:51.0 +0200
+++ goffice-0.8-0.8.17+/goffice/utils/go-format.c 2016-07-01 10:50:12.072984065 +0200
@@ -5537,7 +5537,7 @@
char *
go_format_odf_style_map (GOFormat const *fmt, int cond_part)
{
- char const *format_string = NULL;
+ char const *op = NULL;
g_return_val_if_fail (fmt != NULL, NULL);
g_return_val_if_fail (fmt->typ == GO_FMT_COND, NULL);
@@ -5547,29 +5547,29 @@
switch (fmt->u.cond.conditions[cond_part].op) {
case GO_FMT_COND_EQ:
- format_string = "value()=%g";
+ op = "=";
break;
case GO_FMT_COND_NE:
- format_string = "value()!=%g";
+ op = "!=";
break;
case GO_FMT_COND_NONTEXT: /* Under certain circumstances this */
/*appears for second of two conditions */
case GO_FMT_COND_LT:
- format_string = "value()<%g";
+ op = "<";
break;
case GO_FMT_COND_LE:
- format_string = "value()<=%g";
+ op = "<=";
break;
case GO_FMT_COND_GT:
- format_string = "value()>%g";
+ op = ">";
break;
case GO_FMT_COND_GE:
- format_string = "value()>=%g";
+ op = ">=";
break;
default:
return NULL;
}
- return g_strdup_printf (format_string,
+ return g_strdup_printf ("value()%s%g", op,
fmt->u.cond.conditions[cond_part].val);
}
Bug#811595: FTBFS with GCC 6: statement indented as if it were guarded by
Package: upx-ucl Followup-For: Bug #811595 Note: I’ve opened bug#829168 for one lzma issue reported here.
Bug#829168: misleading indentation in LzmaEnc.c:1350
Package: lzma-dev Version: 9.22-2 Severity: normal https://sources.debian.net/src/lzma/9.22-2/C/LzmaEnc.c/#L1346 Line 1350 is on the same indentation level as line 1347, which is semantically wrong. Even if line 1349 were not commented out, the style used by this file would place the opening brace at the same level of the if statement. This minor style issue makes problems for projects including LzmaEnc.c that want to compile with -Werror=misleading-indentation for their own sake. Please consider cleaning it up.
Bug#811576: patch
Package: tpm-tools Followup-For: Bug #811576 The indentation is wrong. Attaching a patch, if reportbug allows me to do it. diff -ru tpm-tools-1.3.8/src/tpm_mgmt/tpm_present.c tpm-tools-1.3.8+/src/tpm_mgmt/tpm_present.c --- tpm-tools-1.3.8/src/tpm_mgmt/tpm_present.c 2016-07-01 08:24:21.0 +0200 +++ tpm-tools-1.3.8+/src/tpm_mgmt/tpm_present.c 2016-07-01 08:23:48.149277316 +0200 @@ -357,5 +357,5 @@ out: if (szTpmPasswd && !isWellKnown) shredPasswd( szTpmPasswd ); - return iRc; +return iRc; }
Bug#823309: missing dependency on python-networkx
Package: androguard Version: 2.0-1 Severity: serious $ apkviewer foo.apk Traceback (most recent call last): File "/usr/bin/apkviewer", line 25, in from androguard.core.data import data File "/usr/lib/python2.7/dist-packages/androguard/core/data/data.py", line 18, in from networkx import DiGraph ImportError: No module named networkx Installing python-networkx fixes it. -- System Information: Versions of packages androguard depends on: ii ipython 2.3.0-2 ii libbz2-1.01.0.6-7+b3 ii libc6 2.19-18+deb8u4 ii libgcc1 1:4.9.2-10 ii liblzma5 5.1.1alpha+20120614-2+b3 ii libmuparser2 2.2.3-4 ii libsnappy11.1.2-3 ii libstdc++64.9.2-10 ii zlib1g1:1.2.8.dfsg-2+b1 androguard recommends no packages. Versions of packages androguard suggests: pn python-pyside.qtcore pn python-pyside.qtgui
Bug#803259: support for deprecated openssl features
Package: testssl.sh Version: 2.6+dfsg1-2 Severity: wishlist Debian's standard openssl installation does not provide every (mis)feature. This results in some things not being testable by testssl.sh. Example snippet: 56 Bit encryptionLocal problem: No 56 Bit encryption configured in /usr/bin/openssl Upstream offers statically linked openssl binaries for this. I'm not sure what an appropriate solution for Debian is. Maybe the openssl maintainers could be persuaded to build a openssl-insecure package from their source.
Bug#802488: improve descriptions of programming-language sections
Package: ftp.debian.org Severity: normal https://packages.debian.org/unstable/ seems to be the canonical list of sections and their descriptions. I assume this is under the purview of ftp-masters. If not, please re-assign. Most programming-language specific sections have a description of the form Everything about . This doesn't tell me much. To be specific, the packages being put into, say "python", seem to fall into two broad categories: 1. programs written in python: e.g. agtl, custodia, mat, openstack-dashboard 2. programs and libraries useful to people developing in python: e.g. cython, pypy, python-*, twistedchecker My personal opinion is that there is no point putting class 1 into "python". If you agree, the description should probably reflect that. Suggestion: Development tools and libraries useful to people developing in I was also pondering "... useful to developers" but this could be mis-read as people developing the language itself.
Bug#781326: please link to reproducible.d.n/$suite/$arch/$srcpkg
Package: tracker.debian.org Followup-For: Bug #781326 Hi Mattia, Uwe is correct that the tracker links to a broken URL (without .html). Not on the main package page, but from the action-item. Example that currently works: On https://tracker.debian.org/pkg/tex4ht a link goes to https://reproducible.debian.net/rb-pkg/tex4ht.html ... correct, but not optimal, as is the main thrust of this bug. Clicking on the question mark takes you to https://tracker.debian.org/action-items/223917 where "identified" links to the broken https://reproducible.debian.net/rb-pkg/tex4ht
Bug#795276: outdated homepage in package descriptions
Source: openni2 Version: 2.2.0.33+dfsg-1 Severity: minor The homepage link in all your package descriptions points to www.openni.org, which seems to be the home of the original OpenNI (not the forked version 2) and just redirects to Apple's main page. http://structure.io/openni seems a better alternative.
Bug#794630: kernel version detection broken with changes in jessie's linux-image-* packages
Package: apt-dater
Version: 0.9.0-8
Severity: normal
Tags: patch
apt-dater-host tries to find out in do_kernel() whether the running kernel is
(a) Debian's or custom, and
(b) current or obsoleted by a newer installed version.
Both checks no longer work correctly after I updated my servers to jessie, due
to slight
changes in its linux-image-* packages.
The effect is that every machine is detected as running a custom kernel.
This patch solves problem (a)
--- /usr/bin/apt-dater-host~
+++ /usr/bin/apt-dater-host
@@ -368,7 +368,7 @@
else {
my $vstr = `cat $verfile`;
unless($vstr =~ /^\S+ \S+ \S+ \(Debian ([^\)]+)\)/ ||
- $vstr =~ /^\S+ \S+ \S+ \(debian-kernel\@lists\.debian\.org\) .+
Debian (\S+)$/) {
+ $vstr =~ /^\S+ \S+ \S+ \(debian-kernel\@lists\.debian\.org\) .+
Debian (\S+)(?: \(\d{4}-\d\d-\d\d\))?$/) {
print $infostr 2 $version\n;
return;
}
But then I ran into problem (b) which I solved like this:
--- /usr/bin/apt-dater-host~
+++ /usr/bin/apt-dater-host
@@ -376,12 +376,12 @@
}
my $reboot = 0;
-unless(open(HDPKG, dpkg-query -W -f='\${Version} \${Status;20}
\${Maintainer} \${Provides}\n' 'linux-image*'|grep -E 'install ok installed
(Debian|Ubuntu) Kernel Team'|grep linux-image|)) {
+unless(open(HDPKG, dpkg-query -W -f='\${Version} \${Status;20}
\${Maintainer} \${Provides}\n' 'linux-image*'|)) {
print $infostr 9 $version\n;
return;
}
while(HDPKG) {
- next unless (/^(\S+)\s/);
+ next unless (/^(\S+) install ok installed (?:Debian|Ubuntu) Kernel Team
.*? (?:linux-image|linux-modules-)/);
$reboot=1 unless (system(dpkg, --compare-versions, $vers, lt, $1)
8);
}
Please consider fixing this bug in an update to jessie!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772423: O: haskell-doc -- Assorted Haskell language documentation
Hi, please summarise or give a pointer to the discussion. br, -- Robert BihlmeyerASSISTArrow ECS Internet Security AG -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773197: origami package replaced by a completely different package
Package: origami Version: 1.2.7-1 Severity: serious https://packages.debian.org/jessie/origami and https://packages.debian.org/sid/origami are totally different. I assume this is a slip-up by the uploader of the sid version, which should get a new name. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770327: non-root induced DoS via /proc/brcm_monitor0
Package: broadcom-sta-dkms Version: 6.30.223.248-2 Severity: critical Tags: security upstream The wl module creates /proc/brcm_monitorN for each applicable device. At least with linux-image-3.16-0.bpo.2-amd64, reading from this file reliably sends my box into la-la land (symptoms are that CPU#2 is reported as stuck, and almost any process hangs). The file is mode 644, so this is possible for any local user. I noted this with monotone, which tries to trawl /proc files in a (arguably mistaken) attempt to gather randomness. monotone offers a network service, which may be affected. I can try reproduction with different kernels if it helps. What the file actually does is opaque to me. An easy fix would be to remove world readability in lines 3305 and 3308 of src/wl/sys/wl_linux.c -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767327: b.d.o: wrong package links in reassigned message
Package: bugs.debian.org the Bug reassigned from package 'foo' to 'bar'. message uses a defective href of https://bugs.debian.org/cgi-bin/%3Ca%20href=%22pkgreport.cgi?package=foo%22%3Efoo%3C/a%3E for the foo link. Looks like one sprinkling too many of magick HTML dust. Live example here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554538#6 I don't think XSS is possible, though. br, -- Robert Bihlmeyer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763885: isrcsubmit: documenting the Recommends
Package: isrcsubmit Version: 2.0.0-1 Severity: wishlist Hi, maybe add the following to the package description: If python3-keyring is installed, isrcsubmit uses it to cache your MusicBrainz password, so you don't have to enter it on every invocation. I like Recommends Suggests to have some blurb attached, so I can decide for/against installing the package referenced. For example, I still don't know if or how good isrcsubmit works without cdrdao. br, -- Robbe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751773: torbrowser-launcher: spurious (runtime) dependency on debhelper
Package: torbrowser-launcher Version: 0.0.7-1 Severity: normal Hi Jake, unless torbrowser-launcher actually builds a deb from the downloaded torbrowser, I can't see it needing debhelper during runtime. So I suggest removing it from the Depends: line. Build-Depend'ing on debhelper is enough except in curious cases. FWIW, could you loosen the build-dependency to debhelper (= 9)? Looks like you don't use features newer than that, and just depending on version 9 would make backporting a bit more straight-forward. br, -- Robert BihlmeyerASSISTArrow ECS Internet Security AG -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751087: whatmaps will break apt if it is removed but not purged
Package: whatmaps Version: 0.0.6-2 Severity: grave /etc/apt/apt.conf.d/50whatmaps_apt's Pre-Install-Pkgs command does not check whether whatmaps is actually installed. In the case of whatmaps being removed but not purged its failing will prevent apt from installing any package. (I actually noticed the bug in the bpo version. As far as I can see from inspecting the source, the bug still exists in 0.0.6-2) -- Robert BihlmeyerASSISTArrow ECS Internet Security AG -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751088: whatmaps binary is only for root
Package: whatmaps Version: 0.0.6-2 Severity: minor Runnning whatmaps as non-root will only give an unhelpful permission error. It would be nice if whatmaps could give a more meaningful diagnostic. Regardless of the error, I think sbin is a more appropriate place for whatmaps. (I actually noticed the bug in the bpo version. As far as I can see from scanning the changelog, the bug still exists in 0.0.6-2) -- Robert BihlmeyerASSISTArrow ECS Internet Security AG -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748125: System.Posix.Directory.readDirStream can return strings that S.P.Files.getFileStatus cannot use
Hi, Joachim Breitner nome...@debian.org writes: Am Mittwoch, den 14.05.2014, 17:00 +0200 schrieb Robert Bihlmeyer: I don't think running a program with LC_CTYPE=*.UTF-8 means that all filenames that it encounters have to be valid UTF-8. the problem is: What else should they be? The String type represents unicode characters, so using that for a file name requires them to be decoded somehow. I agree, there is no straight-forward solution. Interestingly, most of the invalid UTF-8 I tried survived the roundtrip through String. What doesn't work in these cases is outputting this String -- but I wouldn't expect it to. But getFileStatus accepts the String and stats the right file (can be proven with strace -fe stat for example). Up to now I found exactly one class of byte sequences that do not work: illegal (sub-optimal) encodings of ASCII characters. The attached tar contains a filename with the two bytes C0 and B7 followed by '.txt'. C0B7 is an invalid encoding of 37 i.e. '7'. It looks like GHC accepts the invalid encoding and stores the result as the normal character '7'. The error points in this direction: dirtest.hs: 7.txt: getFileStatus: does not exist (No such file or directory) Contrary to that, a sub-optimal encoding of 'ö' (U+00F6) as E0 83 B6 works fine, as do the numerous other illegal combinations of high-bit-set characters I tried. So my assumption is that there is special casing if the result of UTF-8 decoding is an ASCII character. I guess the solution, which you have found already, for uses where arbitrary filenames need to work is to use a type that is meant for that, i.e. ByteString. Maybe deprecating the interfaces that assume UTF-8 clean filenames is the solution. One (unfortunately) still can't assume that all the world is UTF-8. But most illegal sequences are round-trippable -- e.g. the E0 83 B6 from above is not re-encoded/corrected to C3 B6. Therefore, my question is whether the ASCII special case could be removed. br, -- Robert BihlmeyerASSISTArrow ECS Internet Security AG r.bihlme...@arrowecs.at A-1100 Wien, Wienerbergstraße 11 Tel: +43 1 370 94 40Fax: +43 1 370 94 40-333 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748125: System.Posix.Directory.readDirStream can return strings that S.P.Files.getFileStatus cannot use
Package: ghc Version: 7.4.1-4 Severity: normal If the LANG/LC_ environment specifies an UTF-8 locale the following program getFileStatus will sometimes fail with ENOENT. In my tests this is the case for some (not all) filenames containing invalid UTF-8 Attached is a simple tar containing files with an all-ASCII name, an UTF-8 name (both work) and a GB2312 name exhibiting the problem. I don't think running a program with LC_CTYPE=*.UTF-8 means that all filenames that it encounters have to be valid UTF-8. import System.Posix.Directory import System.Posix.Files isNull = null makeString x = x concat' = concat putStrLn' = putStrLn scanDir :: DirStream - IO () scanDir dir = do entry - readDirStream dir if isNull entry then return () else do stat - getFileStatus entry putStrLn' $ concat' [makeString (if isDirectory stat then dir: else file: ), entry] scanDir dir main = do changeWorkingDirectory $ makeString /tmp/dirtest dir - openDirStream $ makeString . scanDir dir closeDirStream dir Changing the program to use the ByteString variants (example below) works as no conversion is ever done. import qualified Data.Char import qualified Data.ByteString import qualified Data.ByteString.Char8 import System.Posix.Directory.ByteString import System.Posix.Files.ByteString isNull = Data.ByteString.null makeString x = Data.ByteString.pack $ map (toEnum . fromEnum) x concat' = Data.ByteString.concat putStrLn' = Data.ByteString.Char8.putStrLn scanDir :: DirStream - IO () scanDir dir = do entry - readDirStream dir if isNull entry then return () else do stat - getFileStatus entry putStrLn' $ concat' [makeString (if isDirectory stat then dir: else file: ), entry] scanDir dir main = do changeWorkingDirectory $ makeString /tmp/dirtest dir - openDirStream $ makeString . scanDir dir closeDirStream dir dirtest.tar Description: Unix tar archive Regards, -- Robert BihlmeyerASSISTArrow ECS Internet Security AG
Bug#748126: System.Posix.Directory.readDirStream can return strings that S.P.Files.getFileStatus cannot use
Package: ghc Version: 7.4.1-4 Severity: normal If the LANG/LC_ environment specifies an UTF-8 locale the following program getFileStatus will sometimes fail with ENOENT. In my tests this is the case for some (not all) filenames containing invalid UTF-8 Attached is a simple tar containing files with an all-ASCII name, an UTF-8 name (both work) and a GB2312 name exhibiting the problem. I don't think running a program with LC_CTYPE=*.UTF-8 means that all filenames that it encounters have to be valid UTF-8. import System.Posix.Directory import System.Posix.Files isNull = null makeString x = x concat' = concat putStrLn' = putStrLn scanDir :: DirStream - IO () scanDir dir = do entry - readDirStream dir if isNull entry then return () else do stat - getFileStatus entry putStrLn' $ concat' [makeString (if isDirectory stat then dir: else file: ), entry] scanDir dir main = do changeWorkingDirectory $ makeString /tmp/dirtest dir - openDirStream $ makeString . scanDir dir closeDirStream dir Changing the program to use the ByteString variants (example below) works as no conversion is ever done. import qualified Data.Char import qualified Data.ByteString import qualified Data.ByteString.Char8 import System.Posix.Directory.ByteString import System.Posix.Files.ByteString isNull = Data.ByteString.null makeString x = Data.ByteString.pack $ map (toEnum . fromEnum) x concat' = Data.ByteString.concat putStrLn' = Data.ByteString.Char8.putStrLn scanDir :: DirStream - IO () scanDir dir = do entry - readDirStream dir if isNull entry then return () else do stat - getFileStatus entry putStrLn' $ concat' [makeString (if isDirectory stat then dir: else file: ), entry] scanDir dir main = do changeWorkingDirectory $ makeString /tmp/dirtest dir - openDirStream $ makeString . scanDir dir closeDirStream dir dirtest.tar Description: Unix tar archive Regards, -- Robert BihlmeyerASSISTArrow ECS Internet Security AG
Bug#741001: liblz4: botched table in package description
Package: liblz4-1 Version: 0.0~r113-1 Severity: minor Many packaging tools will line-wrap the description, so your timing comparison table ends up being unreadable. If you indent this part of the description with *two* spaces, the formatting will be preserved akin to HTML's pre (I'm not sure if this table is not too much information anyway. Maybe just summarise it like LZ4 is faster than ... on compression with compression ratio comparable to But that's just a suggestion.) HTH, -- Robert BihlmeyerASSISTArrow ECS Internet Security AG -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738701: iceweasel 24 from stable-security breaks firebug and vice versa
Package: xul-ext-firebug Version: 1.9.2~b2-1 Severity: grave Since upgrading to iceweasel 24.3.0esr-1~deb7u1 firebug cannot be enabled anymore: * F12 is dead * Neither the beetle button nor the arrow next to it give a response * In the Tools menu there is a firebug.Firebug entry, but no submenu is behind it. It also causes breakage in iceweasel itself. The context menu is messed up, it gives a long list of options¹, and none of them work. Seems like the menu integration code of firebug has gone awry as well. The menu is back to normal if firebug is disabled. All this has been reproduced on two machines (i386, amd64) running stable, and with an empty $HOME/.mozilla Footnote: ¹ Normally, the options shown are dependent on which object you right-clicked on. Here I see the options for all kinds of objects listed one after the other. br, -- Robert BihlmeyerASSISTArrow ECS Internet Security AG -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738701: firebug 1.12.1-1 works with iceweasel 24
fixed 738701 1.12.1-1 thanks I have not tried 1.12.0~a4-1, which looks like an alpha version. Versions between 1.9.2~b2-1 (affected) and 1.12.0 were not packaged. Reading the changelog, it was seemingly known that newer iceweasels break firebug. May I suggest that some kind of conflict is declared in the future? br, -- Robert BihlmeyerASSISTArrow ECS Internet Security AG -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736800: [src:moodle] Sourceless flash file
# This bug affects moodle for some time already. Details below. found 736800 2.2.2.dfsg-1 thanks webservice/amf/testclient/AMFTester.swf is present since at least Moodle 2.0: http://git.moodle.org/gw?p=moodle.git;a=tree;f=webservice/amf/testclient;h=de1e4b15a9b5d4222e01327c54e8658450382f0f;hb=64063ad95adb0442dd25cbb593afa0884c33b71c Build instructions and source is in the same directory, but you need Adobe Flex to compile it. Seems like a false positive. lib/flowplayer/* Has been there since 2.0.3: http://git.moodle.org/gw?p=moodle.git;a=tree;f=lib/flowplayer;h=61724063575df2ceccc25c51795ac703e195f12b;hb=06ede85e1f2286de63a462aa89a27830d4c1b1c0 This is somewhat problematic. Source is available under GPL3 from here: http://flash.flowplayer.org/download/ Since neither the deb nor moodle upstream currently includes source, there is a GPL compliance issue. My immediate recommendation is to elide it, similar to the treatment flvplayer has gotten before. The GPL issue needs to be reported to upstream. A longterm project would be to work with upstream toward using flowplayer's HTML5 version (with source, of course). (Before doing that, it would be interesting to ponder whether Flowplayer Ltd.'s usage of GPL3 clause 5d is conformant with Debian's view. See http://flowplayer.org/license/free-license-faq.html for details.) -- Robert BihlmeyerASSISTArrow ECS Internet Security AG -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735312: moodle: deletes files from packages libjs-yui-*
Package: moodle Version: 2.5.3-3 Severity: serious Having libjs-yui-common and libjs-yui-common installed, an upgrade of moodle from 2.5.3-2 to -3 results in loss of a large number of files from these two packages. What I think happens here is that dpkg first sets the symlink of /usr/share/moodle/lib/yuilib/3.9.1/build to /usr/share/javascript/yui3, and then goes on to remove all the files from /u/s/m/lib/yuilib/3.9.1/build/ that are no longer contained in the new version of moodle. It *will* follow the symlink and this results in removal of these files from /usr/share/javascript/yui3 instead. This is perfectly reproducable for me: install -2, then upgrade to -3. dpkg -L libjs-yui3-common | while read f; do [ -e $f ] || echo $f; done will list a lot of missing files afterwards. Apart from being a policy violation this bug also cripples the functionality of moodle itself. My suggestion would be: 1. elide the dir removal from preinst 2. don't include the symlink in the package contents 3. remove the dir and create the symlink in the postinst When transplanting the dir removal code, remember that [ -d ... ] will return true for a symlink to a directory. br, -- Robert Bihlmeyer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730451: wrong case in homepage link
Package: libghc-osm-dev Version: 0.6.4-1 Severity: minor The homepage link should go to http://hackage.haskell.org/package/OSM The lower case variant (osm) does not work. TIA br, -- Robert Bihlmeyer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720160: wrong short description
Package: libboost-exception-dev Version: 1.54.0.1 Severity: minor The short description seems to apply to a different package: set of date-time libraries based on generic programming concepts (default version) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711846: iceweasel windows resized to 0x0 due to wrongly interpreted maximum width and height
Package: sawfish Version: 1:1.5.3-2.1+b1 Severity: serious Tags: patch Since iceweasel 17, which hit stable now, resizing a browser window results in it being 0x0. For me, one window is immediately sized to an unusable dimension, another one is strangely unaffected. This effectively breaks iceweasel for me, thus the severity. If I am the only one seeing this, it can be downgraded, of course. I am testing backporting an upstream patch right now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711847: security upgrade to iceweasel 17 (needlessly) breaks cookie monster
Package: xul-ext-cookie-monster Version: 1.1.0-4 Severity: grave With the upgrade to iceweasel 17, cookie monster 1.1.0-4 became uninstallable. The changes from -5 fix that, so this is a request to migrate 1.1.0-5 to wheezy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711846: Patch: iceweasel windows resized to 0x0 due to wrongly interpreted maximum width and height
Straight from debian/patches. Description: cap max-width / max-height of a window Cherry-picked from upstream commit 798c6992. Fixes issues with Iceweasel 17. Author: Robert Bihlmeyer ro...@orcus.priv.at Origin: upstream Bug-Debian: 711846 --- sawfish-1.5.3.orig/src/windows.c +++ sawfish-1.5.3/src/windows.c @@ -1286,6 +1286,13 @@ associated with WINDOW. Possible keys in hints = VWIN(win)-hints; flags = hints-flags; +/* workaround stuff like Firefox 17 that + * has enormous max-width/maxh-height */ +if (hints-max_width = 32767) + hints-max_width = 32767; +if (hints-max_height = 32767) + hints-max_height = 32767; + /* Some sanity checking */ if ((flags PMinSize) (hints-min_width 0 || hints-min_height 0))
Bug#677371: proposed docfix for missing readline
Hi, The manpage should not just document a feature that we don't have. So I put in verbiage that this is missing, and why. I left some documentation about readline intact, because one may be connected to another host that has a readline-enabled socat, while reading the page on wheezy. br, -- Robert Bihlmeyer --- socat.1.orig 2012-12-20 09:30:51.665600173 +0100 +++ socat.1 2012-12-20 09:40:57.057582287 +0100 @@ -667,18 +667,12 @@ EXEC, SYSTEM .IP \fB\f(CWREADLINE\fP\fP Uses GNU readline and history on stdio to allow editing and reusing input -lines (example)\. This requires the GNU readline and -history libraries\. Note that stdio should be a (pseudo) terminal device, -otherwise readline does not seem to work\. +lines (example)\. +.br +Due to licensing restrictions the readline feature is disabled in Debian\. +See BUGS\. .br -Option groups: FD,READLINE,TERMIOS -.br -Useful options: -history, -noecho -.br -See also: -STDIO +You can use STDIO instead\. .IP \fB\f(CWSCTP-CONNECT:host:port\fP\fP Establishes an SCTP stream connection to the specified host [IP address] and port [TCP service] @@ -1979,6 +1973,8 @@ .PP \fI\fBREADLINE option group\fP\fP .PP +Due to licensing restrictions the readline feature is disabled in Debian (see BUGS)\. +.br These options apply to the readline address type\. .IP \fB\f(CWhistory=filename\fP\fP Reads and writes history from/to filename (example)\. @@ -3203,7 +3199,6 @@ ttyS0\'s terminal parameters to practicable values, crnl converts to correct newline characters\. escape allows to terminate the socat process with character control-O\. -Consider using READLINE instead of the first address\. .IP \.LP \.nf @@ -3262,15 +3257,6 @@ Option reuseaddr allows immediate restart of the server process\. .IP -.IP \fB\f(CWsocat READLINE,noecho=\'[Pp]assword:\' EXEC:\'ftp ftp\.server\.com\',pty,setsid,ctty\fP\fP - -.IP -wraps a command line history (READLINE) around the EXEC\'uted ftp client utility\. -This allows editing and reuse of FTP commands for relatively comfortable -browsing through the ftp directory hierarchy\. The password is echoed! -pty is required to have ftp issue a prompt\. -Nevertheless, there may occur some confusion with the password and FTP -prompts\. .IP (\fB\f(CWsocat PTY,link=$HOME/dev/vmodem0,raw,echo=0,wait-slave EXEC:\'ssh modemserver\.us\.org socat - /dev/ttyS0,nonblock,raw,echo=0\'\fP\fP) .IP @@ -3660,7 +3646,8 @@ when address options cr or crnl are used: They show the data \fIafter\fP conversion in either direction\. .PP -The data transfer blocksize setting (\-b) is ignored with address readline\. +The licenses of OpenSSL and GNU Readline are incompatible\. Therefore readline +support is disabled in Debian\. .PP Send bug reports to socat@dest-unreach\.org .PP
Bug#658217: libfreerdp1 and libfreerdp0: error when trying to install together
Hi, upgrading freerdp-x11 from 0.7.4 (squeeze) to 1.0.0 (sid) hits exactly this bug. I.e. upgrades from squeeze to wheezy will stumble over this, unless this bug is fixed. Declaring a conflict would solve this case, but still not make them co-installable. So either fix the underlying cause, or move remmina-plugin-rdp to libfreerdp1 as well in a mini-transition. The former is preferable, I guess. br, -- Robert BihlmeyerASSISTArrow ECS Internet Security AG r.bihlme...@arrowecs.at A-1100 Wien, Wienerbergstraße 11 Tel: +43 1 370 94 40Fax: +43 1 370 94 40-333 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585354: patch to fix exception syntax removed with python 2.6
tags patch 585354 thanks Here's a tested fix. --- /usr/sbin/check-selinux-installation 2006-09-11 17:41:56.0 +0200 +++ /tmp/check-selinux-installation 2012-01-04 10:06:46.0 +0100 @@ -9,7 +9,7 @@ class ErrorBase: def __str__(self): - raise Error with no description found. Class: %s % self.__class__ + raise NotImplementedError(Error with no description found. Class: %s % self.__class__) def fixable(self): return False def fix(self): ]2;Terminal robbe@baal
Bug#654608: deprecated python constructs in /usr/share/selinux-basics/tests
Package: selinux-basics Version: 0.3.7 Severity: minor Tags: patch os.popen2() and os.popen3() are deprecated. The attached patch replaces these in two test scripts. --- /tmp/10_test_kernel_processes.py2012-01-04 10:20:19.0 +0100 +++ /usr/share/selinux-basics/tests/10_test_kernel_processes.py 2012-01-04 15:13:49.0 +0100 @@ -16,13 +16,13 @@ @staticmethod def test(): - import os + from subprocess import Popen, PIPE badprocs = [] - (getin, getout) = os.popen2(getfilecon /proc/[0-9]*) - getin.close() - for line in getout.readlines(): + pipe = Popen(getfilecon /proc/[0-9]*, shell=True, stdin=PIPE, stdout=PIPE, close_fds=True) + pipe.stdin.close() + for line in pipe.stdout.readlines(): (dir, context) = line.split() components = dir.split(/) pid = components[-1] @@ -34,7 +34,7 @@ file.close() if badproc: badprocs.append(pid) - getout.close() + pipe.stdout.close() if len(badprocs) 0: return [TestNoKernelT.ErrorBadKernelProcesses(badprocs)] return [] --- /tmp/01_verify_init.py 2012-01-04 12:37:34.0 +0100 +++ /usr/share/selinux-basics/tests/01_verify_init.py 2012-01-04 15:13:14.0 +0100 @@ -12,14 +12,14 @@ @staticmethod def test(): - import os + from subprocess import Popen, PIPE contextok = False - (getin, getout, geterr) = os.popen3(getfilecon /proc/1) - getin.close() + pipe = Popen(getfilecon /proc/1, shell=True, stdin=PIPE, stdout=PIPE, stderr=PIPE, close_fds=True) + pipe.stdin.close() - for line in getout.readlines(): + for line in pipe.stdout.readlines(): line = line.rstrip() if line == : continue if line.endswith(:system_r:init_t) \ @@ -27,12 +27,12 @@ contextok = True else: print ..%s.. % line - getout.close() + pipe.stdout.close() - for line in geterr.readlines(): + for line in pipe.stderr.readlines(): if line.find(failed) = 0: contextok = failed - geterr.close() + pipe.stderr.close() if contextok == failed: return [TestInitDomain.ErrorGetfileconFailed()] HTH -- Robert BihlmeyerASSISTArrow ECS Internet Security AG r.bihlme...@arrowecs.at A-1100 Wien, Wienerbergstraße 11 Tel: +43 1 370 94 40Fax: +43 1 370 94 40-333
Bug#531660: patch: Check selinux wrongly report: /etc/pam.d/login is not SELinux enabled (Squeeze)
tags 531660 patch thanks Attached is a patch that groks the pam_selinux line from squeeze's login (1:4.1.4.2+svn3283-2) --- /usr/share/selinux-basics/tests/21_pam.py~ 2011-12-22 10:00:26.0 +0100 +++ /usr/share/selinux-basics/tests/21_pam.py 2011-12-22 10:03:22.0 +0100 @@ -13,7 +13,7 @@ @staticmethod def test(): import os, re - r = re.compile(r'^\s*session\s*required\s*pam_selinux.so') + r = re.compile(r'^\s*session\s+(required|\[success=ok\s+ignore=ignore\s+module_unknown=ignore\s+default=bad\])\s+pam_selinux.so') result = [] if os.access(/etc/pam.d/ssh, os.F_OK): -- Robert BihlmeyerASSISTArrow ECS Internet Security AG r.bihlme...@arrowecs.at A-1100 Wien, Wienerbergstraße 11 Tel: +43 1 370 94 40Fax: +43 1 370 94 40-333
Bug#612924: texlive-base: fails to upgrade: cannot stat `/usr/share/texlive-base/pdftexconfig.tex': No such file or directory
Hi, No, we don't need a fix for that. People using sid are supposed to be able to fix these things with some help. I see this exact bug on a lenny-squeeze upgrade. The machine in question has never used tex* packages from sid. Also happened a few weeks ago on another machine on a lenny-squeeze (then still testing) upgrade. -- Robbe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600012: texlive-base: Claims to recreate pdftexconfig.tex upon clean install
Summary: breaks lenny-sid upgrade; probably RC This also happens during an upgrade from lenny. Why? I guess because this conffile was previously associated with texlive-base-bin, which got removed (and the unchanged pdftexconfig.tex with it). The original report is about a harmless message. Unfortunately, in my case the resurrection logic does not work at all. The preinst tries to take the file from /usr/share/texlive-base/pdftexconfig.tex. But there's nothing there yet, because the package is not unpacked yet (preinst, remember!). Therefore the script fails, preventing package installation completely and stopping the upgrade. Putting something at the above path works around the bug. Cheers, -- Robert Bihlmeyer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538958: cannot connect due to failing USB redirection
Package: vmware-view-open-client Version: 3.1.0-169073+dfsg-1 Severity: important Tags: patch Connecting to any View server that has USB redirection turned on will fail: You can logon, choose a desktop, then the client crashes. Last messages: Starting usb redirection to '127.0.0.1:35001' with ticket '156c2a19-5d40-4d8e-9b8d-bd001cdfc66e'. Relative or system path /usr/bin/vmware-view-usb does not exist. /usr/bin/vmware-view-usb was not found; disabling USB redirection.ASSERT procHelper.cc:129 ASSERT procHelper.cc:129 Reason is that the (not FOSS) USB redirection tool is not found and this case is not cleanly handled. This bug is recognised upstream at http://code.google.com/p/vmware-view-open-client/issues/detail?id=31 which also includes a trivial patch. Please apply. TIA -- Robert Bihlmeyer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#458084: FTBFS: bashism in debian/rules
Package: libmtp
Version: 0.2.4-2
Severity: serious
Tags: patch
Justification: no longer builds from source
With /bin/sh being dash this package fails to build due to a bashism in line
51 of debian/rules:
cp $${f/libmtp$(SOVERSION)/libmtp} $$f ;\
The attached patch fixes it.
diff -u libmtp-0.2.4/debian/rules\~ libmtp-0.2.4/debian/rules
--- libmtp-0.2.4/debian/rules~ 2007-12-28 15:52:37.0 +0100
+++ libmtp-0.2.4/debian/rules 2007-12-28 15:46:00.0 +0100
@@ -3,6 +3,7 @@
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk
+SHELL=/bin/bash
DEB_DH_INSTALL_SOURCEDIR = debian/tmp
DB2MAN = /usr/share/sgml/docbook/stylesheet/xsl/nwalsh/manpages/docbook.xsl
XP = xsltproc -''-nonet
Diff finished at Fri Dec 28 15:52:44
Bug#420569: logrotate snippet does not cope with removed (but not purged) pyca
Package: pyca Version: 20031118-1 Severity: minor I had pyca installed in the version from sarge, and removed it during upgrade to etch. I've not purged it yet, so /etc/logrotate.d/pyca remains. This snippet does not handle well the fact that /var/log/pyca no longer exists. Every day I get a mail containing: /etc/cron.daily/logrotate: error: error accessing /var/log/pyca: No such file or directory error: pyca:1 glob failed for /var/log/pyca/*.out run-parts: /etc/cron.daily/logrotate exited with return code 1 Maybe this could be fixed? Perhaps this issue is better handled in logrotate, though. I currently have logrotate 3.7.1-3 installed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415788: bug 415788: postfix smtpd segfault
severity 415788 grave thanks ObSeverity: this affects default installations (which have TLS on) in current etch. Non-running smtpd is mostly unusable, IMO. It seems that libpostfix-tls.so.1 was compiled against a version of libssl0.9.8 that contains symbols that are not included in the version currently in etch (0.9.8c-4): $ gcc -o /dev/null /usr/lib/libpostfix-tls.so.1 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crt1.o: In function `_start': ../sysdeps/i386/elf/start.S:115: undefined reference to `main' /usr/lib/libpostfix-tls.so.1: undefined reference to [EMAIL PROTECTED]' /usr/lib/libpostfix-tls.so.1: undefined reference to `var_tls_daemon_rand_bytes' /usr/lib/libpostfix-tls.so.1: undefined reference to [EMAIL PROTECTED]' /usr/lib/libpostfix-tls.so.1: undefined reference to [EMAIL PROTECTED]' /usr/lib/libpostfix-tls.so.1: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status The current sid version of libssl0.9.8 (0.9.8e-4) includes these symbols. I guess the root cause is libssl0.9.8 not providing a correct shlibs file. Please clone/reassign in this case. Etch will no longer be affected when 0.9.8e-4 migrates. If that is not imminent, maybe postfix should work around this by building with the older libssl0.9.8? Cheers, -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409750: touches conffile (/etc/mysql/my.cnf) of other package (mysql-common)
Package: mysql-server-5.0 Version: 5.0.32-3 Severity: serious mysql-server-5.0's postinst modifies /etc/mysql/my.cnf to add/change the old_passwd setting, in violation of policy 10.7.3 and 10.7.4. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409374: postinst not idempotent: adds duplicate lines to ld.so.hwcappkgs
Package: libc6-xen Version: 2.3.6.ds1-10 Severity: normal Tags: patch (Technically a policy violation, but the result seems relatively harmless, therefore I left the Severity at normal.) The postinst parses /etc/ld.so.hwcappkgs and if there is already a line for libc6-xen, it sets $isrecorded (line 30). Only if this is not set in line 40 another line for libc6-xen is added to the file. The problem is that line 30 is in a sub-shell so the setting of $isrecorded does not propagate to line 40 (outer shell). The attached patch fixes that. diff -u /var/lib/dpkg/info/libc6-xen.postinst /tmp/libc6-xen.postinst --- /var/lib/dpkg/info/libc6-xen.postinst 2007-02-02 14:37:56.0 +0100 +++ /tmp/libc6-xen.postinst 2007-02-02 14:37:57.0 +0100 @@ -36,10 +36,10 @@ fi fi echo $pkg $ver /etc/ld.so.hwcappkgs.tmp - done) /etc/ld.so.hwcappkgs + done if [ $isrecorded != yes ]; then echo $opt $curver /etc/ld.so.hwcappkgs.tmp - fi + fi) /etc/ld.so.hwcappkgs mv /etc/ld.so.hwcappkgs.tmp /etc/ld.so.hwcappkgs else # libc6 did not create ld.so.hwcappkgs correctly or ld.so.hwcappkgs
Bug#387646: postfix: Confusing default for the debconf question regarding synchronous updates
reopen 387646 found 387646 2.3.6-1 thanks This bug is still present in 2.3.6-1 (currently in sid and etch), although the default now seems to be false instead of off. Still, debconf expects a boolean question to be answered either with yes or no -- i.e. the default should be no. You can easily reproduce this with dpkg-reconfigure -f readline postfix Using the dialog frontend will not show the error... -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401183: 401183 affects linux-image-2.6.18-3-xen-* as well
clone 401183 -1 reassign -1 linux-2.6 2.6.18-8 retitle -1 linux-image-2.6.18-8-xen-*.postinst not idempotent thanks I looked into the linux-2.6 source package (2.6.18-8), and contained xen postinst scripts are affected. What is the difference between udpate-initramfs -c and update-initramfs -u? Only that the first one bugs if the initrd exists already? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401183: linux-image-2.6.17-2-xen-686.postinst not idempotent
Package: linux-image-2.6.17-2-xen-686 Version: 2.6.17-9 Severity: serious ObSeverity: policy 6.2 looks like a MUST to me, though not explicitly When configuring this package a second time the update-initramfs -c -k 2.6.17-2-xen-686 bombs because the initramfs file is already present. Maybe the old file should be deleted before this? Another option is to not check the existence of $2, but whether the initramfs file exists to decide between -c and -u. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400601: support for current version of eToken NG (eToken 64, USB id 0529:0700)
Package: openct
Version: 0.6.10-1rb1
Severity: normal
Tags: patch
I have a newer eToken NG that identifies itself on USB with vendor 0529
(Aladdin) and model 0700. I just copied the older definitions (0529:0600)
everywhere I found them, as the new model seems to work just fine with the
current etoken64 driver.
See patch.
diff -ruN openct-0.6.10/debian/changelog openct-0.6.10+/debian/changelog
--- openct-0.6.10/debian/changelog 2006-11-27 13:06:24.0 +0100
+++ openct-0.6.10+/debian/changelog 2006-11-27 12:03:46.0 +0100
@@ -1,3 +1,9 @@
+openct (0.6.10-1rb1) unstable; urgency=low
+
+ * Recognise 0529/0700 as an alternative vendor/id of eToken 64.
+
+ -- Robert Bihlmeyer [EMAIL PROTECTED] Mon, 27 Nov 2006 12:03:46 +0100
+
openct (0.6.10-1) unstable; urgency=medium
* New upstream release. Urgency medium to fix these bugs before the
diff -ruN openct-0.6.10/etc/Info.plist openct-0.6.10+/etc/Info.plist
--- openct-0.6.10/etc/Info.plist 2006-09-12 18:38:49.0 +0200
+++ openct-0.6.10+/etc/Info.plist 2006-11-27 10:30:14.0 +0100
@@ -16,6 +16,7 @@
string0x0529/string
string0x0529/string
string0x0529/string
+ string0x0529/string
string0x073d/string
string0x04b9/string
string0x04b9/string
@@ -45,6 +46,7 @@
string0x050c/string
string0x0514/string
string0x0600/string
+ string0x0700/string
string0x0005/string
string0x1202/string
string0x1300/string
diff -ruN openct-0.6.10/etc/openct.conf.in openct-0.6.10+/etc/openct.conf.in
--- openct-0.6.10/etc/openct.conf.in 2006-09-20 20:42:57.0 +0200
+++ openct-0.6.10+/etc/openct.conf.in 2006-11-27 10:32:57.0 +0100
@@ -60,6 +60,7 @@
driver etoken64 {
ids = {
usb:0529/0600,
+ usb:0529/0700,
};
};
driver eutron {
diff -ruN openct-0.6.10/etc/openct.udev openct-0.6.10+/etc/openct.udev
--- openct-0.6.10/etc/openct.udev 2006-11-06 23:21:05.0 +0100
+++ openct-0.6.10+/etc/openct.udev 2006-11-27 10:32:16.0 +0100
@@ -9,6 +9,7 @@
SYSFS{idVendor}==0529, SYSFS{idProduct}==0514, RUN+=/lib/udev/openct_usb
# eToken 64
SYSFS{idVendor}==0529, SYSFS{idProduct}==0600, RUN+=/lib/udev/openct_usb
+SYSFS{idVendor}==0529, SYSFS{idProduct}==0700, RUN+=/lib/udev/openct_usb
# eutron
SYSFS{idVendor}==073d, SYSFS{idProduct}==0005, RUN+=/lib/udev/openct_usb
# ikey2k
diff -ruN openct-0.6.10/etc/openct.usermap openct-0.6.10+/etc/openct.usermap
--- openct-0.6.10/etc/openct.usermap 2006-09-12 18:38:49.0 +0200
+++ openct-0.6.10+/etc/openct.usermap 2006-11-27 10:31:54.0 +0100
@@ -7,6 +7,7 @@
openct 0x0003 0x0529 0x05140x 0x 0x00 0x000x000x000x00 0x00 0x
# eToken 64
openct 0x0003 0x0529 0x06000x 0x 0x00 0x000x000x000x00 0x00 0x
+openct 0x0003 0x0529 0x07000x 0x 0x00 0x000x000x000x00 0x00 0x
# eutron
openct 0x0003 0x073d 0x00050x 0x 0x00 0x000x000x000x00 0x00 0x
# ikey2k
--
Robbe
Bug#400600: please clarify role of /lib/cryptsetup/cryptdisks.functions
Package: cryptsetup
Version: 2:1.0.4-8
Severity: wishlist
I originally thought that /lib/cryptsetup/cryptdisks.functions is just to share
code between the scripts /etc/init.d/cryptdisks{,-early}.
But now these scripts just exit with an OK status if this file is not
present/readable... Under my assumption above it should be a grave error
instead.
It would be nice if README.Debian provided documentation how the scripts are
intended to work together.
--
Robbe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399177: iptables does not always resolve HOSTNAME/MASKLEN correctly
Package: iptables
Version: 1.3.6.0debian1-2
Severity: normal
Tags: patch
This is in a situation where DNS is unavailable:
iptables -A INPUT -j ACCEPT -s orcus
works -- orcus is resolved correctly via /etc/hosts --, but
iptables -A INPUT -j ACCEPT -s orcus/24
does not, /etc/hosts resolving does not work, and it falls back to DNS
(which also does not work *and* incurs a wait for a timeout).
It is the same when orcus is replaced with localnet which can be
found in /etc/networks. The form orcus/255.255.255.0 runs fine.
This seems to be a recent breakage ... I didn't pinpoint the version, though.
I the culprit in parse_hostnetworkmask(); if I apply the ipt-hosts.patch
the problem goes away. What the problematic code does is pad orcus to
orcus.0.0.0 with the obvious consequences. Actually the idea is good (allow
e.g. 1.2/16) but the condition before pad_cidr() is completely bogus. So
my suggestion is to remove this ill thought-out feature until
correctly implemented.
FWIW, I'm also attaching a patch that fixes a mini-bug in the Makefile: the
-a in a test commandline usually means and, so -a FILE should probably
read -e FILE.
diff -ruN iptables-1.3.6.0debian1/iptables/iptables.c
iptables-1.3.6.0debian1+/iptables/iptables.c
--- iptables-1.3.6.0debian1/iptables/iptables.c 2006-11-18 11:17:14.0
+0100
+++ iptables-1.3.6.0debian1+/iptables/iptables.c2006-11-18
10:44:07.0 +0100
@@ -702,8 +702,6 @@
if ((p = strrchr(buf, '/')) != NULL) {
*p = '\0';
addrp = parse_mask(p + 1);
- if (strrchr(p + 1, '.') == NULL)
- pad_cidr(buf);
} else
addrp = parse_mask(NULL);
inaddrcpy(maskp, addrp);
diff -ruN iptables-1.3.6.0debian1/iptables/Makefile
iptables-1.3.6.0debian1+/iptables/Makefile
--- iptables-1.3.6.0debian1/iptables/Makefile 2006-11-18 11:17:14.0
+0100
+++ iptables-1.3.6.0debian1+/iptables/Makefile 2006-11-18 09:45:00.0
+0100
@@ -79,7 +79,7 @@
# Generic test if arch wasn't found above
ifneq ($(POINTERTEST),1)
# Try to determine if kernel is 64bit and we are compiling for 32bit
- ifeq ($(shell [ -a $(KERNEL_DIR)/include/asm ] echo YES), YES)
+ ifeq ($(shell [ -e $(KERNEL_DIR)/include/asm ] echo YES), YES)
64bitkernel := $(shell echo -e \#include asm/types.h\n\#if
BITS_PER_LONG == 64\nkernel_is_64bits\n\#endif | $(CC) $(CFLAGS) -D__KERNEL__
-E - | grep kernel_is_64bits)
ifdef 64bitkernel
32bituser := $(shell echo -e \#include stdio.h\n\#if
!defined(__arch64__) !defined(_LP64)\nuserspace_is_32bit\n\#endif | $(CC)
$(CFLAGS) -E - | grep userspace_is_32bit)
Bug#394827: minicom: please ship NEWS
Package: minicom Version: 2.2-2 Severity: wishlist Upstream seems to provide a NEWS file -- it would be nice if this could be included in /usr/share/doc/minicom/. TIA, -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389589: XkbModel: pc105 broken
Denis Barbier [EMAIL PROTECTED] writes: Is this problem fixed when X is restarted? I rebooted the computer several times since installing the new version of xkb-data and the problem persisted. Only when I implemented the workarounds detailed in the original report did the extra key start to work again. It's a bit strange that I am the only one with this problem... I've read in another bug report that the pc105 definition is now upstream's default -- maybe this fact is related (e.g pc should now be equal to what was formerly pc(pc105) but isn't here for some reason)? TIA, -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389589: XkbModel: pc105 broken
Package: xkb-data Version: 0.8-13 Severity: normal From my xorg.conf: Section InputDevice IdentifierGeneric Keyboard Driverkeyboard OptionCoreKeyboard OptionXkbRules xorg OptionXkbModel pc105 OptionXkbLayout de OptionXkbVariantnodeadkeys OptionXkbOptionsaltwin:super_win EndSection But even though pc105 is specified, the key with | on it does nothing. $ setxkbmap -v 7 Applied rules from xorg: model: pc105 layout: de variant:nodeadkeys options:altwin:super_win Trying to build keymap using the following components: keycodes: xfree86+aliases(qwertz) types: complete compat: complete symbols:pc+de(nodeadkeys)+altwin(super_win) geometry: pc(pc105) So it seems the xorg rules now incorrectly map model pc105 and layout de to symbols pc+de and not pc(pc105)+de as before. Looks like line 270 from /usr/share/X11/xkb/rules/xorg is to blame for that: * * = pc+%l%(v) The corresponding line (374) from the same file from xkb-data 0.8-12 reads: * * = pc(pc105)+%l%(v) (actually for my case line 372 from this file should match:) $pcmodels * = pc(%m)+%l%(v) Anyway, the additional key works with this version and does not anymore. A temporary fix is: $ setxkbmap -v 7 -symbols 'pc(pc105)+de(nodeadkeys)+altwin(super_win)' Warning! Multiple definitions of symbols Using command line, ignoring rules file Applied rules from xorg: model: pc105 layout: de variant:nodeadkeys options:altwin:super_win Trying to build keymap using the following components: keycodes: xfree86+aliases(qwertz) types: complete compat: complete symbols:pc(pc105)+de(nodeadkeys)+altwin(super_win) geometry: pc(pc105) Changing line 270 back to * * = pc(pc105)+%l%(v) fixes it for good. But I guess the whole section should be changed back ... or the symbols/pc file modified to always include 105 keys. TIA, Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386735: docs missing from debian package
Package: wodim Version: 5:1.0~pre4-1 Severity: minor /usr/share/doc/wodim/changelog.gz talks about a FAQ, but I can't find it in the package. /usr/share/doc/cdrkit-doc/ABOUT mentions a FORK file, I haven't seen that either. /usr/share/doc/cdrkit-doc/wodim/ is still empty, maybe the stuff belongs there? (Although cdrkit-doc seems to contain mostly aging/old stuff, maybe new docs should go to their relevant packages?) I hope cdrkit will become a sustainable effort and wish you the best! -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379737: [Pkg-cryptsetup-devel] Bug#379737: cryptsetup: cannot handle UTF-8 in passphrase
Hi, David Härdeman [EMAIL PROTECTED] writes: There is a caveat: if someone has a latin1 locale, sets a passphrase with non-ascii characters, and later changes to a utf8 locale, he is subsequently locked out of his data. Well, that goes for both cryptsetup during the initramfs stage and during normal use of the system, so it's something that will have to be addressed sooner or later by the user anyway. Correct. But during normal use the user can set her console to non-UTF8. Cryptosetup could also use large translation tables (glibc's?) that may not be available in initramfs. People that encrypted CDRs with latin1-passphrases will see this problem (during normal use) for some time. My other solution (normalising the passphrase to UTF-8 always) would have no such problems, but it's a rather big hammer -- we can't put big translation tables on initramfs I guess. Well, it wouldn't work simply because we can't know which encoding to convert from (i.e. was the old input in iso8859-1, or in iso8859-15, or something else). The idea is to translate to UTF-8 on luksAddKey time. To be more concrete: 1. Old passwords that are not UTF-8 are lost and need to be manually fixed. Should be documented. 2. Newly created keys always get their passphrases translated from whatever encoding is active (as per LANG and LC_*) to UTF-8. 3. initramfs always sets the terminal into UTF-8 mode, so new passwords will work without a hitch. The feature from bullet 2 will probably need /usr/lib/gconv, but it is not needed for the version put onto initramfs. (That was my main fear, to bloat the initramfs by 5 megs or more.) For legacy compatibility (e.g. old CDRs) cryptsetup could take a --encoding=X parameter that translated from the current encoding (usually UTF-8) to X so that passphrases encoded in X are still usable. This leaves d-i to think about. -- Robbe
Bug#379737: [Pkg-cryptsetup-devel] Bug#379737: cryptsetup: cannot handle UTF-8 in passphrase
David Härdeman [EMAIL PROTECTED] writes: I'll add some code later this week to the initramfs hook which checks for a UTF-8 locale (the same code that the kbd package init.d script uses), and if so, the initramfs script will have to run kbd_mode -u and loadkeys --unicode instead of simply running loadkeys. Makes sense. There is a caveat: if someone has a latin1 locale, sets a passphrase with non-ascii characters, and later changes to a utf8 locale, he is subsequently locked out of his data. (That will actually happen to me as I temporarily changed to a latin1 locale to set my passphrase -- as a workaround to this bug. Once your fix hits my machine this passphrase, containing non-UTF8 sequences, is unusable. Of course I am forewarned, and can fix things...) I wonder whether having non-ascii in my passphrase is worth it. It is more unstable than one would think. My other solution (normalising the passphrase to UTF-8 always) would have no such problems, but it's a rather big hammer -- we can't put big translation tables on initramfs I guess. Take care, -- Robbe
Bug#384225: please ship NEWS
Package: gtk+2.0 Version: 2.8.20-1 Severity: wishlist Seems upstream has a useful NEWS file. It would be fine if that ended up in, say, /usr/share/doc/libgtk2.0-common/ TIA -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384234: changelog.gz is no changelog
Package: libcompress-zlib-perl Version: 1.42-1 Severity: minor /usr/share/doc/libcompress-zlib-perl/changelog.gz just links to the README, which does not contain any changelog information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379726: cryptsetup: luksAddKey asks for unlock-passpharse twice
reopen 379726 thanks (I find it rude if you close bugs you don't yet understand.) Jonas Meurer [EMAIL PROTECTED] writes: what else do you mean? with luksAddKey you add a new key, nothing else. so it makes perfectly sence that the passphrase is asked twice. I meant it unnecessarily ask twice for the passphrase to an *existing* key. Just try it out. ~# cryptsetup luksFormat /dev/loop1 WARNING! This will overwrite data on /dev/loop1 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: [enter: number1] Verify passphrase: [enter: number1] Command successful. ~# cryptsetup luksAddKey /dev/loop1 Enter any LUKS passphrase: [enter: number1] Verify passphrase: [enter: number1] this is useless key slot 0 unlocked. Enter new passphrase for key slot: [enter: number2] Verify passphrase: [enter: number2] Command successful. Greetings, -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379986: [Pkg-xfce-devel] Bug#379986: conflicts with current xfce
Yves-Alexis Perez [EMAIL PROTECTED] writes: There was at least two open bugs on xfdesktop4 which described this situation (379650 and 379689), just closed because xfdesktop4 4.3.90.2 has been uploaded (depending on libxfce4util4). Couldn't you have checked the BTS before reporting this bug ? When packages.debian.org says that my package version is current I only skim the resolved bugs section of the BTS. It's my fault that in this superficial perusal I did not connecect xfdesktop4-4.3.90.2 missing nor uninstallable on unstable amd6 with the problem I saw. We are in the midlde of a transition from beta1 to beta2 and it takes time. be patient, everything should be ok in the next few days. I actually set the bug to fixed in 4.3.90.2 before you sent your mail, no need to get all worked up... It was a (duplicate) bug report, not an insult. Thanks for working on xfce! -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379986: conflicts with current xfce
Package: xfdesktop4 Version: 4.3.90.1-2 Severity: grave xfdesktop4 depends on libxfce4util2. Most other xfce stuff depends on libxfce4util4 which conflicts with libxfce4util2. So one has to choose... I guess xfdesktop4 just needs a recompile with the new lib. -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379726: cryptsetup: luksAddKey asks for unlock-passpharse twice
Package: cryptsetup Version: 2:1.0.3-3 Severity: minor cryptsetup luksAddKey will ask you for the passphrase of an existing key ... twice. The second time is unnecessary. Mind, that I am not talking about the passphrase for the *new* key, where asking for verification makes perfect sense. TIA, -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379723: cryptsetup: luksDelKey is too eager
Package: cryptsetup Version: 2:1.0.3-3 Severity: wishlist It can be very easy to delete a vital key with cryptsetup luksDelKey. I have not checked whether it will delete the last key, but even if you have two, one of them may be unusable (passphrase forgotten), you want to delete this one, but actually delete the one where you know the passphrase ... ouch! I would suggest a query for one of the *other* keys, so the above situation can not happen. TIA, -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379719: cryptsetup: keymap change should be more prominently documented
Package: cryptsetup Version: 2:1.0.3-3 My passphrase for / includes characters that are on different positions in the us and de keyboard layouts. What I did before was loadkeys us before setting up the key (so that the passphrase Härdeman would actually become H'rdeman, as the key labeled ä would generate a ' in us). With the new fix for #376393 I could no longer use this passphrase (because entering Härdeman would no longer result in the correct H'rdeman). It is not usually catastrophic, because most keys that can be generated by a us keyboard are somehow possible to get on an international keyboard, but it's quite a bother to find them. It would have been easier if this were documented outside the changelog, e.g. in NEWS.Debian. TIA, -- Robbe
Bug#379737: cryptsetup: cannot handle UTF-8 in passphrase
Package: cryptsetup Version: 2:1.0.3-3 (Last report for today, I promise!) This issue is related to the keymap troubles. If you luksAddKey in an UTF-8 environment entering ä in the passphrase will result in the two bytes 0xc3 and 0xa4. When you later reenter this ä during the initram/initrd phase, the console is not (yet) in Unicode mode, so it only results in the single byte 0xe4 ... the passphrases will not match. I am unsure how to solve this. Canonising all passphrases before hashing is a nice option, but this may involve largish tables unsuitable for an initrd. Maybe the console should be switched to Unicode mode akin to loading the right keymap? TIA, -- Robbe
Bug#378868: apt: http method uses absoluteURI when Proxy is set to false
Package: apt Version: 0.6.44.2 Severity: wishlist On a freshly installed etch (from an 20060716 d-i snapshot) if you didn't select a proxy during the install, you end up with Acquire::http::Proxy false; in your /etc/apt/apt.conf. IMO the installer should put nothing there in this case, and this may be the real bug. The effect of this setting is that apt does not use a proxy, *but* uses absoluteURI in its requests like so: GET http://server/path HTTP/1.1 Host: server ... RFC2616 says that clients should only use this form to talk to proxies, although it also requires servers to accept this form... In practise this form creates problems with some strict (IMO broken) firewalls. If the Proxy config is removed entirely, the usual abs_path is used instead: GET /path HTTP/1.1 Host: server ... Severity is debatable. It does break downloading sometimes, although it shouldn't be a problem if all the /other/ components (http server, transparent proxy, firewalls) are RFC-compliant. TIA, -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378697: debian-installer: netinst image misses cryptsetup package
Package: debian-installer Severity: normal Happens with the snapshot downloaded today from http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso dated 20060716. I partitioned with / being on an encrypted volume. base-installer then tries to install the cryptsetup package from CD, but it is not there (only the udeb). Thus Install the base system fails. -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378697: debian-installer: netinst image misses cryptsetup package
Frans Pop [EMAIL PROTECTED] writes: This was fixed on the 16th, so daily images later than that should have the package included. Ah, thanks! FWIW, the businesscard image from the same day worked, as it did not expect the cryptsetup package on the CD but downloaded it from the net. The system won't boot now, but that's another bug... -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378422: missing newline in error message
Package: cryptsetup Version: 2:1.0.3-3 Severity: minor $ cryptsetup luksUUID /dev/sda1; echo '-- newline missing' /dev/sda1 is not a LUKS partition Command failed.-- newline missing The Command failed. misses a \n at the end. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372755: NEWS is outdated
Package: libxslt1.1 Version: 1.1.17-1 Severity: minor /usr/share/doc/libxslt1.1/NEWS.gz describes versions up to 1.1.16. The web page it references (http://xmlsoft.org/XSLT/news.html) is current (1.1.17). -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370300: please ship ChangeLog
Package: xserver-xorg-input-evdev Version: 1:1.1.2-1 Severity: wishlist Please put upstream's ChangeLog in the documentation directory. TIA, Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367096: undeclared dependency on libnautilus-burn2
Package: nautilus-cd-burner Version: 2.12.3-2 Severity: serious ~$ nautilus-cd-burner nautilus-cd-burner: error while loading shared libraries: libnautilus-burn.so.2: cannot open shared object file: No such file or directory ~$ ldd $(which nautilus-cd-burner) linux-gate.so.1 = (0xe000) libnautilus-burn.so.2 = not found Installing libnautilus-burn2 by hand fixes that problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365596: please ship NEWS
Package: libxml2 Version: 2.6.24.dfsg-1 Severity: wishlist Upstream seems to include an up-to-date NEWS file, it would be nice if it could be distributed in /usr/share/libxml2/ in the Debian packages. TIA, Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364645: doc-base files point to wrong locations
Package: cfengine-doc Version: 1.6.5-2 Severity: normal The new doc-base reports: warning: file `/usr/share/info/cfengine-Reference.info' does not exist at /usr/sbin/install-docs line 718, /usr/share/doc-base/cfengine-reference line 15. warning: file `/usr/share/info/cfengine-Tutorial.info' does not exist at /usr/sbin/install-docs line 718, /usr/share/doc-base/cfengine-tutorial line 15. It seems that you need to append .gz to the file names. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364647: doc-base file points to wrong location
Package: openct Version: 0.6.6-2 Severity: normal The new doc-base reports: warning: file `/usr/share/doc/openct/html/openct.html' does not exist at /usr/sbin/install-docs line 718, /usr/share/doc-base/openct-manual line 9. This should probably be changed to index.html. Thanks, Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362316: libglib2.0-data: slight change to long description
Package: libglib2.0-data Severity: minor Version: 2.10.1-2 The package description says: This package contains the common files which the runtime libraries need. This left me wondering why libglib2.0 only recommends libglib2.0-data, if the files are needed. I suggest the following replacement: This package is needed for the runtime libraries to display messages in languages other than English. This also explains the nature of the contained files, so that a more informed decision can be made whether to install this package alongside libglib2.0. -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361900: what is unison-latest-stable supposed to do?
Package: unison Version: 2.13.16-5 Severity: normal The package contains lrwxrwxrwx root/root 0 2006-02-07 00:36:58 ./usr/bin/unison-latest-stable - unison-2.13.16 What is this symlink for? I found nothing about it in /usr/share/doc/unison, and its manpage also just symlinks to unison's normal manpage. My first guess was that it represents the version of unison present in Debian stable, so syncing with sarge hosts is easy. But for that the symlink need be different, and contained in the unison2.9.1 package... Perhaps it means the latest stable version of *unison* (not Debian), so if one has development versions installed, one can opt-out of using them? There's no un-stable version of unison in Debian, currently, so that is not that useful here. I'd like two things to happen: The unison-latest-stable symlink should be documented as to what its purpose is. Or removed if there is none. This is severity normal, I think. Something like my first guess should be implemented, either under the unison-latest-stable name, or unison-sarge, or whatever. That's a wishlist item. TIA, Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360621: unhelpful short description
Package: libthai0 Severity: minor LibThai library is quite redundant for the short description. I suggest Thai language support routines or something similar. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359292: depends on obsolete libopenal0
tags + 359292 patch thanks Well, after the rebuild crystalspace does no longer depend on libopenal0, but it seems to have been built without OpenAL support now (no dependency on libopenal0a, and the buildd log says checking for OpenAL... no). It turns out that CS really uses alut, which is now in a different package, needing an additional build-dependency. The following patch will make the configure check work. But I'm not sure whether that wholly fixes the issue, as my test build borked on some swig-generated files (maybe I will look into *that* problem later). --- crystalspace-0.99-20060125/debian/control 2006-04-02 11:42:19.0 +0200 +++ crystalspace-0.99-20060125+/debian/control 2006-04-02 11:37:38.0 +0200 @@ -2,7 +2,7 @@ Section: games Priority: optional Maintainer: Christian Bayle [EMAIL PROTECTED] -Build-Depends: debhelper (= 4.0), python2.3-dev | python2.2-dev | python-dev , nasm (= 0.98.08-1), lib3ds-dev (= 1.2.0), libogg-dev (= 1.0rc2-1), libmikmod2-dev, libvorbis-dev (1.0.0), docbook-to-man, xlibmesa-gl-dev | libgl-dev, zip, libpng3-dev, libjpeg62-dev, libfreetype6-dev, zlib1g-dev, libode-dev, libopenal-dev, libcal3d-dev, swig, dh-buildinfo, flex, bison, texinfo, tetex-bin, doxygen, gs-common, glutg3-dev, libmng-dev, libsdl1.2-dev, autoconf, libx11-dev, libxext-dev, libxxf86vm-dev, x-dev +Build-Depends: debhelper (= 4.0), python2.3-dev | python2.2-dev | python-dev , nasm (= 0.98.08-1), lib3ds-dev (= 1.2.0), libogg-dev (= 1.0rc2-1), libmikmod2-dev, libvorbis-dev (1.0.0), docbook-to-man, xlibmesa-gl-dev | libgl-dev, zip, libpng3-dev, libjpeg62-dev, libfreetype6-dev, zlib1g-dev, libode-dev, libopenal-dev, libalut-dev, libcal3d-dev, swig, dh-buildinfo, flex, bison, texinfo, tetex-bin, doxygen, gs-common, glutg3-dev, libmng-dev, libsdl1.2-dev, autoconf, libx11-dev, libxext-dev, libxxf86vm-dev, x-dev Build-Depends-Indep: debhelper (= 4.0) Standards-Version: 3.6.2.0 -- Robbe
Bug#359255: crystalspace - FTBFS: Unmatched ( in regex
tags + 359255 patch thanks $ needs to be spelled $$ to escape make's clutches. Here's a patch. I also fixed the commented-out lines. --- crystalspace-0.99-20060125/debian/rules 2006-04-02 11:42:19.0 +0200 +++ crystalspace-0.99-20060125+/debian/rules 2006-04-02 10:30:31.0 +0200 @@ -52,18 +52,18 @@ # @@@ FIXME: This does not handle plugins protected by ifeq/ifneq. # perl -pi -e s/^#PLUGINS/PLUGINS/ $(CURDIR)/CS/mk/user.mak # Temp remove of render3d renderers - #perl -pi -e s/^PLUGINS(.*render3.*$)/#PLUGINS\1/ $(CURDIR)/CS/mk/user.mak -## perl -pi -e s/^PLUGINS(.*glshader_cg$)/#PLUGINS\1/ $(CURDIR)/CS/mk/user.mak + #perl -pi -e s/^PLUGINS(.*render3.*$$)/#PLUGINS\1/ $(CURDIR)/CS/mk/user.mak +## perl -pi -e s/^PLUGINS(.*glshader_cg$$)/#PLUGINS\1/ $(CURDIR)/CS/mk/user.mak # Temp? remove of cslua - #perl -pi -e s/^PLUGINS(.*cslua.*$)/#PLUGINS\1/ $(CURDIR)/CS/mk/user.mak + #perl -pi -e s/^PLUGINS(.*cslua.*$$)/#PLUGINS\1/ $(CURDIR)/CS/mk/user.mak # Temp? remove of openal - #perl -pi -e s/^PLUGINS(.*openal.*$)/#PLUGINS\1/ $(CURDIR)/CS/mk/user.mak + #perl -pi -e s/^PLUGINS(.*openal.*$$)/#PLUGINS\1/ $(CURDIR)/CS/mk/user.mak # Remove broken support of python because of swig or g++ on s390 and powerpc ifeq ($(DEB_HOST_ARCH),$(findstring $(DEB_HOST_ARCH), s390)) - perl -pi -e s/^PLUGINS(.*cspython.*$)/#PLUGINS\1/ $(CURDIR)/CS/mk/user.mak + perl -pi -e s/^PLUGINS(.*cspython.*$$)/#PLUGINS\1/ $(CURDIR)/CS/mk/user.mak endif ifeq ($(DEB_HOST_ARCH),$(findstring $(DEB_HOST_ARCH), powerpc)) - perl -pi -e s/^PLUGINS(.*cspython.*$)/#PLUGINS\1/ $(CURDIR)/CS/mk/user.mak + perl -pi -e s/^PLUGINS(.*cspython.*$$)/#PLUGINS\1/ $(CURDIR)/CS/mk/user.mak endif find $(CURDIR)/CS -name .cvsignore | xargs rm -f # --disable-qsqrt was added for a gcc3.2 bug -- Robbe
Bug#359292: depends on obsolete libopenal0
I wrote: But I'm not sure whether that wholly fixes the issue, as my test build borked on some swig-generated files Yes it does -- after working-around the swig breakage my compile ran through, the resulting .deb depends on libalut0 libopenal0a and contains the sndoal.so plugin. -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359292: depends on obsolete libopenal0
Package: crystalspace Version: 0.99-20060125-1 Severity: normal libopenal0a is the current version and conflicts with libopenal0. See http://lists.debian.org/debian-devel/2006/02/msg00850.html for background information. A simple rebuild should fix this bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359060: contains filename in legacy encoding
Package: xblast-tnt-levels Version: 20050106-1 Severity: wishlist Hi Alfie, not really a bug, but something that should be changed sooner or later: $ ls /usr/share/games/xblast-tnt/level/reco*2.xal /usr/share/games/xblast-tnt/level/reconstruct?on2.xal The character shown as ? is really 00EE ilatin small letter i with circumflex and should sometimes be encoded as 0xc3 0xae (... or simply changed to i). cu, Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357828: logging should be locale-independent
Package: aptitude Version: 0.4.1-1 Severity: minor It seems that at least the second line of each stanza (containing the date) in /var/log/aptitude is depending on the locale that aptitude is running under. I think this is problematic. Logfiles should be machine-parseable. But the parser has no easy way to find out what locale was used, so it would need to be able handle all of them, in principle. Running aptitude a number of times, it will normally just append to the current log. If the runs were made with different locales active, this will result in a file with different date formats for the same date, which seems evil. Surely evil is the case I am currently looking at, where the encoding changes mid-file: some stanzas are in iso8859-1, others in utf-8. My proposal is to always pretend that something like en_US.UTF-8 was in effect for logging, i.e. encode in UTF-8 (though everything *should* be ASCII, afaics) and use English messages, date format, etc. Thanks for considering, Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336429: acknowledged by developer (Not a bug)
reopen 336429 thanks [EMAIL PROTECTED] (Debian Bug Tracking System) writes: Not a bug: It's the proper upstream manpage. It's an upstream bug, then. But it's still a bug, as the manpage does not fit the binary. -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355262: please ship NEWS
Package: libexif12 Version: 0.6.13-1 Severity: wishlist Tags: patch The attached patch puts upstream's NEWS file in /usr/share/doc/libexif12/ Please consider it for inclusion. Robbe diff -ruN libexif-0.6.13-/debian/libexif12.docs libexif-0.6.13/debian/libexif12.docs --- libexif-0.6.13-/debian/libexif12.docs 1970-01-01 01:00:00.0 +0100 +++ libexif-0.6.13/debian/libexif12.docs2006-03-04 16:03:15.0 +0100 @@ -0,0 +1 @@ +NEWS
Bug#355267: please ship docs/NEWS
Package: avahi Severity: wishlist Tags: patch It would be nice if upstream's NEWS file were available in /usr/share/doc/libavahi-common-data/. The attached patch should DTRT, but I have no insight into CDBS. diff -ruN avahi-0.6.9/debian/libavahi-common-data.docs avahi-0.6.9+/debian/libavahi-common-data.docs --- avahi-0.6.9/debian/libavahi-common-data.docs1970-01-01 01:00:00.0 +0100 +++ avahi-0.6.9+/debian/libavahi-common-data.docs 2006-03-04 16:26:08.0 +0100 @@ -0,0 +1 @@ +docs/NEWS
Bug#350791: build-depends on deprecated package svgalibg1-dev
Package: lirc Version: 0.7.2-2 Severity: normal Tags: patch libsvga1-dev seems to be the current development package for svgalib. -- Robbe diff -ruN lirc-0.7.2/debian/control lirc-0.7.2+/debian/control --- lirc-0.7.2/debian/control 2006-01-31 21:47:24.0 +0100 +++ lirc-0.7.2+/debian/control 2006-01-31 21:46:58.0 +0100 @@ -2,7 +2,7 @@ Section: utils Priority: extra Maintainer: Amaya Rodrigo Sastre [EMAIL PROTECTED] -Build-Depends: debhelper (= 4.2.20), libusb-dev, libasound2-dev, libice-dev, libsm-dev, libx11-dev, svgalibg1-dev [i386], libirman-dev, autotools-dev, devscripts, dpatch, libxt-dev +Build-Depends: debhelper (= 4.2.20), libusb-dev, libasound2-dev, libice-dev, libsm-dev, libx11-dev, libsvga1-dev [i386], libirman-dev, autotools-dev, devscripts, dpatch, libxt-dev Standards-Version: 3.6.2 Uploaders: Hector Garcia [EMAIL PROTECTED]
Bug#349912: please ship NEWS
Package: syslog-ng Version: 1.9.8.1 Severity: wishlist The upstream tarball includes a NEWS file, it would be nice if you installed that into /usr/share/doc/syslog-ng. TIA, Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346476: please provide a version based on wide-character ncurses (libncursesw5)
Package: libcurses-perl
Version: 1.12-1wide1
Severity: wishlist
Tags: patch
I'd like to be able to use curses from perl with wide-characters.
The attached patch builds an alternative version libcursesw-perl
that links to the wide libraries. It could be done cleaner by building
each version in a separate build-directory, but I don't know how to do
that with perl extensions. Therefore I punted and built both
alternatives from the install target.
Another option is to *always* link libcurses-perl with the wide
libraries, offering no narrow alternative. AFAICS libncursesw is
fully compatible with libncurses, so that should not be a problem, but
I don't know for sure. That would make the patch much cleaner.
Perhaps the two-alternatives option could be used for now, and the
wide-only option in the future.
The patch also includes an important dh_shlibdeps call, without which
the packages lack Depends: libncurses5 (this should probably be in a
separate bug).
diff -ruN libcurses-perl-1.13/debian/changelog
libcurses-perl-1.13+/debian/changelog
--- libcurses-perl-1.13/debian/changelog2006-01-06 19:18:10.0
+0100
+++ libcurses-perl-1.13+/debian/changelog 2006-01-07 11:25:52.0
+0100
@@ -1,3 +1,16 @@
+libcurses-perl (1.13-1rb1) unstable; urgency=low
+
+ * Build versions based on wide-character and normal (narrow) ncurses:
++ Build-depend on libcursesw5-dev as well.
++ The build target now does nothing.
++ Split off three sub-targets from the install target: install-pre,
+ and one for each library version to be built and installed.
++ Put the examples in both packages.
+ * dh_installdirs call was superflous.
+ * Add missing dh_shlibdeps call.
+
+ -- Robert Bihlmeyer [EMAIL PROTECTED] Sat, 7 Jan 2006 11:25:52 +0100
+
libcurses-perl (1.13-1) unstable; urgency=low
* New upstream release (Closes: #338211)
diff -ruN libcurses-perl-1.13/debian/control libcurses-perl-1.13+/debian/control
--- libcurses-perl-1.13/debian/control 2006-01-06 19:18:10.0 +0100
+++ libcurses-perl-1.13+/debian/control 2006-01-06 19:20:15.0 +0100
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Jay Bonci [EMAIL PROTECTED]
Standards-Version: 3.6.2.1
-Build-Depends: perl (= 5.8), libncurses5-dev, debhelper (= 4.0)
+Build-Depends: perl (= 5.8), libncurses5-dev, libncursesw5-dev, debhelper (=
4.0)
Package: libcurses-perl
Architecture: any
@@ -19,3 +19,16 @@
This package was previously called perl-curses. To comply with informal
Debian standards, it has been renamed to libcurses-perl.
+Package: libcursesw-perl
+Architecture: any
+Depends: ${perl:Depends}, ${shlibs:Depends}
+Provides: perl-curses, libcurses-perl
+Replaces: perl-curses
+Conflicts: perl-curses, libcurses-perl
+Description: Curses interface for Perl
+ libcurses-perl (the Curses module from CPAN) will let you
+ use the ncurses/curses terminal screen manipulation
+ routines from Perl programs.
+ .
+ This version of the package is based on the wide-character (unicode) version
+ of ncurses.
diff -ruN libcurses-perl-1.13/debian/dirs libcurses-perl-1.13+/debian/dirs
--- libcurses-perl-1.13/debian/dirs 2006-01-06 19:18:10.0 +0100
+++ libcurses-perl-1.13+/debian/dirs1970-01-01 01:00:00.0 +0100
@@ -1,6 +0,0 @@
-usr/bin
-usr/sbin
-usr/lib/perl5
-usr/share/doc/libcurses-perl
-usr/share/man/man1
-usr/share/man/man3
diff -ruN libcurses-perl-1.13/debian/libcursesw-perl.examples
libcurses-perl-1.13+/debian/libcursesw-perl.examples
--- libcurses-perl-1.13/debian/libcursesw-perl.examples 1970-01-01
01:00:00.0 +0100
+++ libcurses-perl-1.13+/debian/libcursesw-perl.examples2006-01-06
18:45:23.0 +0100
@@ -0,0 +1 @@
+demo*
diff -ruN libcurses-perl-1.13/debian/rules libcurses-perl-1.13+/debian/rules
--- libcurses-perl-1.13/debian/rules2006-01-06 19:18:10.0 +0100
+++ libcurses-perl-1.13+/debian/rules 2006-01-07 11:20:59.0 +0100
@@ -10,27 +10,38 @@
#PACKAGE=`pwd | sed -e s/.*\/\\(.*\\)-.*/\\1/`
PACKAGE='libcurses-perl'
+PACKAGEW='libcursesw-perl'
build:
- dh_testdir
- # Add here commands to compile the package.
- #perl Makefile.PL PANELS MENUS FORMS verbose INSTALLDIRS=vendor
- perl Makefile.PL PANELS MENUS verbose INSTALLDIRS=vendor
+
clean:
dh_testdir
dh_testroot
-$(MAKE) clean
- rm -f Makefile.old
+ rm -f Makefile.old stamp-install-narrow stamp-install-wide
dh_clean
-install:
+install-pre:
dh_testdir
dh_testroot
- dh_clean -k
- dh_installdirs
+stamp-install-narrow:
+ -$(MAKE) clean
+ perl Makefile.PL PANELS MENUS verbose INSTALLDIRS=vendor
$(MAKE) PREFIX=$(CURDIR)/debian/$(PACKAGE)/usr OPTIMIZE=-O2 -g -Wall
test install
+ touch $@
+
+stamp-install-wide:
+ -$(MAKE) clean
+ CURSES_CFLAGS=-I/usr/include/ncursesw CURSES_LDFLAGS=-lncursesw \
+ CURSES_PANEL_LDFLAGS=-lpanelw CURSES_MENU_LDFLAGS
