Bug#816607: void EncoderStrategy::AppendToBitStream(LONG, LONG): Assertion `bitpos >=0' failed
I forgot to mention, to compile this testcase: g++ test_dcmtk.cpp -O0 -g -o test_dcmtk -rdynamic -ldcmdata -ldcmimage -ldcmimgle -ldcmjpeg -ldcmnet -ldcmpstat -ldcmqrdb -ldcmsr -ldcmtls -lijg12 -lijg16 -lijg8 -lofstd -ldcmjpls -loflog -I/usr/include -DHAVE_CONFIG_H It ignores any arguments given at runtime. Op do 3 mrt. 2016 om 23:09 schreef Sjors Gielen <sj...@sjorsgielen.nl>: > Hello Matthieu, > > A test case is attached. It allocates an uncompressed 1165 by 1434 pixel > 16-bit image, and writes a relatively small set of pixels while still > reproducing the issue. > > It then fills a DcmFileFormat wih the values required to store it as a > valid Dicom JPEG-LS image. During the dcmff.saveFile() call, the assertion > failure happens: > > test_dcmtk: /home/sjors/src/charls-1.0/encoderstrategy.h:81: void > EncoderStrategy::AppendToBitStream(LONG, LONG): Assertion `bitpos >=0' > failed. > > Hopefully this will allow you to reproduce as well. I know about three > fixes/workarounds (I don't know which one applies): > 1. The patch dcmtk applied, which returns before the assertion is ever > checked, > 2. Calling Flush() again if bitpos is still lower than 0, or > 3. Increasing the amount of iterations in Flush() so that bitpos cannot be > lower than 0 after returning from that function. > > Maybe some input from the CharLS developers would be useful here. > > Sjors > > Op do 3 mrt. 2016 om 22:37 schreef Sjors Gielen <sj...@sjorsgielen.nl>: > >> Hello Mathieu, >> >> I have a working test-case, but as it contains an uncompressed image, it >> is currently 7 MB. I'm trying to make it smaller before I'll upload it, and >> hope to have that done by tomorrow. It uses CharLS through DCMTK – which, >> on Debian, uses system CharLS, not the DCMTK-shipped one. >> >> I have been using the patch you linked as a workaround in the past, but >> upstream CharLS has expressed doubts over the patch as committed to DCMTK's >> shipped CharLS. I haven't verified these doubts myself, but the patch is >> not applied to CharLS upstream either. See: >> http://charls.codeplex.com/workitem/10742 and >> https://github.com/team-charls/charls/blob/master/src/encoderstrategy.h#L83 >> . >> >> Interestingly, in the first link above, upstream says the problem is >> linked in this changeset: >> https://github.com/team-charls/charls/commit/c7cf959f348f8e0c47f1197c89ef959372c572e9 >> – >> I can see that that changeset adds a test, but not that it fixes the actual >> issue upstream... >> >> Sjors >> >> Op do 3 mrt. 2016 om 21:15 schreef Mathieu Malaterre <ma...@debian.org>: >> >>> Control: tags -1 moreinfo >>> >>> Dear OP, >>> >>> Since you did not provide material to reproduce the issue, did you try >>> the proposed patch ? >>> >>> >>> http://git.dcmtk.org/?p=dcmtk.git;a=commitdiff;h=d885abd90ef90f6566555298064190561ff0412a >>> >>> Unless some kind of sample file is provided I cannot possibly include >>> a fix for the next upload. >>> >>
Bug#816607: libcharls1: void EncoderStrategy::AppendToBitStream(LONG, LONG): Assertion `bitpos >=0' failed
Package: libcharls1 Version: 1.0-6 Severity: important Dear Maintainer, I can reliably reproduce an assertion failure in LibCharLS version 1.0-6. My investigation into this is still pending, but nonetheless I wanted to raise this early so that we could discuss potential fixes. The assertion happens in EncoderStrategy with very specific inputs, that occur for me in production. From my early investigation, I can see that the AppendToBitStream function is called while bitpos is 0, with a length of 31, causing bitpos to become -31. The Flush() function is then called to raise bitpos back to >= 0, but after 4 iterations bitpos is still at -1, causing an assertion failure. I'm not sure yet about the semantic meaning of this, or where the true bug is. This bug has been known upstream for a while[0], and is said to be fixed in master, but there has been no CharLS release for years and I haven't figured out where it is fixed exactly just yet. I can reproduce this bug by saving a lossless JPEG image through the DICOM Toolkit. It appears I'm not the only one, as somebody reported this already in 2012[1] and a colleague of mine in 2014[2]. I will attempt to produce a fully self-sufficient test case without DCMTK if needed. [0] http://charls.codeplex.com/workitem/10742 [1] http://forum.dcmtk.org/viewtopic.php?f=1=3412 [2] https://bugs.launchpad.net/ubuntu/+source/charls/+bug/1329695 -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libcharls1 depends on: ii libc6 2.21-9 ii libgcc11:5.3.1-8 ii libstdc++6 5.3.1-8 ii multiarch-support 2.21-9 libcharls1 recommends no packages. libcharls1 suggests no packages. -- no debconf information
Bug#751634: /usr/lib/xbmc/xbmc.bin: XBMC aborts when scrolling over some directory
Package: xbmc-bin Version: 2:11.0~git20120510.82388d5-1+b1 Severity: important File: /usr/lib/xbmc/xbmc.bin Since upgrading from Wheezy to Jessie, xbmc has started to crash (sometimes SIGABRT, sometimes SIGSEGV) while scrolling through a directory of videos that previously worked fine. The specific directory it crashes on tends to change a bit, but there is one that has always made XBMC crash until now. Next to the crash itself, this also means I cannot scroll past the directory in question, unless I connect a mouse, therefore filing as important. I've tried to gather as much information as I could without rebuilding the package with debugging symbols and checking the source. The steps to reproduce are not very helpful, but including them for completeness as follows: 1. Start Xbmc and control it through the API (I use 'xbmc_control' for this). I doubt this matters, but noting anyway. 2. From the Home screen, use right and left inputs to go to Movies. 3. Press Down, go right to Files, press Select. 4. Scroll through the list of movies. In my case, I scroll 2 down, select, 3 down, select, 5 down, select. 5. At the moment I start scrolling through this list (by pressing down), Xbmc aborts. I've enabled Xbmc's debug logging and connected a Gdb instance. The moment I press the down key, Gdb reports SIGABRT or SIGSEGV (it differs). One stack trace I captured looks like pasted below. Considering the symptoms I think chances are high this is some generic memory corruption and if this bug is not already fixed in newer versions of xbmc, it probably needs to be upstreamed. (gdb) bt #0 0x7fecbe130064 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fecbe131c00 in malloc () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x7fecbe6bb07d in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x7fecbe6bb179 in operator new[](unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x008d7fbb in CBaseTexture::Allocate(unsigned int, unsigned int, unsigned int) () #5 0x008d86ec in CBaseTexture::LoadFromFile(CStdStrchar const, unsigned int, unsigned int, bool, unsigned int*, unsigned int*) () #6 0x00d9f35c in CImageLoader::DoWork() () #7 0x00714649 in CJobWorker::Process() () #8 0x00d204e2 in CThread::staticThread(void*) () #9 0x7fecc4908b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #10 0x7fecbe1920ed in clone () from /lib/x86_64-linux-gnu/libc.so.6 #11 0x in ?? () (gdb) info threads Id Target Id Frame * 23 Thread 0x7feca2a76700 (LWP 3046) xbmc.bin 0x7fecbe130064 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 11 Thread 0x7fecae6ae700 (LWP 2543) xbmc.bin 0x7fecbe1874a3 in poll () from /lib/x86_64-linux-gnu/libc.so.6 10 Thread 0x7fecadead700 (LWP 2547) xbmc.bin 0x7fecbe187571 in ppoll () from /lib/x86_64-linux-gnu/libc.so.6 9Thread 0x7fecacc92700 (LWP 2549) xbmc.bin 0x7fecc31c2201 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 8Thread 0x7feca3ffe700 (LWP 2550) xbmc.bin 0x7fecbe18bbe3 in select () from /lib/x86_64-linux-gnu/libc.so.6 7Thread 0x7fecad6ac700 (LWP 2555) xbmc.bin 0x7fecbe18bbe3 in select () from /lib/x86_64-linux-gnu/libc.so.6 6Thread 0x7feca2275700 (LWP 2556) xbmc.bin 0x7fecbe1874a3 in poll () from /lib/x86_64-linux-gnu/libc.so.6 5Thread 0x7feca1a74700 (LWP 2557) xbmc.bin 0x7fecbe18bbe3 in select () from /lib/x86_64-linux-gnu/libc.so.6 4Thread 0x7feca1273700 (LWP 2558) xbmc.bin 0x7fecbe18bbe3 in select () from /lib/x86_64-linux-gnu/libc.so.6 3Thread 0x7fec9bfff700 (LWP 2560) xbmc.bin 0x7fecbe18bbe3 in select () from /lib/x86_64-linux-gnu/libc.so.6 2Thread 0x7fec9b7fe700 (LWP 2561) xbmc.bin 0x7fecbe18bbe3 in select () from /lib/x86_64-linux-gnu/libc.so.6 1Thread 0x7fecc89637a0 (LWP 2529) xbmc.bin 0x7fecbe1874a3 in poll () from /lib/x86_64-linux-gnu/libc.so.6 The debug log mentions, apart from the import that it is doing at the same time, only the incoming JSONRPC request to press Input.down and that the down (f081) key was indeed pressed. Also, some Thread Jobworker start, auto detete: 1 but I don't know if this is related to the key press or to the import step. It's worth noting I saw this crash happen also when the importer was not running at the same time. I'll see if I have time to update to the newest version of Xbmc in unstable, and build it with debugging symbols and maybe the address sanitizer to see if I can gather more information about this bug to triage it upstream. -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xbmc-bin depends on: ii
Bug#751634: Erratum
The bug report says since upgrading from wheezy to jessie, but I just noticed I didn't even do that yet: this bug occurs on vanilla wheezy. I'll try upgrading to xbmc from wheezy-backports to see if the bug still occurs there. Sjors signature.asc Description: OpenPGP digital signature
Bug#745419: [Pkg-xen-devel] Bug#745419: xen-utils-4.1: Pygrub fails to boot from LVM LV when something installed in the volume boot record
Hi Ian, Thanks for your reply. My thoughts are inline. Ian Campbell schreef op 22-04-14 16:14: I'm afraid I don't follow your logic here. is_disk_image is trying to determine whether or not the device (be it a virtual device or otherwise) contains a partition table or not. A device with a partition table is a disk image as in a full disk image, as opposed to a device which is unpartitioned and could be used via the per partition block device thing in the block driver. Ah, that makes sense. So is_disk_image is used to decide whether we're giving it /dev/sda or /dev/sda1, i.e. there is a partition table/possibility of multiple partitions, or a single partition that fills the device. Still, the problem remains there was a single partition, but it thought there was a partition table. It seems that your block device does include the DOS MBR/partition table indicator (the 0x55aa signature at the end of the first sector) and therefore is considered to be a disk image. But perhaps it doesn't actually contain a valid partition table? What does fdisk -l report for this device? It would seem so. This was caused by the grub-pc install script; it may have thought /dev/xvda2 was a disk instead of a partition. `fdisk -l` seems to indicate a valid but empty list of partitions: Disk /dev/vpsdisks/blup.kassala.de-disk: 4294 MB, 4294967296 bytes 255 heads, 63 sectors/track, 522 cylinders, total 8388608 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x Device Boot Start End Blocks Id System Do you think it would be possible for Pygrub to detect this situation and continue booting from a single-partition image? Does this still happen with pygrub from a newer Xen? I can see that much has changed around this area since 4.1.x. If you can reproduce with something newer then I think your best bet is to report this upstream: http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen I've noticed and investigated this bug on a production Xen machine. At this moment I have no spare machine to test with later versions of Xen. Maybe it would be possible for someone else to test this, or I can try looking through pygrub's history on Xen trunk soon. Sjors signature.asc Description: OpenPGP digital signature
Bug#745419: xen-utils-4.1: Pygrub fails to boot from LVM LV when something installed in the volume boot record
Package: xen-utils-4.1 Version: 4.1.4-3+deb7u1 Severity: important When an LVM LV that serves as the root disk for a Xen DomU contains a boot loader (or possibly other data) in its volume boot record, pygrub fails to boot it, printing Error: boot loader didn't return any data before exiting. I think this is because of the function is_disk_image on line 45 of /usr/lib/xen-4.1/bin/pygrub: it should return false on LVM LV's because they are not disk images but virtual devices, but it returns true because of certain bytes in the first block of 512 bytes being set. This causes get_partition_offsets to seek fruitlessly for a partition instead of simply returning [0], causing the bootloader not to find the right partition. Detailed steps to reproduce: We have a domU called blup.kassala.de, it is running Jessie, its root disk is a LVM LV at /dev/vpsdisks/blup.kassala.de-disk. The first 512 bytes are null: # dd if=/dev/vpsdisks/blup.kassala.de-disk bs=1 count=512 | hexdump -C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0200 xm create -c blup.kassala.de.cfg shows the machine boots fine. After boot, we log in and apt-get install grub2. During the installation, we say to install the bootloader to /dev/xvda2, the root disk. We then halt the system. The first 512 bytes are now non-null: # dd if=/dev/vpsdisks/blup.kassala.de-disk bs=1 count=512 | hexdump -C eb 63 90 00 00 00 00 00 00 00 00 00 00 00 00 00 |.c..| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0050 00 00 00 00 00 00 00 00 00 00 00 80 80 12 46 00 |..F.| 0060 00 00 00 00 ff fa 90 90 f6 c2 80 74 05 f6 c2 70 |...t...p| [snip] 0180 7d e8 2e 00 cd 18 eb fe 47 52 55 42 20 00 47 65 |}...GRUB .Ge| 0190 6f 6d 00 48 61 72 64 20 44 69 73 6b 00 52 65 61 |om.Hard Disk.Rea| 01a0 64 00 20 45 72 72 6f 72 0d 0a 00 bb 01 00 b4 0e |d. Error| 01b0 cd 10 ac 3c 00 75 f4 c3 00 00 00 00 00 00 00 00 |u..| 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| 0200 We try to boot the DomU again: # xm create -c blup.kassala.de.cfg Using config file ./blup.kassala.de.cfg. Error: Boot loader didn't return any data! We write 512 nullbytes to the disk and retry booting the domU: # dd if=/dev/zero of=/dev/vpsdisks/blup.kassala.de-disk bs=1 count=512 # xm create -c blup.kassala.de.cfg The pyGRUB menu appears normally and the machine boots. -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xen-utils-4.1 depends on: ii e2fslibs 1.42.5-1.1 ii libc6 2.13-38+deb7u1 ii libgnutls26 2.12.20-8+deb7u1 ii libncurses5 5.9-10 ii libpci3 1:3.1.9-6 ii libtinfo5 5.9-10 ii libuuid1 2.20.1-5.3 ii libxen-4.14.1.4-3+deb7u1 ii libxenstore3.04.1.4-3+deb7u1 ii python2.7.3-4+deb7u1 ii python2.7 2.7.3-6+deb7u2 ii xen-utils-common 4.1.4-3+deb7u1 ii zlib1g1:1.2.7.dfsg-13 Versions of packages xen-utils-4.1 recommends: ii bridge-utils 1.5-6 ii qemu-keymaps 1.1.2+dfsg-6a+deb7u1 ii qemu-utils 1.1.2+dfsg-6a+deb7u1 ii xen-hypervisor-4.1-amd64 [xen-hypervisor-4.1] 4.1.4-3+deb7u1 Versions of packages xen-utils-4.1 suggests: pn xen-docs-4.1 none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745419: xen-utils-4.1: Pygrub fails to boot from LVM LV when something installed in the volume boot record
Sjors Gielen schreef op 21-04-14 15:43: When an LVM LV that serves as the root disk for a Xen DomU contains a boot loader (or possibly other data) in its volume boot record, pygrub fails to boot it, printing Error: boot loader didn't return any data before exiting. Forgot to include three details: * filed as important because the bug has a major effect on the usability of the package. Especially if the domU is maintained by someone who has no acces to dom0, he might inexplicably break the booting of his system without being able to fix it. (The dom0 administrator also gets a very vague error message, so he might be unable to fix it too.) * We couldn't reproduce this bug on a Wheezy domU because there, the grub-pc configuration wouldn't write to /dev/xvda2. So if you try to reproduce but can't, double-check this. * Also, if you try to reproduce, make sure to halt the DomU before checking if the first 512 bytes were updated; we noticed this update was not always immediately visible on the dom0, even after running `sync` in the domU. Probably waiting a while also works, but if you want to be sure, halt it. signature.asc Description: OpenPGP digital signature
Bug#705115: cannot compile this atomic library call yet fixed in clang trunk
This bug is fixed in Clang trunk, revision 183033: http://llvm.org/viewvc/llvm-project?view=revisionrevision=183033 This fix will be in Clang 3.4, probably not in Clang 3.3. Considering this bug makes clang-3.2 unusable on armhf for any serious code, maybe a back-port of this patch would be something good to try? signature.asc Description: OpenPGP digital signature
Bug#705115: cannot compile this atomic library call yet fixed in clang trunk
Erratum: even though revision 183033 is supposed to fix this bug on
architectures for which we don't provide these operations as builtins
(e.g. ARM), I've just compiled Clang from the earlier revision 182770 and in
there, the following test program already compiles and runs fine:
sjors@baz:~/clang/test$ cat stdcout.cpp
#include iostream
int main() {
std::cout Hello World std::endl;
}
sjors@baz:~/clang/test$ ./stdcout
Hello World
So it appears this bug was fixed (at least on ARM) earlier than r183033,
specifically between 3.2 and r182770. I have yet to find out exactly what
commit did it. This could be good news for this bug.
signature.asc
Description: OpenPGP digital signature
Bug#701943: quassel-core: Only start quassel-core after its database
Package: quassel-core Version: 0.8.0-1 Severity: normal Tags: patch The init script /etc/init.d/quassel-core allows starting quassel-core before its databases are set up. This is OK in the default configuration where quassel-core uses SQLite, but on large setups quassel-core is set up using a back-end of PostgreSQL or MySQL, so quassel-core has no database when it initially starts. This causes quassel-core to go into initial set-up mode, allowing anyone who connects with it to reconfigure it. The solution is to only start quassel-core when mysql and postgresql have started, if they exist. Therefore, these two services should be added to the Should-Start and Should-Stop lines: # Should-Start: mysql postgresql # Should-Stop: mysql postgresql Filing as normal, because this bug only appears on non-default (but common) set-ups, and makes the application initially unusable on them. Only after a restart of the daemon (preferably before someone re-configuring it) does the application start to act as intended. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages quassel-core depends on: ii adduser3.113+nmu3 ii libc6 2.13-38 ii libgcc11:4.7.2-5 ii libqca22.0.3-4 ii libqt4-network 4:4.8.2+dfsg-11 ii libqt4-script 4:4.8.2+dfsg-11 ii libqt4-sql 4:4.8.2+dfsg-11 ii libqt4-sql-sqlite 4:4.8.2+dfsg-11 ii libqtcore4 4:4.8.2+dfsg-11 ii libstdc++6 4.7.2-5 ii lsb-base 4.1+Debian8 ii openssl1.0.1e-1 quassel-core recommends no packages. quassel-core suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701943: quassel-core: Only start quassel-core after its database
Erratum: the init script is at /etc/init.d/quasselcore (without the dash). signature.asc Description: OpenPGP digital signature
Bug#700717: request-tracker4: Server path display issue in /usr/bin/rt
Package: request-tracker4
Version: 4.0.7-4
Severity: minor
When Request Tracker is installed under a path, such as
https://rt.example.org/rt, the /usr/bin/rt tool does not display the path
correctly. This makes debugging connection issues harder, for example.
To reproduce, run: RTSERVER=https://rt.example.org/rt; rt edit ticket/6
This gives as output Password will be sent to rt.example.orgrt over SSL,
instead of rt.example.org/rt. This is caused by line 1016 in /usr/bin/rt:
(my $server = $config{server}) =~ s/^.*\/\/([^\/]+)\/?/$1/;
This regular expression removes everything before the first two slashes, then
takes everything before the next slash, and removes the next slash too. If the
idea here is to take only the hostname, a .*$ should be added to the match part
of the regular expression; if the idea is to include the path it should either
be inside the parantheses or be within its own parantheses and $2 should be
added to the replace option. So either of the following three lines fix this
problem:
(my $server = $config{server}) =~ s/^.*\/\/([^\/]+)\/?.*$/$1/;
(my $server = $config{server}) =~ s/^.*\/\/([^\/]+\/?)/$1/;
(my $server = $config{server}) =~ s/^.*\/\/([^\/]+)(\/)?/$1$2/;
Filing as minor because $server is only used for cosmetic purposes.
-- Package-specific info:
Changed files:
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages request-tracker4 depends on:
ii dbconfig-common 1.8.47+nmu1
ii debconf [debconf-2.0]1.5.49
ii fonts-droid [ttf-droid] 20111207+git-1
ii libapache-session-perl 1.89-1
ii libcache-simple-timedexpiry-perl 0.27-2
ii libcgi-emulate-psgi-perl 0.14-1
ii libcgi-psgi-perl 0.15-1
ii libclass-accessor-perl 0.34-1
ii libclass-returnvalue-perl0.55-1
ii libconvert-color-perl0.08-1
ii libcss-squish-perl 0.09-1
ii libdata-ical-perl0.18+dfsg-1
ii libdatetime-locale-perl 1:0.45-1
ii libdatetime-perl 2:0.7500-1
ii libdbi-perl 1.622-1
ii libdbix-searchbuilder-perl 1.62-1
ii libdevel-globaldestruction-perl 0.06-1
ii libdevel-stacktrace-perl 1.2700-1
ii libemail-address-perl1.895-1
ii libfcgi-procmanager-perl 0.24-1
ii libfile-sharedir-perl1.00-0.1
ii libgd-graph-perl 1.44-6
ii libgd-text-perl 0.86-8
ii libgnupg-interface-perl 0.45-1
ii libgraphviz-perl 2.10-1
ii libhtml-format-perl 2.10-1
ii libhtml-mason-perl 1:1.48-1
ii libhtml-mason-psgihandler-perl 0.52-1
ii libhtml-quoted-perl 0.03-1
ii libhtml-rewriteattributes-perl 0.04-1
ii libhtml-scrubber-perl0.09-1
ii libhtml-tree-perl5.02-1
ii libipc-run-perl 0.92-1
ii libipc-run3-perl 0.045-1
ii libjson-perl 2.53-1
ii liblist-moreutils-perl 0.33-1+b1
ii liblocale-maketext-fuzzy-perl0.11-1
ii liblocale-maketext-lexicon-perl 0.91-1
ii liblog-dispatch-perl 2.32-1
ii libmailtools-perl2.09-1
ii libmime-tools-perl [libmime-perl]5.503-1
ii libmime-types-perl 1.35-1
ii libmodule-versions-report-perl 1.06-1
ii libnet-cidr-perl 0.15-1
ii libperlio-eol-perl 0.14-1+b3
ii libplack-perl0.9989-1
ii libregexp-common-net-cidr-perl 0.02-1
ii libregexp-common-perl2011121001-1
ii libregexp-ipv6-perl 0.03-1
ii libtext-autoformat-perl 1.669002-1
ii libtext-password-pronounceable-perl 0.30-1
ii libtext-quoted-perl 2.06-1
ii libtext-template-perl1.45-2
ii libtext-wikiformat-perl 0.79-1
ii libtext-wrapper-perl 1.04-1
ii libtime-modules-perl 2011.0517-1
ii libtimedate-perl 1.2000-1
ii libtree-simple-perl 1.18-1
ii libuniversal-require-perl0.13-1
ii liburi-perl 1.60-1
ii libxml-rss-perl 1.49-1
ii libxml-simple-perl 2.20-1
ii perl [libencode-perl]5.14.2-16
ii perl-modules [libfile-temp-perl] 5.14.2-16
ii postfix [mail-transport-agent] 2.9.3-2.1
ii rsyslog [system-log-daemon] 5.8.11-2
ii rt4-apache2 4.0.7-4
ii rt4-clients
Bug#698998: felix-main: felix-framework requires java-wrappers to be installed, but it's not listed as a dependency
Package: felix-main Version: 4.0.1-2 Severity: important felix-main includes a script called felix-framework, which is a short-hand for starting the Felix framework in one go. This script sources the file /usr/lib/java-wrappers/java-wrappers.sh without checking whether that file exists. The file comes from the java-wrappers package, but that package is not listed as a dependency for felix-main. This causes using the felix-framework tool to fail if java-wrappers is not installed. Two solutions are possible: java-wrappers can be added as a run-time dependency for the felix-main package, or a check can be added to the tool not to source the /usr/lib/java-wrappers/java-wrappers.sh file if it doesn't exist. Without the felix-framework short-hand, the Felix framework can still be used by calling java -jar /usr/share/felix-framework/bin/felix.jar yourself. Therefore I'm giving this bug Severity: important for breaking a normal use-case but not breaking the pacakge completely. sjors@foo:~$ felix-framework /usr/bin/felix-framework: 9: .: Can't open /usr/lib/java-wrappers/java-wrappers.sh sjors@foo:~$ sudo apt-get install java-wrappers […] sjors@foo:~$ felix-framework […] Welcome to Apache Felix Gogo g! -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages felix-main depends on: ii libfelix-bundlerepository-java 1.6.6-1 ii libfelix-gogo-command-java 0.12.0-2 ii libfelix-gogo-runtime-java 0.10.0-2 ii libfelix-gogo-shell-java0.10.0-2 ii libfelix-main-java 4.0.1-2 felix-main recommends no packages. Versions of packages felix-main suggests: pn libfelix-main-java-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690733: dcmtk: There should be a debug package
Package: dcmtk
Version: 3.6.0-9.1~sjors1
Severity: wishlist
Dear Maintainer,
I think it would be great if dcmtk had a libdcmtk2-dbg package to help
debugging the binaries and shared libraries of dcmtk. In fact, I've gone ahead
and created a patch that will add a -dbg package as mentioned, with the correct
debugging symbols, created using Debian policies. Please let me know if you can
merge it like this, or if you need anything else.
-- System Information:
Debian Release: wheezy/sid
APT prefers precise-updates
APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500,
'precise')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-31-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dcmtk depends on:
ii adduser 3.113ubuntu2
ii libc62.15-0ubuntu10.2
ii libcharls1 1.0-1
ii libdcmtk23.6.0-9.1~sjors1
ii libgcc1 1:4.6.3-1ubuntu5
ii libjpeg8 8c-2ubuntu7
ii libpng12-0 1.2.46-3ubuntu4
ii libssl1.0.0 1.0.1-4ubuntu5.5
ii libstdc++6 4.6.3-1ubuntu5
ii libtiff4 3.9.5-2ubuntu1.2
ii libwrap0 7.6.q-21
ii libxml2 2.7.8.dfsg-5.1ubuntu4.2
ii zlib1g 1:1.2.3.4.dfsg-3ubuntu4
dcmtk recommends no packages.
dcmtk suggests no packages.
-- no debconf information
diff -Nurd dcmtk-3.6.0/debian/changelog debian/changelog
--- dcmtk-3.6.0/debian/changelog 2011-11-23 16:31:46.0 +0100
+++ debian/changelog 2012-10-15 21:01:19.565216697 +0200
@@ -1,3 +1,10 @@
+dcmtk (3.6.0-9.1~sjors1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Add libdcmtk2-dbg package for debugging symbols.
+
+ -- Sjors Gielen sj...@sjorsgielen.nl Mon, 15 Oct 2012 16:11:03 +0200
+
dcmtk (3.6.0-9) unstable; urgency=low
* Remove dot wrapper, not required anymore.
diff -Nurd dcmtk-3.6.0/debian/control debian/control
--- dcmtk-3.6.0/debian/control 2011-11-23 16:31:46.0 +0100
+++ debian/control 2012-10-15 21:01:19.565216697 +0200
@@ -89,3 +89,18 @@
.
This package contains the on-line documentation for the DCMTK libraries
and utilities in HTML format.
+
+Package: libdcmtk2-dbg
+Section: debug
+Architecture: any
+Priority: extra
+Depends: libdcmtk2 (= ${binary:Version}), ${misc:Depends}
+Conflicts: libdcmtk0, libdcmtk0c2, dcmtk ( 3.6.0)
+Replaces: libdcmtk0, libdcmtk0c2
+Description: OFFIS DICOM toolkit library debugging symbols
+ DCMTK includes a collection of libraries and applications for examining,
+ constructing and converting DICOM image files, handling offline media,
+ sending and receiving images over a network connection, as well as
+ demonstrative image storage and worklist servers.
+ .
+ This package contains the debugging symbols for libdcmtk2.
diff -Nurd dcmtk-3.6.0/debian/rules debian/rules
--- dcmtk-3.6.0/debian/rules 2011-11-23 15:57:10.0 +0100
+++ debian/rules 2012-10-16 23:43:32.092784636 +0200
@@ -153,7 +153,7 @@
# Do not forget to install the shared libs as well
# TODO: make use of d-shlibs (andreas tille)
find $(CURDIR) -path $(CURDIR)/debian -prune -o \
- -name 'lib*.so' -exec install -s -m 644 \{\} $(PKGDIR_DCMTK_LIB)/usr/lib \;
+ -name 'lib*.so' -exec install -m 644 \{\} $(PKGDIR_DCMTK_LIB)/usr/lib \;
# Fix filenames / add symlinks for shared libs
for i in $(PKGDIR_DCMTK_LIB)/usr/lib/*.so; do \
@@ -175,7 +175,7 @@
dh_install -i
dh_link -i
dh_lintian -i
- dh_strip -i
+ dh_strip --dbg-package=libdcmtk2-dbg -i
dh_compress -i
dh_fixperms -i
dh_installdeb -i
@@ -198,7 +198,7 @@
mv $(PKGDIR_DCMTK)/usr/share/dcmtk/*.dic $(PKGDIR_DCMTK_LIB)/usr/share/dcmtk/
dh_link -a
dh_lintian -a
- dh_strip -a
+ dh_strip --dbg-package=libdcmtk2-dbg -a
dh_compress -a
dh_fixperms -a
dh_perl -a
Bug#649520: munin: Munin should not automatically add itself to Apache configuration
Package: munin Version: 1.4.6-1 Severity: wishlist Munin installs itself into /etc/apache2/conf.d, which makes Apache automatically load access rules for the Munin configuration for every address in Apache. This is both unexpected and insecure. The problem is the following line in the postinst script: ln -s ../../munin/apache.conf /etc/$webserver/conf.d/munin For this purpose, /etc/apache2/mods-available exists. If Munin would insert its Apache configuration here, it would not be autoloaded, but would still be easily loaded using a2enmod munin. Therefore, I would like to request for the above line to be changed to: ln -s ../../munin/apache.conf /etc/$webserver/mods-available/munin This makes Munin installation behave as expected. If you want, you can display installation hints as to a2enmod munin for adding a '/munin' to every host Apache serves. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages munin depends on: ii adduser3.113 ii cron 3.0pl1-120 ii libdigest-md5-perl none ii libhtml-template-perl 2.10-1 ii liblog-log4perl-perl 1.29-1 ii librrds-perl 1.4.3-3.1+b2 ii libstorable-perl none ii munin-common 1.4.6-1 ii perl [libtime-hires-perl] 5.12.4-6 ii perl-modules 5.12.4-6 ii rrdtool1.4.3-3.1+b2 ii ttf-dejavu 2.33-2 Versions of packages munin recommends: ii libdate-manip-perl 6.25-1 ii munin-node 1.4.6-1 Versions of packages munin suggests: ii apache2-mpm-itk [httpd] 2.2.21-2 ii elinks [www-browser] 0.12~pre5-4 ii libnet-ssleay-perl 1.42-1 ii links [www-browser] 2.3-1 -- Configuration Files: /etc/munin/apache.conf changed [not included] /etc/munin/munin.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634826: Please package the last version
Package: trac-git Version: 0.0.20100513-2 Followup-For: Bug #634826 This version of the package is unusable next to trac -- not only does it not work with version 0.12, it also gives some vague error instead of bailing out with a clear message. It would be better if this package had trac 0.12 in its dependencies, but better yet if it were updated to the newest version of trac-git: http://trac-hacks.org/wiki/GitPlugin. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages trac-git depends on: ii git [git-core] 1:1.7.6.3-1 ii python 2.7.2-8 ii python-central 0.6.17 ii trac0.12.2-1 trac-git recommends no packages. trac-git suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647893: quassel-core: Silently disables SSL support if a certificate is expired
Package: quassel-core Version: 0.7.3-1 Severity: important Tags: upstream Quassel-core by default reads a quasselCert.pem file, containing a certificate and a private key, to determine if it can enable SSL support for communication between client and core. If it couldn't load the certificate, it silently disables SSL support for communication. This also means that if the certificate is expired, the core will be unable to load it, and silently disable SSL support. There is no mention of this in the logs, unless one enables the non-standard debug mode, then there is a single message failed to load certificate, will continue without ssl support (nothing about expiration). In my opinion, determining whether to enable SSL support should be a configuration setting, not a check if a file can be loaded, but that's maybe too large a change. At the very least, Quassel should log messages of type error if the certificate is expired or otherwise invalid, but it does exist. Then, I think it should still load the certificate if it is only expired, and enable SSL support, and let the client decide whether it wants to connect. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages quassel-core depends on: ii adduser3.113 ii libc6 2.13-21 ii libgcc11:4.6.1-4 ii libqca22.0.3-2 ii libqt4-network 4:4.7.3-5 ii libqt4-script 4:4.7.3-5 ii libqt4-sql 4:4.7.3-5 ii libqt4-sql-sqlite 4:4.7.3-5 ii libqtcore4 4:4.7.3-5 ii libstdc++6 4.6.1-4 ii lsb-base 3.2-28 ii openssl1.0.0e-2 quassel-core recommends no packages. quassel-core suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647893: quassel-core: Silently disables SSL support if a certificate is expired
Apparantly I have failed here: this message did show in my log prior to start-up: 2011-10-18 19:41:18 Warning: SslServer: Invalid certificate 2011-10-18 19:41:18 Warning: SslServer: Unable to set certificate file Quassel Core will still work, but cannot provide SSL for client connections. Please see http://quassel-irc.org/faq/cert to learn how to enable SSL support. 2011-10-18 19:41:18 Warning: SslServer: Invalid certificate 2011-10-18 19:41:19 Info: PostgreSQL Storage Backend is ready. Quassel Schema Version: 16 Still, in my opinion, in the case of an expired certificate it is the clients' decision whether or not to allow it, so the core should accept it (and the client should warn about it). But regarding the log message -- I did not check carefully enough and overlooked it, my apologies. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610729: mpt-status fails to find HP Proliant RAID array, keeps sending failure e-mails
Package: mpt-status Version: 1.2.0-7 Severity: normal The mpt-status tool was installed on my Debian Lenny HP Proliant server after installation. It instantly began sending me an e-mail every two hours containing just: This is a RAID status update from mpt-statusd. The mpt-status program reports that one of the RAIDs changed state: Report from /etc/init.d/mpt-statusd on [hostname] Running the tool myself, I found the mptctl wasn't loaded into my kernel. After loading it, the tool asked me to run mpt-status -d to find my SCSI ID, because it couldn't find any disks. The two-hourly e-mail from mpt-status started telling me this too at this point. mpt-status -d subsequently checked 16 SCSI ID's, but couldn't find a disk. This HP Proliant has a Compaq Smart Array 64xx which can be perfectly queried with array-info. mpt-statusd should either get support for it, or it should not send me those e-mails automatically, and maybe it shouldn't have been installed in the first place if it won't support my hardware. -- System Information: Debian Release: 6.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mpt-status depends on: ii daemon 0.6.4-1 turns other processes into daemons ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip mpt-status recommends no packages. Versions of packages mpt-status suggests: ii bsd-mailx [mailx] 8.1.2-0.20100314cvs-1 simple mail user agent -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610730: mpt-status: -p asks to e-mail author if no SCSI device can be found, but author e-mail address is nonexistant
Package: mpt-status Version: 1.2.0-7 Severity: minor File: mpt-status The mpt-status executable might not detect a hardware RAID in your SCSI ID's correctly. In this case, mpt-status -p will fail to find the drive, and say Nothing found, contact the author. The author e-mail address in the manpage (Roberto Nibali r...@drugphish.ch), doesn't exist (results in a delivery failure 550 No Such User Here). The manpage should probably be updated, or the mpt-status tool should be updated to say something like Nothing found, please report this as a bug (on the Debian bugtracker). -- System Information: Debian Release: 6.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mpt-status depends on: ii daemon 0.6.4-1 turns other processes into daemons ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip mpt-status recommends no packages. Versions of packages mpt-status suggests: ii bsd-mailx [mailx] 8.1.2-0.20100314cvs-1 simple mail user agent -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sune Vuorela wrote: Package: wnpp Severity: wishlist Owner: Sune Vuorela report...@pusling.com * Package name: Qoreutils Version : 1.0.0 Upstream Author : John Doe j...@qoreutils.org * URL : http://www.qoreutils.org/ * License : GPL Programming Lang: C++ with Qt Description : Coreutils reimplemented using Qt libraries Qoreutils is a reimplementation of the classic tools from coreutils, such as ls, mkdir and cp I'm packaging this on behalf of the Debian Qt/KDE maintainers as a first step towards making the Qt libraries Essential: yes and on the way to take over the world. For KMess, we have recently switched to Tcl/Tk (TMess): http://kmess.org/board/viewtopic.php?f=13t=3894 We did this mainly because we thought Qt and KDE was very inferior and insuperior to Tcl/Tk. A lot of projects are making the same smart decision. I think coreutils should not be rewritten in Qt but in Tcl, because it will be the fastest, easiest and most maintainable solution. I for one accept TclCoreutils, and with it Tcl, as my leader. - - Sjors -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknTYnkACgkQHJNr90P0N+FlAQCggp9Ikw7LvL/PloP+PWXQjLYR ugoAnAsi6g1XGjfDdO+m4leWDazy4wBk =Wdvo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries
- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sune Vuorela wrote: Package: wnpp Severity: wishlist Owner: Sune Vuorela report...@pusling.com * Package name: Qoreutils Version : 1.0.0 Upstream Author : John Doe j...@qoreutils.org * URL : http://www.qoreutils.org/ * License : GPL Programming Lang: C++ with Qt Description : Coreutils reimplemented using Qt libraries Qoreutils is a reimplementation of the classic tools from coreutils, such as ls, mkdir and cp I'm packaging this on behalf of the Debian Qt/KDE maintainers as a first step towards making the Qt libraries Essential: yes and on the way to take over the world. For KMess, we have recently switched to Tcl/Tk (TMess): http://kmess.org/board/viewtopic.php?f=13t=3894 We did this mainly because we thought Qt and KDE was very inferior and insuperior to Tcl/Tk. A lot of projects are making the same smart decision. I think coreutils should not be rewritten in Qt but in Tcl, because it will be the fastest, easiest and most maintainable solution. I for one accept TclCoreutils, and with it Tcl, as my leader. - - - Sjors - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknTYnkACgkQHJNr90P0N+FlAQCggp9Ikw7LvL/PloP+PWXQjLYR ugoAnAsi6g1XGjfDdO+m4leWDazy4wBk =Wdvo - -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513073: Bug #513073 - debhelper impossible to unpack on Win32 due to case insensitivity - please reopen
Hello Joey and list, I'd like to ask you to reopen this bug. I have sent you a patch which fixes debhelper so it can unpack on case insensitive file systems or operating systems. debhelper has in its main directory, next to the regular debian directory, also a Debian directory which contains Perl modules. The patch (see the original bug report) fixes this case conflict by moving the Debian directory to lib/. The main argument not to apply this patch was, that by applying it it becomes your reponsibility to keep debhelper working on Win32. That's not the case, because there are other people to keep checking compatibility for you, like me and other users who would want debhelper to work on their platform. If I'm correct, OS X may work in case insensitive mode too. Other than that, I am already trying to get Debian packages to work under Cygwin. I can confirm the patch makes debhelper unpack cleanly. As far as I'm aware the patch does not break anything on other platforms (please tell me if I'm wrong). I'm cc'ing the list to hear their opinion on this matter. If they agree the patch should not be applied, I will create a seperate source package just for debhelper on Cygwin. Thank you, Sjors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513073: Bug #513073 - debhelper impossible to unpack on Win32 due to case insensitivity - please reopen
Neil Williams schreef: On Tue, 24 Feb 2009 23:07:35 +0100 Sjors Gielen mailingl...@dazjorz.com wrote: I'd like to ask you to reopen this bug. I have sent you a patch which fixes debhelper so it can unpack on case insensitive file systems or operating systems. debhelper has in its main directory, next to the regular debian directory, also a Debian directory which contains Perl modules. The patch (see the original bug report) fixes this case conflict by moving the Debian directory to lib/. Even if only looking at perl packages installed on my own machine, this problem is not unique to debhelper - any package that has a Debian:: perl module is likely to have exactly the same problem/feature. $ ls /usr/share/perl5/Debian AdduserCommon.pm DebhelperDependency.pm DpkgCross.pm AptContents.pmDefoma DictionariesCommon.pm Dwww DebConf Dependencies.pm DocBasePackages Not really. For example the Defoma directory there: defoma-0.11.10$ find . -name '*.pm' ./pm/Defoma/SubstCache.pm [...] DocBase: doc-base-0.8.20$ find . -name '*.pm' ./perl/Debian/DocBase/Document.pm This is a problem of packaging only. For debhelper, this is the current situation: debhelper-7.0.15$ find . -name '*.pm' ./Debian/Debhelper/Sequence/python_support.pm As you see, the Debian dir here conflicts with the regular debian directory on case insensitive filesystems. If I'm correct, OS X may work in case insensitive mode too. It's been a while since I used OSX but I certainly remember .DS_Store directories all over the place and various applications using a mix of capitalised and lower case directory names. So this would not only help debhelper on Win32 platforms, but also on OS X in some configurations. Sjors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515663: ITP: kmess2 -- Windows(R) Live(R) Messenger(R) Client for KDE4.
Rafael Belmonte schreef: Kmess 1.5 is the current stable version of kmess, and built in KDE3, kmess2 is the current development version of kmess and built in KDE4, it is not stable yet, but it provides functional svn snapshots regularly. I am not sure if kmess and kmess2 packages should be at the same time in the archive until kmess2 is not stable. What do you think? I've CC'd two of the KMess developers I know, Diederik and Valerio. There's a pro and a con for adding KMess2 to the repositories: - pro: KMess 1.5 is a very old and much less featured version of KMess. - con: It's still even in alpha. I'm not sure but I think I remember some very old packages being replaced by newer versions, which were not declared stable. In any case, I think it would be best to have a version of KMess 1.5 in the repositories (http://kmess.svn.sourceforge.net/svnroot/kmess/tags/kmess/kmess-1.5.2), and the latest tag of KMess 2 (that's kmess-2.0alpha2). If no maintainers can be found, I'll opt to be a maintainer for KMess, it'd be a good learning path for me and I do have a little coding experience with the program (I added a little feature, heh.) If there's any Debian policy I missed on this, please let me know. Sjors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515663: ITP: kmess2 -- Windows(R) Live(R) Messenger(R) Client for KDE4.
Sune Vuorela schreef: On Monday 16 February 2009 20:38:38 Rafael Belmonte wrote: Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org --- Please fill out the fields below. --- Package name: kmess2 Version: 2.0alpha Upstream Author: Diederik van der Boor URL: http://kmess.org License: GPL-2 What's the advantage of keeping kmess and kmess2 in the archive in parallel ? I'm not sure if the KDE 3 libraries are still in the repositories, nor anything about usual Debian policy (I've only been following for a short time now) but KMess uses KDE 3 and KMess2 uses KDE 4. You probably already knew this, but I wanted to drop a mail just in case. /Sune -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513073: Status update on #513073 - debhelper impossible to unpack on Win32 due to case insensitivity
Hey all, I'm wondering about the status of this bug. A patch has been supplied which fixes a problem as seen on Cygwin. Has it been committed yet? Can the bug be closed? Sjors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513073: closed by Joey Hess jo...@debian.org (Re: Bug#513073: debhelper impossible to unpack on Win32 due to case insensitivity)
Joey Hess schreef: You're implicitly asking me to take care to avoid the case of files that differ only in case, which would be an ongoing effort, for no appreciable benefit. I'm asking you to apply this patch to make it possible for users with case-insensitive filesystems to install debhelper, nothing else. It is not your responsibility to keep debhelper working on case insensitive filesystems, but it would be ignorant to not apply a patch that fixes this and creates no new problems. Any subsequent change that is required to keep debhelper and other packages working on case insensitive filesystems will not be your responsibility, and by applying this patch you are not taking that responsibility. The benefit is not appreciable to you, mind you. And Windows is not the only case insensitive platform. How does this work on the Mac? Is it possible to unpack, let alone compile, debhelper on OS X? - Sjors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513073: debhelper impossible to unpack on Win32 due to case insensitivity
Package: debhelper
Version: 7.0.17
Hey all,
The debhelper package contains both a 'debian' directory for debian/rules etc
and a
'Debian' directory for the Debian/Debhelper/*.pm Perl modules. Therefore, on
Win32
(i.e. Cygwin), it is impossible to unpack debhelper - when you try, you get
only the
debian/ folder, so the modules are missing.
A patch is available in the Debian GNU/kCygwin project SVN repository on
Sourceforge.
For reference, I've also added it below.
Apart from applying this patch, the Debian directory should be moved to
lib/Debian, of
course.
Only in debhelper-orig: Debian
Only in debhelper: lib
diff -ur debhelper-orig/Makefile debhelper/Makefile
--- debhelper-orig/Makefile 2008-07-31 18:27:07.0 +0200
+++ debhelper/Makefile 2009-01-26 06:36:26.0 +0100
@@ -51,10 +51,10 @@
version:
printf package
Debian::Debhelper::Dh_Version;\n\$$version='$(VERSION)';\n1 \
- Debian/Debhelper/Dh_Version.pm
+ lib/Debian/Debhelper/Dh_Version.pm
clean:
- rm -f *.1 *.7 Debian/Debhelper/Dh_Version.pm
+ rm -f *.1 *.7 lib/Debian/Debhelper/Dh_Version.pm
po4a --rm-translations --rm-backups man/po4a/po4a.cfg
for lang in $(LANGS); do \
if [ -e man/$$lang ]; then rmdir man/$$lang; fi; \
@@ -66,8 +66,8 @@
$(DESTDIR)$(PERLLIBDIR)/Sequence
install $(shell find -maxdepth 1 -mindepth 1 -name dh\* |grep -v
\.1\$$) $(DESTDIR)/usr/bin
install -m 0644 autoscripts/* $(DESTDIR)/usr/share/debhelper/autoscripts
- install -m 0644 Debian/Debhelper/*.pm $(DESTDIR)$(PERLLIBDIR)
- install -m 0644 Debian/Debhelper/Sequence/*.pm
$(DESTDIR)$(PERLLIBDIR)/Sequence
+ install -m 0644 lib/Debian/Debhelper/*.pm $(DESTDIR)$(PERLLIBDIR)
+ install -m 0644 lib/Debian/Debhelper/Sequence/*.pm
$(DESTDIR)$(PERLLIBDIR)/Sequence
test: version
./run perl -MTest::Harness -e 'runtests grep { ! /CVS/ ! /\.svn/ }
@ARGV' t/*
diff -ur debhelper-orig/run debhelper/run
--- debhelper-orig/run 2008-07-31 18:27:07.0 +0200
+++ debhelper/run 2009-01-26 06:36:04.0 +0100
@@ -7,7 +7,7 @@
# Ensure that builds are self-hosting, which means I have to use the .pm
# files in this package, not any that may be on the system.
-export PERL5LIB=$(pwd)
+export PERL5LIB=$(pwd)/lib
# If any automatic script generation is done in building this package,
# be sure to use the new templates from this package.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513073: closed by Joey Hess jo...@debian.org (Re: Bug#513073: debhelper impossible to unpack on Win32 due to case insensitivity)
Debian Bug Tracking System schreef: Sjors Gielen wrote: The debhelper package contains both a 'debian' directory for debian/rules etc and a 'Debian' directory for the Debian/Debhelper/*.pm Perl modules. Therefore, on Win32 (i.e. Cygwin), it is impossible to unpack debhelper - when you try, you get only the debian/ folder, so the modules are missing. A patch is available in the Debian GNU/kCygwin project SVN repository on Sourceforge. For reference, I've also added it below. Apart from applying this patch, the Debian directory should be moved to lib/Debian, of course. Sorry, but I think I'd rather not worry about compatability with case-insensative filesystems in debhelper. Why? I'm trying to port Debian to Cygwin. It matters here. And I've already supplied you with a patch, which does not break things anywhere; removes the uglyness of having two directories with the same name case-insensitively; and adds Cygwin and Win32 as platforms to build debhelper on. The fact you'll never build it on there, is unimportant in this case. - Sjors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504757: Agreed
I just fixed a problem I could not even find out using ssh's highest debug level - had to pipe it through strace! write(2, debug1: server_input_channel_req..., 69debug1: server_input_channel_req: channel 0 request x11-req reply 0^M ) = 69 write(2, debug1: session_by_channel: sess..., 49debug1: session_by_channel: session 0 channel 0^M ) = 49 write(2, debug1: session_input_channel_re..., 58debug1: session_input_channel_req: session 0 req x11-req^M ) = 58 stat64(/usr/bin/X11/xauth, 0xbfecc9bc) = -1 ENOENT (No such file or directory) write(3, 70\356\372\230\277Ha+\360\263\302\324~oP\240\4\274\325..., 96) = 96 write(2, debug1: server_input_channel_req..., 69debug1: server_input_channel_req: channel 0 request pty-req reply 1^M ) = 69 write(2, debug1: session_by_channel: sess..., 49debug1: session_by_channel: session 0 channel 0^M ) = 49 write(2, debug1: session_input_channel_re..., 58debug1: session_input_channel_req: session 0 req pty-req^M ) = 58 write(2, debug1: Allocating pty.\r\n, 25debug1: Allocating pty.^M Maybe I will check the source and add in a warning if xauth could not be found, in a few days, and send in a patch. Sjors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
