Bug#710520: apt: New /usr/lib/apt/methods/bzip2 (gzip) now incompatible with pbzip2
Package: apt Version: 0.9.7.8 Severity: normal Hi there, In squeeze /usr/lib/apt/methods/bzip2 was an independent binary, but in wheezy it has become a symlink to the gzip method binary which now appears to attempt to cope with various compression methods. Unfortunately, this implementation is incompatible with the output of pbzip2 (a valid .bz2 file), whereas the old one wasn't. This generally happens because the decompressor assumes that all the data is in a single stream. The format of bz2 files means that a concatination of output files should be equal to the output of the concatination of input file (i.e. cat *.bz2|bzcat === bzcat *.bz2). The binary must read *all* the data, not just the first stream. As .gz also has the same semantics and based on how I reckon pigz will work, I suspect (I haven't tested, sorry) that the gzip module may also be incompatible with pigz if the gzip reading logic is the same. Thanks for all your hard work, as ever. -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image.*; APT::NeverAutoRemove:: ^kfreebsd-image.*; APT::NeverAutoRemove:: ^linux-restricted-modules.*; APT::NeverAutoRemove:: ^linux-ubuntu-modules-.*; APT::NeverAutoRemove:: ^gnumach$; APT::NeverAutoRemove:: ^gnumach-image.*; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Architectures ; APT::Architectures:: amd64; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2; APT::Compressor::bzip2::Extension .bz2; APT::Compressor::bzip2::Binary bzip2; APT::Compressor::bzip2::Cost 3; APT::Compressor::bzip2::CompressArg ; APT::Compressor::bzip2::CompressArg:: -9; APT::Compressor::bzip2::UncompressArg ; APT::Compressor::bzip2::UncompressArg:: -d; APT::Compressor::xz ; APT::Compressor::xz::Name xz; APT::Compressor::xz::Extension .xz; APT::Compressor::xz::Binary xz; APT::Compressor::xz::Cost 4; APT::Compressor::xz::CompressArg ; APT::Compressor::xz::CompressArg:: -6; APT::Compressor::xz::UncompressArg ; APT::Compressor::xz::UncompressArg:: -d; APT::Compressor::lzma ; APT::Compressor::lzma::Name lzma; APT::Compressor::lzma::Extension .lzma; APT::Compressor::lzma::Binary xz; APT::Compressor::lzma::Cost 5; APT::Compressor::lzma::CompressArg ; APT::Compressor::lzma::CompressArg:: --format=lzma; APT::Compressor::lzma::CompressArg:: -9; APT::Compressor::lzma::UncompressArg ; APT::Compressor::lzma::UncompressArg:: --format=lzma; APT::Compressor::lzma::UncompressArg:: -d; APT::CompressorName ; APT::CompressorExtension .; APT::CompressorBinary ; APT::CompressorCost 100; APT::CompressorCompressArg ; APT::CompressorCompressArg:: -9; APT::CompressorUncompressArg ; APT::CompressorUncompressArg:: -d; Dir /; Dir::State var/lib/apt/; Dir::State::lists lists/; Dir::State::cdroms cdroms.list; Dir::State::mirrors mirrors/; Dir::State::extended_states extended_states; Dir::State::status /var/lib/dpkg/status; Dir::Cache var/cache/apt/; Dir::Cache::archives archives/; Dir::Cache::srcpkgcache srcpkgcache.bin; Dir::Cache::pkgcache pkgcache.bin; Dir::Etc etc/apt/; Dir::Etc::sourcelist sources.list; Dir::Etc::sourceparts sources.list.d; Dir::Etc::vendorlist vendors.list; Dir::Etc::vendorparts vendors.list.d; Dir::Etc::main apt.conf; Dir::Etc::netrc auth.conf; Dir::Etc::parts apt.conf.d; Dir::Etc::preferences preferences; Dir::Etc::preferencesparts preferences.d; Dir::Etc::trusted trusted.gpg; Dir::Etc::trustedparts trusted.gpg.d; Dir::Bin ; Dir::Bin::methods /usr/lib/apt/methods; Dir::Bin::solvers ; Dir::Bin::solvers:: /usr/lib/apt/solvers; Dir::Bin::dpkg /usr/bin/dpkg; Dir::Bin::bzip2 /bin/bzip2; Dir::Bin::xz /usr/bin/xz; Dir::Media ; Dir::Media::MountPath /media/cdrom; Dir::Log var/log/apt; Dir::Log::Terminal term.log; Dir::Log::History history.log; Dir::Ignore-Files-Silently ; Dir::Ignore-Files-Silently:: ~$;
Bug#658239: pbzip2 fails to preserve ownership on 0 length files
Package: pbzip2 Version: 1.1.1-1 Severity: important pbzip2, when run as root, does not preserve the user and group ownership of the source file on the newly created .bz2 file if the source file is zero length. This is inconsistent with its behaviour in lenny, but worse it is inconsistent with bzip2 itself for which it should be a drop in replacement. This may seem trivial (it's a weird edge case, I'll grant you), but it just broke a lot of cron jobs following a dist-upgrade :) wilson:~# : test1 wilson:~# : test2 wilson:~# chown mike test? wilson:~# pbzip2 test1 wilson:~# bzip2 test2 wilson:~# ls -l test?.bz2 -rw-r--r-- 1 root root 14 Feb 1 11:19 test1.bz2 -rw-r--r-- 1 mike root 14 Feb 1 11:18 test2.bz2 -- System Information: Debian Release: 6.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF8, LC_CTYPE=en_GB.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pbzip2 depends on: ii libbz2-1.0 1.0.5-6+squeeze1 high-quality block-sorting file co ii libc6 2.11.3-2 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8GCC support library ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 pbzip2 recommends no packages. pbzip2 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#641419: linux-image-2.6.32-5-amd64: sendfile(2) behaves incorrectly in 2.6.32-5-amd64, overwriting written data
On Tue, Sep 13, 2011 at 01:34:17PM +0100, Ben Hutchings wrote: On Tue, 2011-09-13 at 10:18 +, Mike Ashton wrote: Package: linux-2.6 Version: 2.6.32-35squeeze2 Severity: important In the squeeze standard 64 bit kernel (with either 64 or 32 bit userspace) sendfile(2) is overwriting data already written to the file descriptor by write(2). Here's a minimal test case: [...] Please can you test whether the attached patch fixes this. Hi Ben, Yes, I can confirm that your patch not only fixes my minimal test case but also the (much more complex) issue we were having. Thank you. Should I deploy my custom deb file, or are you likely to push this out soon enough that I'd be making an unnecessary mess? Mike Ashton Network Infrastructure Manager moo.com :: email | m...@moo.com MOO Print Ltd 32 Scrutton Street (Rear) London EC2A 4RQ +44(0) 207 392 2781 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641419: linux-image-2.6.32-5-amd64: sendfile(2) behaves incorrectly in 2.6.32-5-amd64, overwriting written data
Package: linux-2.6
Version: 2.6.32-35squeeze2
Severity: important
In the squeeze standard 64 bit kernel (with either 64 or 32 bit
userspace) sendfile(2) is overwriting data already written to the file
descriptor by write(2). Here's a minimal test case:
-
echo there turtle.jpeg
cat EOF sendfiletest.c
#include unistd.h
#include fcntl.h
int main()
{
int fd1=open(turtle.jpeg, O_RDONLY);
int fd2=open(test6.pdf, O_RDWR|O_CREAT|O_TRUNC, 0644);
write(fd2, hello, 5);
sendfile(fd2,fd1, NULL, 10);
}
EOF
gcc sendfiletest.c -o sendfiletest
./sendfiletest
cat test6.pdf
On squeeze's 2.6.32-5-amd64 kernel the file will contain there. On
lenny, it will contain hellothere. On later (backported or
handbuilt) kernels, the behaviour returns to hellothere.
This isn't just a nasty bug, but I'm concerned it might be exploitable.
It certainly causes our pdf generation library to go horrible wrong :)
If there's anything else I can do to be of assistance, please do let
me know.
To be explicit, the server I sent this mail from is _not_ vulnerable
because it's running a backport kernel. This bug report refers to the
squeeze standard kernel, not the one I'm running here.
-- Package-specific info:
** Kernel log: boot messages should be attached
-- System Information:
Debian Release: 6.0.2
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.39-bpo.2-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages linux-image-2.6.32-5-amd64 depends on:
ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy
ii initramfs-tools [linux-init 0.99~bpo60+1 tools for generating an initramfs
ii linux-base 3.3~bpo60+1 Linux image base package
ii module-init-tools 3.12-1 tools for managing Linux kernel mo
Versions of packages linux-image-2.6.32-5-amd64 recommends:
ii firmware-linux-free2.6.32-35squeeze2 Binary firmware for various driver
ii libc6-i686 2.11.2-10 Embedded GNU C Library: Shared lib
Versions of packages linux-image-2.6.32-5-amd64 suggests:
ii lilo 1:22.8-10 LInux LOader - The Classic OS load
pn linux-doc-2.6.32 none (no description available)
Versions of packages linux-image-2.6.32-5-amd64 is related to:
ii firmware-bnx2 0.33 Binary firmware for Broadcom NetXt
ii firmware-bnx2x0.33 Binary firmware for Broadcom NetXt
pn firmware-ipw2x00 none (no description available)
pn firmware-ivtv none (no description available)
pn firmware-iwlwifi none (no description available)
pn firmware-linuxnone (no description available)
pn firmware-linux-nonfreenone (no description available)
pn firmware-qlogic none (no description available)
pn firmware-ralink none (no description available)
pn xen-hypervisornone (no description available)
-- debconf-show failed
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#385146: Not a supported combination
On Thu, Aug 31, 2006 at 06:04:29PM +0100, Helge Kreutzmann wrote: severity 385146 wishlist thanks I've never used trac, but saw your report and felt a little strange. You blame a Debian version which version requirements are perfectly fullfilled (as you say, trac works with stable subversion) as shipped by Debian for a system you created by installing software not shipped in Debian. Moreover, trac broke because a *dependency* changed. How do you think the author of trac should have estimated this before the release of Sarge? I think you can do one or more of the following: a) complain against the person who installed the backported subversion for breaking your setup b) backport a more recent trac c) check if tracs depencency in *sid* are correct; if they are not, then update this bug with that info d) point out which part of Debian policy is violated by your combination of a Debian release with your own software packages e) provide a solution how to avoid such situation in the future f) explain what in your opinion should happen now: stable is only updated with severe bugs (e.g. security, read the www.debian.org or d-d-a for details), certainly not to fix some random dependency for a backport Hi Helge. That was a very defensive response, so I'd like to clarify first of all that I'm not _blaming_ _anyone_. It's an open source project, people contribute their efforts for free, how could I complain or blame anyone? I'm trying to help make things slightly better by correcting what I see as a problem that could impact other people. It's already impacted on me, so I've got nothing left to gain personally by having things changed. In reverse order, for no apparent reason: f) the stability of debian systems and packages should refer to the packages themselves, a policy in place for good and sensible reasons, but not necessary to remedial fixes to their metadata. e) I would advocate updating package dependencies if they are found to be incorrect. I don't necessarily advocate providing an updated package number for this, as the package itself hasn't changed, but that's debatable. d) I'm interested in things being correct and working reliably, giving the end user a positive and consistent experience. That's why I work very hard to get debian, rather than redhat, into every environment I work in. It's hard work, but ultimately worth it mainly because debian's packaging and dependency subsystem enables me to run a better service as a result. I'd like debian to be as reliable as possible, and backports are a part of life when providing a service to a technical team - nobody is going to accept a bug riddled version of software from a year ago because it's stable; that argument won't wash. If you're going to quote policy over correctness, and dismiss an issue because it's not supported (I've got a support contract!? Nice!) then I might as well talk to redhat, because at least they'll be apologetic while doing the wrong thing. c) I can't imagine that being an issue, because that version of trac will have been compiled against a sid system. The issue is that the dependencies for stable trac are misstated and as such are too loose. b) That's my department's plan, as it happens, but this will take a little while due to the schema for trac (against which one writes reports within the tool) being fairly fluid. As I said, my concern isn't about _me_ and I can change the package on my system with ease, but I don't believe that people should be able to install conflicting or incompatible packages from any combinations of distribution. As Steve points out, this will be a problem when mixing pure debian distributions as well. a) I installed it. That's why I'm raising this issue that I encountered. Backports usually work flawlessly, but what's happened in this case is that they've not realised there's a problem because the dependencies specified by trac allow the system to install incompatible packages without warning. That's nobody's _fault_, but it _is_ something that isn't as good as it could be, given a small, low-impact change. Ta, Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385146: Not a supported combination
Thanks for the response - we'll leave this in the hands of the maintainer now and stop wittering at people :-) I thought I'd selected normal severity (the default for M-x debian-bug). If I did something dopey like raise it as serious (I can just about see me doing that because it talks about policy rather than the package itself, which is sort of where this problem falls) then I apologise, and please feel free to downgrade it. Ta, Mike. -Original Message- From: Helge Kreutzmann [mailto:[EMAIL PROTECTED] Sent: 01 September 2006 14:28 To: Mike Ashton Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Bug#385146: Not a supported combination Hello Mike, On Fri, Sep 01, 2006 at 12:10:59PM +0100, Mike Ashton wrote: I've never used trac, but saw your report and felt a little strange. You blame a Debian version which version requirements are perfectly fullfilled (as you say, trac works with stable subversion) as shipped by Debian for a system you created by installing software not shipped in Debian. Moreover, trac broke because a *dependency* changed. How do you think the author of trac should have estimated this before the release of Sarge? I think you can do one or more of the following: a) complain against the person who installed the backported subversion for breaking your setup b) backport a more recent trac c) check if tracs depencency in *sid* are correct; if they are not, then update this bug with that info d) point out which part of Debian policy is violated by your combination of a Debian release with your own software packages e) provide a solution how to avoid such situation in the future f) explain what in your opinion should happen now: stable is only updated with severe bugs (e.g. security, read the www.debian.org or d-d-a for details), certainly not to fix some random dependency for a backport Hi Helge. That was a very defensive response, so I'd like to clarify first of all that I'm not _blaming_ _anyone_. It's an open source Point taken, I should'nt have used such strong words. I guess I looked too long on the not-lowering numbers of RC bugs. project, people contribute their efforts for free, how could I complain or blame anyone? I'm trying to help make things slightly better by correcting what I see as a problem that could impact other people. It's already impacted on me, so I've got nothing left to gain personally by having things changed. Ok, thanks for reporting then. I simply saw no way a Debian developer could act on this report, and it was not filed important or lower but with an RC severity (for Etch). f) the stability of debian systems and packages should refer to the packages themselves, a policy in place for good and sensible reasons, but not necessary to remedial fixes to their metadata. Yes, I agree. e) I would advocate updating package dependencies if they are found to be incorrect. I don't necessarily advocate providing an updated package number for this, as the package itself hasn't changed, but that's debatable. There you'll have to talk to the stable RMs. I can't remember an update for such a reason, though. But in principle it should be possible. I don't know if they read this bug log, you might ask on Debian release if an update in the next point release is possible. d) I'm interested in things being correct and working reliably, giving the end user a positive and consistent experience. That's Thanks. Debian cares for its users as well. why I work very hard to get debian, rather than redhat, into every environment I work in. It's hard work, but ultimately worth it mainly because debian's packaging and dependency subsystem enables me to run a better service as a result. I'd like debian to be as reliable as possible, and backports are a part of life when providing a service to a technical team - nobody is going to accept a bug riddled version of software from a year ago because it's stable; that argument won't wash. If you're going to quote policy over correctness, and dismiss an issue because it's not supported (I've got a support contract!? Nice!) then I might as well talk to redhat, because at least they'll be apologetic while doing the wrong thing. There you misunderstood me. The Debian developers work hard to get their system in shape and to ensure, that stable is stable (including that security issues found are fixed). That is the support I was taking about. I am happy, of course, if a developer also spends time ensuring that non standard configurations are supported (e.g. conflicts with non-debian packages, support for backports (which quite a few packages provide)) and grateful, but *I* would consider it a nice request, but no a relase critical bug (for Etch). And yes, I've done backports and found similar errors to yours as well. And sorry to hear that a bug riddled
Bug#385146: trac: trac has an inaccurate dependency and can be installed but broken.
Package: trac Version: 0.8.1-3sarge5 Severity: serious As you can see below, trac depends on subversion, but this isn't quite true. It depends on the particular version of libsvn0 that stable subversion comes with. If you install a backport subversion, libsvn_swig_py is no longer included in libsvn0, which causes trac to fail. So the reason I'm raising a bug against trac for this, as well mentioning this to backports, is dpkg didn't spot the problem because trac's dependencies aren't strict enough - it doesn't just depend on subversion (= 1.0.1), it depends explicitly on libsvn0 certainly less than 1.3.2, and probably much less than that. To reproduce this problem, simply install a backport subversion on a stable system and then try to use trac-admin. I hope that all made sense. Cheers, Mike. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.16.20 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages trac depends on: ii python2.3.5-2An interactive high-level object-o ii python-clearsilver0.9.13-3.2 python bindings for clearsilver ii python-sqlite 1.0.1-2python interface to SQLite ii python2.3-subversion 1.1.4-2python modules for interfacing wit ii subversion1.1.4-2advanced version control system (a -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
