Bug#1069484: marked as pending in cowdancer
Control: tag -1 pending Hello, Bug #1069484 in cowdancer reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/pbuilder-team/cowdancer/-/commit/ee7fd54fec3145ce95fb735b5ff2f83a9352d599 Fix FTBFS when symbols are redirected We already have various #undef's to try and counteract any LFS redirection in the preprocessor, but with the time64 transition turning on more LFS things we now hit __asm__-based redirection, which we have no way of disabling once applied (and we really don't want to start messing with disabling LFS or time64_t things as those will surely eventually stop working). Instead, let's use __asm__ ourselves to control which symbols we interpose, giving the C functions themselves different names that won't collide with the standard library. Closes: #1069484 (this message was generated automatically) -- Greetings https://bugs.debian.org/1069484
Bug#1001276: ctfutils: library conflict on libctf.so.0 with libctf0
Control: reassign -1 binutils Control: retitle -1 binutils: Hijacks libctf library name on (k)FreeBSD On 7 Dec 2021, at 15:25, Jessica Clarke wrote: > > On 7 Dec 2021, at 15:09, Andreas Beckmann wrote: >> >> Package: ctfutils >> Version: 10.3~svn297264-2 >> Severity: serious >> >> Hi, >> >> there is a (potential) library conflict: >> >> ctfutils (src:ctfutils): /usr/lib/libctf.so.0 >> libctf0 (src:binutils): /usr/lib/$DEB_HOST_MULTIARCH/libctf.so.0 >> >> I don't know if the libraries could be used as replacements of each >> other, but if both packages are installed, only one of libraries will >> be used to resolve dependencies of other shared libraries or binaries. > > *sigh* What is the plan for building binutils on real FreeBSD? Because > that has a libctf (albeit, now at .2) in the base system that will > conflict. Is this just a GNU-written replacement we should disable in > binutils on kfreebsd-*? Presumably that’s what they do on FreeBSD… Regardless, this is binutils’s bug, it can’t just hijack libraries, especially those that are OS-provided system libraries like libctf. Jess
Bug#1001276: ctfutils: library conflict on libctf.so.0 with libctf0
On 7 Dec 2021, at 15:09, Andreas Beckmann wrote: > > Package: ctfutils > Version: 10.3~svn297264-2 > Severity: serious > > Hi, > > there is a (potential) library conflict: > > ctfutils (src:ctfutils): /usr/lib/libctf.so.0 > libctf0 (src:binutils): /usr/lib/$DEB_HOST_MULTIARCH/libctf.so.0 > > I don't know if the libraries could be used as replacements of each > other, but if both packages are installed, only one of libraries will > be used to resolve dependencies of other shared libraries or binaries. *sigh* What is the plan for building binutils on real FreeBSD? Because that has a libctf (albeit, now at .2) in the base system that will conflict. Is this just a GNU-written replacement we should disable in binutils on kfreebsd-*? Presumably that’s what they do on FreeBSD... Jess
Bug#995333: polyml: FTBFS on arm64: Segmentation fault ./polyimport polytemp.txt -I . < ./exportPoly.sml
Control: severity -1 important Control: title -1 polyml: Intermittent FTBFS on arm64 Built ok after a give back, so not sure what’s up... Jess > On 29 Sep 2021, at 21:17, Sebastian Ramacher wrote: > > Source: polyml > Version: 5.7.1-4 > Severity: serious > Tags: ftbfs sid bookworm > Justification: fails to build from source (but built successfully in the past) > X-Debbugs-Cc: sramac...@debian.org > > | Use: basis/MONO_VECTOR_SLICE.sml > | Use: basis/MONO_ARRAY.sml > | Use: basis/MONO_ARRAY_SLICE.sml > | Use: basis/StringSignatures.sml > | Use: basis/String.sml > | /bin/bash: line 1: 3933030 Segmentation fault ./polyimport > polytemp.txt -I . < ./exportPoly.sml > | make[3]: *** [Makefile:1174: polyexport.o] Error 139 > > See > https://buildd.debian.org/status/fetch.php?pkg=polyml&arch=arm64&ver=5.7.1-4%2Bb1&stamp=1632490442&raw=0 > > Cheers > -- > Sebastian Ramacher >
Bug#975921: mali-midgard: Contains auto-generated file without corresponding source
Source: mali-midgard
Version: 16.0+pristine-4
Severity: serious
mali_base_hwconfig_issues.h currently has:
> /* AUTOMATICALLY GENERATED FILE. If you want to amend the issues/features,
> * please update base/tools/hwconfig_generator/hwc_{issues,features}.py
> * For more information see base/tools/hwconfig_generator/README
> */
Unless patches to this file are accepted, this is not the preferred
form, and the mentioned scripts do not exist (I assume they are
Arm-internal scripts).
Jess
Bug#972043: libreoffice: 1:6.1.5-1 -> 1:7.0.2-1 upgrade fails
Source: libreoffice Version: 1:7.0.2-1 Severity: serious I came to upgrade an old VM and was faced with: > Preparing to unpack .../09-libreoffice-common_1%3a7.0.2-1_all.deb ... > dpkg-maintscript-helper: error: file > '/usr/lib/libreoffice/share/registry/math.xcd' not owned by package > 'libreoffice-common:all' > dpkg-maintscript-helper: error: directory > '/usr/lib/libreoffice/share/registry' contains files not owned by package > libreoffice-common:all, cannot switch to symlink > dpkg: error processing archive > /tmp/apt-dpkg-install-yFAjDA/09-libreoffice-common_1%3a7.0.2-1_all.deb > (--unpack): > new libreoffice-common package pre-installation script subprocess returned > error exit status 1 > rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or > directory > rmdir: failed to remove '/var/lib/libreoffice': No such file or directory > ... > debian:~ jrtc27% sudo dpkg -S /usr/lib/libreoffice/share/registry/math.xcd > libreoffice-math: /usr/lib/libreoffice/share/registry/math.xcd I have 1:6.1.5-1 installed and was upgrading to 1:7.0.2-1. Jess
Bug#970882: filesystems that don't begin with empty blocks trash sun disk labels as 1st partition
Control: reassign -1 partman-auto Control: found -1 153 Control: severity -1 important (affects less-common file systems and only for a ports architecture) > On 24 Sep 2020, at 22:52, Catherine A. Frederick / mptcultist > wrote: > > Package: debian-installer > Version: 20200314 > Severity: grave > User: debian-sp...@lists.debian.org > Usertags: sparc64 > X-Debbugs-Cc: debian-sp...@lists.debian.org > > Currently, the debian installer uses the force(-f) switch on mkfs to > make sure that mkfs doesn't bail creating the first partition on the > disk with an error stating it found a partition label where the > partition start is. This behavior works fine for ext2, which starts > with 2 empty blocks, but for other filesystems like XFS the partition > label is immediately trashed(can be observed by parted reporting the > label type with "loop"). This location was apparently necessary for > SILO, and it always functioned as the first partition created by > guided partitioning was always ext-default and boot first, but now > that debian-sparc64 uses GRUB2 this _probably_ isn't necessary. > > In manual partitioning the behavior is trivially replicable by > creating a first partition with an XFS filesystem, where upon choosing > "beginning" for the location of the new filesystem the start is placed > at 0. When formatting happens after confirming this setup, the disk > label is promptly trashed and the system is rendered unbootable. > > src: https://tldp.org/HOWTO/LVM-HOWTO/sundisklabels.html >
Bug#957380: istgt: diff for NMU version 0.4~20111008-3.1
On 12 Aug 2020, at 20:16, Sudip Mukherjee wrote: > > On Wed, Aug 12, 2020 at 8:04 PM Sudip Mukherjee > wrote: >> >> On Wed, Aug 12, 2020 at 7:54 PM Jessica Clarke wrote: >>> >>> On 12 Aug 2020, at 19:51, Sudip Mukherjee >>> wrote: >>>> >>>> HI Jess, >>>> >>>> On Wed, Aug 12, 2020 at 7:21 PM Jessica Clarke wrote: >>>>> >>>>> On 12 Aug 2020, at 19:15, Sudip Mukherjee >>>>> wrote: >>>>>> >>>>>> Control: tags 957380 + patch >>>>>> Control: tags 957380 + pending >>>>>> >>>>>> Dear maintainer, >>>>>> >>>>>> I've prepared an NMU for istgt (versioned as 0.4~20111008-3.1) and >>>>>> uploaded it to DELAYED/2. Please feel free to tell me if I >>>>>> should cancel it. >>>>> >>>>> Thanks, I've been meaning to do this but it's just not a high enough >>>>> priority for me. Could you please however use `typedef` instead, as I >>>>> believe the intent of the code (based on how these ones are written, >>>>> and what's around it) is to have `ISTGT_LU_TASK_TYPE` be the type name, >>>>> not `enum ISTGT_LU_TASK_TYPE`? Would you also be willing to file it as >>>>> a merge request against https://salsa.debian.org/bsd-team/istgt? > > https://salsa.debian.org/bsd-team/istgt has UNRELEASED changes and the > version is 0.5~20120901-1 there. But since there is no pristine-tar or > upstream branch, I am unable to generate > istgt_0.5~20120901.orig.tar.gz to build and test with the proposed > patch. Ah, yes and that 0.5 work looks half-baked. I've created a new 0.5 feature branch for that and rewound master (yes, bad practice, I know, but I highly doubt anyone else has a clone) to the 0.4~20111008-3 release so you should be good to use it as-is now. Jess
Bug#957380: istgt: diff for NMU version 0.4~20111008-3.1
On 12 Aug 2020, at 19:51, Sudip Mukherjee wrote:
>
> HI Jess,
>
> On Wed, Aug 12, 2020 at 7:21 PM Jessica Clarke wrote:
>>
>> On 12 Aug 2020, at 19:15, Sudip Mukherjee wrote:
>>>
>>> Control: tags 957380 + patch
>>> Control: tags 957380 + pending
>>>
>>> Dear maintainer,
>>>
>>> I've prepared an NMU for istgt (versioned as 0.4~20111008-3.1) and
>>> uploaded it to DELAYED/2. Please feel free to tell me if I
>>> should cancel it.
>>
>> Thanks, I've been meaning to do this but it's just not a high enough
>> priority for me. Could you please however use `typedef` instead, as I
>> believe the intent of the code (based on how these ones are written,
>> and what's around it) is to have `ISTGT_LU_TASK_TYPE` be the type name,
>> not `enum ISTGT_LU_TASK_TYPE`? Would you also be willing to file it as
>> a merge request against https://salsa.debian.org/bsd-team/istgt?
>
> I have cancelled the upload from DELAYED queue but I am not really
> sure how you can use typedef here.
> iiuc, ISTGT_LU_TASK_TYPE is supposed to be an enum which has
> ISTGT_LU_TASK_RESPONSE and ISTGT_LU_TASK_REQPDU as its members where
> ISTGT_LU_TASK_RESPONSE will have a value of 1 and ISTGT_LU_TASK_REQPDU
> will have 0 and these enum members are used in the code to determine
> the task type.
typedef enum {
ISTGT_LU_TASK_RESULT_IMMEDIATE = 0,
ISTGT_LU_TASK_RESULT_QUEUE_OK = 1,
ISTGT_LU_TASK_RESULT_QUEUE_FULL = 2,
} ISTGT_LU_TASK_RESULT;
should work, i.e. just adding typedef to the original code, instead of
moving the ISTGT_LU_TASK_RESULT etc around.
Jess
Bug#957380: istgt: diff for NMU version 0.4~20111008-3.1
On 12 Aug 2020, at 19:15, Sudip Mukherjee wrote:
>
> Control: tags 957380 + patch
> Control: tags 957380 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for istgt (versioned as 0.4~20111008-3.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should cancel it.
Thanks, I've been meaning to do this but it's just not a high enough
priority for me. Could you please however use `typedef` instead, as I
believe the intent of the code (based on how these ones are written,
and what's around it) is to have `ISTGT_LU_TASK_TYPE` be the type name,
not `enum ISTGT_LU_TASK_TYPE`? Would you also be willing to file it as
a merge request against https://salsa.debian.org/bsd-team/istgt?
Jess
> --
> Regards
> Sudip
>
> diff -Nru istgt-0.4~20111008/debian/changelog
> istgt-0.4~20111008/debian/changelog
> --- istgt-0.4~20111008/debian/changelog 2012-06-26 23:25:01.0
> +0100
> +++ istgt-0.4~20111008/debian/changelog 2020-08-12 19:05:25.0
> +0100
> @@ -1,3 +1,10 @@
> +istgt (0.4~20111008-3.1) unstable; urgency=medium
> +
> + * Non-maintainer upload.
> + * Fix ftbfs with GCC-10. (Closes: #957380)
> +
> + -- Sudip Mukherjee Wed, 12 Aug 2020 19:05:25
> +0100
> +
> istgt (0.4~20111008-3) unstable; urgency=low
>
> * Fix "cannot determine device size from symlink" Apply patch to use stat()
> diff -Nru istgt-0.4~20111008/debian/patches/fix_ftbfs.patch
> istgt-0.4~20111008/debian/patches/fix_ftbfs.patch
> --- istgt-0.4~20111008/debian/patches/fix_ftbfs.patch 1970-01-01
> 01:00:00.0 +0100
> +++ istgt-0.4~20111008/debian/patches/fix_ftbfs.patch 2020-08-12
> 19:05:25.0 +0100
> @@ -0,0 +1,31 @@
> +Description: Fix ftbfs with GCC-10
> + The enum variable is not used, use that as the enum name to declare it.
> +
> +Author: Sudip Mukherjee
> +Bug-Debian: https://bugs.debian.org/957380
> +Forwarded: no
> +---
> +
> +--- istgt-0.4~20111008.orig/src/istgt_lu.h
> istgt-0.4~20111008/src/istgt_lu.h
> +@@ -270,16 +270,16 @@ typedef struct istgt_lu_cmd_t {
> + } ISTGT_LU_CMD;
> + typedef ISTGT_LU_CMD *ISTGT_LU_CMD_Ptr;
> +
> +-enum {
> ++enum ISTGT_LU_TASK_RESULT {
> + ISTGT_LU_TASK_RESULT_IMMEDIATE = 0,
> + ISTGT_LU_TASK_RESULT_QUEUE_OK = 1,
> + ISTGT_LU_TASK_RESULT_QUEUE_FULL = 2,
> +-} ISTGT_LU_TASK_RESULT;
> ++};
> +
> +-enum {
> ++enum ISTGT_LU_TASK_TYPE {
> + ISTGT_LU_TASK_RESPONSE = 0,
> + ISTGT_LU_TASK_REQPDU = 1,
> +-} ISTGT_LU_TASK_TYPE;
> ++};
> +
> + typedef struct istgt_lu_task_t {
> + int type;
> diff -Nru istgt-0.4~20111008/debian/patches/series
> istgt-0.4~20111008/debian/patches/series
> --- istgt-0.4~20111008/debian/patches/series 2012-06-26 22:04:42.0
> +0100
> +++ istgt-0.4~20111008/debian/patches/series 2020-08-12 19:00:39.0
> +0100
> @@ -3,3 +3,4 @@
> fix-as-needed-build.patch
> fix-autosize.patch
> add-reload.patch
> +fix_ftbfs.patch
>
Bug#957230: Bug#966370: bsdmainutils: 12.1.3 removal of lorder breaks rdeps
On 29 Jul 2020, at 09:04, Michael Meskes wrote: > > On Mon, Jul 27, 2020 at 03:01:31PM +0100, Jessica Clarke wrote: >> Package: bsdmainutils >> Version: 12.1.3 >> Severity: serious >> Control: affects -1 src:freebsd-buildutils src:freebsd-glue src:freebsd-libs >> >> Hi, >> The removal of lorder in 12.1.3 causes various freebsd-* packages to >> FTBFS which are now scheduled for autoremoval from testing. Please >> restore this shell script; it's not deprecated, it's still widely used >> by the BSDs and maintained in at least FreeBSD. > > I'm surprised it is actually used as it was pointed out to me that the script > has been non-functional for quite a while. I do recall having an issue with it at one point a few years back and meaning to submit a patch to bsdmainutils to fix it, but resolved it one way or another without that, though can't find any evidence of that nor can I remember what the problem was. But regardless, it was working well enough for the freebsd-* packages to build fine. > Anyway, it cannot easily be "restored" > because the old bsdmainutils package does not exist anymore. All tools except > ncal and calendar, which are now in their own package, are now build out of > util-linux. Would it be possible to include lorder.sh in one of the affected > freebsd packages? Yeah, it's possible, and that's no doubt what I'll end up doing. But I really don't appreciate all the breakage that's come about from bsdmainutils in the past few months. The util-linux handover was poorly-handled causing all kinds of problems across the archives (release and ports), and this removal of something, and thus *deliberately breaking* the package's "API", should have been done more carefully by checking whether anyone is actually using it (archive-wide rebuilds like is done for the new GCC versions is the easy-but-computationally-expensive way to do it). As it stands, I got hit with a surprise set of RC bugs from the first archive-wide rebuild after this change landed, and I therefore have to react in a time-pressured way to fix it lest packages be removed from testing (though, arguably, testing doesn't matter so much for these given kfreebsd-* aren't release architectures). This really should have been found out first, with Severity: important bugs filed a month or more in advance of making the change, that can then be upgraded to be release-critical further down the line. So, please, never do a transition like this again. Jess
Bug#966370: bsdmainutils: 12.1.3 removal of lorder breaks rdeps
Package: bsdmainutils Version: 12.1.3 Severity: serious Control: affects -1 src:freebsd-buildutils src:freebsd-glue src:freebsd-libs Hi, The removal of lorder in 12.1.3 causes various freebsd-* packages to FTBFS which are now scheduled for autoremoval from testing. Please restore this shell script; it's not deprecated, it's still widely used by the BSDs and maintained in at least FreeBSD. Jess
Bug#965091: glibc: setgroups: Bad address [2.31/x32, regression from 2.30]
[H.J. Lu Cc'ed as author of what looks like the problematic commit] On Wed, 15 Jul 2020 23:47:27 +0200 (CEST) Thorsten Glaser wrote: > Some more analysis: > > We enter libc from openssh code with the correct values in rsi and rdi: > > > (gdb) u > => 0x56560e45 : call 0x5655d0b0 > (gdb) info r > rax0xfffe 65534 > rbx0x5663a000 1449369600 > rcx0x0 0 > rdx0x0 0 > rsi0xd2e0 4294955744 > rdi0x1 1 > rbp0x56641b50 1449401168 > rsp0xd260 4294955616 > r8 0x0 0 > r9 0x0 0 > r100xf7a8 4155017352 > r110x246 582 > r120x565d71d1 1448964561 > r130x3 3 > r140xe2cc 58060 > r150x5663c730 1449379632 > rip0x56560e45 1448480325 > eflags 0x282 [ SF IF ] > cs 0x3351 > ss 0x2b43 > ds 0x2b43 > es 0x2b43 > fs 0x0 0 > gs 0x0 0 > > > Inside glibc, there’s an indirect call: > > > => 0xf79949f4 <__GI_setgroups+100>: call rax > rax0xf7833500 4152571136 > => 0xf7833500 <__nptl_setxid>: push r15 > > > Some time in __nptl_setxid later, here’s the bug: > > > 1162in allocatestack.c > rax0xf77ca840 4152141888 > rbx0xd230 4294955568 > rcx0x0 0 > rdx0x1 1 > rsi0xd2e0 4294955744 > rdi0xf77ca840 4152141888 > rbp0xf77ca840 4152141888 > rsp0xd1d0 4294955472 > r8 0x0 0 > r9 0x0 0 > r100xf77caac0 4152142528 > r110x246 582 > r120xf784a360 4152664928 > r130xf784a360 4152664928 Looks like df76ff3a446a787a95cf74cb15c285464d73a93d broke this upstream (x32: Properly pass long to syscall [BZ #25810]). setgroups uses INLINE_SETXID_SYSCALL, which in turn passes its arguments through the various id fields in xid_command. Unfortunately, those are `long int`, and so, when the `const gid_t *list` argument gets later passed through INTERNAL_SYSCALL_NCS, it's treated as an integer argument and thus sign-extended, despite actually being a pointer. I think xid_command's id fields need to become __kernel_ulong or equivalent, with ARGIFY happening inside INLINE_SETXID_SYSCALL when it still knows what the types are. Jess
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
On 11 Jul 2020, at 23:47, Johannes Schauer wrote: > > Hi, > > I put Jessica and Ralf in CC because they are the solver experts. :) > > On Wed, 8 Jul 2020 18:27:54 +0200 Adam Borowski wrote: >> This problem can't possibly be caused by elogind. A package may cause a >> problem only if: >> 1. some of its code is actually run (preinst, postinst, payload), or >> 2. it's the first alternative and the solver uses "first alternative only" >> or is otherwise unable to use the full solutions space >> >> The docs say: >>'aspcud' resolver which (in contrast to apt and aptitude) is a real >>solver (in the math sense) and will thus always find a solution if a >>solution exists. >> >> Given a set of packages A containing package X, if A - X contains a >> solution, A with X also does -- ie, no relations declared by X (Breaks, >> Conflicts, Depends, Provides, ...) may possibly invalidate that solution. >> >> And we have: >> * unstable: apt resolver, doesn't even consider libelogind0 >> * experimental: aspcud, supposed to be a full solver >> >> Thus, it looks to me like a problem in apt-cudf, almost surely not in the >> solver itself but in its integration with apt. > > I managed to find out where the problem comes from. The problem is indeed not > aspcud but apt-cudf. Apt transforms the problem into the EDSP format, and > libelogind0 looks like this: > > Package: libelogind0 > Architecture: amd64 > Version: 243.7-1+debian1 > APT-ID: 7784 > Multi-Arch: same > Source: elogind > Source-Version: 243.7-1+debian1 > Priority: optional > Section: libs > APT-Release: > o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64 > APT-Pin: 500 > APT-Candidate: yes > Depends: libc6 (>= 2.30), libcap2 (>= 1:2.10) > Conflicts: libsystemd0, systemd > Replaces: libsystemd0 > Provides: libsystemd0 (= 243.7) > > That's all good and seems fine. It is then the job of apt-cudf to turn the > EDSP > format into CUDF format which is understood by common CUDF solvers. And that's > where things go wrong, because the CUDF stanza for libelogind0 reads: > > package: libelogind0%3aamd64 > version: 23683 > depends: libc6%3aamd64 >= 16972 , libcap2%3aamd64 >= 25386 > conflicts: systemd%3aamd64 , --virtual-systemd%3aamd64 , systemd%3aamd64 , > --virtual-systemd%3aamd64 , libelogind0%3aamd64 > provides: libelogind0 , --virtual--versioned-libsystemd0%3aamd64 = 23682 , > --virtual-libsystemd0%3aamd64 = 2147483646 > installed: true > priority: optional > name: libelogind0 > architecture: amd64 > number: 243.7-1+debian1 > source: elogind > sourcenumber: 243.7-1+debian1 > sourceversion: 23683 > replaces: libsystemd0 , --virtual-libsystemd0 > native: 1 > type: bin > apt-pin: 500 > apt-id: 7784 > apt-candidate: true > section: libs > > Looking into the conflicts field, the conflict with libsystemd0 doesn't exist > anymore. This explains why aspcud happily adds libelogind0 into the solution: > because it wasn't told, that it conflicts with libsystemd0. If you want to > find > out the above at home, just run sbuild with --build-deps-failed-commands=%s > like so: > >$ sbuild -d unstable --extra-repository='deb http://deb.debian.org/debian > experimental main' --extra-repository='deb-src http://deb.debian.org/debian > experimental main' --build-dep-resolver=aspcud > --build-deps-failed-commands=%s hplip_3.20.6+dfsg0-1 > > and then after build-deps failed to install, run the following to create an > EDSP file: > >$ APT_EDSP_DUMP_FILENAME=/tmp/dump.edsp apt-get install > --with-source=resolver-* --simulate --solver=dump -o > APT::Solver::Strict-Pinning=false sbuild-build-depends-main-dummy > > You can then copy the EDSP file out of the schroot and put it into apt-cudf: > >$ apt-cudf -v --solver=aspcud -c > "-count(solution,APT-Release:=/a=experimental/),-removed,-changed,-new" > /tmp/dump.edsp --dump > > Using the --dump option you can also see the cudf translation. To save you the > trouble, I put the EDSP file as an attachment to this mail. > > Thanks! > > cheers, josch Is this not the bug I fixed a while ago and you committed upstream recently[1]? There hasn't been a dose3 upload to Debian yet with that fixed. Jess [1] https://scm.gforge.inria.fr/anonscm/gitweb?p=dose/dose.git;a=commitdiff;h=226e7eb544bd02b128c19be5e79a9b236439159f
