Bug#849825: openocd: fails to program Intel flash on MIPS target
Package: openocd
Version: 0.9.0
Tags: patch
openocd fails to program the Intel TE28F160 flash memory attached to
the AR7 (MIPS core) in a Solwise SAR600E router (the AR7 is also used
in many other routers) with the error "Unknown architecture". There
are two reasons for the failure.
The first reason is that the architecture problem only prevents block
writing. It does not prevent word-at-a-time writing (granted this is
horrendously slow, but it is a lot better than nothing). The openocd
code does in fact contain a fallback to word-at-a-time writing for the
case that block writing is not possible, but with a MIPS target it
fails to trigger the fallback.
The second reason is that the code for word-at-a-time writing doesn't
actually work as supplied, because part of the logic is scrambled
(although that same logic appears correct and unscrambled in several
other places, including just a few lines further on from the error).
Attached is a patch to (a) ensure that the fallback does get
triggered, and (b) unscramble the scrambled bit of code.
--
Pigeon
Be kind to pigeons - - Pigeon's Nest: http://pigeonsnest.co.uk/
GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
diff -Naur openocd-0.9.0.orig/src/flash/nor/cfi.c openocd-0.9.0/src/flash/nor/cfi.c
--- openocd-0.9.0.orig/src/flash/nor/cfi.c 2014-03-29 17:55:12.0 +0100
+++ openocd-0.9.0/src/flash/nor/cfi.c 2016-12-31 18:48:48.884400377 +0100
@@ -1212,8 +1212,12 @@
arm_algo.core_mode = ARM_MODE_SVC;
arm_algo.core_state = ARM_STATE_ARM;
} else {
- LOG_ERROR("Unknown architecture");
- return ERROR_FAIL;
+ if (strncmp(target_type_name(target), "mips_m4k", 8) == 0) {
+ return (ERROR_TARGET_RESOURCE_NOT_AVAILABLE);
+ } else {
+ LOG_ERROR("Unknown architecture");
+ return ERROR_FAIL;
+ }
}
cfi_intel_clear_status_register(bank);
@@ -1989,7 +1993,9 @@
uint8_t status;
retval = cfi_intel_wait_status_busy(bank, cfi_info->word_write_timeout, &status);
- if (retval != 0x80) {
+ if (retval != ERROR_OK)
+ return retval;
+ if (status != 0x80) {
retval = cfi_send_command(bank, 0xff, flash_address(bank, 0, 0x0));
if (retval != ERROR_OK)
return retval;
signature.asc
Description: Digital signature
Bug#833346: wodim --devices" does not work
Tags: patch
Without following the discussion in detail, since life is too short, I
will note only that a cursory web search reveals people having this
problem at least as far back as 2008, and being advised to use a
symlink, config option, command line option, command alias, etc, to
force wodim to check /dev/sr* devices. I consider that such actions
should only be necessary in unusual cases; while peculiar situations
may exist (I don't know if they do or not) in which scanning for
/dev/sr* may be undesirable, with a vanilla setup it is not only
desirable but necessary, and resorting to reconfiguration should be a
step required only in the unusual cases.
Based on the statement (source forgotten) that there is supposed to be
a one-to-one correspondence between /dev/sr* and /dev/scd*, I submit
the attached trivial patch against cdrkit-1.1.11-3 to make it scan
for both.
--
Pigeon
Be kind to pigeons - - Pigeon's Nest: http://pigeonsnest.co.uk/
GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
--- cdrkit-1.1.11.orig/libusal/scsi-linux-sg.c 2008-02-26 08:02:13.0 +
+++ cdrkit-1.1.11/libusal/scsi-linux-sg.c 2016-10-14 02:59:05.867695082 +0100
@@ -508,8 +508,9 @@
else {
/* scan and maybe keep one open, sg_setup decides */
#define HDX 0
-#define SCD 1
-#define SG 2
+#define SR 1
+#define SCD 2
+#define SG 3
int h;
/*
retry_scan_open:
@@ -525,6 +526,15 @@
last='z';
break;
}
+case(SR):
+ {
+ if(!check_linux_26())
+ continue;
+ pattern="/dev/sr%d";
+ first=0;
+ last=255;
+ break;
+ }
case(SCD):
{
if(!check_linux_26())
signature.asc
Description: Digital signature
Bug#805427: ngspice: FTBFS due to lyx/elyxer problem
Package: ngspice Version: 26-1+b1 Versions of related packages: elyxer1.2.5-1 lyx 2.1.4-2 lyx-common2.1.4-2 Building ngspice from source fails with the error "No information for exporting the format HTML.", generated by 'lyx --export html' in the documentation build stage. This is because, despite installing elyxer to comply with the ngspice Build-Depends, lyx remains unaware that it is available. Running 'dpkg-reconfigure lyx' and 'dpkg-reconfigure elyxer' did not help. The answer turned out to be to select "Tools -> Reconfigure" from within the lyx GUI. Having done this, building ngspice succeeds and the generated HTML documentation seems to be fine. The proper solution would therefore seem to be to invoke that same option by means of a command in the elyxer/lyx postinst script, but since I know zip about lyx I have no idea how this might be achieved. I am not sure where to report this bug because it is an FTBFS of one package caused by a configuration error involving two other packages. Please reassign if this is felt appropriate. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#789462: src:kmod - documentation not buit, "orig".tar.xz isn't
On Sun, Jun 21, 2015 at 10:30:24AM +0200, Marco d'Itri wrote:
> On Jun 21, Pigeon wrote:
>
> > Surely the Debian version of the tarball should be identical to the
> > kernel.org original, and any Debianising patching performed through
> Not at all.
> But I will welcome patches to build the documentation from the git tree.
Sorry for delayed reply... is this any good? (Patch attached)
--
Pigeon
Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/
GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
diff -urN kmod-20.orig/debian/rules kmod-20/debian/rules
--- kmod-20.orig/debian/rules 2015-03-10 03:02:07.0 +
+++ kmod-20/debian/rules 2015-06-25 00:27:30.750498479 +0100
@@ -17,6 +17,7 @@
dpkg-buildflags --export=configure || true) \
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
--with-rootlibdir=/lib/$(DEB_HOST_MULTIARCH) \
+ --enable-gtk-doc \
--enable-debug
CONFFLAGS_udeb = $(CONFFLAGS) \
$(subst -O2,-Os -fomit-frame-pointer,$(shell DEB_BUILD_MAINT_OPTIONS="hardening=-all" \
diff -urN kmod-20.orig/libkmod/docs/gtk-doc.make kmod-20/libkmod/docs/gtk-doc.make
--- kmod-20.orig/libkmod/docs/gtk-doc.make 1970-01-01 01:00:00.0 +0100
+++ kmod-20/libkmod/docs/gtk-doc.make 2014-09-08 10:49:01.0 +0100
@@ -0,0 +1,289 @@
+# -*- mode: makefile -*-
+
+
+# Everything below here is generic #
+
+
+if GTK_DOC_USE_LIBTOOL
+GTKDOC_CC = $(LIBTOOL) --tag=CC --mode=compile $(CC) $(INCLUDES) $(GTKDOC_DEPS_CFLAGS) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
+GTKDOC_LD = $(LIBTOOL) --tag=CC --mode=link $(CC) $(GTKDOC_DEPS_LIBS) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS)
+GTKDOC_RUN = $(LIBTOOL) --mode=execute
+else
+GTKDOC_CC = $(CC) $(INCLUDES) $(GTKDOC_DEPS_CFLAGS) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
+GTKDOC_LD = $(CC) $(GTKDOC_DEPS_LIBS) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS)
+GTKDOC_RUN =
+endif
+
+# We set GPATH here; this gives us semantics for GNU make
+# which are more like other make's VPATH, when it comes to
+# whether a source that is a target of one rule is then
+# searched for in VPATH/GPATH.
+#
+GPATH = $(srcdir)
+
+TARGET_DIR=$(HTML_DIR)/$(DOC_MODULE)
+
+SETUP_FILES = \
+ $(content_files) \
+ $(DOC_MAIN_SGML_FILE) \
+ $(DOC_MODULE)-sections.txt \
+ $(DOC_MODULE)-overrides.txt
+
+EXTRA_DIST = \
+ $(HTML_IMAGES) \
+ $(SETUP_FILES)
+
+DOC_STAMPS=setup-build.stamp scan-build.stamp sgml-build.stamp \
+ html-build.stamp pdf-build.stamp \
+ sgml.stamp html.stamp pdf.stamp
+
+SCANOBJ_FILES = \
+ $(DOC_MODULE).args \
+ $(DOC_MODULE).hierarchy \
+ $(DOC_MODULE).interfaces \
+ $(DOC_MODULE).prerequisites \
+ $(DOC_MODULE).signals
+
+REPORT_FILES = \
+ $(DOC_MODULE)-undocumented.txt \
+ $(DOC_MODULE)-undeclared.txt \
+ $(DOC_MODULE)-unused.txt
+
+gtkdoc-check.test: Makefile
+ $(AM_V_GEN)echo "#!/bin/sh -e" > $@; \
+ echo "$(GTKDOC_CHECK_PATH) || exit 1" >> $@; \
+ chmod +x $@
+
+CLEANFILES = $(SCANOBJ_FILES) $(REPORT_FILES) $(DOC_STAMPS) gtkdoc-check.test
+
+if GTK_DOC_BUILD_HTML
+HTML_BUILD_STAMP=html-build.stamp
+else
+HTML_BUILD_STAMP=
+endif
+if GTK_DOC_BUILD_PDF
+PDF_BUILD_STAMP=pdf-build.stamp
+else
+PDF_BUILD_STAMP=
+endif
+
+all-gtk-doc: $(HTML_BUILD_STAMP) $(PDF_BUILD_STAMP)
+.PHONY: all-gtk-doc
+
+if ENABLE_GTK_DOC
+all-local: all-gtk-doc
+endif
+
+docs: $(HTML_BUILD_STAMP) $(PDF_BUILD_STAMP)
+
+$(REPORT_FILES): sgml-build.stamp
+
+ setup
+
+GTK_DOC_V_SETUP=$(GTK_DOC_V_SETUP_$(V))
+GTK_DOC_V_SETUP_=$(GTK_DOC_V_SETUP_$(AM_DEFAULT_VERBOSITY))
+GTK_DOC_V_SETUP_0=@echo " DOC Preparing build";
+
+setup-build.stamp:
+ -$(GTK_DOC_V_SETUP)if test "$(abs_srcdir)" != "$(abs_builddir)" ; then \
+ files=`echo $(SETUP_FILES) $(expand_content_files) $(DOC_MODULE).types`; \
+ if test "x$$files" != "x" ; then \
+ for file in $$files ; do \
+ destdir=`dirname $(abs_builddir)/$$file`; \
+ test -d "$$destdir" || mkdir -p "$$destdir"; \
+ test -f $(abs_srcdir)/$$file && \
+ cp -pf $(abs_srcdir)/$$file $(abs_builddir)/$$file || true; \
+ done; \
+ fi; \
+ fi
+ $(AM_V_at)touch setup-build.stamp
+
+
+ scan
+
+GTK_DOC_V_SCAN=$(GTK_DOC_V_SCAN_$(V))
+GTK_DOC_V_SCAN_=$(GTK_DOC_V_SCAN_$(AM_DEFAULT_VERBOSITY))
+GTK_DOC_V_SCAN_0=@echo " DOC Scanning header files";
+
+GTK_DOC_V_INTROSPECT=$(GTK_DOC_V_INTROSPECT_$(V))
+GTK_DOC_V_INTROSPECT_=$(GTK_DOC_V_INTROSPECT_$(AM_DEFAULT_VERBOSITY))
+GTK_DOC_V_INTROSPECT_0=@echo " DOC Introspecting gobjects";
+
+scan-build.stamp: setup-build.stamp $(HFILE_GLOB) $(CFILE_GLOB)
+ $(GTK_DOC_V_SCAN)_source_dir='' ; \
+ for i in $(DOC_SOURCE_DIR) ; do \
+ _source_dir="$${_source_dir} --source-dir=$$i"
Bug#789462: src:kmod - documentation not buit, "orig".tar.xz isn't
Package: kmod Version: 20-1 The file http://http.debian.net/debian/pool/main/k/kmod/kmod_20.orig.tar.xz is not actually the original source code, and the kmod API documentation is missing from the packages built from it. File sha256sum http://http.debian.net/debian/pool/main/k/kmod/kmod_20.orig.tar.xz 591d729557cf2fcaa434534f7f55f096592f459cfb33501791424076d077295e https://www.kernel.org/pub/linux/utils/kernel/kmod/kmod-20.tar.xz 89c1a1a2193c31f9ebe582640bfa2bd401341dc24119f5a7f702588116fadaa0 Several files in the kernel.org version are missing from the Debian version, including kmod-20/libkmod/docs/gtk-doc.make and kmod-20/libkmod/docs/Makefile.in. The package as originally written is supposed to contain API documentation in HTML format. When built from the Debian source this documentation is missing. If, however, before executing dpkg-source -x, the genuine kmod-20.tar.xz from kernel.org is copied as kmod_20.orig.tar.xz and the hashes in kmod_20-1.dsc adjusted accordingly, the resulting kmod_20-1_amd64.deb *does* contain the API documentation; it is under /usr/share/gtk-doc/html/libkmod-3. Surely the Debian version of the tarball should be identical to the kernel.org original, and any Debianising patching performed through the agency of kmod_20-1.debian.tar.xz. It should not be necessary to refer back to kernel.org to get the complete package including all files needed to build the API documentation. Further, and obviously, the documentation being missing from the Debian package is a thorough pain to anyone wanting to write code using the API. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#782168: inetutils-ping: change to default pattern if none specified
Package: inetutils-ping
Version: 2:1.9.2.39.3a460-3
Severity: wishlist
Tags: patch
The existing version of inetutils-ping, if no "pattern" (-p option) is
specified, pads the ping packet with a sequence of bytes of ascending
value.
I suggest that this function could instead be fittingly fulfilled by
the use of the following sequence instead:
47 4e 55 20 54 65 72 72 79 20 50 72 61 74 63 68 65 74 74 20
See "Going Postal" for further information.
A patch is supplied.
--
Pigeon
Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/
GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
diff -ru /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460.orig/debian/local/man/ping.1 /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460/debian/local/man/ping.1
--- /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460.orig/debian/local/man/ping.1 2014-10-25 22:20:56.00000 +0100
+++ /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460/debian/local/man/ping.1 2015-04-08 20:24:20.996324389 +0100
@@ -110,7 +110,7 @@
Numeric output only.
No attempt will be made to lookup symbolic names for host addresses.
.It Fl p Ar pattern
-You may specify up to 16 ``pad'' bytes to fill out the packet you send.
+You may specify up to 20 ``pad'' bytes to fill out the packet you send.
This is useful for diagnosing data-dependent problems in a network.
For example,
.Dq Li \-p ff
diff -ru /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460.orig/doc/inetutils.texi /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460/doc/inetutils.texi
--- /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460.orig/doc/inetutils.texi 2014-10-25 20:53:34.0 +0100
+++ /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460/doc/inetutils.texi 2015-04-08 20:25:34.252932546 +0100
@@ -701,7 +701,7 @@
@itemx --pattern=@var{pat}
@opindex -p
@opindex --pattern
-You may specify up to 16 pad bytes to fill out the packet you send.
+You may specify up to 20 pad bytes to fill out the packet you send.
This is useful for diagnosing data-dependent problems in a network.
For example, @option{-p ff} will cause the sent packet to be filled
with all ones.
@@ -958,7 +958,7 @@
@itemx --pattern=@var{pattern}
@opindex -p
@opindex --pattern
-Up to 16 hexadecimal pad bytes are given as @var{pattern}.
+Up to 20 hexadecimal pad bytes are given as @var{pattern}.
These are use for filling out the packets you send.
This option is useful for diagnosing data-dependent problems
within a network.
diff -ru /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460.orig/ping/ping_common.c /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460/ping/ping_common.c
--- /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460.orig/ping/ping_common.c 2014-10-25 20:53:35.0 +0100
+++ /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460/ping/ping_common.c 2015-04-08 20:17:02.884687314 +0100
@@ -70,6 +70,15 @@
data_buffer = xmalloc (data_length);
+#ifdef DEFAULTPATTERN
+ if (!pat) pat = DEFAULTPATTERN;
+ for (p = data_buffer; p < data_buffer + data_length; p++)
+ {
+ *p = pat[i];
+ if (++i >= len)
+ i = 0;
+ }
+#else
if (pat)
{
for (p = data_buffer; p < data_buffer + data_length; p++)
@@ -84,6 +93,7 @@
for (i = 0; i < data_length; i++)
data_buffer[i] = i;
}
+#endif /* ifdef DEFAULTPATTERN */
}
void
diff -ru /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460.orig/ping/ping_common.h /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460/ping/ping_common.h
--- /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460.orig/ping/ping_common.h 2014-10-25 20:53:35.0 +0100
+++ /home/pigeon/debian/inetutils/inetutils-1.9.2.39.3a460/ping/ping_common.h 2015-04-08 20:42:55.641577853 +0100
@@ -27,8 +27,15 @@
#include
+#define DEFAULTPATTERN "\x47\x4e\x55\x20\x54\x65\x72\x72\x79\x20" \
+ "\x50\x72\x61\x74\x63\x68\x65\x74\x74\x20"
+
#define MAXWAIT 10 /* Max seconds to wait for response. */
-#define MAXPATTERN 16 /* Maximal length of pattern. */
+#ifdef DEFAULTPATTERN
+#define MAXPATTERN 20 /* Maximal length of pattern = length of DEFAULTPATTERN */
+#else
+#define MAXPATTERN 16 /* original value */
+#endif
#define OPT_FLOOD 0x001
#define OPT_INTERVAL0x002
signature.asc
Description: Digital signature
Bug#776413: Policy violation: ed priority "optional", should be "important"
Package: ed Version: any The priority of the ed package has been changed to "optional". According to the changelog this is apparently for no reason other than a response to bug #416585, the content of which is simply one person's suggestion which he makes without providing any justification beyond his personal whim. The Debian policy manual http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities says: "If the expectation is that an experienced Unix person who found it missing would say "What on earth is going on, where is foo?", it must be an important package." Surely it is beyond question that this applies to ed. Anyone needing to edit a file via a simple line-oriented interface on a Unix-like system will automatically reach for ed and will be most disconcerted to find it missing. And certainly ed used to have priority "important" as this suggests it should. The assertion in bug #416585 that "anyone who wants it can easily install it" is not true. The principal value of ed is that it is an editor which works when nothing else does. If the system is broken, or incompletely installed, or only accessible via the most primitive of interfaces, or in other situations of a like kind, which are the sort of situations in which ed or an equivalent is likely to be the only editor that is usable at all, it is also highly likely that installing ed (or anything else for that matter) will be impossible. And the lack of a functional editor makes it many times harder to fix whatever problem has given rise to the need for it. I have recently been caught this way a couple of times myself. In one case I was able to copy /bin/ed from another system onto a USB stick and use that. In another I had to use yucky workarounds like sed -i -e 'editing commands' 'filename'. Another virtue of ed is that it is possible to use it to patch binaries without the risk that arises with less primitive editors of some automatic formatting function messing the whole thing up. For instance if a hard-coded pathname is causing problems then ed is capable of changing it to something else of the same or shorter length with no collateral damage. The kind of situation in which such a problem is likely to arise is also the kind of situation in which editing the source and recompiling is likely to be impossible. In short, not only is it a policy violation for ed to have priority "optional", it also means that an important repair and rescue tool is likely to be unavailable when it is most needed. Therefore I strongly suggest that the priority for ed be reset to "important". -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#756246: youtube-dl: AttributeError: 'NoneType' object has no attribute 'group'
Package: youtube-dl Version: 2014.07.15-1 Signature extraction on youtube videos fails with: AttributeError: 'NoneType' object has no attribute 'group' Example failing video URL: http://www.youtube.com/watch?v=FaDUTU6cDok This bug is fixed in upstream version 2014.07.25.1 -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#732277: Option for acpid to drop certain events completely
On Wed, Dec 18, 2013 at 10:00:01PM -0500, Ted Felix wrote: > Again, thanks for the patch. I've taken it and made a few minor > "improvements" and it is now available via git on acpid2's > sourceforge page. This should be the proper incantation to grab a > copy of the latest source: > > git clone git://git.code.sf.net/p/acpid2/code acpid2-code > > If you could build this and try it out, I would appreciate it. > One key change you'll notice is that the action to drop events has > been changed from the more emphatic DIEDIEDIE to the more mundane > . Hopefully this doesn't ruffle any feathers. Sorry for the delayed reply - obstructed first by the root filesystem on my main box eating itself and then by Christmas occurring... I have built your git code and installed it. It seems to be working fine, and looking over your changes I see no reason why this should not be the case :) I think the idea of a separate drop list is neater than overloading the command list, too. Nice one! -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#732277: Option for acpid to drop certain events completely
Package: acpid Version: 2.0.20-1 Severity: wishlist Tags: patch It is sometimes desirable to configure acpid to ignore certain events completely, such that no processing is carried out upon them at all. Unfortunately the standard configuration options do not allow this. There is a problem with acpid on certain laptops which generate periodic spurious battery insertion/removal events at short intervals. For example, with acpid event logging turned on I get: Dec 16 05:29:44 laptop acpid: received netlink event "battery PNP0C0A:00 0080 0001" in my syslog every 16-17 seconds or so (sometimes double that). Googling on the subject indicates that while it is a fairly uncommon problem, it is one that has been cropping up every now and then for as long as acpid has existed, and there seems to be no solution, no hint as to the cause, nor even any certainty as to whether it is the laptop or the battery itself which is causing it - I found a few mentions of the problem having been cured by replacing an ageing battery, but on the other hand I get periodic battery insertion events (as above) with both a nearly dead and a brand new battery installed, and periodic battery removal events (as above but with final dword ) with the battery removed. The frequency of these spurious events causes diverse difficulties with power management as they trigger processing by various acpid clients, which may in turn cause disk access and prevent the hard drive from being powered down. It seems fairly common for power management software to misinterpret "battery inserted" as being the same as "external power disconnected" (which is a separate ACPI event in its owm right) and switch the machine to low power mode, causing a message to be written to syslog to say that this has happened every few seconds and keeping the hard drive running. Indeed the comments in /etc/acpi/events/battery and /etc/acpi/events/ac seem to present a variant of this error. There would seem to be no particular difficulty likely to arise from dropping the battery insertion/removal events entirely since even if they were working properly they would not be of significant value; to be notified when the battery is inserted or removed is not very useful. If the laptop is running on external power it makes no difference; if it is not, nothing will be notified of battery removal anyway... Unfortunately there is no way to configure acpid to ignore an event entirely; it is only possible to add extra responses by means of external programs called through files in /etc/acpi/events. Other external programs which connect to acpid via /var/run/acpid.socket and submit rules which match the event in question will still receive it, and this cannot be prevented without drastic measures. I have therefore patched acpid to accept a pseudo-action - by default DIEDIEDIE but configurable via a command-line option - which causes it to abort all processing of an event. So for example the following can be put in /etc/acpi/events/battery: event=battery.* action=DIEDIEDIE and the spurious battery events will be dropped and not passed to any clients. Patch is attached. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F diff -ur acpid-2.0.20.orig/acpid.8 acpid-2.0.20/acpid.8 --- acpid-2.0.20.orig/acpid.8 2013-02-15 14:22:20.0 + +++ acpid-2.0.20/acpid.8 2013-12-16 08:45:48.098952122 + @@ -47,6 +47,13 @@ ordering is guaranteed), as well as one rule to be defined for multiple events. To force \fBacpid\fP to reload the rule configuration, send it a SIGHUP. .PP +The pseudo-action DIEDIEDIE causes the event to be dropped +completely and no further processing undertaken; clients connecting +via the UNIX domain socket (see below) will not be notified of the +event. This may be useful on some machines, such as certain laptops which +generate spurious battery events at frequent intervals. The name of +this pseudo-action may be redefined with a commandline option. +.PP In addition to rule files, \fBacpid\fP also accepts connections on a UNIX domain socket (\fI/var/run/acpid.socket\fP by default). Any application may connect to this socket. Once connected, \fBacpid\fP will send the text of @@ -124,6 +131,11 @@ the file exists, it will be removed and over-written. Default is \fI/var/run/acpid.pid\fP. .TP +.BI \-k "\fR, \fP" \-\-killstring " string" +This option defines the pseudo-action which tells \fBacpid\fP to abort +all processing of an event, including client notifications. +Default is \fIDIEDIEDIE\fP. +.TP .BI \-v "\fR, \fP" \-\-version Print version information and exit. .TP diff -ur acpid-2.0.20.orig/acpid.c acpid-2.0.20/acpid.c --- acpid-2.0.20.orig/acpid.c 2013-08-15 21:12:51.0 +0100 +++ acpid-2.0.20/acpid.c 2013-12-16 07:56:43.022309944 +
Bug#717617: ibus: Some characters cannot be typed when in different locale
Package: ibus Version: 1.5.1.is.1.4.2-2 Severity: important Dear Maintainer, My locale is set to en_AU.UTF-8. When I'm using the chinese input table, in particular, ibus-table-cangjie-big, some characters are not recognized. For example, from the cangjie-big.txt table, there is: tanw蘭 1000 but when i type "tanw" it is not recognized. More examples are "iknf", "vfok", "damh". But if I set my LANG to zh_TW.UTF-8, and those characters work. Is this a bug or is this a setup problem? Thanks. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ibus depends on: ii gconf-service 3.2.6-1 ii gconf23.2.6-1 ii gnome-icon-theme 3.4.0-2 ii libc6 2.17-3 ii libgconf-2-4 3.2.6-1 ii libglib2.0-0 2.36.1-2build1 ii libgtk2.0-0 2.24.18-1 ii libibus-1.0-0 1.5.1.is.1.4.2-1 ii librsvg2-common 2.36.4-2 ii libx11-6 2:1.5.0-1+deb7u1 ii python2.7.3-5 ii python-ibus 1.5.1.is.1.4.2-2 ii python-notify 0.1.1-3 ii python-xdg0.19-5 Versions of packages ibus recommends: ii ibus-gtk 1.5.1.is.1.4.2-1 ii ibus-gtk3 1.5.1.is.1.4.2-1 ii im-config [im-switch] 0.22-3 ii python-appindicator0.4.92-2 Versions of packages ibus suggests: pn ibus-doc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#703475: hexcurse: Hex search fails when pattern preceded by partial duplicate
Package: hexcurse Version: 1.55-2 Severity: normal Tags: patch The hex search function in hexcurse fails to find instances of certain search patterns when they are preceded in the file by a duplicate of the first few bytes of the pattern. Example: File (4MB): http://filehost.serveftp.net/things/stream.base..out Patterns: 0106 01ba The first instance of 0106 in the file occurs at offset 0x1c9, but the first instance found by hexcurse is that at 0x19269. The instance at 0x1c9 is not found. The sequence 01ba occurs at offset 0x3e2159 but hexcurse reports "not found". This bug is caused by hexSearch() failing to correctly adjust the file pointer following a matching attempt. The attached patch implements the extremely simple fix. The patch also fixes the warnings that the package will imminently fail to build from source due to the non-existence of debian/compat, and the warning about DH_COMPAT being set too low. -- Pigeon Be kind to pigeons- - Pigeon's Nest: http://pigeonsnest.co.uk/ Lucy Pinder TV: http://www.lucy-pinder.tv/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F diff -Nru hexcurse-1.55/debian/compat hexcurse-1.55-patched/debian/compat --- hexcurse-1.55/debian/compat 1970-01-01 01:00:00.0 +0100 +++ hexcurse-1.55-patched/debian/compat 2013-03-20 04:03:35.0 + @@ -0,0 +1 @@ +5 diff -Nru hexcurse-1.55/debian/rules hexcurse-1.55-patched/debian/rules --- hexcurse-1.55/debian/rules 2013-03-20 04:02:53.0 + +++ hexcurse-1.55-patched/debian/rules 2013-03-20 04:03:55.0 + @@ -6,7 +6,7 @@ #export DH_VERBOSE=1 # This is the debhelper compatability version to use. -export DH_COMPAT=2 +export DH_COMPAT=5 configure: configure-stamp configure-stamp: diff -Nru hexcurse-1.55/src/file.c hexcurse-1.55-patched/src/file.c --- hexcurse-1.55/src/file.c 2003-12-15 13:43:47.0 + +++ hexcurse-1.55-patched/src/file.c 2013-03-20 04:05:06.0 + @@ -253,6 +253,7 @@ break; } + fseek(fp, startLoc, SEEK_SET); if ((loop == length) && (flag)) /* if found it*/ return startLoc - 1; /* return location*/ signature.asc Description: Digital signature
Bug#683499: Segmentation fault in gen7_update_renderbuffer_surface()
Hi,
I have an Intel HD 4000 from the i7-3770 processor.
I'm still having this segfault for any GL programs (e.g.
glxgears).
I'm on Debian testing, libgl1-mesa-dri 8.0.5-3
I think the stack trace is pretty much the same.
Program received signal SIGSEGV, Segmentation fault.
gen7_update_renderbuffer_surface (brw=0x77fd8040, rb=0x61a0c0, unit=0)
at gen7_wm_surface_state.c:200
200 gen7_wm_surface_state.c: No such file or directory.
(gdb) bt
#0 gen7_update_renderbuffer_surface (brw=0x77fd8040, rb=0x61a0c0, unit=0)
at gen7_wm_surface_state.c:200
#1 0x7fffee26b750 in brw_update_renderbuffer_surfaces (brw=0x77fd8040)
at brw_wm_surface_state.c:1047
#2 0x7fffee255a90 in brw_upload_state (brw=brw@entry=0x77fd8040)
at brw_state_upload.c:503
#3 0x7fffee243527 in brw_try_draw_prims (max_index=,
min_index=, ib=0x0, nr_prims=2, prim=0x80e680,
arrays=0x699a70, ctx=0x77fd8040) at brw_draw.c:482
#4 brw_draw_prims (ctx=0x77fd8040, arrays=0x699a70, prim=0x80e680,
nr_prims=2, ib=0x0, index_bounds_valid=, min_index=0,
max_index=161, tfb_vertcount=0x0) at brw_draw.c:566
#5 0x7fffee370c2c in vbo_save_playback_vertex_list (ctx=0x77fd8040,
data=0x80dee8) at vbo/vbo_save_draw.c:298
#6 0x7fffee2c2542 in ext_opcode_execute (node=0x80dee0,
ctx=0x77fd8040) at main/dlist.c:602
#7 execute_list (ctx=0x77fd8040, list=)
at main/dlist.c:7505
#8 0x7fffee2c5f82 in _mesa_CallList (list=1) at main/dlist.c:8922
#9 0x004028a2 in ?? ()
#10 0x00401fd1 in ?? ()
#11 0x76b61ead in __libc_start_main (main=,
argc=, ubp_av=, init=,
fini=, rtld_fini=, stack_end=0x7fffe478)
at libc-start.c:228
#12 0x004025fd in ?? ()
#13 0x7fffe478 in ?? ()
#14 0x001c in ?? ()
#15 0x0001 in ?? ()
#16 0x7fffe76a in ?? ()
#17 0x in ?? ()
The line is:
struct intel_region *region = irb->mt->region;
But irb->mt is NULL.
I have tried a few different versions of kernels (3.2, 3.4,
3.7) but the crash is exactly the same.
Thanks.
Pigeon.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698109: PHP5 integer error in json_decode()
Package: php5
Version: 5.2.6.dfsg.1-1+lenny9
I realise this is an old version, but on looking through the bug
reports and changelogs I see no mention of any similar bugs or actions
to fix them, so I consider it possible that the bug still exists.
json_decode() does not always correctly decode integer values on large
integers such as twitter status IDs. It subtracts 1, or sometimes 2,
from the decoded value. This does not always happen and appears to be
unpredictable.
This is not an overflow error as the integers concerned, though large,
are still below the limit for the 64-bit system on which I discovered
the bug.
Here are some examples of incorrect output, generated using
command-line PHP with sample truncated twitter JSON strings:
Subtracting 1:
int(190624640131428353)
string(18) "190624640131428353"
int(190624640131428353)
array(1) {
[0]=>
array(3) {
["created_at"]=>
string(30) "Mon Jan 14 01:01:28 + 2013"
["id"]=>
int(190624640131428352)
["id_str"]=>
string(18) "190624640131428353"
}
}
array(1) {
[0]=>
object(stdClass)#1 (3) {
["created_at"]=>
string(30) "Mon Jan 14 01:01:28 + 2013"
["id"]=>
int(190624640131428352)
["id_str"]=>
string(18) "190624640131428353"
}
}
Subtracting 2:
int(190624590269513730)
string(18) "190624590269513730"
int(190624590269513730)
array(1) {
[0]=>
array(3) {
["created_at"]=>
string(30) "Mon Jan 14 01:01:28 + 2013"
["id"]=>
int(190624590269513728)
["id_str"]=>
string(18) "190624590269513730"
}
}
array(1) {
[0]=>
object(stdClass)#1 (3) {
["created_at"]=>
string(30) "Mon Jan 14 01:01:28 + 2013"
["id"]=>
int(190624590269513728)
["id_str"]=>
string(18) "190624590269513730"
}
}
By comparison, the (larger) integer 190694799109677056 is handled correctly.
--
Pigeon
Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/
- - Lucy Pinder TV: http://www.lucy-pinder.tv/
GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
signature.asc
Description: Digital signature
Bug#624548: More info for #624548
> Pretty sure it's the XFS bug, 1st bullet, 1st item on: > http://blog.mraw.org/2011/04/03/DXN-8/ Thank you very much. I, for one, can confirm that is the problem I am having. And fixed by removing the xfs package as well as removing the xfs FontPath in my xorg.conf. Regards, Pigeon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#624548: More info for #624548
Hi all, I have the same problem for a quite while now. The first time was running urxvt as mentioned by others. I also found that clicking on a qt dropdown list (so that it pops up the list of items for you to choose) will cause a crash too. Tested with qtconfig-qt4 and skype. The backtrace from Xorg is pretty much the same as running urxvt: Backtrace: 0: Xorg (xorg_backtrace+0x26) [0x4a3836] 1: Xorg (0x40+0x65049) [0x465049] 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fabbf523000+0xf020) [0x7fabbf532020] 3: Xorg (doListFontsWithInfo+0x10b) [0x43372b] 4: Xorg (ProcessWorkQueue+0x21) [0x436eb1] 5: Xorg (WaitForSomething+0x65) [0x45e745] 6: Xorg (0x40+0x32a92) [0x432a92] 7: Xorg (0x40+0x26fae) [0x426fae] 8: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) [0x7fabbe25cead] 9: Xorg (0x40+0x2729d) [0x42729d] I'm using nvidia with the proprietary driver btw. Pigeon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#586702: cups insists on lp owning /dev/lp? - lp group rw isn't good enough
Package: cups Version: 1.3.8-1+lenny6 Trying to print to an HPLJ6 on /dev/lp1 fails if lp is not the owner of the device node, even if lp has group rw on it. (Same applies to other parallel ports.) crw-rw 1 root lp 6, 1 Jun 17 20:13 /dev/lp1 - Doesn't work. /var/log/cups/error_log contains: E [21/Jun/2010:15:15:19 +0100] PID 31216 (/usr/lib/cups/backend/parallel) stopped with status 1! E [21/Jun/2010:15:15:19 +0100] [Job 352] Unable to open device file "/dev/lp1": Permission denied Note "permission denied" even though lp has rw permissions on the node. chowning the node to lp:sys and restarting cups fixes it. crw-rw 1 lp sys 6, 1 Jun 17 20:13 /dev/lp1 - Does work. However these permissions automatically revert to the non-working setup on reboot so it is necessary either to chown it again manually every time or bodge it with a startup script. Versions of packages cups Depends on: libavahi-compat-libdnssd1 0.6.23-3lenny1 libc6 2.7-18 libcups2 1.3.8-1+lenny6 libcupsimage2 1.3.8-1+lenny6 libdbus-1-3 1.2.1-5+lenny1 libgnutls26 2.4.2-6+lenny1 libkrb53 1.6.dfsg.4~beta1-5lenny1 libldap-2.4-2 2.4.11-1 libpam0g 1.0.1-5+lenny1 libpaper1 1.1.21 libslp1 1.2.1-6.2 debconf 1.5.11etch2 xpdf-utils 3.01-9.1+etch5 perl-modules 5.10.0-19lenny2 procps 1:3.2.7-3 ghostscript 8.62.dfsg.1-3.2lenny1 lsb-base 3.2-20 cups-common 1.3.8-1+lenny6 ssl-cert 1.0.23 adduser 3.102 Versions of packages cups Recommends: cups-client 1.3.8-1+lenny6 smbclient 3.0.24-6etch10 foomatic-filters 3.0.2-20061031-1.2 avahi-utils 0.6.23-3lenny1 Versions of installed packages cups Suggests: cups-bsd 1.3.8-1+lenny6 foomatic-db-engine 3.0.2-20061031-1 foomatic-db 20061031-1 hplip 2.8.6.b-4 -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#585586: xloadimage: BMP format not supported
Package: xloadimage Version: 4.1-16 Trying to view a Windows BMP image gives the error message "unknown or unsupported image type". BMP is not exactly an obscure format and it would be very useful to have it supported. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#478293: xterm: scrollback: disable "scroll to bottom on new output" while Shift key remains depressed?
Package: xterm Severity: wishlist xterm provides the facility to turn the scrollback feature "scroll to bottom on new output" on or off completely, but it would be very useful to have a third option, so that that feature is disabled while the Shift key is held down and re-enabled only when the Shift key is released. Say I am running "tail -f /var/log/syslog" in an xterm. I want "scroll to bottom on new output" enabled so that the tail "works". I then go into scrollback using Shift-PageUp in order to read some portion of the log output which has scrolled off the top. I have read half of whatever it was when suddenly there is some new syslog output and the xterm jumps back to the bottom and I lose my place. Which is really annoying. At the moment the options available are 1) put up with it 2) explicitly disable "scroll to bottom on new output" every time I use scrollback and then re-enable it afterwards 3) Ctrl-C out of "tail -f", use eg. less to examine the log file, then restart "tail -f" once I've finished It would be really useful if holding down the Shift key would disable "scroll to bottom on new output" for as long as the Shift key remains depressed, and then re-enable it when the Shift key is released. That way I could read the tailed log in scrollback without it randomly jumping out of sight, and when I'd finished reading it would revert to normal without any extra action required. -- Pigeon Be kind to pigeons Pigeon's Nest - http://pigeonsnest.co.uk/ Lucy Pinder Television - http://www.lucy-pinder.tv/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#454546: Cause of problem, possible patch
On Fri, Dec 14, 2007 at 11:36:45PM +0100, Brice Goglin wrote: > I have forwarded your problem at the URL above. Feel free to add any comment > if you think it could help. These which I have just googled are probably relevant: Probably related problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392864 Reasoning behind the introduction of the problem code: https://bugzilla.novell.com/show_bug.cgi?id=144682 Copied to above bugzilla along with link to this bug. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#454546: Cause of problem, possible patch
On Sat, Dec 08, 2007 at 01:11:10PM +0100, Brice Goglin wrote: > Does both wheels work very fine with your patch? > (apart from some "unrecognized packet" warnings in the Xorg log) ...update since my last message: I have since had several unrecognised packet events recorded in the log, but both wheels have continued to work fine throughout. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#454546: Cause of problem, possible patch
On Sat, Dec 08, 2007 at 01:11:10PM +0100, Brice Goglin wrote:
> Pigeon wrote:
> > Looking at the source code for xserver-xorg-input-mouse it seems that this
> > behaviour is a gross overreaction to the reception of a spurious z-axis
> > packet from the mouse.
> >
> > if (pMse->negativeW != MSE_NOAXISMAP) {
> > switch (pBuf[3] & 0x0f) {
> > case 0x00: break;
> > case 0x01: dz = 1; break;
> > case 0x02: dw = 1; break;
> > case 0x0e: dw = -1; break;
> > case 0x0f: dz = -1; break;
> > default:
> > xf86Msg(X_INFO,
> > "Mouse autoprobe: Disabling secondary
> > wheel\n");
> > pMse->negativeW = pMse->positiveW =
> > MSE_NOAXISMAP;
> > }
> > }
> >
> > So, if it receives any z-axis data that it does not understand, it does not
> > simply ignore it, it immediately and for no reason nukes the secondary
> > wheel,
> > and moreover does this in such a way that it also destroys any wheel
> > remapping,
> > with the result that it also destroys my vertical wheel. This is very rude.
> >
> > So I am currently testing the following patch, which simply reports and then
> > ignores the spurious packet, instead of making my mouse unusable.
> >
> >
>
> I will report your problem upstream. Does both wheels work very fine
> with your patch?
> (apart from some "unrecognized packet" warnings in the Xorg log)
Because of the intermittent nature of the problem the warning has only
appeared once since I installed the patch, but it has indeed occurred,
and both wheels are still working fine. As far as I can tell there is
no problem.
--
Pigeon
Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/
GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
signature.asc
Description: Digital signature
Bug#454546: Cause of problem, possible patch
Looking at the source code for xserver-xorg-input-mouse it seems that this
behaviour is a gross overreaction to the reception of a spurious z-axis
packet from the mouse.
if (pMse->negativeW != MSE_NOAXISMAP) {
switch (pBuf[3] & 0x0f) {
case 0x00: break;
case 0x01: dz = 1; break;
case 0x02: dw = 1; break;
case 0x0e: dw = -1; break;
case 0x0f: dz = -1; break;
default:
xf86Msg(X_INFO,
"Mouse autoprobe: Disabling secondary
wheel\n");
pMse->negativeW = pMse->positiveW =
MSE_NOAXISMAP;
}
}
So, if it receives any z-axis data that it does not understand, it does not
simply ignore it, it immediately and for no reason nukes the secondary wheel,
and moreover does this in such a way that it also destroys any wheel remapping,
with the result that it also destroys my vertical wheel. This is very rude.
So I am currently testing the following patch, which simply reports and then
ignores the spurious packet, instead of making my mouse unusable.
diff -u src/mouse.c.orig src/mouse.c
--- src/mouse.c.orig2007-12-06 14:57:38.0 +
+++ src/mouse.c 2007-12-06 14:27:08.0 +
@@ -1511,9 +1511,14 @@
case 0x0e: dw = -1; break;
case 0x0f: dz = -1; break;
default:
+#ifdef notdef
xf86Msg(X_INFO,
"Mouse autoprobe: Disabling secondary wheel\n");
pMse->negativeW = pMse->positiveW = MSE_NOAXISMAP;
+#else
+ xf86Msg(X_INFO,
+ "ExplorerPS/2 decode: unrecognised z-axis packet
received\n");
+#endif
}
}
if (pMse->negativeW == MSE_NOAXISMAP)
--
Pigeon
Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/
GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
signature.asc
Description: Digital signature
Bug#454546: Mouse wheel mapping randomly fails with "(II) Mouse autoprobe: Disabling secondary wheel"
Package: xorg Version: 1:7.1.0-19 After the X server has been up for some random amount of time the scroll wheel mapping on my two-wheel mouse (Trust AmiTrack trackball configured using ExplorerPS2 protocol - same thing happens using IMPS2) goes to cock. The vertical wheel becomes a horizontal wheel and the horizontal wheel becomes a double-spacing horizontal wheel. This often, but not invariably, happens when scrolling a page in the browser that has not fully loaded and the browser is chugging while it loads and not responding immediately to scroll events. Sometimes it happens after X has been up only a few minutes. Sometimes it takes several days at the same level of activity before it happens. The only cure is to restart X - and with it all the applications - major PITA. Restarting gpm, or unplugging and replugging the mouse, does nothing. When it happens the following message appears in Xorg.0.log: (II) Mouse autoprobe: Disabling secondary wheel xorg.conf mouse section reads: Section "InputDevice" # Identifier and driver Identifier "Mouse1" Driver "mouse" #Option "Protocol""IMPS/2" Option "Protocol""ExplorerPS/2" #Option "Protocol""auto" #Option "Device" "/dev/psaux" Option "Device" "/dev/gpmdata" Option "Buttons""7" Option "ZAxisMapping" "6 7 5 4" Option "Emulate3Buttons" "off" EndSection As you can see I have tried various protocol options, and have tried reading direct vs. reading via gpm -Rraw; with the latter I have tried the same protocol options in gpm. The behaviour is the same in all cases. I still get the "autoprobe" log message even when not using "Protocol" "auto". Mouse uses PS/2 port, kernel is custom 2.6.10. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#445120: Upgrade to etch breaks Mustek parallel port scanners
Package: libsane Version: 1.0.18-5 The version of /etc/sane.d/dll.conf supplied with this package has the mustek_pp backend commented out. The result is that on upgrading my sarge box to etch, my Mustek parallel port scanner was no longer usable. Uncommenting the line cured the problem. It is a quick and easy problem to solve, but it should not need to be solved in the first place. The same problem may apply to other makes of scanner as there are a few other random backends also commented out. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#294378: Evolution: Bug #294378
4-1 libcamel1.2-10 1.10.2-2 libdbus-1-3 1.1.1-1 libdbus-glib-1-20.73-2 libebook1.2-9 1.10.2-2 libecal1.2-71.10.2-2 libedataserver1.2-9 1.10.2-2 libedataserverui1.2-8 1.10.2-2 libegroupwise1.2-13 1.10.2-2 libexchange-storage1.2-31.10.2-2 libfontconfig1 2.4.2-1.2 libfreetype62.2.1-5 libgconf2-4 2.16.1-1 libglade2-0 2.6.1-1 libglib2.0-02.12.11-3 libgnome2-0 2.18.0-4 libgnomecanvas2-0 2.14.0-2 libgnome-keyring0 0.8.1-2 libgnome-pilot2 2.0.15-2 libgnomeprint2.2-0 2.18.0-2 libgnomeprintui2.2-02.18.0-2 libgnomeui-02.18.1-2 libgnomevfs2-0 2.18.1-2 libgnutls13 1.6.3-1 libgtk2.0-0 2.10.13-1 libgtkhtml3.14-19 3.14.2-1 libhal1 0.5.9.1-2 libice6 1.0.3-2 libldap22.1.30-13.4 libnm-glib0 0.6.4-7 libnotify1 0.4.4-3 libnspr4-0d 4.6.6-3 libnss3-0d 3.11.5-3 liborbit2 2.14.7-0.1 libpango1.0-0 1.16.4-1 libpisock9 0.12.2-9 libpisync0 0.12.2-9 libpng12-0 1.2.15~beta5-1 libpopt01.10-3 libsm6 1.0.2-2 libsoup2.2-82.2.100-1 libx11-61.0.3-7 libxcursor1 1.1.7-4 libxext61.0.1-2 libxfixes3 4.0.1-5 libxi6 1.0.1-4 libxinerama11.0.1-4.1 libxml2 2.6.29.dfsg-1 libxrandr2 1.2.1-1 libxrender1 0.9.1-3 zlib1g 1.2.3-13 Thanks. Pigeon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426873: jed: no "cancel" option when accidentally exiting
Package: jed Version: 0.99.18-8.etch.4 Severity: wishlist When one selects the "exit" option from jed without having first saved the buffer, a prompt appears offering the option of saving the file or not saving it. So far so good... But if the selection of the "exit" option was the result of accidentally pressing the wrong key, this prompt is not fully appropriate. It lacks a "cancel" option, so there is no way to recover from one's mistake without exiting the editor (and saving the file) then firing up the editor again. This is especially annoying when using jed to compose emails from mutt. I request that the "save file y/n" exit prompt should be altered to "y/n/cancel", with the "cancel" option returning you to the editor. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#426068: chkrootkit gives false positive with iceweasel
Package: chkrootkit Varsion: 0.47-1.1 Package: iceweasel Version: 2.0.0.3-1 iceweasel creates the file /usr/lib/iceweasel/.autoreg which is picked up by chkrootkit as a false positive. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#423889: imagemagick documentation highly suboptimal
Package: imagemagick Version: 7:6.2.4.5.dfsg1-0.14 There is essentially no documentation for this package either in plain text or manpage format. The only documentation provided is in HTML, which is frankly a complete pain. Furthermore the HTML documentation is less complete than the manpages provided with older versions of this package, necessitating considerably more experimentation to figure out the correct option/argument format to get the desired effect. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#392521: syslog-summary nukes dates and PIDs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: syslog-summary Version: 1.12 When syslog-summary is run on a syslog file it nukes the dates and PIDs from the log entries, as in the following example: Raw log fragment: Oct 11 07:36:48 nestie syslogd 1.4.1#10: restart. Oct 11 07:36:48 nestie anacron[16978]: Job `cron.daily' terminated (exit status: 1) (mailing output) Oct 11 07:37:04 nestie identd[17356]: started Oct 11 07:37:04 nestie anacron[16978]: Normal exit (1 jobs run) Oct 11 07:38:02 nestie /USR/SBIN/CRON[17384]: (mail) CMD ( if [ -x /usr/sbin/exim -a -f /etc/exim/exim.conf ]; then /usr/sbin/exim -q ; fi) Oct 11 07:39:01 nestie /USR/SBIN/CRON[17402]: (pigeon) CMD (ping -c 4 195.40.1.36 > /dev/null 2>&1 || ssh stunted 'touch /tmp/pingdontwork'^I) Oct 11 07:40:01 nestie /USR/SBIN/CRON[17417]: (pigeon) CMD (/home/pigeon/bin/fprcpics 2>/dev/null) Oct 11 07:45:01 nestie /USR/SBIN/CRON[17504]: (root) CMD (/root/bin/update-resolv.conf) Oct 11 07:50:01 nestie /USR/SBIN/CRON[17570]: (pigeon) CMD (/home/pigeon/bin/fprcpics 2>/dev/null) Oct 11 07:51:54 nestie dhttpd[17621]: Request from 70.34.169.178: GET /pigeons_nest_website_images/quantum-weirdness.png HTTP/1.1 Oct 11 07:51:54 nestie dhttpd[17621]: File: /var/www/pigeons_nest_website_images/quantum-weirdness.png Oct 11 07:51:54 nestie dhttpd[17621]: Status: 0 (OK) Oct 11 07:51:54 nestie dhttpd[17621]: Referer: http://pigeon.dyndns.org/stuff/macroscopic-quantum-phenomena.html Oct 11 07:51:54 nestie dhttpd[17621]: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Output of "syslog-summary fragment": Summarizing syslog 0 Lines skipped (already processed) 0 Patterns to ignore 0 Ignored lines 1 nestie syslogd 1.4.1#10: restart. 1 nestie anacron: Job `cron.daily' terminated (exit status: 1) (mailing output) 1 nestie identd: started 1 nestie anacron: Normal exit (1 jobs run) 1 nestie /USR/SBIN/CRON: (mail) CMD ( if [ -x /usr/sbin/exim -a -f /etc/exim/exim.conf ]; then /usr/sbin/exim -q ; fi) 1 nestie /USR/SBIN/CRON: (pigeon) CMD (ping -c 4 195.40.1.36 > /dev/null 2>&1 || ssh stunted 'touch /tmp/pingdontwork'^I) 2 nestie /USR/SBIN/CRON: (pigeon) CMD (/home/pigeon/bin/fprcpics 2>/dev/null) 1 nestie /USR/SBIN/CRON: (root) CMD (/root/bin/update-resolv.conf) 1 nestie dhttpd: Request from 70.34.169.178: GET /pigeons_nest_website_images/quantum-weirdness.png HTTP/1.1 1 nestie dhttpd: File: /var/www/pigeons_nest_website_images/quantum-weirdness.png 1 nestie dhttpd: Status: 0 (OK) 1 nestie dhttpd: Referer: http://pigeon.dyndns.org/stuff/macroscopic-quantum-phenomena.html 1 nestie dhttpd: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) This behaviour makes analysis of the log file a somewhat futile process. It is the behaviour seen when SYSLOGSUMMARY=1 is set in /etc/logcheck/logcheck.conf for default installations of logcheck and syslog-summary. Versions of packages syslog-summary depends on: python2.2: 2.2.3dfsg-2sarge1 Other information: libc6: 2.3.2.ds1-22sarge3 Kernel: Linux schnellbox 2.6.16schnellbox.raid.highmem.acpischnellbox.raid.highmem.acpi #1 PREEMPT Sun May 28 15:50:52 BST 2006 i686 GNU/Linux - -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFLaa7UxADjyHGH38RApNQAJ4rUD8DQgaqjMOxvIhs2aiAAt0fIwCgnz0C aGY4iCNTu34GYxhH0dyhsYc= =lIv8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392520: syslog-summary nukes dates and PIDs
Package: syslog-summary Version: 1.12 When syslog-summary is run on a syslog file it nukes the dates and PIDs from the log entries, as in the following example: Raw log fragment: Oct 11 07:36:48 nestie syslogd 1.4.1#10: restart. Oct 11 07:36:48 nestie anacron[16978]: Job `cron.daily' terminated (exit status: 1) (mailing output) Oct 11 07:37:04 nestie identd[17356]: started Oct 11 07:37:04 nestie anacron[16978]: Normal exit (1 jobs run) Oct 11 07:38:02 nestie /USR/SBIN/CRON[17384]: (mail) CMD ( if [ -x /usr/sbin/exim -a -f /etc/exim/exim.conf ]; then /usr/sbin/exim -q ; fi) Oct 11 07:39:01 nestie /USR/SBIN/CRON[17402]: (pigeon) CMD (ping -c 4 195.40.1.36 > /dev/null 2>&1 || ssh stunted 'touch /tmp/pingdontwork'^I) Oct 11 07:40:01 nestie /USR/SBIN/CRON[17417]: (pigeon) CMD (/home/pigeon/bin/fprcpics 2>/dev/null) Oct 11 07:45:01 nestie /USR/SBIN/CRON[17504]: (root) CMD (/root/bin/update-resolv.conf) Oct 11 07:50:01 nestie /USR/SBIN/CRON[17570]: (pigeon) CMD (/home/pigeon/bin/fprcpics 2>/dev/null) Oct 11 07:51:54 nestie dhttpd[17621]: Request from 70.34.169.178: GET /pigeons_nest_website_images/quantum-weirdness.png HTTP/1.1 Oct 11 07:51:54 nestie dhttpd[17621]: File: /var/www/pigeons_nest_website_images/quantum-weirdness.png Oct 11 07:51:54 nestie dhttpd[17621]: Status: 0 (OK) Oct 11 07:51:54 nestie dhttpd[17621]: Referer: http://pigeon.dyndns.org/stuff/macroscopic-quantum-phenomena.html Oct 11 07:51:54 nestie dhttpd[17621]: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) After processing through syslog-summary: Summarizing syslog 0 Lines skipped (already processed) 0 Patterns to ignore 0 Ignored lines 1 nestie syslogd 1.4.1#10: restart. 1 nestie anacron: Job `cron.daily' terminated (exit status: 1) (mailing output) 1 nestie identd: started 1 nestie anacron: Normal exit (1 jobs run) 1 nestie /USR/SBIN/CRON: (mail) CMD ( if [ -x /usr/sbin/exim -a -f /etc/exim/exim.conf ]; then /usr/sbin/exim -q ; fi) 1 nestie /USR/SBIN/CRON: (pigeon) CMD (ping -c 4 195.40.1.36 > /dev/null 2>&1 || ssh stunted 'touch /tmp/pingdontwork'^I) 2 nestie /USR/SBIN/CRON: (pigeon) CMD (/home/pigeon/bin/fprcpics 2>/dev/null) 1 nestie /USR/SBIN/CRON: (root) CMD (/root/bin/update-resolv.conf) 1 nestie dhttpd: Request from 70.34.169.178: GET /pigeons_nest_website_images/quantum-weirdness.png HTTP/1.1 1 nestie dhttpd: File: /var/www/pigeons_nest_website_images/quantum-weirdness.png 1 nestie dhttpd: Status: 0 (OK) 1 nestie dhttpd: Referer: http://pigeon.dyndns.org/stuff/macroscopic-quantum-phenomena.html 1 nestie dhttpd: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) This behaviour makes analysis of the log file a somewhat futile process. -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#372719: Freetype and OpenOffice
A similar problem occurs with openoffice 1.1.3 in sarge although in this case the crash occurs not when saving a file but when launching the application. Again, downgrading to libfreetype6_2.1.7-2.4 solved the problem, as did upgrading to libfreetype6_2.1.7-3. -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#377154: tcpd fails to exec imap-login when running dovecot from inetd
On Mon, Jul 10, 2006 at 06:55:56PM +0200, Marco d'Itri wrote:
> On Jul 10, Pigeon <[EMAIL PROTECTED]> wrote:
>
> > In the case of dovecot, the daemon responding to the incoming imap
> > (or pop3) connection is named "imap-login" (or "pop3-login").
> > Therefore, unless the entries in /etc/hosts.{allow,deny} use the
> > daemon name "imap-login" instead of the obvious "imap" or "imap2" that
> > one might deduce from reading /etc/services, they will not match the
> > daemon name provided by tcpd.c.
>
> Right, I should have tought about this...
> Now I feel bad because you spent all this time working on a patch I
> cannot accept.
Don't worry, I quite enjoyed doing it :-) and it didn't significantly
affect the server setup project since there's a fair bit more still to
do on that with other stuff.
> Overloading the process name to also be a port name is
> unacceptable because it may change existing configurations.
I figured that was only likely to be a problem if it ceased to accept
the process name and only used the port name, which isn't how I've
done it. But no matter, I accept what you say.
> OTOH the feature you are proposing may be interesting, so I suggest you
> try again with a new patch which only consider port numbers and not
> symbolic names. Hopefully it will also be much less intrusive.
As in, the entries in /etc/hosts.{allow,deny} may be port numbers
instead of process names? OK, shouldn't involve much more than
taking most of the code out of my existing patch :-) I'll get onto
it later tonight.
> BTW, the correct way to work on a DBS package after unpacking it is
> like:
>
> ./debian/rules unpack
>
> ./debian/rules diff
>
> Then move your patch to debian/patches/ and clean+unpack again.
Thanks!
> > Now, there is much generic Linux documentation on the net that says
> > that the daemon names in /etc/hosts.{allow,deny} should correspond to
> > those in /etc/services. Certainly the dovecot wiki entry I referred to
>
> There is a lot of stupid and broken Linux documentation around.
> hosts_access(5) is very clear about this.
It is clear, but not, I suggest, so clear that it cannot be
misinterpreted.
hosts_access(5) says "_daemon_ is the process name of a network daemon
process... Network daemon process names are specified in the inetd
configuration file". As indeed they are, and are reported by ps.
However, if someone reading this doesn't fully understand it and
refers to inetd.conf(5) for clarification, they may be further confused,
as inetd.conf(5) does not name any of the fields "process name". The
relevant field is, for a tcpd-wrapped service, "server program
arguments", but the field that "looks most like" "process name" is
"service name", defined lower down as "the name of a valid service in
the file /etc/services". So if you don't read with sufficient care it
looks as if "_daemon_" ought to be a service name from /etc/services.
Perhaps this is how the writers of the aforementioned broken
documentation got confused? I'll clarify the man page and include that
in my patch.
> > But there is nothing in the Debian changelogs to indicate that support
> > for /etc/services has been removed from the Debian package for any
> > reason - no indication as to why the Debian package doesn't behave as
> > the generic, non-Debian-specific information suggests it might.
>
> Because there has never been such a behavior in the official
> tcp-wrappers package, nor I know about other distributions having
> modified it (and I check most of them from time to time).
...and as you have said above, that which suggests such a behaviour
might have been there is all wrong. Good to have that one cleared up!
--
Pigeon
Be kind to pigeons
Get my GPG key here:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
signature.asc
Description: Digital signature
Bug#377154: tcpd fails to exec imap-login when running dovecot from inetd
- if the secondary tarballs have already been unpacked then
"make" reports "Nothing to do for build.", with the result that
"fakeroot debian/rules build" only does something the first time you
run it. I confess that picking through nested complex Makefiles tends
to melt my brain, so my solution was perhaps not entirely elegant:
- Unpack the source (primary stage) with dpkg-source -x.
- cd to the source directory.
- Do an initial build of the unmodified package, which unpacks the
secondary tarballs and has the useful side effect of confirming that
everything's OK as regards building the unmodified package.
- Modify the source code.
- In debian/rules, comment out the dependency of "build" on "unpack",
so that "fakeroot debian/rules build" always builds the
already-unpacked package (but does not check it's unpacked first,
which doesn't matter in this particular case). This is the
modification referred to above.
- Run "fakeroot debian/rules build" to build the modified package.
- Run "fakeroot debian/rules binary-arch" to build the .debs.
This awkwardness makes me somewhat unsure how to submit my patch... I
can't submit it as a patch against the raw source tree of an unpacked
package because the "raw source tree" as produced by "dpkg-source -x"
doesn't have any source code in it, only secondary tarballs. So I've
submitted it as a patch that works in the "Modify the source code"
stage of the above-described procedure, along with a very minimal
script to automatically build a patched package. I would appreciate
some guidance on what I should have done :-)
--
Pigeon
Be kind to pigeons
Get my GPG key here:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
diff -Nru tcp-wrappers-7.6.dbs/build-tree/tcp_wrappers_7.6/hosts_access.3
tcp-wrappers-7.6.dbs.modified/build-tree/tcp_wrappers_7.6/hosts_access.3
--- tcp-wrappers-7.6.dbs/build-tree/tcp_wrappers_7.6/hosts_access.3
2006-07-10 05:11:05.0 +0100
+++ tcp-wrappers-7.6.dbs.modified/build-tree/tcp_wrappers_7.6/hosts_access.3
2006-07-10 04:19:12.0 +0100
@@ -57,6 +57,10 @@
The name of the daemon process running on the server host.
.IP "RQ_USER (char *)"
The name of the user on whose behalf the client host makes the request.
+.IP "RQ_SERVENT (struct servent *)"
+The daemon name and aliases associated with the server port and socket
+type (tcp or udp) as listed in /etc/services. This is filled in
+automatically if it is empty when hosts_access() is called.
.PP
hosts_access() consults the access control tables described in the
\fIhosts_access(5)\fR manual page. When internal endpoint information
diff -Nru tcp-wrappers-7.6.dbs/build-tree/tcp_wrappers_7.6/hosts_access.c
tcp-wrappers-7.6.dbs.modified/build-tree/tcp_wrappers_7.6/hosts_access.c
--- tcp-wrappers-7.6.dbs/build-tree/tcp_wrappers_7.6/hosts_access.c
2006-07-10 05:11:06.0 +0100
+++ tcp-wrappers-7.6.dbs.modified/build-tree/tcp_wrappers_7.6/hosts_access.c
2006-07-10 05:07:56.0 +0100
@@ -28,9 +28,9 @@
typedef uint32_t u_int32_t;
#endif
#include
-#ifdef INET6
+/*#ifdef INET6*/
#include
-#endif
+/*#endif*/
#include
#include
#include
@@ -39,9 +39,9 @@
#include
#include
#include
-#ifdef INET6
+/*#ifdef INET6*/
#include
-#endif
+/*#endif*/
extern char *fgets();
extern int errno;
@@ -125,13 +125,18 @@
if (resident <= 0)
resident++;
+
verdict = setjmp(tcpd_buf);
+
if (verdict != 0)
return (verdict == AC_PERMIT);
+
if (table_match(hosts_allow_table, request))
return (YES);
+
if (table_match(hosts_deny_table, request) == NO)
return (YES);
+
return (NO);
}
@@ -171,7 +176,7 @@
}
sh_cmd = split_at(cl_list, ':');
match = list_match(sv_list, request, server_match)
- && list_match(cl_list, request, client_match);
+ && list_match(cl_list, request, client_match);
}
(void) fclose(fp);
} else if (errno != ENOENT) {
@@ -223,6 +228,23 @@
return (NO);
}
+/* server_match_aliases - match ssrver information including
+ * daemon executable name, and service name and aliases from /etc/services */
+
+static int server_match_aliases(char *tok, struct request_info *request) {
+ int x;
+ int result;
+
+ result = string_match(tok, eval_daemon(request));
+ if (request->service_entry.s_name) {
+ result |= string_match(tok, request->service_entry.s_name);
+ for (x=0;request->service_entry.s_aliases[x];x++) {
+ result |= string_match(tok,
request->service_entry.s_aliases[x]);
+ }
+ }
+ return(result);
+}
+
/* server_match - match server information */
Bug#377154: tcpd fails to exec imap-login when running dovecot from inetd
Further information: I have discovered that while my workaround does
enable dovecot to be run from inetd the results are still slightly
unexpected. If the access permissions in /etc/hosts.{allow,deny} are
different for the imap and imaps services, the entry for imaps is
ignored, and the permissions for both services are controlled by the
entry for imap.
--
Pigeon
Be kind to pigeons
Get my GPG key here:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
signature.asc
Description: Digital signature
Bug#343723: Debian bug #343723 (dovecot / tcpwrappers)
On Fri, Jul 07, 2006 at 12:07:45PM -0400, Jaldhar H. Vyas wrote: > On Fri, 7 Jul 2006, Jari Aalto+mail.linux wrote: > > >| Hi, > >| > >| If you're trying to control access to dovecot through tcpwrappers may > >| I guess that you've also tried to run it from inetd and failed? If so > >| you may be interested in this workaround with which I have just > >| succeeded in getting it to run from inetd: > >| > >| http://pigeon.dyndns.org/stuff/sarge/dovecot-inetd.html > > > >Thank you for writing the inetd instrcutions. Jaldhar, would > >you add this to README.Debian as well > > Oh I just made an upload today but didn't see this in time. I'll add the > instructions in the next upload. See also bug #377154, my report on the tcpd bug (AFAICT) which prevents dovecot being run from inetd using "standard methods". -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
Bug#377154: tcpd fails to exec imap-login when running dovecot from inetd
On Fri, Jul 07, 2006 at 09:44:19AM +0200, Marco d'Itri wrote: > On Jul 07, Pigeon <[EMAIL PROTECTED]> wrote: > > > /etc/hosts.allow and /etc/hosts.deny are set to allow connections from > > 192.168.1.4, and they work as expected where other services are > > concerned. Connecting from localhost produces the same result. > Hard to believe. I thought the same :-) > Please show your complete and unedited configuration files. OK. These are what I've been testing with - they're rather more permissive than my eventual intention, to eliminate the possibility of the problem being due to me cocking something up :-) = ### BEGIN /etc/hosts.allow # /etc/hosts.allow: list of hosts that are allowed to access the system. # See the manual pages hosts_access(5), hosts_options(5) # and /usr/doc/netbase/portmapper.txt.gz # # Example:ALL: LOCAL @some_netgroup # ALL: .foobar.edu EXCEPT terminalserver.foobar.edu # # If you're going to protect the portmapper use the name "portmap" for the # daemon name. Remember that you can only use the keyword "ALL" and IP # addresses (NOT host or domain names) for the portmapper, as well as for # rpc.mountd (the NFS mount daemon). See portmap(8), rpc.mountd(8) and # /usr/share/doc/portmap/portmapper.txt.gz for further information. # imap: ALL imaps: ALL portmap: 127.0.0.1 sshd: ALL smtp: ALL ### END /etc/hosts.allow = ### BEGIN /etc/hosts.deny # /etc/hosts.deny: list of hosts that are _not_ allowed to access the system. # See the manual pages hosts_access(5), hosts_options(5) # and /usr/doc/netbase/portmapper.txt.gz # # Example:ALL: some.host.name, .some.domain # ALL EXCEPT in.fingerd: other.host.name, .other.domain # # If you're going to protect the portmapper use the name "portmap" for the # daemon name. Remember that you can only use the keyword "ALL" and IP # addresses (NOT host or domain names) for the portmapper. See portmap(8) # and /usr/doc/portmap/portmapper.txt.gz for further information. # # The PARANOID wildcard matches any host whose name does not match its # address. # You may wish to enable this to ensure any programs that don't # validate looked up hostnames still leave understandable logs. In past # versions of Debian this has been the default. # ALL: PARANOID ALL: ALL ### END /etc/hosts.deny = ### BEGIN /etc/inetd.conf (not working) # /etc/inetd.conf: see inetd(8) for further informations. # # Internet server configuration database # # # Lines starting with "#:LABEL:" or "##" should not # be changed unless you know what you are doing! # # If you want to disable an entry so it isn't touched during # package updates just comment it out with a single '#' character. # # Packages should modify this file by using update-inetd(8) # # # #:INTERNAL: Internal services #echo stream tcp nowait rootinternal #echo dgram udp waitrootinternal #chargenstream tcp nowait rootinternal #chargendgram udp waitrootinternal #discardstream tcp nowait rootinternal #discarddgram udp waitrootinternal #daytimestream tcp nowait rootinternal #daytimedgram udp waitrootinternal #time stream tcp nowait rootinternal #time dgram udp waitrootinternal #:STANDARD: These are standard services. #:BSD: Shell, login, exec and talk are BSD protocols. #:MAIL: Mail, news and uucp services. imapstream tcp nowait root/usr/sbin/tcpd /usr/lib/dovecot/imap-login imaps stream tcp nowait root/usr/sbin/tcpd /usr/lib/dovecot/imap-login --ssl #:INFO: Info services #:BOOT: Tftp service is provided primarily for booting. Most sites # run this only on machines acting as "boot servers." #:RPC: RPC based services #:HAM-RADIO: amateur-radio services #:OTHER: Other services ### END /etc/inetd.conf (not working) = ### BEGIN /etc/inetd.conf (working) # /etc/inetd.conf: see inetd(8) for further informations. # # Internet server configuration database # # # Lines starting with "#:LABEL:" or "##" should not # be changed unless you know what you are doing! # # If you want to disable an entry so it isn't touched during # package updates just comment it out with a single '#' character. # # Packages should modify this file by using update-inetd(8) # # # #:INTERNAL: Internal services #echo stream tcp
Bug#377154: tcpd fails to exec imap-login when running dovecot from inetd
Package:tcpd Version: 7.6.dbs-8 When running dovecot-imapd from inetd, tcpd fails to exec the imap-login binary, although "ps ax" suggests otherwise. The dovecot man page suggests that it is possible to run dovecot from inetd, and the dovecot wiki <http://wiki.dovecot.org/InetdInstall> gives an appropriate entry for /etc/inetd.conf (edited to reflect the file locations in Debian): imap stream tcp nowait root/usr/sbin/tcpd /usr/lib/dovecot/imap-login imaps stream tcp nowait root/usr/sbin/tcpd /usr/lib/dovecot/imap-login --ssl Unfortunately this doesn't work. I can telnet to port 143, telnet connects OK, and "ps axf" on the server shows that /usr/lib/dovecot/imap-login has been started in response to the incoming connection. I then see a line like localhost imap-login[2820]: refused connect from 192.168.1.4 (192.168.1.4) appear in /var/log/syslog, and the telnet session dies with Connection closed by foreign host. /etc/hosts.allow and /etc/hosts.deny are set to allow connections from 192.168.1.4, and they work as expected where other services are concerned. Connecting from localhost produces the same result. The "sledgehammer" experiment of deleting the imap-login binary gives the incredible result that no change in the behaviour is observed. "ps axf" on the server still shows that /usr/lib/dovecot/imap-login has been started in response to the incoming connection, even though the file no longer exists. !!! The less violent experiment of replacing /usr/lib/dovecot/imap-login with /usr/lib/dovecot/imap in /etc/inetd.conf provides the expected behaviour as far as the actual connection is concerned, but this of course bypasses the login process so the IMAP session is automatically logged in as root as soon as the connection is made - not exactly the desired behaviour. A workaround - which seems to be reasonably robust against breakage by package upgrades AFAICT - is to execute: mkdir /usr/local/lib/dovecot ln -s /usr/lib/dovecot/imap-login /usr/local/lib/dovecot/imap and edit the entries in /etc/inetd.conf accordingly: imap stream tcp nowait root/usr/sbin/tcpd /usr/local/lib/dovecot/imap imaps stream tcp nowait root/usr/sbin/tcpd /usr/local/lib/dovecot/imap --ssl This then gives the desired behaviour - logins to the IMAP server work, and access can be controlled using /etc/hosts.allow and /etc/hosts.deny. Kernel: Debian stock 2.4.27-3-686-smp libc6: 2.3.2.ds1-22sarge3 dovecot-imapd: 0.99.14-1sarge0 netkit-inetd: Version: 0.10-10 Hardware: Dell Poweredge 2450, 512K RAM, 2 x 733MHz PIII -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
