Bug#1053383: verilator version in testing is subject to upstream issue 4362
On Sun, Nov 05, 2023 at 01:39:30PM -0800, Larry Doolittle wrote: > On Mon, Oct 02, 2023 at 11:04:12PM -0700, Larry Doolittle wrote: > > [...] working versions are v5.014 and v5.016. > [and v5.018] Verilator v5.020 was pushed to upstream git on Jan 1, 2024, and I can confirm it also does not suffer from this bug. - Larry
Bug#1053383: verilator version in testing is subject to upstream issue 4362
On Mon, Oct 02, 2023 at 11:04:12PM -0700, Larry Doolittle wrote: > [...] working versions are v5.014 and v5.016. Verilator v5.018 was pushed to upstream git on Oct 31, and I can confirm it also does not suffer from this bug. - Larry
Bug#941804: exim4: remote_smtp_smarthost transport does not set DKIM variables
Andreas - On Thu, Nov 02, 2023 at 04:51:55PM +0100, Andreas Metzler wrote: > Just to be clear: You have got a domain but lack both control of a > machine that is not blocked from accessing outgoing port 25 (and could > deliver) Right. Standard for a "modern" consumer-grade ISP in the U.S. > and the domain package does also lack a smarthost for that > domain that would apply a dkim signature? Yes. The boa.org domain infrastructure and maintenance is self-serve and all-volunteer. (Thanks, Russ!) How would a domain-package smarthost help, if I couldn't get to its port 25 because of the ISP firewall? Of course I don't know the individual situations of others who have posted this question and its answer to various on-line forums. But it's common enough that it was easy to find the answer and patch my Debian exim4 setup to get the desired results. You can see the DKIM my exim4 added, before passing to an ISP smarthost, if you look at the headers of this email. - Larry
Bug#941804: exim4: remote_smtp_smarthost transport does not set DKIM variables
Andreas - On Mon, Oct 16, 2023 at 07:13:28PM +0200, Andreas Metzler wrote: > > severity 941804 normal > > This exim4 bug has taken on increased importance now that gmail requires > > DKIM > > on all (?) incoming messages. > > I do not follow: > > The smarthost transport is typically used by a machine without > permanent internet connection to deliver *to* a smarthost. This > smarthost the does the real delivery using M lookups et al. Basically right. I'd say "permanent and unimpeded Internet connection". See below. > google cares about the DKIM signature of the latter (the real mailserver). Someone has to add the DKIM signature, tied to the sender address. Google doesn't care where in the relaying chain it got added. > OTOH if you want to use google as smarthost you need to use SMTP AUTH > instead of adding a DKIM signature on your personal PC/laptop. My use case is being stuck behind an ISP's firewall, so the smarthost is supplied by the ISP. When the ISP delivers the mail to gmail, google needs some indication that the mail I sent is really from me. That's where DKIM comes in. I _am_ me, so I can make my exim MTA "sign" the message with DKIM on its way to the smarthost. I don't doubt that other people have different setups. Some will need this configuration fixed, some will not. But before google started enforcing SPF/DKIM/DMARC earlier this year, my smarthost routing approach could succeed without complications. Now it needs DKIM. Fortunately I could make that work -- after applying a local patch to fix this bug. - Larry
Bug#941804: exim4: remote_smtp_smarthost transport does not set DKIM variables
Control: found 941804 4.94.2-7+deb11u1 found 941804 4.96-15+deb12u2 found 941804 4.97~RC1-2 severity 941804 normal thanks This exim4 bug has taken on increased importance now that gmail requires DKIM on all (?) incoming messages. I checked and can confirm its presence in the three versions above, as currently used in bullseye, bookworm, and trixie. - Larry
Bug#1053383: verilator version in testing is subject to upstream issue 4362
Apologies for the possibly confusing typo above. > I can confirm that the bug shows up in v5.012, but not v5.014 or v6.016. Of course I mean to say that working versions are v5.014 and v5.016. Where v5.016 doesn't look properly tagged yet, but is actually commit cef3960a. - Larry
Bug#1053383: verilator version in testing is subject to upstream issue 4362
Package: verilator Version: 5.012-1+b1 My use case triggers upstream issue 4362 https://github.com/verilator/verilator/issues/4362 Earlier versions of verilator, like 5.006-3 found in bookworm, do not show the same bug, so it counts as a regression. I personally built several versions from source on bookworm. I can confirm that the bug shows up in v5.012, but not v5.014 or v6.016. I humbly suggest you update the version in testing. My environment is stock testing/trixie amd64 as of today: kernel 6.1.0-12 libc6 2.37-10 libsystemc-dev 2.3.4-3
Bug#1031711: verilator: reproducible-builds: documentation date depends on timezone
Package: src:verilator
Version: 5.006-2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Dear Maintainer,
The Reproducible Builds effort noticed that verilator does not build
reproducibly.
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/verilator.html
This is because the verilator.pdf file's cover-page date stamp depends on the
timezone.
When this situation was brought to the attention of upstream developers,
their preference was to shift to using an internal release date, rather
than fix the SOURCE_DATE_EPOCH override to be timezone-independent.
The attached patch is an upstream git commit (bc6a778, Feb 12 2023)
to their primary development sources.
With this patch applied (note it needs to be listed _after_ the existing
"Add SOURCE_DATE_EPOCH for docs guide conf.py 3918.patch" in patches/series)
verilator should build reproducibly on tests.reproducible-builds.org!
Thanks for maintaining Verilator!
- Larry
>From bc6a7787ed271a8f52ed5b8f8a9e0e8cbba1ab38 Mon Sep 17 00:00:00 2001
From: Larry Doolittle
Date: Sun, 12 Feb 2023 20:21:03 -0800
Subject: [PATCH] Fix date on the front page of verilator.pdf (#3956) (#3957)
---
docs/guide/conf.py | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/docs/guide/conf.py b/docs/guide/conf.py
index 04759c6de..9f69245dd 100644
--- a/docs/guide/conf.py
+++ b/docs/guide/conf.py
@@ -10,7 +10,6 @@
# --
# -- Path setup
-from datetime import datetime
import os
import re
import sys
@@ -24,10 +23,17 @@ def get_vlt_version():
filename = "../../Makefile"
with open(filename, "r", encoding="utf8") as fh:
for line in fh:
-match = re.search(r"PACKAGE_VERSION_NUMBER *= *([a-z0-9.]+)", line)
+match = re.search(r"PACKAGE_VERSION *= *([a-z0-9.]+) +([-0-9]+)", line)
if match:
-return match.group(1)
-return "unknown"
+return match.group(1), match.group(2)
+match = re.search(r"PACKAGE_VERSION *= *([a-z0-9.]+) +devel", line)
+if match:
+try:
+data = os.popen('git log -n 1 --pretty=%cs').read()
+except Exception:
+data = "" # fallback, and Sphinx will fill in today's date
+return "Devel " + match.group(1), data
+return "unknown", "unknown"
def setup(app):
@@ -44,8 +50,8 @@ author = 'Wilson Snyder'
# The master toctree document.
master_doc = "index"
-version = get_vlt_version()
-release = get_vlt_version()
+version, today_fmt = get_vlt_version()
+release = version
rst_prolog = """
.. role:: vlopt(option)
@@ -89,15 +95,6 @@ source_suffix = [".rst"]
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
-try:
-# https://reproducible-builds.org/specs/source-date-epoch/
-doc_now = datetime.fromtimestamp(int(os.environ["SOURCE_DATE_EPOCH"]))
-print("Using SOURCE_DATE_EPOCH")
-except Exception:
-doc_now = datetime.now()
-# Date format to ISO
-today_fmt = doc_now.strftime("%F")
-
# If true, `todo` and `todoList` produce output, else they produce nothing.
todo_include_todos = True
--
2.30.2
Bug#1030913: verilator: FTBFS on hppa
Thanks, John, for the patch. Submitted upstream as pull-request #3954. https://github.com/verilator/verilator/pull/3954
Bug#1008921: Confirming: Verilator is outdated
Debian Electronics Team - I confirm that Debian Verilator is outdated and not useful for Real Work. I can also confirm that "modern" versions of upstream Verilator build easily from source in Debian Testing, and work well. For me, "modern" means v4.220 or later -- that was posted March 2022. At the time of this email, latest is v5.004, posted Dec 14 2022. - Larry
Bug#1020460: xdaliclock: New version ignores Xresource settings and can't be made transparent
I can confirm that the xdaliclock 2.46 in Bookworm/testing works nothing like historical copies of the program. In my case, I have an ancient incantation buried in my .xsession file /usr/bin/xdaliclock -noseconds -nocycle -builtin1 -bg steelblue -fg black -geom -0-0 and the new xdaliclock understands none of those options. Also, five minutes of digging revealed no documentation that any of those features are supported in some other way. Like Stefan, I reverted to the 2.44 binary that's part of Bullseye, and that works fine. I also confirmed that the xdaliclock_2.44+debian-2 source package builds and runs without issue in a Bookworm environment. If we keep xdaliclock 2.46 in Debian despite Jamie's hostility, can we at least give it a new name, and keep xdaliclock as the traditional (2.44) version? - Larry P.S. Can someone fix the Version tag here? It seems to have been confused by Stefan reverting to 2.44 before filing the bug report. This bug actually applies to 2.46 but not 2.44.
Bug#889720: xauth crashes when directory name matches host name
My testing confirms this bug still applies to xauth-1:1.1-1 in Bullseye,
as the status graphic indicates.
Fixed upstream in xauth-1.1.1. I hope that version can be
packaged in time for Bookworm -- it includes a number of
subtle but important improvements.
Looking at the upstream repo at
https://gitlab.freedesktop.org/alanc/xauth
the fix for this particular issue was applied in commit c2811c95
by Alex Gendin on Sep 26, 2020.
Triggering the bug was also made less likely with commit 18a3c3a7
by Dr. Tilmann Bubeck on Aug 20, 2020, but that change seems
incomplete in my testing. I attach a two-line patch that
gives correct output when a file or directory in $PWD happens
to have the same name as $(hostname).
Example, starting with the buggy Debian Bullseye xauth-1.1:
guest@redacted:~/empty$ ls
guest@redacted:~/empty$ ls -l ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
guest@redacted:~/empty$ xauth list $(hostname -f):0
redacted.localdomain:0 MIT-MAGIC-COOKIE-1 d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth list $(hostname -f):0
Segmentation fault
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
57941079 -rw--- 2 guest guest 0 Mar 31 13:09 /home/guest/.Xauthority-c
57941079 -rw--- 2 guest guest 0 Mar 31 13:09 /home/guest/.Xauthority-l
guest@redacted:~/empty$
Then xauth-1.1.1:
guest@redacted:~/empty$ ls
guest@redacted:~/empty$ ls -l ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
guest@redacted:~/empty$ xauth-1.1.1 list $(hostname -f):0
redacted.localdomain:0 MIT-MAGIC-COOKIE-1 d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth-1.1.1 list $(hostname -f):0
xauth-1.1.1: (argv):1: bad display name "redacted.localdomain:0" in "list"
command
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
And finally my patched xauth-1.1.1:
guest@redacted:~/empty$ ls
guest@redacted:~/empty$ ls -l ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
guest@redacted:~/empty$ xauth-fixed list $(hostname -f):0
redacted.localdomain:0 MIT-MAGIC-COOKIE-1 d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth-fixed list $(hostname -f):0
redacted.localdomain:0 MIT-MAGIC-COOKIE-1 d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
- Larry
--- xauth-1.1.1/parsedpy.c 2021-11-28 15:33:47.0 -0800
+++ xauth-1.1.1-lrd/parsedpy.c 2022-03-31 12:20:38.700070442 -0700
@@ -175,14 +175,14 @@
strncpy(path, displayname, sizeof(path) - 1);
path[sizeof(path) - 1] = '\0';
#endif
-if (0 == stat(path, )) {
+if (0 == stat(path, ) && S_ISSOCK(sbuf.st_mode)) {
family = FamilyLocal;
} else {
char *dot = strrchr(path, '.');
if (dot) {
*dot = '\0';
/* screen = atoi(dot + 1); */
-if (0 == stat(path, )) {
+if (0 == stat(path, ) && S_ISSOCK(sbuf.st_mode)) {
family = FamilyLocal;
}
}
Bug#928415: Possibly helpful follow-up
Alexis Murzeau wrote: > See here: https://news.ycombinator.com/item?id=19826903 Which instructs people to install https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi For me at least, that download resulted in a file with sha256sum b25031ac78020aad3be1fb8144cacbcf4a9b2d866585f066a577c10b835cd800 hotfix-update-xpi-intermedi...@mozilla.com-1.0.2-signed.xpi and installing it (i.e., with firefox hotfix-update-xpi-intermedi...@mozilla.com-1.0.2-signed.xpi ) seems to have the desired effect. I had to use a mouse-click to confirm my wish to install it. - Larry
Bug#744278: upstream 2.11.2 looks ready to use
Friends -
Working in Debian Wheezy, I built scala-2.11.2 from sources without using
un-sourced jars. Source is
https://github.com/scala/scala/archive/v2.11.2.tar.gz
52654124565a1706e9e6d0ad7b0969d319628847 scala-sources-2.11.2.tar.gz
In scala's build.xml I changed the definition of lib-ant.dir from
${lib.dir}/ant to /usr/share/java (to pull in ant.jar from ant-1.8.2-4)
and changed the maven version reflected in maven-ant-tasks.classpath from
2.1.1 to 2.1.3. These changes are similar in purpose and scope to the
patches
0001-Define-system-locations.patch
0002-Use-system-ant-contrib.jar.patch
in Debian's scala-2.9.2
Sometime between scala 2.11.1 and 2.11.2, the local fork of jline was
disabled, and has since been removed from the sources. So I didn't
even do the Build Jline step of the old debian/rules.
Then I removed all the .desired.sha1 files, disconnected myself fully from
the network, and built. 20 minutes later, it told me BUILD SUCCESSFUL.
Not only that, I can run through a bunch of simple scala tutorials using
the resulting build/quick/bin/scala.
I guess my message is that the current scala sources are far more Debian-
friendly than some earlier versions. Of course, it's also possible all those
net-derived jar files (indirectly referenced by .desired.sha1) add some
important functionality that I haven't tested. But ignoring them and
building a base system is probably usable, and such a Debian package
could be uploaded without a lot of work. I'd want Mehdi or some other
scala-experienced person to verify this.
- Larry
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744278: where's the source?
Friends -
I tried to figure out where the sources are for the .jar files
required for scala-2.11.2. I'll append my stupid shell script,
and its output. Some, but not all, of those sources show up in
http://www.java.net/download/openjdk/jdk7u40/promoted/b43/openjdk-7u40-fcs-src-b43-26_aug_2013.zip
f3070ee95d40b1fc9fc6d7d79c7c246f184c7a3e
openjdk-7u40-fcs-src-b43-26_aug_2013.zip
If you can't tell, I'm not really much of a Java person.
But I do want to run chisel, which is written in scala.
I hope this helps, even if only a little.
- Larry
---
# Based on hints in
# http://newspaint.wordpress.com/2013/08/22/looking-inside-a-java-jar-file/
# and in the thread
# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744278
# Run this in scala-2.11.2 (unpacked from
# https://github.com/scala/scala/archive/v2.11.1.tar.gz
# 52654124565a1706e9e6d0ad7b0969d319628847 scala-sources-2.11.2.tar.gz
# ) after it's built (a step that has to be done online, so it can
# download .jar files)
# The following files are already part of Debian:
DEBIAN_ant_contrib=ant-contrib
DEBIAN_ant=ant
DEBIAN_maven_ant_tasks_2=libmaven-ant-tasks-java (2.1.3)
DEBIAN_jsoup_1=libsoup-java (1.6.1)
DEBIAN_annotations=proguard
find -name *desired.sha1 | sed -e 's/.desired.sha1$//' | while read f; do
if test -r $f; then
ls -l $f | awk '{print $5,$6,$7,$8,$9}'
g=`basename $f | sed -e 's/\..*//' -e 's/-/_/g'`
#echo looking for $g
eval dfile=\${DEBIAN_$g}
if test -n $dfile; then
echo file already in Debian package $dfile
else
CLASSES=$(jar tf $f |grep class |sed 's/.class$//')
javap -classpath $f -s $CLASSES | grep ^Compiled from | sort -u
fi
fi
done
---
224277 Jul 21 00:50 ./lib/ant/ant-contrib.jar
file already in Debian as ant-contrib
1506140 Jul 21 00:50 ./lib/ant/ant.jar
file already in Debian as ant
15910 Jul 21 00:50 ./lib/ant/vizant.jar
57795 Jul 21 00:50 ./lib/ant/ant-dotnet-1.0.jar
Compiled from AbstractBuildTask.java
Compiled from CSharp.java
Compiled from DotnetBaseMatchingTask.java
Compiled from DotnetCompile.java
Compiled from DotnetDefine.java
Compiled from DotNetExecTask.java
Compiled from DotnetResource.java
Compiled from Ilasm.java
Compiled from Ildasm.java
Compiled from ImportTypelib.java
Compiled from JSharp.java
Compiled from MSBuildTask.java
Compiled from NAntTask.java
Compiled from NetCommand.java
Compiled from NUnitTask.java
Compiled from VisualBasicCompile.java
Compiled from WixTask.java
Compiled from WsdlToDotnet.java
1314262 Jul 21 00:50 ./lib/ant/maven-ant-tasks-2.1.1.jar
file already in Debian as libmaven-ant-tasks-java (2.1.3)
60850 Jul 21 00:50 ./lib/forkjoin.jar
Compiled from ForkJoinPool.java
Compiled from ForkJoinTask.java
Compiled from ForkJoinWorkerThread.java
Compiled from LinkedTransferQueue.java
Compiled from package-info.java
Compiled from RecursiveAction.java
Compiled from RecursiveTask.java
Compiled from ThreadLocalRandom.java
Compiled from TransferQueue.java
Compiled from Unsafe.java
8886289 Jul 21 00:50 ./tools/push.jar
Compiled from Boot.java
Compiled from Handler.java
Compiled from IProperties.java
Compiled from JarClassLoader.java
Compiled from OneJarFile.java
Compiled from OneJar.java
Compiled from OneJarURLConnection.java
31725 Jul 21 00:50 ./test/files/speclib/instrumented.jar
Compiled from BoxesRunTime.java
Compiled from ScalaRunTime.scala
133835 Jul 21 00:50 ./test/files/lib/jsoup-1.3.1.jar
file already in Debian as libsoup-java (1.6.1)
1136 Jul 21 00:50 ./test/files/lib/genericNest.jar
Compiled from OuterTParams.java
2242 Jul 21 00:50 ./test/files/lib/annotations.jar
file already in Debian as proguard
609 Jul 21 00:50 ./test/files/lib/methvsfield.jar
Compiled from methvsfield.java
1372 Jul 21 00:50 ./test/files/lib/enums.jar
Compiled from OuterEnum.java
2920 Jul 21 00:50 ./test/files/lib/nest.jar
Compiled from nest.java
2065 Jul 21 00:50 ./test/files/lib/macro210.jar
Compiled from Macros.scala
683 Jul 21 00:50 ./test/files/codelib/code.jar
Error: no classes specified
---
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720289: history, analysis, and a recommendation
Dear iceweasel maintainers and lurkers, Here's some history, analysis, and a recommendation. Firefox 10-ESR disabled WebGL/Mesa based on https://bugzilla.mozilla.org/show_bug.cgi?id=777028 in which the rationale comes out clearly: 1. the Firefox team can't control the quality of the Mesa version installed 2. ESR releases are meant for ultra-conservative users who probably are not interested in glitzy frills like WebGL Neither of these assumptions is completely true for a Debian stable release. Also, blacklisting WebGL/Mesa indirectly endorses proprietary drivers; a position that probably doesn't bother Mozilla much, but is at odds with Debian principles. iceweasel_10.0.12esr-1 shipped with patches/fixes/Allow-webGL-with-mesa-assuming-users-will-have-updat.patch which removes the disabling stanza. Its meta-information reads: From: Mike Hommey redacted Date: Fri, 31 Aug 2012 09:01:08 +0200 Subject: Allow webGL with mesa, assuming users will have updated to 8.0.4-2 on wheezy The version in squeeze-backports is not affected by CVE-2012-2864, and the version in squeeze is blacklisted. Firefox 17-ESR disabled WebGL/Mesa based on https://bugzilla.mozilla.org/show_bug.cgi?id=838413 which has much less detail than the Firefox 10 discussion. The starting comment from Benoit Jacob is: In ESR10 Mesa was blacklisted and we've had many occasions to be thankful for that. We should do the same for ESR17. iceweasel_17.0.8esr-1~deb7u1 shipped _without_ any patch changing the WebGL/Mesa blacklisting. If there was any internal discussion leading to that decision, I'm not aware of it. And of course there's no commit message to read. I don't want to second-guess the decision to leave WebGL/Mesa disabled in Wheezy's iceweasel. But if that is in fact the intended behavior, there are two bugs: 1. Not documenting the regression 2. Not providing a bypass I have been taught that software should not set policy, but provide capabilities. (That phrasing is from 2008 by John Kacur, but the idea is much older.) I'm no Firefox source code expert, so I don't really want to write the patch putting in a bypass switch to ignore the blacklist. If I did it, it would probably be based on a magic environment variable. Maybe there's a more GUI way to do it. Whatever. But it should not require a 75+ MB download and 2 hours of CPU time to bypass a blacklist that may or may not have any basis. P.S. Is it expected that the Debian Changelog link from http://packages.debian.org/wheezy/iceweasel tells me Not Found? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720289: more details
Maybe I'm talking to myself. The offending blacklist code is the
stanza on lines 329-332 of widget/xpwidgets/GfxInfoX11.cpp :
if (aFeature == nsIGfxInfo::FEATURE_WEBGL_OPENGL) {
*aStatus = nsIGfxInfo::FEATURE_BLOCKED_DRIVER_VERSION;
aSuggestedDriverVersion.AssignLiteral(Not Mesa);
}
Seems very purposeful. This file is not touched by the Debian patch process,
so that snippet comes directly from iceweasel_17.0.8esr.orig.tar.bz2.
I have not found this stanza anywhere in a Mozilla version control
repository (I know git, but I don't claim to be a GitHub or Mozilla
expert), so I don't know what its historical context is. Wikipedia
tells me FireFox 17 ESR was released on November 20, 2012.
My dpkg-buildpackage -rfakeroot of this package just ended, after
135 minutes of wall-clock time, apparently successfully. So I guess
I could modify or disable this stanza and see how it goes.
Comments, anyone?
- Larry
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720289: more details
I confirmed a few things: 1. Visiting get.webgl.org with iceweasel 17.0.8esr-1~deb7u1 tells me that webgl is not available. 2. Downgrading to iceweasel_10.0.12esr-1_amd64.deb libmozjs10d_10.0.12esr-1_amd64.deb xulrunner-10.0_10.0.12esr-1_amd64.deb from my CD not only shows WebGL Renderer: X.Org -- Gallium 0.4 on AMD ARUBA -- 2.1 Mesa 8.0.5 in about:support, but shows a spinning cube on get.webgl.org. Other WebGL demos work fine too. 3. The CD in question is Debian GNU/Linux 7.1.0 Wheezy - Official amd64 CD Binary-1 20130615-23:06 of course saved to a memory stick, not a real CD. So I would say this is an actual regression, not a possible regression. - Larry [currently downloading iceweasel 17.0.8esr-1~deb7u1 source, but not too optimistic I'll be able to do much with it] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720289: iceweasel: Possible regression in WebGL Renderer: Blocked, looking for Not Mesa
Package: iceweasel
Version: 17.0.8esr-1~deb7u1
Severity: normal
Dear Maintainer,
Upgrading stock wheezy from iceweasel 10.0.12esr-1 (on the CD)
to 17.0.8esr-1~deb7u1 (current security patch as of 2013-08-19)
breaks WebGL renderer detection, at least on my test machine with
Adapter Description: X.Org -- Gallium 0.4 on AMD ARUBA
Vendor ID: X.Org
Device ID: Gallium 0.4 on AMD ARUBA
Driver Version: 2.1 Mesa 8.0.5
I am aware of bugzilla@mozillabug 734297
https://bugzilla.mozilla.org/show_bug.cgi?id=734297
and hope that didn't confuse me.
I checked the WebGL Renderer status (on the about:support page)
immediately before and after the upgrade. The after message is:
Blocked for your graphics driver version. Try updating your graphics driver to
version Not Mesa or newer.
-- Package-specific info:
-- Extensions information
Name: Default theme
Location: /usr/lib/iceweasel/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled
Name: Download YouTube Videos as MP4 user-script
Status: enabled
Name: Greasemonkey
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}
Package: xul-ext-greasemonkey
Status: enabled
-- Plugins information
Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled
-- Addons package information
ii gnome-shell3.4.2-7 amd64graphical shell for the GNOME des
ii iceweasel 17.0.8esr-1~ amd64Web browser based on Firefox
ii xul-ext-grease 0.9.20-1 all extension that enables customizat
-- System Information:
Debian Release: 7.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-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 iceweasel depends on:
ii debianutils 4.3.2
ii fontconfig 2.9.0-7.1
ii libc6 2.13-38
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 libnspr42:4.9.2-1
ii libnspr4-0d 2:4.9.2-1
ii libsqlite3-03.7.13-1+deb7u1
ii libstdc++6 4.7.2-5
ii procps 1:3.3.3-3
ii xulrunner-17.0 17.0.8esr-1~deb7u1
iceweasel recommends no packages.
Versions of packages iceweasel suggests:
ii fonts-stix [otf-stix] 1.1.0-1
ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u1
pn mozplugger none
Versions of packages xulrunner-17.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
ii libcairo2 1.12.2-3
ii libdbus-1-3 1.6.8-1+deb7u1
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 libjpeg8 8d-1
ii libmozjs17d 17.0.8esr-1~deb7u1
ii libnspr4 2:4.9.2-1
ii libnss3 2:3.14.3-1
ii libnss3-1d2:3.14.3-1
ii libpango1.0-0 1.30.0-1
ii libpixman-1-0 0.26.0-4
ii libsqlite3-0 3.7.13-1+deb7u1
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-17.0 suggests:
ii libcanberra0 0.28-6
pn libgnomeui-0 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#696844: patch is valid
I reviewed the pmw-4.24 code, and Thorsten Glaser's patch. His analysis and patch is correct. After the patch, the code is correct even in the presence of ASLR. At least every Debian system, and probably every POSIX system, will unmap page zero to make sure null pointer dereferences are trapped. Since 256 is less than every known page size, these small integers are guaranteed not to be valid pointers of the kind created in tables.c to populate out_mftable_ps[]. So after casting this pointer to unsigned long (guaranteed by the C standard to fit), the test p 256 will work as intended. I can't reproduce the later error reported by Ghostscript. - Larry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512548: fixed in 1.0.1
It would be really stupid to go through another Debian release with this bug unfixed. Upstream's evilwm-1.0.1 is a targeted fix for this bug. - Larry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#442908: also on amd64
I suffer from a less severe case of this bug on amd64. There are only tens, not thousands, of false positives. valgrind version 1:3.4.0-1 Debian sid/squeeze on amd64. Here's a typical false positive: ==28899== Conditional jump or move depends on uninitialised value(s) ==28899==at 0x4015AEE: (within /lib/ld-2.9.so) ==28899==by 0x400731A: (within /lib/ld-2.9.so) ==28899==by 0x40078D5: (within /lib/ld-2.9.so) ==28899==by 0x40017AA: (within /lib/ld-2.9.so) ==28899==by 0x400D435: (within /lib/ld-2.9.so) ==28899==by 0x40016AE: (within /lib/ld-2.9.so) ==28899==by 0x4003BAF: (within /lib/ld-2.9.so) ==28899==by 0x4013F74: (within /lib/ld-2.9.so) ==28899==by 0x4001348: (within /lib/ld-2.9.so) ==28899==by 0x4000A97: (within /lib/ld-2.9.so) ==28899==by 0x1: ??? ==28899==by 0x7FF00084A: ??? ==28899== -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510033: runit and /etc/inittab
block 510033 512821 severity 510033 important thanks Since nobody has put in a rebuttal of my analysis, or offered another suggestion, ... Policy 10.7.4 says The related packages _must_ use the provided program, which I suppose is the justification for the original serious severity level. But that assumes that the program is provided, and it is not in this case. The policy only claims it should, as in The owning package [sysvinit in this case] _should_ also provide a program, hence the wishlist status for #512821. I'd put the severity to normal, except for the postinst also uses plain stdout to communicate with the user, not debconf part of this bug. - Larry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512821: sysvinit: Please provide /etc/inittab modification hooks
Package: sysvinit Version: 2.86.ds1-61 Severity: wishlist /etc/inittab is a historical relic. Useful and standardized, but in some ways it is not a good fit to the rest of Debian. My reading of Debian policy 10.7.1 suggests it qualifies as a configuration file, although not a conffile. At the moment, runit home-brews a way to insert a line of its own into /etc/inittab, classed as a policy violation (bug #510033). Please provide a hook for other Debian packages to insert lines to inittab during install, and revert the change during removal. This request is related to bug #240068, save for the distinction between a conffile and a configuration file. I won't be offended if a maintainer tags this wontfix, but then this bug will act as documentation as to why runit fiddles with other packages configuration files. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages sysvinit depends on: ii initscripts 2.86.ds1-61 Scripts for initializing and shutt ii libc62.7-18 GNU C Library: Shared libraries ii libselinux1 2.0.65-5SELinux shared libraries ii libsepol12.0.30-2Security Enhanced Linux policy lib ii sysv-rc 2.86.ds1-61 System-V-like runlevel change mech ii sysvinit-utils 2.86.ds1-61 System-V-like utilities sysvinit recommends no packages. sysvinit 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#512548: evilwm: hangs instead of shutting down when killed
Package: evilwm Version: 1.0.0-1 Severity: normal The signal handler in 1.0.0 (and earlier) evilwm is theoretically buggy, and some Debian system changes this past year made the consequences real. Stock evilwm now hangs up in response to a kill signal (e.g., control-C or killall evilwm). Since that is the recommended way to exit evilwm, and with the bug present the only way remaining is a kill -9, one could even argue for an important category. I now run a version with a pre-release patch from upstream, that works fine. I'll tag this bug upstream. I can provide Ciaran's patch if needed, but it would be better IMHO for him to make a new release. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages evilwm depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libx11-6 2:1.1.5-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxrandr22:1.2.3-1 X11 RandR extension library evilwm recommends no packages. evilwm 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#511138: xterm: regression - no response to keypad PgUp and PgDn
Thomas - On Thu, Jan 08, 2009 at 10:27:02AM -0500, Thomas Dickey wrote: On Wed, Jan 07, 2009 at 07:30:08PM +0100, Larry Doolittle wrote: Package: xterm Version: 238-2 Severity: normal Upgrading amd64 from xterm_237-1 to xterm_238-2, the keypad PgUp and PgDn keys stopped responding. This is an ordinary PC keyboard. The dedicated PageUp and PageDown keys are still OK. That sounds as if cat -v will not show any response at all. Correct. If it's that type of breakage, it might be possible to see the details in xterm's debug-trace (by configuring xterm with --enable-trace). OK. I added --enable-trace to the debian/rules configure command, and re-ran dpkg-buildpackage -rfakeroot. Finally, I instal the resulting .deb. Now every time I run xterm, I get a Trace-child.out and Trace-parent.out. The first isn't interesting. Here is what looks like the relevant snippet of Trace-parent.out, as I pressed PgUp and PgDn: Handle 7bit-key Input keysym 0xFF9A, 0:'' 7bit KeypadKey ...Input keypad before was 0xFF9A ...Input keypad changed to 0x1FF55 Handle 7bit-key Input keysym 0xFF9B, 0:'' 7bit KeypadKey ...Input keypad before was 0xFF9B ...Input keypad changed to 0x1FF56 Unlike other keystrokes, it never hits a writePtyData. I'll attach a compressed Trace-parent.out, where I simply typed cat -v\n, and then PageUp, PageDown, PgUp, PgDn, PageUp, PageDn, return, ^D, ^D. Maybe there are clues other than the segment above, such as in the setup. - Larry Trace-parent.out.gz Description: Binary data
Bug#511138: xterm: regression - no response to keypad PgUp and PgDn
Package: xterm Version: 238-2 Severity: normal Upgrading amd64 from xterm_237-1 to xterm_238-2, the keypad PgUp and PgDn keys stopped responding. This is an ordinary PC keyboard. The dedicated PageUp and PageDown keys are still OK. (fixed font ASCII table) key keycode xterm_237-1 response dedicated PageUp99 esc[5~ dedicated PageDown 105 esc[6~ keypad PgUp 81 esc[5~ keypad PgDn 89 esc[6~ where the last two break (no output) on xterm_238-2. These keys still work fine (9 and 3 respectively) with the NumLock engaged. Reverting to xterm_237-1 restores proper behavior. The difference is clear and unambiguous, since I can switch installation easily with dpkg, and start one xterm of each flavor in the same X server. The rest of the system is a (nearly) up-to-date sid. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages xterm depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libfontconfig12.6.0-3generic font configuration library ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libncurses5 5.7+20081220-1 shared libraries for terminal hand ii libsm62:1.0.3-2 X11 Session Management library ii libx11-6 2:1.1.5-2 X11 client-side library ii libxaw7 2:1.0.4-2 X11 Athena Widget library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxft2 2.1.12-3 FreeType-based font drawing librar ii libxmu6 2:1.0.4-1 X11 miscellaneous utility library ii libxt61:1.0.5-3 X11 toolkit intrinsics library ii xbitmaps 1.0.1-2Base X bitmaps Versions of packages xterm recommends: ii x11-utils 7.3+2+nmu1 X11 utilities ii xutils1:7.3+18 X Window System utility programs m Versions of packages xterm suggests: pn xfonts-cyrillic 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
Bug#510033: runit and inittab
Sune Vuorela report...@pusling.com reported Runit does cat/sed magic on /etc/inittab on installation and removal. True. it looks like a clear violation of 10.4.7. ITIYM 10.7.4 My analysis: /etc/inittab is not a Debian 10.7.1 conffile, it is rather a configuration file, owned and managed (cough) by sysvinit. The sysvinit postinst does a if [ ! -f /etc/inittab ] then cp -p /usr/share/sysvinit/inittab /etc/inittab fi which satisfies policy 10.7.3. Now we get to 10.7.4, and see if the two or more packages use the same configuration file and it is reasonable for both to be installed at the same time section can apply to sysvinit and runit. Well, runit does not depend on sysvinit, but that shouldn't be a problem, since sysvinit is Essential: yes / Priority: required. Also, when the system is fully runit-ized with runit-run, sysvinit and inittab become irrelevant, so the is capable of operating without it clause applies. If it is desirable for two or more related packages to share a configuration file and for all of the related packages to be able to modify that configuration file -- I assert that is actually what's going on here, although sysvinit never modifies inittab other than providing an initial version -- then (chop) 1. [the owner] will manage the configuration file with maintainer scripts as described in the previous section. Check. The owning package should also provide a program that the other packages may use to modify the configuration file. Sounds like a wishlist bug should be filed against sysvinit. In the absence of that program, the cat/sed magic is properly designed to do what such a program would do. My vote: 1. File above-referenced sysvinit wishlist bug 2. Downgrade and/or tag this bug as lenny-ignore 3. Mark the sysvinit bug as a blocker for this bug Note that the inittab file structure has not been updated since SysV was introduced in 1983. Most other configuration-files-that- are-a-list in Debian have been upgraded to a form that allows easier and more reliable automated maintenance, e.g., /etc/ld.so.conf becomes /etc/ld.so.conf.d/*.conf. But inittab is special, being so old, so standard (e.g., busybox also implements this file), and needed at such an early stage in the boot process. For most programs, the sysvinit script system is an adequate place to slide in. But since one of the points of runit is to replace that ancient infrastructure with something better, it is designed to worm itself down the boot process chain -- when runit-run is installed, bypassing sysvinit completely. I can't see fixing this bug by changing either runit or sysvinit this close to the lenny release. The risk of breakage is too real. I also don't see this bug as having any practical importance. Let me close with a reference to my 2005 essay Unix Daemon Foundations http://recycle.lbl.gov/~ldoolitt/foundations.html Personally, I wish for better runit or other sysvinit-replacement support post-lenny. - Larry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#463425: Patch proposed upstream
On Mon, Nov 17, 2008 at 07:10:34PM -0800, Larry Doolittle wrote: I can confirm that AR5212 doesn't work as-is on Lenny. Never mind. User error. An AR5212 (pci id 168c:0013 (rev 01)) works for me now on linux-image-2.6.26-1-686 version 2.6.26-10. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463425: Patch proposed upstream
An apparently successful patch has been worked out upstream. See http://thread.gmane.org/gmane.linux.kernel.wireless.general/22825/focus=22840 The concluding patch for 2.6.27 was posted From: Elias Oltmanns Subject: Re: [PATCH] ath5k: Fix reset sequence for AR5212 in general and RF5111 in particular Newsgroups: gmane.linux.kernel.wireless.general Date: 2008-10-29 13:25:42 GMT Maybe it also applies to Debian's 2.6.26? I can confirm that AR5212 doesn't work as-is on Lenny. I'm off to try rebuilding a Lenny kernel with this patch. Hmm. Maybe I should try an unstable kernel first. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504538: link-grammar: man page and executable name mismatch
Package: link-grammar Version: 4.3.5-1 Severity: important After a fresh install of link-grammar, I try $ man link-grammar [blah-bah] Looks good. So I try $ link-grammar bash: link-grammar: command not found That's odd. $ dpkg-query -L link-grammar [blah-blah] /usr/bin/link-parser OK, I try $ link-parser linkparser ... and that works just the way the man page says link-grammar should work. Just for fun, I try $ man link-parser [blah-blah] shows the same man page as before. The real man page is /usr/share/man/man1/link-parser.1.gz. The man subsystem has clearly pulled some tricks to try to help out, but the man page contents still refer to the program by the wrong name. In the long-term this is only an annoyance, so you could downgrade to normal if you want. It _is_ extremely confusing at the start. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages link-grammar depends on: ii libc6 2.7-15 GNU C Library: Shared libraries ii liblink-grammar4 4.3.5-1Carnegie Mellon University's link ii link-grammar-dictionaries-en 4.3.5-1Carnegie Mellon University's link link-grammar recommends no packages. link-grammar suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434040: Debian bug #434040 (Conflicting declarations for dev_t)
Josselin - Is there anything that is possible to help fixing this before the release? My reading of header files shows that libc6-dev in etch, lenny, and sid does not suffer from the original problem. The files that include a workaround (ugly, but apparently functional) for possible namespace pollution are /usr/include/sys/kd.h /usr/include/sys/sysctl.h I don't see mention of this problem in the Debian glibc changelog, and I don't know how to pull out older copies to see when this workaround was added. An earlier attempt is part of sarge (libc6-dev version 2.3.2.ds1-22sarge6). The simplest approach to this bug is to close it. Joey mentions apm.h. It turns out this is the _only_ other file (at least on my sid system) in /usr/include that nests to a linux kernel header file. It really should have a workaround like that in glibc. So this bug could be cloned, the copy assigned to apmd, and marked important. I append a patch that is arguably cleaner than the approach used by glibc, and is somewhat tested (I checked that it didn't break the build of battery-stats, osdsh, sleepd, or wmbattery, and it fixes Joey's test case). My patch depends on a feature (__KERNEL_STRICT_NAMES) of linux/types.h that is at least as old as sarge (linux-kernel-headers version 2.5.999-test7-bk-17). This macro is defined in glibc features.h, so it looks like all the preprocessor gyrations in sys/sysctl.h are not needed, because that file includes features.h. - Larry --- apm.h.orig 2003-01-16 13:50:36.0 -0800 +++ apm.h 2008-10-13 13:43:47.0 -0700 @@ -20,6 +20,13 @@ * $Id: apm.h,v 1.7 1999/07/05 22:31:11 apenwarr Exp $ * */ +#ifndef _APM_H +#define _APM_H 1 + +#ifndef __KERNEL_STRICT_NAMES +#define __KERNEL_STRICT_NAMES +#endif + #include linux/apm_bios.h #include sys/types.h @@ -93,3 +100,5 @@ #else #define apm_reject(fd) (-EINVAL) #endif + +#endif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502447: #502447 audacity: crashes on startup
Hi Alexander, I can't reproduce this on my Sid box. My amd64 is not SMP, and the kernel is 2.6.26-8 instead of 2.6.25.4. Could that make a difference? - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501555: same bug on reportbug itself
I can see the same effect on every package (tried 4 before I got bored), including reportbug itself. The screen looks as follows: 36) #475641 [n||] [audacity] audacity: audacity.1.gz is not a gzipped file Re 37) #481424 [n||] [audacity] does not respect locales/$LANG Reported by: W. 38) #483623 [n||] [audacity] audacity: Hangs if pause button pressed before r 39) #491557 [n||] [audacity] audacity: Generates click sound when starting. R 40) #498802 [n||] [audacity] audacity: introduces noise in every audio file R Outstanding bugs -- Normal bugs; More information needed (2 bugs) 41) #253459 [n|M|] [audacity] audacity: the change intonation effect does n 42) #341811 [n|MR|] [audacity] audacity: Clicking Stop after recording make (16-42/66) Is the bug you found listed above [y|N|m|r|q|s|f|?]? Outstanding bugs -- Normal bugs; Will Not Fix (2 bugs) 43) #284576 [n|â and then reportbug does not respond to a return. Control-C works fine. I don't see anything unusual shared by bugs 28476 and 345860 that could trigger the problem, but the number of bugs involved (43 and 37) are both rather large numbers. I can also trigger it with reportbug python2.5: 24) #470645 [i|u|â reportbug boa: 5) #40405 [w|â reportbug libc6: 26) #446503 [i|â My system: linux-image-2.6.26-1-amd64 2.6.26-8 python2.5 2.5.2-11.1 libncursesw55.6+20081004-1 libc6 2.7-15 - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501046: uml-utilities: needlessly strict permissions on uml_net
Package: uml-utilities Version: 20070815-1.1 Severity: wishlist Tags: patch $ ls -l /usr/lib/uml/uml_net -rwsr-x--- 1 root uml-net 23616 2008-04-05 06:46 /usr/lib/uml/uml_net All's well except for the missing r for other. There are no secrets in that file, as far as I can see. If a user wants to see a copy, they can download uml-utilities_20070815-1.1_$ARCH.deb and peek inside. The missing r bit prevents an unprivileged user from running debsums (usefully) on the system -- and on my Debian sid installation at least, that's the only such file. The fix is trivial, but just so I can honestly add the patch flag to this report, here is one: --- debian/postinst.orig2008-10-03 08:17:50.0 -0700 +++ debian/postinst 2008-10-03 08:17:59.0 -0700 @@ -33,7 +33,7 @@ fi if ! dpkg-statoverride --list /usr/lib/uml/uml_net /dev/null; then -dpkg-statoverride --update --add root uml-net 04750 \ +dpkg-statoverride --update --add root uml-net 04754 \ /usr/lib/uml/uml_net fi -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages uml-utilities depends on: ii adduser 3.110 add and remove users and groups ii libc6 2.7-13 GNU C Library: Shared libraries ii libfuse2 2.7.4-1Filesystem in USErspace library ii libncurses5 5.6+20080925-1 shared libraries for terminal hand ii libreadline5 5.2-3 GNU readline and history libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip uml-utilities recommends no packages. Versions of packages uml-utilities suggests: pn user-mode-linux none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#288320: propose closing
I propose we close this bug. The current dash behavior matches that of bash. The corresponding bash bug report (288319) was closed with the changelog entry - Fixed exit status code so that a suspended job returns 128+signal as its exit status (preventing commands after it in `' lists from being executed). That description is consistent with my experiments with both dash and bash. There is one other relevant comment in that bash bug log. Justin Pryzby said This is also documented, kind of, in the manpage. Section: BUGS. If we wanted to send a consistent message to all Debian shell users, we could add to the dash BUGS section something related to the bash text Compound commands and command sequences of the form `a ; b ; c' are not handled gracefully when process suspension is attempted. When a process is stopped, the shell immediately executes the next command in the sequence. It suffices to place the sequence of commands between parentheses to force it into a subshell, which may be stopped as a unit. (which could be improved; it's kinda long, and doesn't mention the return value used in that case) - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491709: patch
Try this patch. I haven't stress-tested it, but it
does at least address the original complaint.
- Larry
--- a/src/exec.c2007-07-13 01:26:43.0 -0700
+++ b/src/exec.c2008-07-23 12:46:04.0 -0700
@@ -752,7 +752,7 @@
struct cmdentry entry;
struct tblentry *cmdp;
const struct alias *ap;
- const char *path = pathval();
+ const char *path = bltinlookup(PATH);
if (verbose) {
outstr(command, out);
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474543: smbclient install size nearly doubled
Hi - Repeating the original (2008-04-28) table: 3.0.28a-1 3.2.0~pre1-1 libtalloc1 0 84 libwbclient0 0 136 libsmbclient 2320 3808 samba-common 694410928 smbclient1252824568 --- total2179239524 and the new (2008-07-21) status (included in my mail to [EMAIL PROTECTED], but not shown by default on the bug status web page): 2:3.0.31-1 2:3.2.0-3 libtalloc1 0 84 libwbclient0 0 136 libsmbclient 2348 3876 samba-common 70366 smbclient1270425628 --- total2208840840 All numbers are for Architecture: amd64. My hope is that there is some systematic cause that can be fixed, and that there is not just general bloat and scope creep in the code between 3.0 and 3.2 branches. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474543: smbclient install size nearly doubled
Steve - On Mon, Jul 21, 2008 at 11:36:03AM -0700, Steve Langasek wrote: On Mon, Jul 21, 2008 at 09:38:43AM -0700, Larry Doolittle wrote: smbclient1270425628 My hope is that there is some systematic cause that can be fixed, and that there is not just general bloat and scope creep in the code between 3.0 and 3.2 branches. I'm afraid that it is probably a question of code bloat. The samba codebase has never had a very rigorous division between client and server code, for instance, so there's probably a fair amount of code duplicated in the executables that isn't actually needed there. I've already ruled out the possibility that a failure to strip the executables was to blame here, which is the only systematic cause I can think of. The bulk of smbclient's installed size comes from five binaries: rpcclient smbcacls smbclient smbcquotas smbget Each one was 1.4 to 2.4 MBytes in smbclient-3.0.31, and are 4.3 to 4.7 MBytes in smbclient-3.2.0. I tried the following quick experiment: 1. Download samba 3.2.0 2. cd source ./configure 3. Delete the stoopid @ in the Makefile rule for bin/smbclient 4. make bin/smbclient strip bin/smbclient 5. ls -l bin/smbclient -rwxr-xr-x 1 ldoolitt ldoolitt 3935560 2008-07-21 16:01 bin/smbclient 6. ar r foo.a [massive cut-and-paste of all the .o files listed in step 4] 7. gcc ... [cut-and paste from step 4, substituting foo.a for the .o files] 8. strip bin/smbclient 9. ls -l bin/smbclient -rwxr-xr-x 1 ldoolitt ldoolitt 3086272 2008-07-21 16:08 bin/smbclient Hmmm. That was an easy megabyte (almost) to trim. But the resulting smbclient binary is still over twice the size of the 3.0.31 version. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484789: invalid date in texlive-latex-base?
I can't verify that Jonathan Cichos answered Junichi Uekawa's question. Here is the debug trace for the case that I hit on my machine. Upgrading texlive-latex-base from 2007-14 to 2007.dfsg.1-1 on sid amd64. $ (echo 'VERSION 2'; echo '' ; ls -1 /var/cache/apt/archives/texlive-latex-base_*.deb | sed 's/^/x x x x /') | /usr/sbin/apt-listbugs apt -d dbg1 Exception `NoMethodError' at /usr/lib/ruby/1.8/rational.rb:78 - undefined method `gcd' for Rational(1, 2):Rational Exception `LoadError' at /usr/lib/ruby/1.8/xml/encoding-ja.rb:12 - no such file to load -- uconv Exception `LoadError' at /usr/lib/ruby/1.8/http-access2.rb:31 - no such file to load -- openssl Exception `ArgumentError' at /usr/lib/ruby/1.8/date.rb:1519 - invalid date $ file dbg1 (stdout from apt-listbugs) attached. - Larry Set XSD::XMLParser::XMLParser as XML processor. Wire dump: = Request ! CONNECT TO bugs.debian.org:80 ! CONNECTION ESTABLISHED POST /cgi-bin/soap.cgi HTTP/1.1 SOAPAction: Content-Type: text/xml; charset=utf-8 User-Agent: SOAP4R/1.5.5 (/114, ruby 1.8.7 (2008-06-20) [x86_64-linux]) Date: Wed Jun 25 10:53:44 -0700 2008 Content-Length: 1059 Host: bugs.debian.org ?xml version=1.0 encoding=utf-8 ? env:Envelope xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; env:Body n1:get_bugs xmlns:n1=Debbugs/SOAP/ env:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; keyvalue n2:arrayType=xsd:anyType[4] xmlns:n2=http://schemas.xmlsoap.org/soap/encoding/; xsi:type=n2:Array item xsi:type=xsd:stringseverity/item item n2:arrayType=xsd:anyType[3] xsi:type=n2:Array item xsi:type=xsd:stringcritical/item item xsi:type=xsd:stringgrave/item item xsi:type=xsd:stringserious/item /item item xsi:type=xsd:stringpackage/item item n2:arrayType=xsd:anyType[1] xsi:type=n2:Array item xsi:type=xsd:stringtexlive-latex-base/item /item /keyvalue /n1:get_bugs /env:Body /env:Envelope = Response HTTP/1.1 200 OK Date: Wed, 25 Jun 2008 17:53:44 GMT Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 SOAPServer: SOAP::Lite/Perl/0.69 Content-Length: 665 Content-Type: text/xml; charset=utf-8 ?xml version=1.0 encoding=UTF-8?soap:Envelope xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; soap:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodyget_bugsResponse xmlns=Debbugs/SOAP/soapenc:Array soapenc:arrayType=xsd:int[4] xsi:type=soapenc:Arrayitem xsi:type=xsd:int363061/itemitem xsi:type=xsd:int483217/itemitem xsi:type=xsd:int356853/itemitem xsi:type=xsd:int483282/item/soapenc:Array/get_bugsResponse/soap:Body/soap:Envelope fetching 363061 483217 356853 483282.. Wire dump: = Request POST /cgi-bin/soap.cgi HTTP/1.1 SOAPAction: Content-Type: text/xml; charset=utf-8 User-Agent: SOAP4R/1.5.5 (/114, ruby 1.8.7 (2008-06-20) [x86_64-linux]) Date: Wed Jun 25 10:53:45 -0700 2008 Content-Length: 741 Host: bugs.debian.org ?xml version=1.0 encoding=utf-8 ? env:Envelope xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; env:Body n1:get_status xmlns:n1=Debbugs/SOAP/ env:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; bugnumber n2:arrayType=xsd:string[4] xmlns:n2=http://schemas.xmlsoap.org/soap/encoding/; xsi:type=n2:Array item xsi:type=xsd:int363061/item item xsi:type=xsd:int483217/item item xsi:type=xsd:int356853/item item xsi:type=xsd:int483282/item /bugnumber /n1:get_status /env:Body /env:Envelope = Response HTTP/1.1 200 OK Date: Wed, 25 Jun 2008 17:53:45 GMT Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 SOAPServer: SOAP::Lite/Perl/0.69 Content-Length: 6863 Content-Type: text/xml; charset=utf-8 ?xml version=1.0 encoding=UTF-8?soap:Envelope xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/; xmlns:apachens=http://xml.apache.org/xml-soap; xmlns:xsd=http://www.w3.org/2001/XMLSchema; soap:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodyget_statusResponse xmlns=Debbugs/SOAP/s-gensym3 xsi:type=apachens:Mapitemkey xsi:type=xsd:int483282/keyvaluesource xsi:type=xsd:stringunknown/sourcefound_versions soapenc:arrayType=xsd:string[1] xsi:type=soapenc:Arrayitem xsi:type=xsd:stringtexlive-base/2007-14/item/found_versionsdone xsi:type=xsd:stringNorbert Preining lt;[EMAIL PROTECTED]gt;/doneblocks xsi:type=xsd:string /date xsi:type=xsd:int1211936402/datefixed
Bug#242866: Closure
On Thu, May 15, 2008 at 02:57:05PM +, maximilian attems wrote: The Debian Kernel Team is guilty of uploading a disjointed kernel. For the record Bastian Blank coded the infrastructure for the stripping and the stripping itself. [chop] In the long run it might be a win for Free Software - history will tell. In the short term this is an annoyance for existing hardware driver support. I want to publicly congratulate the entire Kernel team for their efforts, both on the firmware problem, and all the other issues that come with dealing with such a large code base. The results are real and appreciated. As expected none of the vocal minority, aka Mr. Nerode and Mr. Doolittle, demanding DFSG freeness helped to work out this transition nor to cleanup the created mess. IANADD, and never pretend to be. I help out as much as I can [*], and if you don't like me acting as a messenger in this case, tough noogies. I didn't write the DFSG. The real blame here lies with Linus's historical sloppiness in accepting non-DFSG-free code. I hear he has improved his process this past couple of years. - Larry Doolittle [*] and yes, that includes developing, debugging, and releasing Free Software, not just complaining. Anyone with two minutes and Google can confirm that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479983: asm/page.h: No such file or directory
This is Icarus bug 1890393 https://sourceforge.net/tracker/index.php?func=detailaid=1890393group_id=149850atid=775997 Solution given (by me) on 2008-04-11: It should also work to remove the # include asm/page.h line from vvp/main.cc. That include (and the surrounding if defined(LINUX)/endif) should have been removed in the transition from 0.8.3 to 0.8.4, when the PAGE_SIZE macro was replaced with sysconf() results. This fix is now in the upstream git (v0_8-branch). - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474543: smbclient install size nearly doubled
Package: smbclient Version: 3.2.0~pre2-1 Severity: wishlist On sid amd64, I just upgraded to 3.2.0~pre2-1. I hope most of the jump in size is temporary -- maybe executables weren't stripped? I expect some size increase with every version, but this looks excessive. Installed sizes: 3.0.28a-1 3.2.0~pre1-1 libtalloc1 0 84 libwbclient0 0 136 libsmbclient 2320 3808 samba-common 694410928 smbclient1252824568 --- total2179239524 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages smbclient depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libcomerr21.40.8-2 common error description library ii libkrb53 1.6.dfsg.3~beta1-4 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.7-6.1 OpenLDAP libraries ii libncurses5 5.6+20080308-1 Shared libraries for terminal hand ii libpopt0 1.10-3 lib for parsing cmdline parameters ii libreadline5 5.2-3 GNU readline and history libraries ii libtalloc11.1.0~svn26291-1 hierarchical pool based memory all ii libwbclient0 3.2.0~pre2-1 client library for interfacing wit ii samba-common 3.2.0~pre2-1 Samba common files used by both th smbclient recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470029: dash bug -- or not
Gerrit - I just spent another half hour poking around looking at bug 470029 et al. I start to get the impression that there is no bug in dash. evolution-data-server crashes, traps the crash, calls /usr/lib/libgnomeui-0/gnome_segv2 \evolution-data-server-1.12\ 11 \1.12.1\ in an attempt to get a useful bug report back to the evolution developers. In Gutsy, that program is diverted to debreaper, the python program that is supposed to rummage around in the dead program to create the email. Except that in this case it instead fishes around in the dash that was called with the above -c command line. Dash is still running smoothly as the parent of debreaper, patiently waiting for debreaper to finish. debreaper is too stupid to notice, and reports on dash in the middle of its wait4() call. I looked for evidence of bugs like this attributed to bash, but didn't see them. I can explain that, though, if bash (unlike dash) optimizes the last call into an exec. Then debreaper's parent is evolution-data-server, and the desired stack is traced. An example of the above is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467561 I have some evidence to back this up, but there's also a lot of intuition involved. I thought you'd like to hear it anyway. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470327: problem in fltk-config
The origin of the problem is a change (between fltk1.1-1.1.7 and
fltk1.1-1.1.8~rc1) in the output of fltk-config.
With libfltk1.1{,-dev} version 1.1.7-7 installed, I get
$ fltk-config --use-gl --libs
/usr/lib/libfltk.a /usr/lib/libfltk_gl.a
$
but with revision 1.1.8~rc1-2 I get
$ fltk-config --use-gl --libs
/usr/lib/libfltk.a
/usr/lib/libfltk_gl.a
$
The octplot configure script gets tripped up by the extra linefeed,
so the resulting Makefile has
LIBS = /usr/lib/libfltk.a
/usr/lib/libfltk_gl.a -lfltk_gl -lfltk -lGLU -lGL -lm -lfreetype -lz
instead of
LIBS = /usr/lib/libfltk.a /usr/lib/libfltk_gl.a -lfltk_gl -lfltk -lGLU -lGL
-lm -lfreetype -lz
I humbly suggest reassigning to package fltk1.1, although I could also
make an argument that autoconf should deal with this case. There's not
really anything to fix in octplot, which just does
LIBS=$LIBS `$FLTK_CONFIG $fltkconf_args --use-gl --libs`
in configure.ac.
- Larry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470029: version
For the record, ThomB is running an Ubuntu Gutsy dash .deb that I provided him. It has the same cmdtxt bug fix as Debian 0.5.4-8, and is built with DEB_BUILD_OPTIONS=nostrip, hence the halfway-useful stack trace. For a start, that trace makes it clear that it is not a duplicate of #467065. By analogy, bugs 462414, 462977, 463649, 468376, 468449, 468837, and 469102 are all duplicates of this one, not 467065. 467358 is less clear, since it's architecture (amd64) doesn't match the others, so the stack trace is not provably equivalent. Other than suggesting that users hit by this bug install libc6-dbg, I don't know where to go from here. The obvious dash -c '/usr/lib/libgnomeui-0/gnome_segv2 \evolution-data-server-1.12\ 11 \1.12.1\' only gives me a dash: /usr/lib/libgnomeui-0/gnome_segv2: not found ThomB, could you do a quick ls -l /usr/lib/libgnomeui-0/gnome_segv2 dpkg-query -S /usr/lib/libgnomeui-0/gnome_segv2 ? - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470029: a little more research
There is one Ubuntu filing on this bug: https://bugs.launchpad.net/ubuntu/+bug/185075 There are a couple of hints that Evolution is involved somehow in triggering this bug. Thus the page http://www.gnome.org/projects/evolution/bugs.shtml A Quick Guide to Evolution Bug Hunting may be helpful. It would be really, really nice if we could manage to get a developer to reproduce this bug. The reports so far haven't included enough detail, for me at least. Private email with one bug reporter tells me it shows up unpredictably. Not good. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469732: [Pkg-scicomp-devel] Bug#469732: libglpk0: excessive install dependencies
Falk - On Fri, Mar 07, 2008 at 03:02:41PM +0100, Falk Hueffner wrote: On Thu, Mar 06, 2008 at 10:39:34PM +0100, Rafael Laboissiere wrote: You are absolutely right. I will consider producing two independent library packages, one with MathPROG support and the other without. [chop] Just for the record, I don't think this is a good idea. It makes the package more complicated, users have to waste time with checking out what they need, while 99.99% will not care about 5M of disk space that cost about 0.1 cent. Let's see: a new 500 Gig disk costs about US$100. 5 Meg is 1e-5 of that, or 0.1 cent. Your arithmetic checks. I guess you have never operated an obsolete machine on its last legs, still doing useful work on last-decades technology, with its disks at 99% full, where upgrading disks would also mean upgrading the disk controller, and maybe installing a new kernel to support that controller. Cost of each extra 5 Meg is zero, until the cumulative effect forces an upgrade, which costs both real money and system downtime. A Debian system where sensible package granularity lets people install what they need: priceless. I am an Octave user, and only install libglpk because it is an Octave dependency. I haven't yet done any linear programming within Octave, but it's nice to know that will work if I ever need it. Does adding MathPROG to libglpk benefit me in any way? I honestly don't know, I haven't done the research. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469732: libglpk0: excessive install dependencies
Package: libglpk0 Version: 4.25-1 Severity: wishlist The 4.27-1 update includes: * debian/control: Build-depend on libiodbc2-dev and libmysqlclient15-dev in order to get MathPROG support Apparently this also adds to the install-time dependencies. Upgrading to this version, apt-get tells me: The following extra packages will be installed: libiodbc2 libmysqlclient15off mysql-common [chop] After this operation, 5124kB of additional disk space will be used. Note that the reason I have libglpk0 on my machine is to run Octave (octave3.0 depends on libglpk0 (= 4.25)). Since octave runs fine with libglpk0-4.25, I fail to see why 5 Megabytes of new code is required as of 4.27. I'd like to see Debian dependencies granular enough that stuff like this can be optional. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages libglpk0 depends on: ii libc6 2.7-9 GNU C Library: Shared libraries ii libgmp3c2 2:4.2.2+dfsg-2 Multiprecision arithmetic library libglpk0 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469240: octave3.0: nearly unusable PostScript printing
Package: octave3.0 Version: 1:3.0.0-7 Severity: minor Tags: patch PostScript output for e.g. axis labels uses a tolower() version of the font name, which is broken. Please pull upstream's fix at the next available opportunity. http://velveeta.che.wisc.edu/cgi-bin/hgwebdir.cgi/octave/rev/71209cfdaebe A slightly longer discussion is at https://www.cae.wisc.edu/pipermail/bug-octave/2008-March/005301.html -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages octave3.0 depends on: ii libatlas3gf-base [libl 3.6.0-21.3Automatically Tuned Linear Algebra ii libblas3gf [libblas.so 1.2-1.5 Basic Linear Algebra Subroutines 3 ii libc6 2.7-9 GNU C Library: Shared libraries ii libcurl3-gnutls7.18.0-1 Multi-protocol file transfer libra ii libfftw3-3 3.1.2-3 library for computing Fast Fourier ii libgcc11:4.3.0~rc2-1 GCC support library ii libgfortran3 4.3.0~rc2-1 Runtime library for GNU Fortran ap ii libglpk0 4.25-1linear programming kit with intege ii libhdf5-serial-1.6.5-0 1.6.5-5.2 Hierarchical Data Format 5 (HDF5) ii liblapack3gf [liblapac 3.1.1-0.4 library of linear algebra routines ii libncurses55.6+20080203-1Shared libraries for terminal hand ii libpcre3 7.6-2 Perl 5 Compatible Regular Expressi ii libqhull5 2003.1-8 calculate convex hulls and related ii libreadline5 5.2-3 GNU readline and history libraries ii libstdc++6 4.3.0~rc2-1 The GNU Standard C++ Library v3 ii libsuitesparse-3.1.0 3.1.0-3 collection of libraries for comput ii texinfo4.11.dfsg.1-4 Documentation system for on-line i ii zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime Versions of packages octave3.0 recommends: ii gnuplot 4.2.2-1A command-line driven interactive ii libatlas3gf-base 3.6.0-21.3 Automatically Tuned Linear Algebra -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468642: transition from /var/service to /etc/service
The runit-1.8.0-3 changelog includes
* debian/runit.preinst, debian/runit.postinst: move away from /var/service/
to /etc/service/; restart runsvdir; retain backward compatibility symlink
/var/service - /etc/service until rdepends have adopted (#461478).
which presumably triggers the effect I saw.
I was able to complete the upgrade by performing it from a console
that is not managed by runit.
Whatever strategy is adopted for making this transition needs to
deal more gracefully with the possibility that apt/dpkg are run
from a process that will be terminated by a blanket runsvdir restart.
In my case I use getty's managed from runit, and X via startx from
there. Other usage patterns will be different -- how about a console
started from sshd managed by runit, or {g,w,x}dm started from runit?
- Larry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468642: runit: fails to install/upgrade
Package: runit Version: 1.8.0-4 Severity: critical Justification: breaks unrelated software Upgrading from runit 1.8.0-2 to 1.8.0-4 fails. It seems to restart user processes, including the one that is doing the upgrade. The first time it kicked me out of X. It leaves dpkg/apt in an unusable and unrecoverable state. Symptom: # apt-get upgrade E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. # dpkg --configure -a Setting up runit (1.8.0-4) ... Debian GNU/Linux lenny/sid recycle tty5 recycle login: First, I would respectfully request advice on how to recover apt/dpkg state. Do you think downgrading to 1.8.0-2 will work? Hmm, I left a non-runit-managed console around, maybe I can try dpkg --configure -a from there. Second, if there are any experiments I can do to isolate the problem, let me know. Nothing showed up in dmesg from the process shown above. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash runit depends on no packages. Versions of packages runit recommends: pn fgettynone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467065: dash bug with if in a pipe: patch included
(Herbert: for context, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467065 )
This is a real bug in upstream dash, which has existed since at
least dash-0.5.1 (July 2004). It is a latent bug in cmdtxt()
(which I think applies only to pipes) as it handles if commands.
The attached patch fixes it for me.
It's possible this patch will fix one or more of #462414,
#462977, and #463649. I'll send messages there to see if
the submitters can test.
- Larry
diff -ur dash-0.5.4/src/jobs.c dash-0.5.4-fixed/src/jobs.c
--- dash-0.5.4/src/jobs.c 2007-07-13 01:26:43.0 -0700
+++ dash-0.5.4-fixed/src/jobs.c 2008-02-24 11:24:44.0 -0800
@@ -1235,11 +1235,12 @@
cmdputs(if );
cmdtxt(n-nif.test);
cmdputs(; then );
- n = n-nif.ifpart;
if (n-nif.elsepart) {
- cmdtxt(n);
+ cmdtxt(n-nif.ifpart);
cmdputs(; else );
n = n-nif.elsepart;
+ } else {
+ n = n-nif.ifpart;
}
p = ; fi;
goto dotail;
Bug#463649: can you test a patch?
Dear submitters - I just posted a patch for dash in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467065 Is it possible for you to test and find out if it addresses your dash problems? Please report back. If it does not solve your problem, you probably need to provide more in-depth information as to what triggers the fault. If you need help on that step, you are welcome to contact me privately. I can guess from the version involved that you see this in Ubuntu Gutsy, which I have available to me. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467065: dash segfault with nested if/for in pipe
Package: dash
Version: 0.5.4-7
Severity: important
Steps to reproduce segfault, within dash:
mkdir -p dash-test
touch dash-test/a.xpm
if test -d dash-test; then echo dash-test; for pixmap in dash-test/*.xpm;
do echo ${pixmap}; done; fi | less
The first two lines can be given in any shell, they're only for setup.
The crash only seems to affect interactive operation, other things I
tried like dash -c blah blah and dash EOT
blah blah
EOT
didn't produce the crash. My bug title is a somewhat wild guess as to
what actually triggers the crash.
I found this bug investigating 459181, it may or may not be related.
Backtraces from the above line, and a minor variant that segfaults in
a different place.
=== CRASH VARIANT 1
if test -d dash-test; then echo dash-test; for pixmap in dash-test/*.xpm;
do echo ${pixmap}; done; fi | less
Program received signal SIGSEGV, Segmentation fault.
cmdtxt (n=0x6966)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/jobs.c:1196
1196switch (n-type) {
(gdb) bt
#0 cmdtxt (n=0x6966)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/jobs.c:1196
#1 0x004089f5 in cmdtxt (n=0x6966)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/jobs.c:1264
#2 0x00408d28 in forkshell (jp=0x61b760, n=0x619d10,
mode=value optimized out)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/jobs.c:1178
#3 0x00403cb6 in evalpipe (n=0x61b5c0, flags=0)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/eval.c:540
#4 0x00403978 in evaltree (n=0x61b5c0, flags=0)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/eval.c:289
#5 0x00409da5 in cmdloop (top=1)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/main.c:237
#6 0x00409ff9 in main (argc=1, argv=0x7fff272a89c8)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/main.c:178
=== CRASH VARIANT 2
if test -d dash-test; then for pixmap in dash-test/*.xpm; do echo
${pixmap}; done; fi | less
Program received signal SIGSEGV, Segmentation fault.
cmdtxt (n=0x619de0)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/jobs.c:1204
1204cmdtxt(lp-n);
(gdb) bt
#0 cmdtxt (n=0x619de0)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/jobs.c:1204
#1 0x004089f5 in cmdtxt (n=0x619de0)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/jobs.c:1264
#2 0x00408d28 in forkshell (jp=0x61b760, n=0x619d10,
mode=value optimized out)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/jobs.c:1178
#3 0x00403cb6 in evalpipe (n=0x619ed8, flags=0)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/eval.c:540
#4 0x00403978 in evaltree (n=0x619ed8, flags=0)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/eval.c:289
#5 0x00409da5 in cmdloop (top=1)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/main.c:237
#6 0x00409ff9 in main (argc=1, argv=0x7aa861a8)
at /home/ldoolitt/deb-src/dash-0.5.4/build-tmp/../src/main.c:178
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages dash depends on:
ii libc6 2.7-8 GNU C Library: Shared libraries
dash recommends no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467065: more info
I spent way too much time in front of gdb. More info: The bug does not reproduce on i386/gcc-4.1 (Gutsy). The bug does reproduce with stock dash-0.5.4 on amd64/gcc-4.2 (Sid). It is not affected, and is much easier to follow within gdb, by compiling -O0. The bug is not affected by building/running under efence. Something corrupts the variable n in jobs.c:commandtext(), in between getting passed in and being used as the parameter to cmdtxt(). It's possible to turn on -DDEBUG in building dash, but you first have to disable the ps-cmd argument to TRACE() in jobs.c:commandtext(). The traces are interesting, but have not helped my investigation of this bug. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467065: more info
On Fri, Feb 22, 2008 at 02:34:09PM -0800, Larry Doolittle wrote: The bug does not reproduce on i386/gcc-4.1 (Gutsy). The second example does. I have simplified the example some more. No setup required. To an interactive dash, cut-and-paste: if true; then for x in foo; do echo bar; done; fi | cat Reproduces with all of upstream dash-0.5.4 on i386/gcc-4.1 (Gutsy) upstream dash-0.5.4 on amd64/gcc-4.2 (Sid) binary 0.5.4-1ubuntu3 on i386/gcc-4.1 (Gutsy) binary dash-0.5.4-7 on amd64/gcc-4.2 (Sid) Something corrupts the variable n in jobs.c:commandtext(), in between getting passed in and being used as the parameter to cmdtxt(). Scratch that. There are a bunch of calls to cmdtxt(), one per node as it traverses the parsed command structure. When it finishes the if statement and everything inside, it gets to a corrupted node (or maybe corrupted node pointer). - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466793: flex: new lint in YY_INPUT definition
Package: flex
Version: 2.5.34-3
Severity: normal
I started getting new warnings from the C compile phase of
lexers as of 2.5.34, which I verified showed up in the transition
from 2.5.33-12 to 2.5.34-1. The warnings are:
warning: comparison between signed and unsigned integer expressions
I tracked it down to a change in the definition of the YY_INPUT macro.
Any gcc-4.2 or gcc-4.3 compiler will detect the problem. To reproduce,
start with a very simple example.lex:
%option nounput
%{
extern int keyword(const char *str, unsigned len);
%}
%%
[a-zA-Z_][a-zA-Z0-9$_]* { return keyword(yytext, yyleng); }
%%
Then build:
flex -o example.cc example.lex
gcc -Wall example.cc -c
The warning that pops out when using lex-2.5.34 is
example.cc: In function 'int yy_get_next_buffer()':
example.cc:934: warning: comparison between signed and unsigned integer
expressions
It's easy to see the fault in example.cc. In both flex versions,
YY_INPUT is used as
YY_INPUT( (YY_CURRENT_BUFFER_LVALUE-yy_ch_buf[number_to_move])
(yy_n_chars), (size_t) num_to_read );
Note that the third argument is of type (size_t). The old, lint-free
definition of YY_INPUT starts
#define YY_INPUT(buf,result,max_size) \
if ( YY_CURRENT_BUFFER_LVALUE-yy_is_interactive ) \
{ \
int c = '*'; \
size_t n; \
for ( n = 0; n max_size \
(c = getc( yyin )) != EOF c != '\n'; ++n ) \
buf[n] = (char) c; \
but the new definition changes the declaration of n to
int n;
which not only generates a warning for the comparison n max_size,
it's a real mistake.
It took me some effort to isolate and analyze to this point.
I started trying to find the origin of the problem in the
flex code base, but quickly found myself in over my head.
I hope you can take it from here.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages flex depends on:
ii debconf [debconf-2.0] 1.5.19 Debian configuration management sy
ii libc6 2.7-8 GNU C Library: Shared libraries
ii m41.4.10-1 a macro processing language
Versions of packages flex recommends:
ii gcc [c-compiler] 4:4.2.2-2 The GNU C compiler
ii gcc-4.0 [c-compiler] 4.0.3-7The GNU C compiler
ii gcc-4.2 [c-compiler] 4.2.3-1The GNU C compiler
ii gcc-4.3 [c-compiler] 4.3-20080202-1 The GNU C compiler
-- debconf information excluded
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459156: patch
The problem is in a different treatment of echo \n.
Under bash it comes out \n, under dash it comes out
.
This patch quickly bypasses the problem. Trust it as
far as you can throw it.
- Larry
--- kbd-1.12/configure 2004-01-03 06:53:39.0 -0800
+++ kbd-1.12-hack/configure 2008-01-23 16:27:43.0 -0800
@@ -151,14 +151,14 @@
#
# 2. For lib/nls.h: do we have libintl.h and gettext() ?
#
-echo '
+cat conftest.c EOT
#include libintl.h
main(int a, char **v){
if (a == -1) /* false */
gettext(There is no gettext man page\n);
exit(0);
}
-' conftest.c
+EOT
eval $compile
if [ $nls = 1 ]; then
if test -s conftest ./conftest 2/dev/null; then
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455909: tracking down misaligned memory accesses
Martin - After running for a mere 20 hours, /proc/cpu/alignment reports millions of misaligned word accesses from the kernel: System: 2765980 After checking 2.6.23 from unstable as maks suggested, please report back more detail on the hardware you have in service. I have seen an ARM system act like this with epro100 network drivers. It would be helpful if you could run some quick experiments to isolate the source of the alignment faults to a subsytem (e.g., USB, network, disk). - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454174: xmds: please rebuild against libfftw3-3
Package: xmds Version: 1.6.3-1 Severity: important please rebuild against libfftw3-3 Justification for using important instead of wishlist: other software in this category, e.g. octave, is built against libfftw3-3, which replaces fftw3. Thus it's not currently possible in sid to install both xmds and the latest octave. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages xmds depends on: ii fftw-dev 2.1.3-20+b1 library for computing Fast Fourier ii fftw3-dev3.1.2-2 library for computing Fast Fourier ii libc62.7-3 GNU C Library: Shared libraries ii libgcc1 1:4.2.2-4 GCC support library ii libmpich1.0-dev 1.2.7-4 mpich static libraries and develop ii libstdc++6 4.2.2-4 The GNU Standard C++ Library v3 xmds recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439363: how come youtub-dl is in stable?
To me, youtube-dl is the epitome of a package that belongs in volatile. Putting it in stable invites bugs like this. I have no idea if it can be switched to etch-volatile at this time. Personally, I run a copy built from upstream source. Its build requirements and resource needs are trivial. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383403: linux-2.6: includes nondistributable and non-free binary firmware
Package: linux-2.6 Severity: serious Justification: Policy 2.1 The following 59 files, found in Debian's linux-2.6_2.6.17.orig.tar.gz, apparently contain software in binary form, for which Debian has no corresponding source code. Debian policy states that The program must include source code, and must allow distribution in source code as well as compiled form. Therefore Debian must not distribute these files. drivers/atm/atmsar11.data drivers/atm/pca200e.data drivers/atm/pca200e_ecd.data drivers/atm/sba200e_ecd.data drivers/char/drm/mga_ucode.h drivers/char/drm/r128_cce.c drivers/char/drm/radeon_cp.c drivers/char/dsp56k.c drivers/char/ip2/fip_firm.h drivers/media/dvb/ttpci/av7110_hw.c drivers/media/dvb/ttusb-budget/dvb-ttusb-dspbootcode.h drivers/media/video/usbvideo/vicam.c drivers/net/appletalk/cops_ffdrv.h drivers/net/appletalk/cops_ltdrv.h drivers/net/bnx2_fw.h drivers/net/cassini.h drivers/net/e100.c drivers/net/hamradio/yam1200.h drivers/net/hamradio/yam9600.h drivers/net/myri_code.h drivers/net/pcmcia/ositech.h drivers/net/starfire_firmware.h drivers/net/tg3.c drivers/net/tokenring/3c359_microcode.h drivers/net/typhoon-firmware.h drivers/scsi/advansys.c drivers/scsi/ql1040_fw.h drivers/scsi/ql12160_fw.h drivers/scsi/ql1280_fw.h drivers/scsi/qla2xxx/ql2100_fw.c drivers/scsi/qla2xxx/ql2200_fw.c drivers/scsi/qla2xxx/ql2300_fw.c drivers/scsi/qla2xxx/ql2322_fw.c drivers/scsi/qla2xxx/ql2400_fw.c drivers/scsi/qlogicpti_asm.c drivers/usb/misc/emi26_fw.h drivers/usb/net/kawethfw.h drivers/usb/serial/io_fw_boot2.h drivers/usb/serial/io_fw_boot.h drivers/usb/serial/io_fw_down2.h drivers/usb/serial/io_fw_down3.h drivers/usb/serial/io_fw_down.h drivers/usb/serial/ti_fw_3410.h drivers/usb/serial/ti_fw_5052.h drivers/usb/serial/whiteheat_fw.h sound/isa/sb/sb16/sb16_csp_codecs.h sound/isa/wavefront/wavefront_fx.c sound/oss/maestro3.h sound/oss/ymfpci_image.h sound/oss/yss225.c sound/pci/cs46xx/cs46xx_image.h sound/pci/cs46xx/imgs/cwc4630.h sound/pci/cs46xx/imgs/cwcasync.h sound/pci/cs46xx/imgs/cwcdma.h sound/pci/cs46xx/imgs/cwcemb80.h sound/pci/cs46xx/imgs/cwcsnoop.h sound/pci/korg1212/korg1212-firmware.h sound/pci/maestro3.c sound/pci/ymfpci/ymfpci_image.h This list is probably not perfect. Corrections are welcome. Additional information is posted at http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html -- System Information: deleted (irrelevant) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375925: cpio: pre-installation script crashes
Package: cpio Version: 2.6-14 Severity: grave Justification: renders package unusable cpio_2.6-14 fails to install with apt-get upgrade. Preparing to replace cpio 2.6-13 (using .../archives/cpio_2.6-14_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/cpio_2.6-14_amd64.deb (--unpack): subprocess pre-installation script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/cpio_2.6-14_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) .. and the system is left with the previous (2.6-13) cpio installed and functional. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages cpio depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries cpio recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373952: python2.3: reproduces on amd64
Package: python2.3 Version: 2.3.5-14 Followup-For: Bug #373952 I get an identical error message when attempting to update python2.3 on my amd64 sid machine. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages python2.3 depends on: ii libbz2-1.01.0.3-2high-quality block-sorting file co ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libdb4.3 4.3.29-5 Berkeley v4.3 Database Libraries [ ii libncurses5 5.5-2 Shared libraries for terminal hand ii libreadline5 5.1-7 GNU readline and history libraries ii libssl0.9.8 0.9.8b-2 SSL shared libraries ii python-central0.4.16 register and build utility for Pyt ii zlib1g1:1.2.3-11 compression library - runtime Versions of packages python2.3 recommends: pn python2.3-cjkcodecs | python2 none (no description available) pn python2.3-cjkcodecs | python2 none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366790: libselinux1: 1.30-1_amd64 endlessly wants to be upgraded
Package: libselinux1 Version: 1.30-1 Severity: normal # apt-get install libselinux1 appears to succeed, messages are: Preparing to replace libselinux1 1.30-1 (using .../libselinux1_1.30-1_amd64.deb) ... Unpacking replacement libselinux1 ... Setting up libselinux1 (1.30-1) ... # But after such installation, libselinux1 appears to apt-get to still need upgrading! It is perpetually on my upgrade list. Maybe this is really a bug in apt-get, triggered by the unusual version (1.30-1_amd64). I have apt-get version 0.6.44 installed on this vanilla sid system. apt is pointed to http://ftp.us.debian.org/debian/ unstable main. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-amd64-generic Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libselinux1 depends on: ii libc6 2.3.6-7GNU C Library: Shared libraries ii libsepol1 1.12-1 Security Enhanced Linux policy lib libselinux1 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341786: fakeroot: includes 32-bit compatibility libraries in pure 64-bit amd64 installation
Package: fakeroot Version: 1.5.5 Severity: normal Out of the 905 packages on my pure 64-bit amd64 debian sid machine, only this one and the recent libg2c0-dev put any files in /emul/ia32-linux/ . For general cleanliness and possible improved security, I don't want any 32-bit compatibility libraries on this machine. Hence the pure in my machine description. I'm not opposed to having 32-bit libraries built for 64-bit machines, but they should be somehow separated and optional (even suggested), since many people _do_ want to run 32-bit code on their 64-bit processors. I happen to not be one one of them. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-amd64-k8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages fakeroot depends on: ii libc6 2.3.5-8.1 GNU C Library: Shared libraries an fakeroot recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341788: libg2c0-dev: includes 32-bit compatibility libraries in pure 64-bit amd64 installation
Package: libg2c0-dev Version: 1:3.4.5-1 Severity: normal Out of the 905 packages on my pure 64-bit amd64 debian sid machine, only this one and fakeroot put any files in /emul/ia32-linux/ . For general cleanliness and possible improved security, I don't want any 32-bit compatibility libraries on this machine. Hence the pure in my machine description. I'm not opposed to having 32-bit libraries built for 64-bit machines, but they should be somehow separated and optional (even suggested), since many people _do_ want to run 32-bit code on their 64-bit processors. I happen to not be one one of them. This bug is effectively a followup to #341147, indicatating that I'm not happy with the solution they found. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-amd64-k8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages libg2c0-dev depends on: ii gcc-3.4-base 3.4.5-1The GNU Compiler Collection (base ii libg2c0 1:3.4.5-1 Runtime library for GNU Fortran 77 libg2c0-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323956: doesn't reproduce on my debian box
I summarized my research with: [T]his might not apply to debian at all. Michelle Konzack chimed in with: It does not affect Debian, but Mandrake and Redhat... :-) Florian Weimer asked: Can you rule out that it's not reproducible with some other charset? I can't rule anything out. If I understand the bug reports and examples correctly, the charset in question is the one specified in the e-mail header, and is therefore part of the example mbox files. The only technical discussion I can find on-line is on the mutt mailing list: http://comments.gmane.org/gmane.mail.mutt.devel/8379 and that faded away without resolution a month ago. There is no (current relevant) activity regarding handler.c in the mutt CVS tree. Tamotsu's patch has been ignored. So this still looks to me like a non-bug for Debian. If the mutt developers don't understand and can't reproduce it, I'm reluctant to spend much effort on the Debian side. If Michelle has personally confirmed it affects Mandrake and Redhat, maybe (s)he can use one of those systems to try the test program posted by Thomas Roessler at http://permalink.gmane.org/gmane.mail.mutt.devel/8383 For the record, my debian sid system gives the result rv = 0, errno = 0 (?) 'AAA*' - Larry signature.asc Description: Digital signature
Bug#326561: usbdevice_fs.h [patch]
Guys -
I get similar problems building USRP (not yet a Debian package).
I can fix things up by deleting the line
#include linux/compat.h
from /usr/include/linux/usbdevice_fs.h.
This change is not obviously broken, as it is one of only two *.h
files in there that includes compat.h. The other one is kexec.h,
which looks to me like a unique special case.
After making that change, I can confirm that fxload and openct
build on amd64 again.
I have no idea what form is desired for patch submissions, but
I'll try with an attachment. This patch makes the deletion I
described above, and adds a regression test for usbdevice_fs.h
to the testsuite directory.
I hope this helps.
- Larry
diff -urN ../linux-kernel-headers-2.6.13+0rc3/include/linux/usbdevice_fs.h
./include/linux/usbdevice_fs.h
--- ../linux-kernel-headers-2.6.13+0rc3/include/linux/usbdevice_fs.h
2005-07-12 21:46:46.0 -0700
+++ ./include/linux/usbdevice_fs.h 2005-09-13 10:36:55.0 -0700
@@ -32,7 +32,6 @@
#define _LINUX_USBDEVICE_FS_H
#include linux/types.h
-#include linux/compat.h
/* - */
diff -urN ../linux-kernel-headers-2.6.13+0rc3/testsuite/Makefile
./testsuite/Makefile
--- ../linux-kernel-headers-2.6.13+0rc3/testsuite/Makefile 2005-09-13
10:48:26.0 -0700
+++ ./testsuite/Makefile2005-09-13 10:33:16.0 -0700
@@ -2,7 +2,7 @@
TESTS_295 = $(patsubst %,295-%,$(TESTS))
# Filter out tests which no one tries to use -ansi; not worth fixing.
-NON_ANSI = videodev.o videodev-time.o cdrom.o
+NON_ANSI = videodev.o videodev-time.o cdrom.o usbdevice_fs.o
TESTS_ANSI = $(patsubst %,ansi-%,$(filter-out $(NON_ANSI),$(TESTS)))
# Similarly for C++.
diff -urN ../linux-kernel-headers-2.6.13+0rc3/testsuite/usbdevice_fs.c
./testsuite/usbdevice_fs.c
--- ../linux-kernel-headers-2.6.13+0rc3/testsuite/usbdevice_fs.c
1969-12-31 16:00:00.0 -0800
+++ ./testsuite/usbdevice_fs.c 2005-09-13 10:25:19.0 -0700
@@ -0,0 +1,6 @@
+#include linux/usbdevice_fs.h
+
+int main()
+{
+ return 0;
+}
signature.asc
Description: Digital signature
Bug#323956: doesn't reproduce on my debian box
I read the full-disclosure post, and its reply. http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2005-08/0600.html Two example mailboxes are given (one in each post), and it is suggested that the problem is triggered by a library runtime version mismatch. I tried both examples on debian sid x86_64, mutt 1.5.10-1 debian sarge x86, mutt 1.5.9-2 All four combinations (two mailboxes, two debian systems) ran normally, no crashes or any other unusual behavior. So this might not apply to debian at all. - Larry signature.asc Description: Digital signature
Bug#318460: htmldoc depends on obsolete libfltk1.1c102
Package: htmldoc Severity: grave Justification: renders package unusable # apt-get install libfltk1.1c102 Reading package lists... Done Building dependency tree... Done Package libfltk1.1c102 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package libfltk1.1c102 has no installation candidate Quoting Aaron M. Ucko in Bug 318173: I've already addressed this in fltk1.1 1.1.6-6, which replaces libfltk1.1c102 with a new libfltk1.1 package built against libglu1c2 (and with G++ 4 as well). Any FLTK-based applications you use will now need to be recompiled as part of the ongoing C++ transition. I also notice a circular dependency between fltk1.1 and htmldoc, which makes it harder to work around the problem by building from source. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-9-amd64-k8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317708: amd64-specific bug in XPDF based programs?
Hamish - On Mon, Jul 11, 2005 at 02:40:45PM +1000, Hamish Moffatt wrote: Derek (upstream) says There was a change in the way FT handles CID font encodings in 2.1.8. I'm just about to release Xpdf 3.01 which will have code to handle that correctly. OK, I believe it. Someone with more debian experience than me will have to come up with a way to encode this in the dependencies of freetype and xpdf. Can freetype-2.1.10 be revised to conflict with xpdf 3.01 ? Sometimes xpdf bugs go away just by recompiling xpdf with new freetype versions. Have you tried recompiling xpdf with freetype 2.1.10? Yes. It doesn't help. When Derek releases 3.01 and you package it for Debian, don't forget to fix #316836 (patch given). - Larry signature.asc Description: Digital signature
Bug#94041: Freetype (either version) not 64-bit clean
While freetype version 2.1.10 (as used in Debian sid) still has the source code constructs described in this bug report, the result does seem to work fine on a 64-bit arch (amd64). * It builds without any of the characteristic 64-bit unclean warnings. * I can run ttfbanner -p 8 $f test without crashing for every .ttf file on my system (which does not include ARIAL.TTF). * Fitting 32-bits into an unsigned long is a satisfactory and standards-compliant way to program. It may be wasteful on a 64-bit machine, but it does not (necessarily) get the wrong answer. * The version with claimed 64-bit bugs is five years old. Any real 64-bit bugs that once existed probably got fixed upstream years ago. Unless someone (Chris?) comes up with a live, reproducible 64-bit bug in this package, I suggest this bug get closed. - Larry signature.asc Description: Digital signature
Bug#317708: amd64-specific bug in XPDF based programs?
I wrote - So it's either a deeper library version problem, or xpdf on amd64 itself. Combining Hamish's results with mine points to a deeper library version problem. Something to do with font encoding. Broken stack on amd64 sid: xpdf 3.00-13 libt1-5 5.0.2-3 libfreetype6 2.1.10-1 zlib1g 1:1.2.2-6 Working stack on i386 sarge: xpdf 3.00-13 libt1-5 5.0.2-3 libfreetype6 2.1.7-2.4 zlib1g 1:1.2.2-4.sarge.1 Where I hope I hit all the relevant packages. Hamish, can you add your version info to the above? I'll try to figure out the recipe to downgrade libfreetype6 on sid and retest. - Larry signature.asc Description: Digital signature
Bug#317708: amd64-specific bug in XPDF based programs?
I wrote - Broken stack on amd64 sid: xpdf 3.00-13 libt1-5 5.0.2-3 libfreetype6 2.1.10-1 zlib1g 1:1.2.2-6 Working stack on i386 sarge: xpdf 3.00-13 libt1-5 5.0.2-3 libfreetype6 2.1.7-2.4 zlib1g 1:1.2.2-4.sarge.1 I'll try to figure out the recipe to downgrade libfreetype6 on sid and retest. Whoo, hoo! That was the definitive test. Replacing libfreetype6 with 2.1.7-2.4 on debian sid makes the problem disappear. Time to reassign the bug to libfreetype6. The Debian changelog isn't any help, I guess it's time for a binary search through all the changes to find the origin of this behavior. - Larry signature.asc Description: Digital signature
Bug#317708: amd64-specific bug in XPDF based programs?
I wrote -
Replacing libfreetype6 with 2.1.7-2.4 on debian sid
makes the problem disappear.
Working on debian sid amd64,
I just downloaded freetype-2.1.{7,8,9,10}.tar.bz2 from
http://sourceforge.net/project/showfiles.php?group_id=3157
I gave each of them a ./configure make, which ran
smoothly (even with gcc-4.0!). I then ran a copy of xpdf
pointed at the resulting .so file, e.g.,
LD_LIBRARY_PATH=~/src/freetype-2.1.10/objs/.libs xpdf
SportyAdventur-eng-rgb.pdf
The garbled fonts showed up when using any version except 2.1.7.
There were a _lot_ of changes from versions 2.1.7 (2003-11-07)
to 2.1.8 (2004-04-21). I read the ChangeLog, but nothing jumped
out at me. Can a freetype developer jump in and help isolate the
problem?
- Larry
P.S. to [EMAIL PROTECTED]: see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=317708
Our test file is
http://www.dnt.de/dl/58/SportyAdventur-eng-rgb.pdf
signature.asc
Description: Digital signature
Bug#308783: RdFToI.c
On Mon, May 23, 2005 at 11:20:52AM -0700, Larry Doolittle wrote: [chop] I noticed you changed the semantics of compressed file detection. Sorry for the brainless chatter. I jumped to conclusions after reading the patch, not looking at or testing the final code. Both versions of the code (before and after your fix) handle both modes (with or without the .Z or .gz supplied) just fine. - Larry signature.asc Description: Digital signature
Bug#308783: patch
See attached.
In case of too many mail/BTS/web gateways, I posted a backup copy at
http://recycle.lbl.gov/~ldoolitt/087a_SECURITY_libXpm_vulnerabilities.diff
When I say tested I mean tested in isolation.
My attempts to fully test the debian build process
have so far failed, for (I think) unrelated reasons.
apt-src and I are not friends yet.
- Larry
Candidate response to debian bug #308783, based on
http://ftp.x.org/pub/X11R6.8.1/patches/X11R6.8.1-to-X11R6.8.2.patch.gz
This patch is to be applied _after_
$ md5sum 087_SECURITY_libXpm_vulnerabilities.diff
810923ff9eac7eb83d96870a4fbaab15 087_SECURITY_libXpm_vulnerabilities.diff
Other than sorting out the patch basis and removing fuzz, my only contribution
is to remove a compilation warning caused by a missing FUNC(xpmPipeThrough, ...)
in RdFToI.c. Verified against the full X11R6.8.2 sources: the only
other differences are CVS tags and some trailing spaces in the source.
Tested, works. 2005-05-23 Larry Doolittle [EMAIL PROTECTED]
diff -ur xc~/extras/Xpm/lib/RdFToI.c xc/extras/Xpm/lib/RdFToI.c
--- xc~/extras/Xpm/lib/RdFToI.c 2005-05-23 10:12:01.211131000 -0700
+++ xc/extras/Xpm/lib/RdFToI.c 2005-05-23 10:22:48.159031812 -0700
@@ -36,15 +36,11 @@
/* October 2004, source code review by Thomas Biege [EMAIL PROTECTED] */
#include XpmI.h
-#include sys/stat.h
-#if !defined(NO_ZPIPE) defined(WIN32)
-# define popen _popen
-# define pclose _pclose
-# if defined(STAT_ZFILE)
-# include io.h
-# define stat _stat
-# define fstat _fstat
-# endif
+#ifndef NO_ZPIPE
+#include fcntl.h
+#include errno.h
+#include sys/types.h
+#include sys/wait.h
#endif
LFUNC(OpenReadFile, int, (char *filename, xpmData *mdata));
@@ -122,89 +118,132 @@
}
#endif /* CXPMPROG */
-/*
- * open the given file to be read as an xpmData which is returned.
- */
#ifndef NO_ZPIPE
- FILE *s_popen(char *cmd, const char *type);
-#else
-# define s_popen popen
+/* Do not depend on errno after read_through */
+FUNC(xpmPipeThrough, FILE*, (int fd, const char* cmd, const char* arg1, const
char* mode));
+FILE*
+xpmPipeThrough(fd, cmd, arg1, mode)
+int fd;
+const char* cmd;
+const char* arg1;
+const char* mode;
+{
+FILE* fp;
+int status, fds[2], in = 0, out = 1;
+pid_t pid;
+if ( 'w' == *mode )
+ out = 0, in = 1;
+if ( pipe(fds) 0 )
+ return NULL;
+pid = fork();
+if ( pid 0 )
+ goto fail1;
+if ( 0 == pid )
+{
+ close(fds[in]);
+ if ( dup2(fds[out], out) 0 )
+ goto err;
+ close(fds[out]);
+ if ( dup2(fd, in) 0 )
+ goto err;
+ close(fd);
+ pid = fork();
+ if ( pid 0 )
+ goto err;
+ if ( 0 == pid )
+ {
+ execlp(cmd, cmd, arg1, NULL);
+ perror(cmd);
+ goto err;
+ }
+ _exit(0);
+err:
+ _exit(1);
+}
+close(fds[out]);
+/* calling process: wait for first child */
+while ( waitpid(pid, status, 0) 0 EINTR == errno )
+ ;
+if ( WIFSIGNALED(status) ||
+(WIFEXITED(status) WEXITSTATUS(status) != 0) )
+ goto fail2;
+fp = fdopen(fds[in], mode);
+if ( !fp )
+ goto fail2;
+close(fd); /* still open in 2nd child */
+return fp;
+fail1:
+close(fds[out]);
+fail2:
+close(fds[in]);
+return NULL;
+}
#endif
+/*
+ * open the given file to be read as an xpmData which is returned.
+ */
static int
OpenReadFile(filename, mdata)
char *filename;
xpmData *mdata;
{
-#ifndef NO_ZPIPE
-char buf[BUFSIZ];
-# ifdef STAT_ZFILE
-char *compressfile;
-struct stat status;
-# endif
-#endif
-
if (!filename) {
mdata-stream.file = (stdin);
mdata-type = XPMFILE;
} else {
-#ifndef NO_ZPIPE
- size_t len = strlen(filename);
-
- if (len == 0)
- return(XpmOpenFailed);
- if ((len 2) !strcmp(.Z, filename + (len - 2))) {
- mdata-type = XPMPIPE;
- snprintf(buf, sizeof(buf), uncompress -c \%s\, filename);
- if (!(mdata-stream.file = s_popen(buf, r)))
- return (XpmOpenFailed);
-
- } else if ((len 3) !strcmp(.gz, filename + (len - 3))) {
- mdata-type = XPMPIPE;
- snprintf(buf, sizeof(buf), gunzip -qc \%s\, filename);
- if (!(mdata-stream.file = s_popen(buf, r)))
- return (XpmOpenFailed);
-
- } else {
-# ifdef STAT_ZFILE
- if (!(compressfile = (char *) XpmMalloc(len + 4)))
+ int fd = open(filename, O_RDONLY);
+#if defined(NO_ZPIPE)
+ if ( fd 0 )
+ return XpmOpenFailed;
+#else
+ const char* ext = NULL;
+ if ( fd = 0 )
+ ext = strrchr(filename, '.');
+#ifdef STAT_ZFILE /* searching for z-files if the given name not found */
+ else
+ {
+ size_t len = strlen(filename);
+ char *compressfile = (char *) XpmMalloc(len + 4);
+ if ( !compressfile )
return (XpmNoMemory
Bug#308783: new s_popen() function is insecure garbage
Branden Robinson asked: Could I get a second opinion (or more than one) from you guys as to whether this is actually an exploitable security problem? I can't answer this in the affirmative, but then I only spent about 15 minutes looking for a way to exploit it. I note that apt-rdepends finds 9043 packages that depend on libxpm4, so the opportunities are immense. It's probably easier to fix the problem then scrutinize 9043 packages for plausible cases of uncontrolled input of xpm file names. Matej's assessment is: This completely breaks the transparent compression and decompression. Which I agree with. The options for addressing this bug are: 1. Do nothing, almost guaranteeing an exploit will be found. 2. Write a real fix, instead of the stupid s_popen thing. I might play around with option 2. There are two strategies that make technical sense: a. skip the sprintf/parsing step, and go directly to execlp(uncompress,-c,filename); b. put the uncompress/unzip code (zlib calls) inline Where (a) involves less coding and makes fewer changes to the build/depends process, but (b) is probably more robust at runtime. The compression and decompression methods become distinct code paths. Is someone from the Debian X Strike Force already working on this? - Larry signature.asc Description: Digital signature
Bug#308783: new s_popen() function is insecure garbage
Daniel et al. - On Mon, May 23, 2005 at 11:32:19AM +1000, Daniel Stone wrote: I might play around with option 2. There are two strategies that make technical sense: Why would you do this when there's already a version upstream that fixes this? I don't like the idea of having yet another Xpm 'security fix' variant out there. OK, so I was slow finding the proper upstream fix. Now that I found it within http://ftp.x.org/pub/X11R6.8.2/patches/X11R6.8.1-to-X11R6.8.2.patch.gz I gave it a quick review (it matches my strategy (a)). So, let me rephrase the question: Has Matej and someone from the Debian X Strike Force reviewed and/or started to test the X11R6.8.2 patch to xc/extras/Xpm/lib/RdFToI.c xc/extras/Xpm/lib/WrFFrI.c and maybe xc/extras/Xpm/lib/XpmI.h ? - Larry signature.asc Description: Digital signature
Bug#309507: libpolyxmass_0.8.7-1 (unstable): fails to build
Bug #309507 is effectively a duplicate of #303856. Same source, same bug, different compiler and host system. The patch given by Kurt Roeckx in 303856 for AMD64 should also take care of the S390 folks. - Larry signature.asc Description: Digital signature
Bug#307226: bug isolation
I can reproduce the bug on amd64 pure64. I can isolate the segfault to t-db-setDirty(true); in the middle of void TodoDB::remove() in TodoDB.cc. It's helpful to run with -vv. - Larry signature.asc Description: Digital signature
Bug#306195: instructions to solve
Like many other people, I kept getting dpkg: error processing /var/cache/apt/archives/libwxgtk2.4-python_2.4.2.6.1_amd64.deb (--unpack): trying to overwrite `/usr/bin/helpviewer', which is also in package wxpython2.5.3 during an apt-get upgrade of libwxgtk2.4-python. Turns out wxpython2.5.3 has been withdrawn (see http://bugs.debian.org/287623), so the right fix is apt-get remove wxpython2.5.3 libwxgtk2.4-python should then install normally. - Larry signature.asc Description: Digital signature
Bug#277690: snacc: FTBFS patch
File compiler/back-ends/c-gen/gen-code.c uses ctime(3) without a prototype, so its result is assumed integer (it's really a pointer). Adding #include time.h to that file fixes the FTBFS. Patch appended. I can't vouch for proper operation of the result. There are still a ton of warnings about incompatible pointer types. Somebody should turn up the gcc warning level and clean up the code base. Is this code maintained upstream? - Larry diff -ur snacc-1.3bbn-orig/compiler/back-ends/c-gen/gen-code.c snacc-1.3bbn/compiler/back-ends/c-gen/gen-code.c --- snacc-1.3bbn-orig/compiler/back-ends/c-gen/gen-code.c 2001-01-26 17:02:52.0 -0800 +++ snacc-1.3bbn/compiler/back-ends/c-gen/gen-code.c2005-05-02 10:58:48.268141081 -0700 @@ -33,6 +33,7 @@ */ #include stdio.h +#include time.h #include asn-incl.h #include asn1module.h signature.asc Description: Digital signature
Bug#298198: html2text: Segfaults on amd64.
I reproduced this bug, found the problem, and fixed it. Patch attached.
The problem is in the usage of get_attribute, which is a variable
argument function. The function checks for a NULL (char *) argument
to terminate processing. Callers used 0 to represent the end of
the list, which fails on architectures where int is not the same
length as (char *). Callers should use NULL when they mean NULL.
C++ blurs the difference between 0 and NULL much more than C.
In a variable argument function call, there is still a difference.
libefence and gdb are nice, but eventually I chased this down
with good ol' printf's.
- Larry
diff -ur html2text-1.3.2a/format.C html2text-1.3.2a-fixed/format.C
--- html2text-1.3.2a/format.C 2003-11-23 03:05:29.0 -0800
+++ html2text-1.3.2a-fixed/format.C 2005-04-27 11:47:06.023515000 -0700
@@ -560,7 +560,7 @@
LEFT, Area::LEFT,
CENTER, Area::CENTER,
RIGHT, Area::RIGHT,
-0
+NULL
);
static char cell_attributes[7];
@@ -682,7 +682,7 @@
LEFT, Area::LEFT,
CENTER, Area::CENTER,
RIGHT, Area::RIGHT,
-0
+NULL
);
static BlockFormat bf(P);
@@ -752,7 +752,7 @@
LEFT, Area::LEFT,
MIDDLE, Area::CENTER,
RIGHT, Area::RIGHT,
- 0
+ NULL
);
Area *a = ::format(content.get(), w, halign);
if (a) return a;
@@ -802,7 +802,7 @@
LEFT, Area::LEFT,
CENTER, Area::CENTER,
RIGHT, Area::RIGHT,
-0
+NULL
));
}
@@ -1632,7 +1632,7 @@
A, UPPER_ALPHA,
i, LOWER_ROMAN,
I, UPPER_ROMAN,
-0
+NULL
);
}
diff -ur html2text-1.3.2a/table.C html2text-1.3.2a-fixed/table.C
--- html2text-1.3.2a/table.C2002-07-22 04:32:50.0 -0700
+++ html2text-1.3.2a-fixed/table.C 2005-04-27 11:48:03.336833000 -0700
@@ -122,14 +122,14 @@
LEFT, Area::LEFT,
CENTER, Area::CENTER,
RIGHT, Area::RIGHT,
- 0
+ NULL
);
int row_valign = get_attribute(
row.attributes.get(), VALIGN, Area::MIDDLE,
TOP,Area::LEFT,
MIDDLE, Area::MIDDLE,
BOTTOM, Area::BOTTOM,
- 0
+ NULL
);
const listauto_ptrTableCellcl(*row.cells);
@@ -158,14 +158,14 @@
LEFT, Area::LEFT,
CENTER, Area::CENTER,
RIGHT, Area::RIGHT,
-0
+NULL
);
p-valign= get_attribute(
cell.attributes.get(), VALIGN, row_valign,
TOP,Area::TOP,
MIDDLE, Area::MIDDLE,
BOTTOM, Area::BOTTOM,
-0
+NULL
);
{
auto_ptrArea tmp(cell.format(
@@ -386,7 +386,7 @@
LEFT, Area::LEFT,
CENTER, Area::CENTER,
RIGHT, Area::RIGHT,
-0
+NULL
);
// TABLE = default = no border
signature.asc
Description: Digital signature
Bug#297898: ifupdown: postinst fails
Presumably this error was caused by a missing /etc/network in your chroot. Is it appropriate to add mkdir -p /etc/network to ifupdown.postinst before line 95 : /etc/network/ifstate ? Or maybe earlier in the script? - Larry signature.asc Description: Digital signature
