Bug#1034622: docker.io: Installing docker broke my server: iptables
Package: docker.io Version: 20.10.5+dfsg1-1+deb11u2 Severity: important Dear Maintainer, Installing docker.io rendered my server inoperable. Solely as a result of "apt-get install docker.io", it installed iptables rules which corrupted the network configuration rendering the network unusable. Stopping docker with "systemctl docker stop" did not restore the network state to operability. Uninstalling docker with "dpkg --purge docker.io" did not restore the network state to operability. Manually removing the iptables rules docker installed did not restore the network state to operability. It was a server running lots of vms, so it was a pain to reboot -- the solution which finally restored the network function. The problem was successfully worked around by adding a line to /etc/default/docker: DOCKER_OPTS=--iptables=false Merely installing a software package SHOULD NOT render the network unusable. Suggested correction: Either add iptables=false as default, or do not immediately start docker upon installation so that merely installing docker does not change the network configuration on the machine. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.261-deb11 (SMP w/40 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages docker.io depends on: ii adduser 3.118 ii containerd 1.4.13~ds1-1~deb11u3 ii init-system-helpers 1.60 ii iptables 1.8.7-1 ii libc62.31-13+deb11u5 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libsystemd0 247.3-7+deb11u1 ii lsb-base 11.1.0 ii runc 1.0.0~rc93+ds1-5+deb11u2 ii tini 0.19.0-1 Versions of packages docker.io recommends: ii apparmor 2.13.6-10 ii ca-certificates 20210119 ii cgroupfs-mount 1.4 ii git 1:2.30.2-1+deb11u2 ii needrestart 3.5-4+deb11u2 ii xz-utils 5.2.5-2.1~deb11u1 Versions of packages docker.io suggests: pn aufs-tools ii btrfs-progs5.10.1-2 ii debootstrap1.0.123+deb11u1 pn docker-doc ii e2fsprogs 1.46.2-2 pn rinse pn rootlesskit ii xfsprogs 5.10.0-4 pn zfs-fuse | zfsutils-linux -- Configuration Files: /etc/default/docker changed: DOCKER_OPTS=--iptables=false -- no debconf information
Bug#969551: bash: !ref: unbound variable
Package: bash-completion Version: 1:2.8-6 Severity: normal Dear Maintainer, * What led up to the situation? set -u * What exactly did you do (or not do) that was effective (or ineffective)? cd / cd ho[tab] * What was the outcome of this action? bash: !ref: unbound variable * What outcome did you expect instead? cd home The error appears to come from __reassemble_comp_words_by_ref() in /usr/share/bash-completion/bash_completion -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.219-deb10 (SMP w/40 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#969006: systemd-run has faulty path expansion that will find directories instead of programs
Package: systemd
Version: 241-7~deb10u4
Severity: normal
Tags: upstream
Dear Maintainer,
{iolo.udic.org:herrin:/home/herrin:!} echo $PATH
/home/herrin:/usr/bin:/sbin:/usr/sbin:/usr/lib:/bin:/usr/local/bin
{iolo.udic.org:herrin:/home/herrin:!} systemd-run --scope --user echo stuff
Running scope as unit: run-r6a38909438ac4ec28babc2cafba48965.scope
stuff
{iolo.udic.org:herrin:/home/herrin:!} mkdir echo
{iolo.udic.org:herrin:/home/herrin:!} systemd-run --scope --user echo stuff
Running scope as unit: run-r2a3872adfffa447f8b6b8aeed6fcf9a9.scope
Failed to execute: Permission denied
Aug 25 13:43:07 iolo systemd[24566]: Started /bin/echo stuff.
Aug 25 13:43:07 iolo systemd[24566]:
run-r6a38909438ac4ec28babc2cafba48965.scope: Succeeded.
Aug 25 13:44:00 iolo systemd[24566]: Started /home/herrin/echo stuff.
Aug 25 13:44:00 iolo systemd[24566]:
run-r2a3872adfffa447f8b6b8aeed6fcf9a9.scope: Succeeded.
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- Package-specific info:
-- System Information:
Debian Release: 10.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.141-deb10 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii adduser 3.118
ii libacl1 2.2.53-4
ii libapparmor1 2.13.2-10
ii libaudit11:2.8.4-3
ii libblkid12.33.1-0.1
ii libc62.28-10
ii libcap2 1:2.25-2
ii libcryptsetup12 2:2.1.0-5+deb10u2
ii libgcrypt20 1.8.4-5
ii libgnutls30 3.6.7-4+deb10u5
ii libgpg-error01.35-1
ii libidn11 1.33-2.2
ii libip4tc01.8.2-4
ii libkmod2 26-1
ii liblz4-1 1.8.3-1
ii liblzma5 5.2.4-1
ii libmount12.33.1-0.1
ii libpam0g 1.3.1-5
ii libseccomp2 2.3.3-4
ii libselinux1 2.8-1+b1
ii libsystemd0 241-7~deb10u4
ii mount2.33.1-0.1
ii util-linux 2.33.1-0.1
Versions of packages systemd recommends:
ii dbus1.12.20-0+deb10u1
ii libpam-systemd 241-7~deb10u4
Versions of packages systemd suggests:
ii policykit-10.105-25
pn systemd-container
Versions of packages systemd is related to:
pn dracut
ii initramfs-tools 0.133+deb10u1
ii udev 241-7~deb10u4
-- Configuration Files:
/etc/systemd/system.conf changed [not included]
-- no debconf information
Bug#877330: dpkg: tar (>= 1.28-1) is a build dependency
Thanks Niels, I ended up removing the two conflicting tar options from the two files which had them, and then striking the dependency from dpkg. For what I'm doing, I don't need the .deb's to come up byte-identical when the source is unchanged. You are also correct; I could have just used debhelper from backports. Regards, Bill On Sat, Sep 30, 2017 at 5:04 PM, Niels Thykier <ni...@thykier.net> wrote: > On Sat, 30 Sep 2017 12:11:34 -0400 William Herrin <her...@dirtside.com> > wrote: > > Package: dpkg > > Version: 1.18.24 > > Severity: normal > > > > Dear Maintainer, > > > > *** Reporter, please consider answering these questions, where > appropriate *** > > > >* What led up to the situation? > > Want to build quagga 1.1 on a Jessie machine > > won't build because debhelper < version 10 > > [...] > > Hi, > > (Not the dpkg maintainer, but ...) > > Have you considered using the debhelper/10.2.5~bpo8+1 release from > jessie-backports? Assuming you just need debhelper (>= 10) that should > be sufficient. :) > > FYI/FTR: The backported version of debhelper works without dpkg 1.18 by > disabling some features[1]. I suspect none of them are critical for > your use-case (although, the lack of dbgsym packages can be inconvenient) > > Thanks, > ~Niels > > [1] > > * Existing changes from previous bpo releases: > > - Disable automatic dbgsym as it requires dpkg-dev 1.18.2 > > - Revert of sgml-base trigger as it needs a newer version > > of sgml-base (Related bug: #825005) > > -- William Herrin her...@dirtside.com b...@herrin.us Dirtside Systems . Web: <http://www.dirtside.com/>
Bug#877330: dpkg: tar (>= 1.28-1) is a build dependency
Package: dpkg Version: 1.18.24 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Want to build quagga 1.1 on a Jessie machine won't build because debhelper < version 10 debhelper won't build because dpkg-dev < 1.18 tried to build newer dpkg * What exactly did you do (or not do) that was effective (or ineffective)? dpkg-buildpackage in dpkg-1.18.24 on a Jessie machine * What was the outcome of this action? build failed * What outcome did you expect instead? build succeeded scripts/Dpkg/Source/Archive.pm declares options to the tar command which are not present before 1.28-1. These options are passed to tar during the build tests causing the build to fail with Jessie's version 1.27. tar (>= 1.28-1) is declared in Depends but is not declared in Build-Depends *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.1 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.48 (SMP w/12 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-8.1 ii libc62.24-11+deb9u1 ii liblzma5 5.2.2-1.2+b1 ii libselinux1 2.6-3+b1 ii tar 1.29b-1.1 ii zlib1g 1:1.2.8.dfsg-5 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt1.4.7 pn debsig-verify -- no debconf information
Bug#856045: x11-xserver-utils: Incorrect xrandr: cannot find crtc for output HDMI2
Package: x11-xserver-utils Version: 7.7+3+b1 Severity: normal Dear Maintainer, Running debian stable (jessie) I moved my laptop from home (with one monitor setup) to work (with a different one) using hibernate/resume (that is, no reboot). At home my monitors are eDP1, DP1 and HDMI1. At work they're eDP1, HDMI1 and HDMI2. Arandr generated the following xrandr command to reconfigure the screens for my work environment. It failed. I attempted the xrandr command it generted by hand: xrandr --output HDMI2 --mode 1920x1080 --pos 152x2352 --rotate normal --output HDMI1 --mode 1920x1080 --pos 3992x2352 --rotate normal --output DP1 --off --output eDP1 --mode 1920x1080 --pos 2072x2352 --rotate normal --output DP2 --off The command failed with the following error: xrandr: cannot find crtc for output HDMI2 Despite what the error said, HDMI2 was connected and recognized by xrandr as being connected. The following sequence of commands (the second identical to the original above) successfully configured the display as intended. xrandr --output DP1 --off xrandr --output HDMI2 --mode 1920x1080 --pos 152x2352 --rotate normal --output HDMI1 --mode 1920x1080 --pos 3992x2352 --rotate normal --output DP1 --off --output eDP1 --mode 1920x1080 --pos 2072x2352 --rotate normal --output DP2 --off Regards, Bill Herrin *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.39-desktop (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages x11-xserver-utils depends on: ii cpp 4:4.9.2-2 ii libc62.19-18+deb8u7 ii libice6 2:1.0.9-1+b1 ii libx11-6 2:1.6.2-3 ii libxaw7 2:1.0.12-2+b1 ii libxcursor1 1:1.1.14-1+b1 ii libxext6 2:1.3.3-1 ii libxi6 2:1.7.4-1+b2 ii libxmu6 2:1.1.2-1 ii libxmuu1 2:1.1.2-1 ii libxrandr2 2:1.4.2-1+b1 ii libxrender1 1:0.9.8-1+b1 ii libxt6 1:1.1.4-1+b1 ii libxxf86vm1 1:1.1.3-1+b1 x11-xserver-utils recommends no packages. Versions of packages x11-xserver-utils suggests: pn cairo-5c pn nickle ii xorg-docs-core 1:1.7-1 -- no debconf information
Bug#766249: iceweasel: wheezy force upgraded to 31.2.0esr-2~deb7u1
On Tue, Oct 21, 2014 at 9:23 PM, Mike Hommey m...@glandium.org wrote: On Tue, Oct 21, 2014 at 08:18:14PM -0400, William Herrin wrote: On Tue, Oct 21, 2014 at 6:42 PM, Mike Hommey m...@glandium.org wrote: On Tue, Oct 21, 2014 at 06:05:27PM -0400, William Herrin wrote: https://www.debian.org/security/faq The most important guideline when making a new package that fixes a security problem is to make as few changes as possible. Our users and developers are relying on the exact behaviour of a release once it is made, so any change we make can possibly break someone's system. Wanna bet what Red Hat does? Spoiler alert: the same thing https://www.redhat.com/archives/rhsa-announce/2014-October/msg00026.html Mike, you summarize my complaint: with iceweasel you've done the same lousy job at versioning that Red Hat does. You can do better. To come close to meeting the Debian patch guidelines, you must do better. Reality is that the choice is between not shipping a web browser, or shipping one that's secure. Nonsense. I offered three credible alternatives to the current practice for iceweasel in yesterday's email none of which requires significant additional effort from you. It's impossible to ship a secure browser that stays at the same major version anymore[1]. Agreed. Nevertheless, your conclusion above does not follow from this fact. There are better ways to handle the problem that blithely blowing away the users' configuration, including better ways at the same level of effort. Open your mind. Regards, Bill Herrin
Bug#766249: iceweasel: wheezy force upgraded to 31.2.0esr-2~deb7u1
1. Introduce an iceweasel32 package and obsolete the old iceweasel package at the point where you're no longer able to provide security updates to it. The obsoleted package won't be removed until the sysadmin decides to remove it. This means we should skip the ESR version 31 with the security fixes and put a current devel version into stable? Possible, but seriously, why should we do that? Due respect Carsten, you're being deliberately obtuse here. If firefox esr 31 is the one you deem current and secure, replace 32 in every reference I made. I offer no opinion on that; I would hope you're qualified to make that assessment. No! We do nothing on the versioning! We do nothing more than provide a actual, more bugfixed version for the current stable release of Debian. That's simple and that's all. By your own statement, you moved from Firefox 10 through several iterations all the way to Firefox 31 inside of Wheezy. If you don't like the word versioning to describe that misbehavior, misbehavior that is in conflict with the debian security patch guidelines, pick a word you like better. I haven't seen any bug on this that a user is loosing any configuration depending on upgrading from Iceweasel 24 to 31. Not for lack of me reporting one. Yesterday. 2. Offer a high-priority dialog at install time if the version being replaced is enough older to have compatibility problems, advising that the version being installed is known to be incompatible. Offer an abort upgrade option which will fail out of the package install. No, we do a security update. So there is nothing to do so. Nothing for YOU to do, ya lazy bum. ;) Seriously though, on my side of the fence you create substantial sysadmin work. Now I have to revert the change (hunt down the old package) because you just blew up my configuration, I have to hold the package in apt and pray no dependencies move it back to install. Then I have to schedule a cautious move forward. Then I have to hold the package again so you don't blow me out of the water next time. And then I have to manually keep track because I'm no longer receiving automatic security updates for Firefox and won't know when one is released. Unexpected major version bumps really screw me over bub. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Bug#766249: iceweasel: wheezy force upgraded to 31.2.0esr-2~deb7u1
Subject: iceweasel: wheezy force upgraded to 31.2.0esr-2~deb7u1 Package: iceweasel Version: 31.2.0esr-2~deb7u1 Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? used dselect for routine security patches * What exactly did you do (or not do) that was effective (or ineffective)? dselect, Update, Select, Enter (accept selections), Install * What was the outcome of this action? Iceweasel 31.2.0esr2~deb7u1 from debian unstable installed * What outcome did you expect instead? Iceweasel 24.8.1esr1~deb7u1 from debian stable installed This is a major breach of protocol for debian security patches. You DO NOT, DO NOT, DO NOT release major new upstream versions in the middle of a stable release cycle. You certainly do not release new versions which are significantly incompatible with the old version. I filed this bug against iceweasel as I see no indication of this misbehavior for any other package upgraded by dselect. If this should turn out to be a dselect error, please accept my apologies and advise so that I may refile. -- Package-specific info: -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.58-lvs (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages iceweasel depends on: ii debianutils 4.3.2 ii fontconfig 2.9.0-7.1 ii libc6 2.13-38+deb7u6 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libgtk2.0-0 2.24.10-2 ii libsqlite3-03.7.13-1+deb7u1 ii libstdc++6 4.7.2-5 ii procps 1:3.3.3-3 ii xulrunner-24.0 24.8.1esr-1~deb7u1 iceweasel recommends no packages. Versions of packages iceweasel suggests: pn fonts-mathjax none ii fonts-oflb-asana-math 000.907-4 ii fonts-stix [otf-stix] 1.1.0-1 ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u2 pn mozplugger none Versions of packages xulrunner-24.0 depends on: ii libasound21.0.25-4 ii libatk1.0-0 2.4.0-2 ii libbz2-1.01.0.6-4 ii libc6 2.13-38+deb7u6 ii libcairo2 1.12.2-3 ii libdbus-1-3 1.6.8-1+deb7u4 ii libdbus-glib-1-2 0.100.2-1 ii libevent-2.0-52.0.19-stable-3 ii libfontconfig12.9.0-7.1 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.7.2-5 ii libgdk-pixbuf2.0-02.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgtk2.0-0 2.24.10-2 ii libhunspell-1.3-0 1.3.2-4 ii libmozjs24d 24.8.1esr-1~deb7u1 ii libpango1.0-0 1.30.0-1 ii libstartup-notification0 0.12-1 ii libstdc++64.7.2-5 ii libvpx1 1.1.0-1 ii libx11-6 2:1.5.0-1+deb7u1 ii libxext6 2:1.3.1-2+deb7u1 ii libxrender1 1:0.9.7-1+deb7u1 ii libxt61:1.1.3-1+deb7u1 ii zlib1g1:1.2.7.dfsg-13 Versions of packages xulrunner-24.0 suggests: ii libcanberra0 0.28-6 pn libgnomeui-0 none -- no debconf information
Bug#766249: iceweasel: wheezy force upgraded to 31.2.0esr-2~deb7u1
https://www.debian.org/security/faq The most important guideline when making a new package that fixes a security problem is to make as few changes as possible. Our users and developers are relying on the exact behaviour of a release once it is made, so any change we make can possibly break someone's system. Like mine. In my various Debian deployments I rely on the truth of the quoted statement. When package fails to follow that procedure, particularly when that failure is in a very visible package, I am negatively impacted. It's hard enough to convince the PHB's to use Debian over Red Hat without it blowing up in my face because of a poorly conceived update. I don't know what you did before iceweasel 24.8 and I don't care. Perhaps I didn't notice because while I've run Debian servers for 15 years these past few months are the first time in half a decade that I've given Debian on the desktop a chance. I understand that some upstream software managers behave so badly that your hands can be tied at the Debian level. Certainly that's true of Firefox. But in such a circumstance I beg you: do something other than push out the new upstream version. Here are some alternatives you might consider: 1. Introduce an iceweasel32 package and obsolete the old iceweasel package at the point where you're no longer able to provide security updates to it. The obsoleted package won't be removed until the sysadmin decides to remove it. 2. Offer a high-priority dialog at install time if the version being replaced is enough older to have compatibility problems, advising that the version being installed is known to be incompatible. Offer an abort upgrade option which will fail out of the package install. 3. Package firefox 32 and the previous Wheezy firefoxes in the same bundle. On first run for a user following the update, prompt for which version to execute advising that versions older than current are known to have security flaws. -Bill On Tue, Oct 21, 2014 at 3:30 PM, Carsten Schoenert c.schoen...@t-online.de wrote: Hello William, On Tue, Oct 21, 2014 at 02:44:34PM -0400, William Herrin wrote: Subject: iceweasel: wheezy force upgraded to 31.2.0esr-2~deb7u1 This is a major breach of protocol for debian security patches. You DO NOT, DO NOT, DO NOT release major new upstream versions in the middle of a stable release cycle. You certainly do not release new versions which are significantly incompatible with the old version. no it is not. Debian Wheezy was starting with version 10.0.12 for Iceweasel. Right at the release of Wheezy this version wasn't supported any longer by Mozilla. We did change the major version two times before the current version 31 in stable-security, ESR version 17 and 24. $ rmadison iceweasel | grep security iceweasel | 3.5.16-20| squeeze-security | source, amd64, armel, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc iceweasel | 17.0.10esr-1~deb7u1 | wheezy-security | source, ia64, mips, mipsel iceweasel | 24.5.0esr-1~deb7u1 | wheezy-security | source, sparc iceweasel | 24.8.0esr-1~deb7u1 | wheezy-security | source iceweasel | 24.8.1esr-1~deb7u1 | wheezy-security | source, armhf, kfreebsd-amd64, kfreebsd-i386, s390 iceweasel | 31.2.0esr-2~deb7u1 | wheezy-security | source, amd64, armel, i386, powerpc, s390x Now Mozilla started a new ESR version and the security team has decided to use this versions in the current stable-security repository. An they are right! Regards Carsten -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Bug#766249: iceweasel: wheezy force upgraded to 31.2.0esr-2~deb7u1
On Tue, Oct 21, 2014 at 6:42 PM, Mike Hommey m...@glandium.org wrote: On Tue, Oct 21, 2014 at 06:05:27PM -0400, William Herrin wrote: https://www.debian.org/security/faq The most important guideline when making a new package that fixes a security problem is to make as few changes as possible. Our users and developers are relying on the exact behaviour of a release once it is made, so any change we make can possibly break someone's system. So what is the problem now? That the UI changed more visibly than it did before? Then install this: https://addons.mozilla.org/en-US/firefox/addon/classicthemerestorer/ Mike Well Mike, there are two problems: the one that pisses me off and the one you should care about. The one that pisses me off is that the particular extensions I use have not been ported forward yet (and may or may not be), so upgrading irreparably breaks my user experience. The one you should care about is that as a responsible system administrator I can't even consider deploying Debian to hundreds desktops unless I know the quoted Debian standard above is being followed. Nor can anyone else in a position to deploy large numbers of Debian desktops. Time comes, I'll be asked why not Red Hat and unlike on the server side I won't be able to say, stability. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Bug#633699: binutils: extern int errno = ld terminated with signal 11
Package: binutils
Version: 2.20.1-16
Severity: normal
/* foul.c */
extern int errno;
int main (void) {
return errno;
}
$ gcc -Wall foul.c
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
/usr/bin/ld:
Expected result:
$ gcc -Wall foul.c
/usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section .tbss mismatches
non-TLS reference in /tmp/ccSb3yWk.o
/lib/libc.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status
-- System Information:
Debian Release: 6.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32.27-vm3 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages binutils depends on:
ii libc6 2.11.2-10Embedded 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
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
binutils recommends no packages.
Versions of packages binutils suggests:
pn binutils-doc none (no description available)
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568519: lighttpd fails proxy connections when upgraded to 1.4.19-5+lenny1
Hi Stefan, I'm not using redmine; the problem impacts all documents including static documents on the lighttpd side. Access directly to lighttpd directly from web browsers appears to work with the several I've tried. The only failures I've encountered are when reverse-proxying through apache and it fails with all web browsers in said configuration. This fails 100% of the time when attempted with lighttpd 1.4.19.5+lenny1 and various releases of apache 2.2. I do not recall seeing any log entries on the Lighttpd side. The log entries on the apache side are in the bug ticket. I'm using this directive in a .htaccess file on the apache side to trigger the reverse proxy: RewriteRule ^https/([^\/]+)/(.*)$ https://$1/$2 [P] I then point a web browser to: http://apache.server/directory/https/192.168.1.1/lighttpd.file Worked fine with no configuration changes on either side in lighttpd 1.4.19.5. If for some reason apache actually works with lighttpd when you try to repeat the described behavior, please send me the configs you used. I'll be happy to chase it further and narrow it down. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568519: lighttpd proxy connections from apache fail 1.4.19-5+lenny1
Package: lighttpd Followup-For: Bug #568519 Same problem here. Apache source for the proxy connection is httpd-2.2.3-31.el5.centos.2 worked fine in 1.4.19-5 in 1.4.19.5+lenny1, apache reports: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /https/10.187.2.51/. Reason: Error reading from remote server [Mon Feb 15 09:12:52 2010] [error] [client 1.1.1.1] proxy: error reading status line from remote server 2.2.2.2 downgrading to 1.4.19-5 restores operation. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.27.45-vm (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages lighttpd depends on: ii libattr1 1:2.4.43-2Extended attribute shared library ii libbz2-1.0 1.0.5-1 high-quality block-sorting file co ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii libfam02.7.0-13.3+lenny1 Client library to control the FAM ii libldap-2.4-2 2.4.11-1+lenny1 OpenLDAP libraries ii libpcre3 7.6-2.1 Perl 5 Compatible Regular Expressi ii libssl0.9.80.9.8g-15+lenny6 SSL shared libraries ii libterm-readline-perl- 1.0302-1 Perl implementation of Readline li ii lsb-base 3.2-20Linux Standard Base 3.2 init scrip ii mime-support 3.44-1MIME files 'mime.types' 'mailcap ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime lighttpd recommends no packages. Versions of packages lighttpd suggests: ii apache2-utils 2.2.9-10+lenny6 utility programs for webservers ii openssl 0.9.8g-15+lenny6 Secure Socket Layer (SSL) binary a pn rrdtool none (no description available) -- 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 Archive: http://lists.debian.org/20100215165243.7965.63508.report...@beta.lh-02.com
Bug#503173: grub-common: Segmentation fault in grub-probe
I also get a segv when running under kernels using exec-shield. (http://people.redhat.com/mingo/exec-shield/). # grub-probe No path or device is specified. Try ``grub-probe --help'' for more information. # grub-probe -v -d /dev/hda Segmentation fault There was no output from grub-install offering a clue about the source of the failure (grub-probe segving). The absence of the expected output offered a clue that there was a problem. # grub-install /dev/hda # echo $? 1 I first encountered the error during a kernel install which offered only the following: Running postinst hook script update-grub. Searching for GRUB installation directory ... found: /boot/grub User postinst hook script [update-grub] exited with value 139 Workaround: # echo 0 /proc/sys/kernel/exec-shield # grub-install /dev/hda install_device=/dev/hda Searching for GRUB installation directory ... found: /boot/grub Installation finished. No error reported. This is the contents of the device map /boot/grub/device.map. Check if this is correct or not. If any of the lines is incorrect, fix it and re-run the script `grub-install'. (hd0) /dev/hda (hd1) /dev/hdc # echo 2 /proc/sys/kernel/exec-shield -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#451563: apache2.2-common: HTTP PUT with mod_dav fails to detect an aborted connection
Package: apache2.2-common
Version: 2.2.3-4+etch1
Severity: normal
Apache treats an aborted HTTP PUT as if it completed successfully, logs
the PUT as having completed successfully and leaves the incomplete file
on the disk. It does so even though the transmitted content is much shorter
than the advertised content length.
Replicate with:
httpd.conf:
LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
LoadModule dav_fs_module /usr/lib/apache2/modules/mod_dav_fs.so
LoadModule dav_lock_module /usr/lib/apache2/modules/mod_dav_lock.so
DAVLockDB /tmp/DAVLock
Directory /var/www/dav/
Dav filesystem
/Directory
# mkdir /var/www/dav
# chown www-data /var/www/dav
# curl -T bigfile http://localhost/dav/bigfile
^C
partial upload at /var/www/dav/bigfile remains on the disk.
access_log shows success status 201:
127.0.0.1 - - [16/Nov/2007:17:31:32 -0500] PUT /dav/bigfile HTTP/1.1 201 322
- curl/7.15.5 (i486-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3
libidn/0.6.5
excerpts from tcpdump:
PUT /dav/bigfile HTTP/1.1
User-Agent: curl/7.15.5 (i486-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c
zlib/1.2.3 libidn/0.6.5
Host: minoc.dirtside.com
Accept: */*
Content-Length: 723795856
Expect: 100-continue
HTTP/1.1 100 Continue
[uploaded data until ^C]
Note: FIN packet from source due to program abort
17:31:32.166989 IP (tos 0x0, ttl 64, id 58671, offset 0, flags [DF], proto:
TCP (6), length: 16436) 127.0.0.1.57636 127.0.0.1.80: FP
4587737:4604121(16384) ack 26 win 8192 nop,nop,timestamp 96632442 96632442
Note: Apache responds with success message anyway
17:31:32.170708 IP (tos 0x0, ttl 64, id 31673, offset 0, flags [DF], proto:
TCP (6), length: 629) 127.0.0.1.80 127.0.0.1.57636: P, cksum 0xca8d
(correct), 26:603(577) ack 4604122 win 32768 nop,nop,timestamp 96632443
96632442
[EMAIL PROTECTED]@.N.F..RF..R.P.$f ..e..
..~{..~zHTTP/1.1 201 Created
Date: Fri, 16 Nov 2007 22:31:32 GMT
Server: Apache/2.2.3 (Debian) DAV/2 mod_fastcgi/2.4.2 mod_ssl/2.2.3
OpenSSL/0.9.8c
Location: http://minoc.dirtside.com/dav/bigfile
Content-Length: 322
Content-Type: text/html; charset=UTF-8
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title201 Created/title
/headbody
h1Created/h1
pResource /dav/bigfile has been created./p
hr /
addressApache/2.2.3 (Debian) DAV/2 mod_fastcgi/2.4.2 mod_ssl/2.2.3
OpenSSL/0.9.8c Server at minoc.dirtside.com Port 80/address
/body/html
Note: RST packet from source since the connection is no longer there.
17:31:32.170763 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP
(6), length: 40) 127.0.0.1.57636 127.0.0.1.80: R, cksum 0x1f77
(correct), 1707072287:1707072287(0) win 0
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.56-dualp2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages apache2.2-common depends on:
ii apache2-utils 2.2.3-4+etch1 utility programs for webservers
ii libmagic1 4.17-5etch3 File type determination library us
ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip
ii mime-support 3.39-1MIME files 'mime.types' 'mailcap
ii net-tools 1.60-17 The NET-3 networking toolkit
ii procps 1:3.2.7-3 /proc file system utilities
apache2.2-common recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
