Bug#305618: Description formatting error
reassign 305618 file-roller thanks On Thu, Apr 21, 2005 at 11:05:31AM +0100, Martin Michlmayr wrote: > * Daniel Burrows <[EMAIL PROTECTED]> [2005-04-20 23:55]: > > The homepage and author name at the end of this package's description get > > word-wrapped together. You should probably either make them literally > > formatted, or place a paragraph separator between them (a line that just > > contains a full stop). > > This package doesn't seem to be in Debian? Missing hyphen; I've reassigned. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305840: bugs.debian.org: NMU fix should remove pending tag
On Fri, Apr 22, 2005 at 02:18:10PM +0200, Bastian Kleineidam wrote: > Package: bugs.debian.org > Severity: wishlist > > Hi, > > from the description of the "pending" tag it should be removed when > an uploaded package fixes the bug. This is not automatically the case > for non-maintainer uploads (NMUs). > So I'd wish a NMU which closes the bug (ie. sets it to "fixed in NMU") > would also remove any "pending" tag of the bug automatically. > Example: I did an NMU for fox1.2 closing bug #303327, and had to manually > remove the pending tag. I deliberately avoided this because it complicates some semantics (what if the maintainer wants the pending tag there? how do historical BTS analysers know when the pending tag was removed?) and because the long-term goal is to obsolete the fixed-in-NMU system by means of version tracking. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#207992: bugs: "damnit"
On Mon, Apr 25, 2005 at 09:20:48PM -0400, Justin Pryzby wrote: > Are there any bugs that presently experience this problem? Almost certainly yes. > Also, if the cause was just bug database corruption, then its not even > a bug (except in a .d.o filesystem, but I guess there is no pseudo pkg > for that). This bug happens when sendmail fails and debbugs doesn't clean up properly behind it, but instead leaves an empty log file. It's a legitimate bug and should be left open. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308577: partman: devices[index_of_name(name)] is unspecified
Package: partman Version: 64 Severity: important Tags: sarge, sid parted_server has many instances of this sort of code: return devices[index_of_name(name)].dev; However, index_of_name(name) can change the devices pointer, and according to the C standard the two subexpressions 'devices' and 'index_of_name(name)' may be evaluated in either order. Thus, the semantics of this code are unspecified, so the compiler is free to generate code that evaluates 'devices' first, when it's still NULL at parted_server startup. The practical upshot of this is that parted_server segfaults immediately on OPEN when compiled with gcc 4.0. I've fixed this in SVN trunk. I'm not prepared to bet that earlier versions of gcc will never generate code that evaluates 'devices' before 'index_of_name(name)', so I think we should backport this fix to sarge. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308538: Test whether two submitters actually work
On Wed, May 11, 2005 at 10:44:11AM +0200, Adrian Bunk wrote: > On Tue, May 10, 2005 at 11:01:45PM +0100, Martin Michlmayr wrote: > > Since you're at it, can you also check what happens when the > > submitter contain spaces. (i.e, > > Adrian Bunk <[EMAIL PROTECTED]>, Adrian Bunk <[EMAIL PROTECTED]>) > > They work surprisingly well, too. > > The only problem I've observed until now is that the "Reported by:" link > of the bug can't handle multiple submitters correctly. Good point, thanks. Fixed. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308538: Test whether two submitters actually work
On Wed, May 11, 2005 at 11:49:38AM +0200, Adrian Bunk wrote: > On Wed, May 11, 2005 at 10:41:56AM +0100, Colin Watson wrote: > > On Wed, May 11, 2005 at 10:44:11AM +0200, Adrian Bunk wrote: > > > They work surprisingly well, too. > > > > > > The only problem I've observed until now is that the "Reported by:" link > > > of the bug can't handle multiple submitters correctly. > > > > Good point, thanks. Fixed. > > Thanks for the quick fix. > > But the bug is listed at neither of the two submitters pages. > > It seems a handling of multiple submitters in a way that the bugs belong > to each of them (as it is similarily done with bugs against multiple > packages) is missing. Hmm, OK, I see. Should be fixed now. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290329: testing on PowerMac
FWIW, MODULES=dep works fine for me on my PowerBook. I think this change is probably worth it - we've had a number of issues in the past with large initrds on powerpc. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#230684: fdutils: Should use debconf to ask questions
tags 230684 patch thanks On Sun, Feb 01, 2004 at 10:59:41PM +0100, Petter Reinholdtsen wrote: > Package: fdutils > Version: 5.4-20030718-2 > Severity: wishlist > Tags: i18n > > When installing fdutils for the first time, it ask if fdmount should > be setuid root or not. It would be better if it asked using debconf, > to allow translations and automatic answering of the question using > pre-seeding of debconf answers. This patch implements this. I've left fdutilsconfig there for now, but you might like to consider removing it eventually. http://patches.ubuntu.com/patches/fdutils.230684.diff Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304332: cdebconf X_SETBACKTITLE command
On Tue, Apr 12, 2005 at 03:40:14PM -0400, Joey Hess wrote:
> Colin Watson wrote:
> > I wonder if it might also be worth implementing INFO with no arguments,
> > to clear the info and go back to blank (in the case of cdebconf) or
> > gettext("Debian Configuration") (in the case of debconf)?
>
> I think that's reasonable, but it should also be reset when deconf
> starts a new confmodule, as is currently done with the title. This will
> need to parallell the default_title calls that are currently in debconf,
> I haven't looked at cdebconf.
I've done this, and checked in the result.
I'm unconvinced about this resetting, though. Doesn't resetting it at
the same times as we reset the title defeat the ability to, say, set an
info message during an upgrade to say "System update"? I thought part of
the point of info messages was explicitly *not* to get reset when a new
confmodule connects.
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303284: debconf-utils: debconf-get-selections fails with 'Can't call method "description" on an undefined value'
On Tue, Apr 05, 2005 at 08:39:04PM +0100, Toby Speight wrote: > Package: debconf-utils > Version: 1.4.30.11 > Severity: important > > / > | $ debconf-get-selections >/dev/null > | debconf: DbDriver "passwords" warning: could not open > /var/cache/debconf/passwords.dat: Permission denied > | Can't call method "description" on an undefined value at > /usr/share/perl5/Debconf/Question.pm line 76. > \ > > The output (which I've here diverted to the null device) is truncated, > but I think the interesting information is which package would be next > to be written (that we don't get to see). > > It might be that something is amiss in the debconf database itself, > but it's wrong that this should cause the command to fail. > > I don't have much clue as to how to debug this; I tried single-stepping > in the Perl debugger, but that was slow and unproductive. We really > want to know where the undefined value came from. I'm happy to help > attack this bug, if I have some guidance as to how to approach it. It sounds like you have a template with no description. Could you please send a gzipped copy of /var/cache/debconf/templates.dat to this bug? Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303284: debconf-utils: debconf-get-selections fails with 'Can't call method "description" on an undefined value'
tags 303284 sarge thanks On Tue, May 17, 2005 at 06:32:08PM +0100, Toby Speight wrote: > I have one or two entries such as > > / > | Name: wbritish/languages > | Default: british (British English) > | Description: > | Type: text > | Owners: wbritish/languages > \ > > (there's a trailing space in the "Description: " line) No, it won't be those ones (empty's fine, I was thinking more of missing, of which there is one example, namely alsa-common/card-list). However, forget all that, because I misdiagnosed the problem by misreading the error message; it's the template that's undefined, not the description. This would suggest that you have some entries in config.dat that don't have entries matching their Template: value in templates.dat. By the rather crude method of binary-chopping through the repository with your templates.dat, I find that a fix went in for this in debconf 1.4.34: debconf (1.4.34) unstable; urgency=low * Skip questions with no known type also in debconf-get-selections. -- Joey Hess <[EMAIL PROTECTED]> Wed, 1 Sep 2004 01:25:20 -0400 This patch never got backported to the sarge branch. Joey, would it be a good idea to backport this fix? It looks pretty safe. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#188316: debconf: Missing dependency on python 2.2
On Wed, Apr 09, 2003 at 12:23:14PM -0400, Joey Hess wrote: > root wrote: > > when doing apt-get install debconf I get > > > > Richte debconf ein (1.2.34) ... > > python2.2: can't open file '/usr/lib/python2.2/compileall.py' > > > > Indeed I haven't installed python 2.2 yet. So debconf should depend on > > the appropriate python package. > > If you haven't installed python2.2 yet, then how come you have a > /usr/bin/python2.2 on your system? Debconf only runs the code if you > have python installed already. It will not depend on python. I think you fixed this in debhelper 4.2.13, on 6 July 2004: * dh_python: check to make sure compileall.py is available before running it in the postinst. Closes: #253112 Can this bug be closed? Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309603: dpkg-architecture thinks Linux is the Hurd
Package: dpkg-dev
Version: 1.13.4
Severity: important
Tags: experimental, patch
We had some fun with dpkg-architecture in Ubuntu this morning ...
09:12 * \sh checks why breezy morphes into hurd
09:12 < \sh> -rw-r--r-- 1 shermann shermann 2688 May 18 08:08
libqssl-dev_2.0-1ubuntu1_hurd-i386.deb
09:12 < \sh> -rw-r--r-- 1 shermann shermann 2154 May 18 08:08
libqssl2_2.0-1ubuntu1_hurd-i386.deb
09:31 < Kamion> \sh: try 'dpkg-architecture -qDEB_HOST_ARCH'?
09:31 < \sh> hmm
09:31 < \sh> hurd-i386 *g*
Turns out that dpkg-architecture iterates through cputable and ostable
in whatever order the regexes happen to come out of the %cputable_re and
%ostable_re hashes. In practice the first one is always /gnu[^-]*/, and
since the first gcc-4.0 upload to Ubuntu after we synced dpkg_1.13.4
picked up the change to DEB_HOST_GNU_TYPE and started to spit out
*-linux-gnu in 'gcc -dumpmachine', /gnu[^-]*/ always matches on Linux.
I fixed this using the following patch (I can't seem to get to your arch
archive right now):
diff -Nru /tmp/v5aZgEH5oq/dpkg-1.13.4/debian/changelog
/tmp/N2URRIKZ1E/dpkg-1.13.4ubuntu1/debian/changelog
--- /tmp/v5aZgEH5oq/dpkg-1.13.4/debian/changelog2005-03-29
13:36:52.0 +0100
+++ /tmp/N2URRIKZ1E/dpkg-1.13.4ubuntu1/debian/changelog 2005-05-18
10:08:38.0 +0100
@@ -1,3 +1,11 @@
+dpkg (1.13.4ubuntu1) breezy; urgency=high
+
+ * dpkg-architecture iterates through cputable and ostable config.guess
+regexes in the order in which they appear in the file, to avoid matching
+the Hurd on Linux.
+
+ -- Colin Watson <[EMAIL PROTECTED]> Wed, 18 May 2005 10:08:36 +0100
+
dpkg (1.13.4) experimental; urgency=low
The "Or the Wabbit gets it" Release
diff -Nru /tmp/v5aZgEH5oq/dpkg-1.13.4/scripts/dpkg-architecture.pl
/tmp/N2URRIKZ1E/dpkg-1.13.4ubuntu1/scripts/dpkg-architecture.pl
--- /tmp/v5aZgEH5oq/dpkg-1.13.4/scripts/dpkg-architecture.pl2005-03-29
13:29:32.0 +0100
+++ /tmp/N2URRIKZ1E/dpkg-1.13.4ubuntu1/scripts/dpkg-architecture.pl
2005-05-18 10:06:33.0 +0100
@@ -109,14 +109,14 @@
local ($a);
local ($gnu_cpu, $gnu_os) = &split_gnu($gnu);
-foreach $a (keys %cputable_re) {
+foreach $a (@cpu) {
if ($gnu_cpu =~ /^$cputable_re{$a}$/) {
$cpu = $a;
last;
}
}
-foreach $a (keys %ostable_re) {
+foreach $a (@os) {
if ($gnu_os =~ /^(.*-)?$ostable_re{$a}$/) {
$os = $a;
last;
cputable probably didn't need to be changed since it's fully anchored,
unlike ostable which is only partially anchored, but I did it anyway for
symmetry.
However, you should probably also reorder ostable so that the least
specific regexes are last, otherwise this will cause dpkg-architecture
to think that both KFreeBSD and KNetBSD are the Hurd. Moving hurd after
kfreebsd and knetbsd would be sufficient.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309889: debian-installer-manual: document "--" kernel parameter trick
Package: debian-installer-manual Severity: wishlist The trick used by d-i whereby kernel parameters that appear after "--" are copied into the installed bootloader configuration should be documented somewhere for the benefit of people doing automatic installations. It just works for people doing normal installations, but when you're preseeding you need to know about it so that you can put kernel parameters in the right place. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284081: New parted api, and possibility for parted 1.6.x (x>12) in debian/sarge ...
On Fri, Dec 03, 2004 at 12:40:32PM +, Colin Watson wrote: > Here's a patch that updates python-parted to the new libparted API > (written on work time for Canonical): > > http://people.ubuntulinux.org/patches/python-parted.new-libparted.diff This URL seems to have broken. A working URL is: http://patches.ubuntulinux.org/patches/python-parted.new-libparted.diff -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292781: libparted1.6-udeb Provides: field is incorrect (doesn't match shlibs)
Package: libparted1.6-udeb Version: 1.6.20-1 Severity: serious $ cat /var/lib/dpkg/info/libparted1.6-12.shlibs libparted-1.6 12 libparted1.6-12 (>= 1.6.0) $ dpkg -f libparted1.6-udeb_1.6.20-1_powerpc.udeb Package: libparted1.6-udeb Version: 1.6.20-1 [...] Provides: libparted Older versions of libparted1.6-udeb used to provide libparted1.6-0. Not providing the package name listed in the .shlibs file breaks dependency checking in debian-installer (although there are various workarounds). Note that this was previously reported as #239334; the bug has reappeared. Perhaps you could have a look at how it was fixed last time, and do that again? Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281734: parted: doesn't calculate partition paths correctly when using udev with devfs rules
On Sun, Jan 30, 2005 at 07:35:03AM +0100, Sven Luther wrote: > On Wed, Nov 17, 2004 at 03:21:04PM +0000, Colin Watson wrote: > > On Wed, Nov 17, 2004 at 04:15:18PM +0100, Sven Luther wrote: > > > On Wed, Nov 17, 2004 at 03:00:04PM +, Colin Watson wrote: > > > > http://people.ubuntulinux.org/patches/parted-udev-devfs-rules.patch > > Arg, this patch has dissapeared from there, i suppose i could find it in the > ubuntu parted packages, but it is non-obvious to me yet how to find it. http://patches.ubuntulinux.org/patches/parted-udev-devfs-rules.patch Sorry about that. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281734: parted: doesn't calculate partition paths correctly when using udev with devfs rules
On Sun, Jan 30, 2005 at 12:42:04PM +, Colin Watson wrote: > On Sun, Jan 30, 2005 at 07:35:03AM +0100, Sven Luther wrote: > > On Wed, Nov 17, 2004 at 03:21:04PM +0000, Colin Watson wrote: > > > On Wed, Nov 17, 2004 at 04:15:18PM +0100, Sven Luther wrote: > > > > On Wed, Nov 17, 2004 at 03:00:04PM +, Colin Watson wrote: > > > > > http://people.ubuntulinux.org/patches/parted-udev-devfs-rules.patch > > > > Arg, this patch has dissapeared from there, i suppose i could find it in the > > ubuntu parted packages, but it is non-obvious to me yet how to find it. > > http://patches.ubuntulinux.org/patches/parted-udev-devfs-rules.patch The old URL has been fixed now, too. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#258331: base-installer: kernel choosing probably broken on m68k
tags 258331 fixed-in-experimental thanks On Mon, Jul 05, 2004 at 11:46:03PM +0100, Rob Bradford wrote: > Package: base-installer > Severity: normal > > Just from inspection of the debian/postinst file it appears that the m68k > kernel choosing code is incomplete, possibly as a stub, compared to other > archs' > > i.e. > > m68k) > case "$SUBARCH" in > amiga|atari|mac|bvme6000|mvme147|mvme16x|q40|sun3|sun3x) > trykernel=$SUBARCH ;; > *) warning "Unknown $ARCH subarchitecture '$SUBARCH'." ;; > esac > ;; This should be much better in the experimental branch of base-installer, from version 1.14 onwards. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292989: debconf: passthrough frontend turns SETTITLE into TITLE, producing warnings
Package: debconf Version: 1.4.42 Severity: minor I'm not sure if this is necessarily a bug, but it's a bit ugly: Jan 31 15:42:57 debconf: Obsolete command TITLE called Jan 31 15:42:57 debconf: Obsolete command TITLE Apt configuration called This is from running apt-setup in a chroot using the passthrough frontend, with cdebconf as the real frontend. The first warning is from Debconf::FrontEnd::init(), and the second from using db_settitle. I can see that the first warning might be unavoidable; maybe we could make cdebconf only warn on TITLE when it has a non-empty argument, or something. For the second, though, I think passthrough could use SETTITLE instead. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292989: debconf: passthrough frontend turns SETTITLE into TITLE, producing warnings
On Thu, Feb 03, 2005 at 09:19:05PM -0500, Joey Hess wrote: > Colin Watson wrote: > > I'm not sure if this is necessarily a bug, but it's a bit ugly: > > > > Jan 31 15:42:57 debconf: Obsolete command TITLE called > > Jan 31 15:42:57 debconf: Obsolete command TITLE Apt configuration called > > > > This is from running apt-setup in a chroot using the passthrough > > frontend, with cdebconf as the real frontend. The first warning is from > > Debconf::FrontEnd::init(), and the second from using db_settitle. > > > > I can see that the first warning might be unavoidable; maybe we could > > make cdebconf only warn on TITLE when it has a non-empty argument, or > > something. For the second, though, I think passthrough could use > > SETTITLE instead. > > IIRC the reason we have a deprecation warning in cdebconf about TITLE is > because we wanted to catch titles that were not localised in d-i. But it > is possible to use TITLE outside d-i and localise it -- as debconf does, > for example. True. > To make passthrough use SETTITLE we'd have to make it create a fake > template or pretend there was one for subsequent DATA commands. This > seems overly-complicated. I would agree if the client were using TITLE, but in this case it isn't; it's apt-setup doing 'db_settitle apt-setup/title'. Why would debconf need to create a fake template when the client is already using SETTITLE? Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289352: Debian Bugs information: logs for Bug#289352
[The previous message went to [EMAIL PROTECTED] by mistake, rather than the individual bug. However, since I happened to see it as a result, I'll reply ...] On Fri, Feb 04, 2005 at 10:55:32AM -0500, David A. Desrosiers wrote: > Dan Jacobson wrote: > > Package: pilot-link > > Version: 0.11.8-10 > > Severity: minor > > File: /usr/share/man/man1/read-notepad.1.gz > > > > The NAME field is overloaded, messing up e.g., apropos(1). > > Also don't mention install-expenses. > > "NAME" is a perfectly valid nroff keyword (see > 'man/man1/ls.1.gz' or 'man/man1/gcc.1.gz' for two good examples of > this usage. "NAME" isn't an nroff keyword in any particularly meaningful sense; about the closest nroff has to keywords are "requests" like .ft and .ig. In fact, "NAME" isn't interpreted by nroff itself except as a perfectly normal string of characters. "NAME" is a conventional string used in .SH headers in man pages (or .Sh, when using groff_mdoc(7)) to indicate the name and short description that whatis(1) and apropos(1) should display about each man page. > read-notepad will still contain the "NAME" keyword, as per the > manpage and nroff specification. We are now generating manpages from > XML sources via docbook transformation. If this is a bug in the nroff > output, the bug must be filed there. The existence of the NAME section in read-notepad(1) is correct, and I don't think there's anything wrong with the way it was converted from DocBook. However, its contents are unconventional for a NAME section; in order to produce good whatis(1) and apropos(1) output, those sections should consist of the program's name, "\-", and a one-line description of the program. At present, 'whatis read-notepad' looks like this: read-notepad (1) - Connect to the Palm handheld and list the record information found in the Palm Notepad application (found on OS4 and newer devices). Alternately, if no options are given, each record's image will be converted to files, using Portable Network Graphic (.png) or Portable Pixmap (.ppm) format. The default type is ppm. Viewed on a traditional 80-column terminal, this is suboptimal. Conventional output is more like this: man (1) - an interface to the on-line reference manuals I suggest that read-notepad's NAME section should read something like this when formatted into nroff: \fBread\-notepad\fR \- read information from the Palm Notepad application ... and that the more extended description of its behaviour currently found in the NAME section should be moved to the DESCRIPTION section. Cheers, -- Colin Watson [EMAIL PROTECTED] Debian groff and man-db maintainer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293722: grub: simulated stack not marked PROT_EXEC, causes segfaults on new hardware
Package: grub
Version: 0.95+cvs20040624-12
Severity: important
When using Linux 2.6.10, grub's 'install' command segfaults on new
hardware that has the NX bit available (e.g. AMD64, and I think also new
Pentium 4 systems). This turns out to be because:
* grub's Unix shell allocates a region of memory part of which is used
as a simulated stack;
* the 'install' command uses a nested function which causes GCC to
emit a stack trampoline requiring an executable stack;
* malloc()ed memory is only PROT_READ|PROT_WRITE by default;
* 2.6.10 sets noexec=on by default, thereby assuming that pages
without PROT_EXEC set can be treated as non-executable, and this is
enforced on hardware with the NX bit available.
The attached patch corrects this problem (tested), and I believe should
be harmless on older systems. Please apply. Most of it came from the
mprotect() man page and/or is probably too obvious/short to be
copyrightable, but if I need to sign an assignment to have this go
upstream then I'll be happy to do so.
Thanks,
--
Colin Watson [EMAIL PROTECTED]
--- grub-0.95+cvs20040624.orig/grub/asmstub.c
+++ grub-0.95+cvs20040624/grub/asmstub.c
@@ -42,6 +42,12 @@
#include
#include
#include
+#include
+
+#include
+#ifndef PAGESIZE
+#define PAGESIZE 4096
+#endif
#ifdef __linux__
# include /* ioctl */
@@ -142,6 +148,22 @@
assert (grub_scratch_mem == 0);
scratch = malloc (0x10 + EXTENDED_MEMSIZE + 15);
assert (scratch);
+
+ {
+char *p;
+int ret;
+
+/* Align to a multiple of PAGESIZE, assumed to be a power of two. */
+p = (char *) (((long) scratch) & ~(PAGESIZE - 1));
+
+/* The simulated stack needs to be executable, since GCC uses stack
+ * trampolines to implement nested functions.
+ */
+ret = mprotect (p, 0x10 + EXTENDED_MEMSIZE + 15,
+ PROT_READ | PROT_WRITE | PROT_EXEC);
+assert (ret == 0);
+ }
+
grub_scratch_mem = (char *) int) scratch) >> 4) << 4);
/* FIXME: simulate the memory holes using mprot, if available. */
Bug#212881: Noninteractive patch for cdebconf
On Sat, Feb 05, 2005 at 12:43:14AM -0500, Alex Mohr wrote: > Package: cdebconf > Version: 0.74 > Followup-For: Bug #212881 > > > I developed a patch to cdebconf that provides noninteractive support > for unattended installs. It automatically uses the default setting > for every question and is based on the text installer. I'll include > it below, but it's also available from > http://mnl.cs.sunysb.edu/~amohr/cdebconf-noninteractive-patch How does this differ from the 'none' frontend? (Serious question, I'm not sure.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#63909: base-files: Base Files does not ensure the utmp group exists before trying to use it
On Sun, Feb 06, 2005 at 02:11:32PM +0100, [EMAIL PROTECTED] wrote: > I don't understand why you ask not to create the utmp group > (maybe you don't by now, then this bug should be closed). > If the question was to avoid recreating the utmp group when > upgrading from another distribution than debian , there are ways > to test if hte group already exists, no need to ask the user. > the patch already submitted use grep , but getent passwd would > do fine too. > > > If there is a real need for this question , this bug should at > least be marked wontfix. No, the general issue in this bug (that packages rely on base-passwd to ensure that certain groups exist but that base-passwd might not create them if the user refuses) still exists and has not been solved. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306355: linux-image-2.6.10-5-k7-smp: fails to boot on udev system
On Tue, Apr 26, 2005 at 03:22:49AM +0300, Pasi Savolainen wrote: > Package: linux-image-2.6.10-5-k7-smp > Version: 2.6.10-34 > Severity: important This appears to be a bug report against an Ubuntu kernel. Please report those to Ubuntu, not Debian. Is there anything in particular that misled you into reporting this bug to Debian? If so, perhaps we could fix it. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302814: / a question about 'diff -u'
On Tue, Apr 05, 2005 at 03:40:44AM -0400, A. Costa wrote: > 4) After 'diff -u' it looks like: > > zdiff -u /usr/share/man/man1/bash.1.gz /tmp/bash.1.gz | nl > 1 --- - 2005-04-05 02:46:14.076698000 -0400 > 2 +++ /tmp/bash1.gz.12990 2005-04-05 02:46:14.070147316 -0400 > 3 @@ -5558,7 +5558,7 @@ > 4 semicolons where necessary to preserve syntactic correctness. > 5 The > 6 .B lithist > 7 -shell option causes the shell to save the command with embedded > newlines > 8 +swell shell option causes the shell to save the command with > embedded newlines > 9 instead of semicolons. See the description of the > 10 .B shopt > 11 builtin below under > 12 @@ -5568,7 +5568,7 @@ > 13 .SH "HISTORY EXPANSION" > 14 .PP > 15 The shell supports a history expansion feature that > 16 -is similar to the history expansion in > 17 +is so similar to the history expansion in > 18 .BR csh. > 19 This section describes what syntax features are available. This > 20 feature is enabled by default for interactive shells, and can be > > Longer! It's supposed to be longer. This is a feature. :-) > So, my question is about the 'FROM-FILE' and 'TO-FILE'. In my 'bash' > example, 'FROM-FILE' was "-", and 'TO-FILE' was "/tmp/bash1.gz". > Transient names. > > So I'm worrying if such transient local filenames are useful, or > harmful if they cause patching programs to look for files that don't > exist on a maintainer's system. They're useless in this case, but generally harmless. It's the job of 'patch' to figure out which files should be patched. If it can't figure it out, there are alternative ways of invoking 'patch' to make it do the right thing (you can give it an explicit file to patch). I would suggest generating patches using the source package, not the man page that happens to be installed on your system. Man pages are often generated automatically from other formats, and in that event the patch will have to be applied by hand anyway if you created it using the generated version. Patches against files in binary packages are only haphazardly useful at best. > Plain vanilla 'diff' seemed safer, and nobody complained until now, > though maybe they should have. They probably should have complained, yes. The lack of context in plain 'diff' makes it unsafe; if you send patches like that, they can easily end up patching the wrong lines. Plain 'diff' output is there for purposes other than sending patches to maintainers, and for historical reasons. I imagine most maintainers ended up applying your changes by hand, and your patches were small enough that it was less effort to just do that than to ask for patches that could be applied automatically. > Now IF it's possible to know what values of 'FROM-FILE' and 'TO-FILE' > are most harmless, or better yet, are most useful for maintainers, I'd > be glad to code that in to my man page typo bug report helper script > r the higher orthographic good! > > In a nutshell: What should 'FROM-FILE' and 'TO-FILE' be set to? As long as the basename (everything from the last / onwards) of one of those filenames, is the same as the file in the source package that the maintainer will want to patch, it's easy for maintainers to deal with it using well-known invocations of 'patch'. It's conventional to send patches such that they can be applied by a maintainer using 'patch -p0' or 'patch -p1' when standing in the top level of the source package. This generally involves either: * copying the original versions of some files in the source package to their original names plus ".orig", making your changes, changing to the top level of the source package, and then running 'diff -u foo/bar/baz.orig foo/bar/baz' or similar for each in turn (patch -p0); * copying the entire original source package to its original name plus ".orig", making your changes, changing to the parent directory of the source package, and then running 'diff -ru packagename-1.0.orig packagename-1.0' or similar (patch -p1). If you want to discuss this further, please remove [EMAIL PROTECTED] from the Cc: line. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302814: acknowledged by developer (Re: Bug#302814: 'man keytool' typos: "assocated", "inital" and "keytore")
On Tue, Apr 05, 2005 at 02:00:53AM -0400, A. Costa wrote: > On Mon, 04 Apr 2005 04:33:28 -0700 > [EMAIL PROTECTED] (Debian Bug Tracking System) wrote: > > j2re1.4 isn't part of Debian, so we can't accept bugs on it. Please send > > this to wherever you got the package. > > Never do I wish to spam the fine BTS. But what puzzles me is how > there's a BTS page for 'jre1.4'. That's because other people have reported bugs on j2re1.4, and the BTS obligingly indexes them. This is intentional: the BTS accepts bugs on unknown packages in order that humans can reassign them to the proper place, or close them, rather than having them rejected by a machine. This is generally friendlier to bug reporters, and reduces our chances of having useful bug reports lost due to (common) combinations of typos and mail delivery problems. > (Bear with me on my error trail...) The typos were not submitted. > Since the page existed, it logically followed that Debian ought to > accept bugs for any package the BTS has a slot for. The project accepts bugs for packages where a maintainer is listed. No maintainer is listed for j2re1.4; you can conclude from this that bugs reported against it will not go anywhere useful. > 1) Has this "ghost package" bug been submitted? I'm not even > sure where to look for it -- I'd appreciate if you could point > out where, if you know that it exists. It's not a bug. Please do not report it as such. > (BTW: a suggested fix -- have any current archive pages for packages > like this warn that they accept NO INPUT, and have the bug server > bounce any messages to foreign packages. Don't make any new pages > like this. But keep the old ones; deleting them from the archives > would make holes in the bug count. ) We made an intentional decision several years ago not to bounce bugs to unknown packages. However, I've changed pkgreport.cgi to print a helpful message when a package has no maintainer. I hope that helps. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302814: acknowledged by developer (not in Debian)
On Mon, May 02, 2005 at 04:48:06PM -0400, A. Costa wrote: > ..if you'd read that and followed its URLs, you'd find that I believe > this bug is a symptom of a larger bug -- where to report said big one > I'm not too sure -- so I'm complaining here, in hopes that its > maintainers or tenders will do their part and forward or clone the > greater bug to wherever it is that it ought to go, or suggest the best > forum, thank you very much. I have answered that message, and clarified the bug tracking system's web frontend slightly in response. The rest is intentional behaviour. Please leave this bug in peace to be archived now. :-) Other issues with how the BTS works should be sent to appropriate mailing lists, or a fresh bug on the bugs.debian.org pseudopackage once you have confirmed that it's really a bug. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#307500: choose-mirror: ftbfs [sparc] build fails ./get-iso-codes
On Tue, May 03, 2005 at 08:54:28AM -0700, Blars Blarson wrote: > Package: choose-mirror > Version: 1.08 > Severity: serious > Tags: sid > Justification: fails to build from source > > choose-mirror fails to build from source on sparc and other buildds, > duplicated on sparc pbuilder. > > # C. Perrier 2/7/2004 > # DO NOT actually uncomment these > # the scripts have not been tested enough > # we'd better include this for post-rc1 > # Grab ISO codes from iso-codes package > chmod u+x ./get-iso-codes > ./get-iso-codes > make: *** [build-stamp] Error 1 Joey and I just fixed a bunch of problems with the new choose-mirror build system, including this one, but we need to wait for an l10n-sync run to resurrect some old translations before uploading it. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#111651: time to fix this one?
On Wed, May 04, 2005 at 10:47:35AM +0200, Robert Millan wrote: > On Tue, May 03, 2005 at 08:10:49PM -0400, Theodore Ts'o wrote: > > On Tue, May 03, 2005 at 10:35:56PM +0200, Robert Millan wrote: > > > Now that sarge is frozen (and as I have just checked, a sarge fork > > > of e2fsprogs made), what do you think of looking at this old bug for > > > unstable? > > > > > > Unless I missed something, the solution proposed by Colin's last mails was > > > acceptable but impossible to apply before sarge. Well, er, some testing of it *before* upload would be kind of nice, rather than applying stuff that came off the top of my head. :-) > > > Can we do this now? Are > > > there any caveats that need to be solved first? > > > > Why do you care so much? This bug is priority wishlist for a reason, > > I don't think anyone considers it terribly important. Splitting out > > fsck will bloat the FTP archives by an additional package, and the > > only advantage is that it will save a small amount of disk space > > (0.001% of the space on a 100 gig filesystem, which is pretty moderate > > in these days of 250 gig disks). > > Because it's more than 3 years old. I'm concerned that if we miss the time > frame untill the next freeze of base system, it'll never be fixed. I don't even consider it especially important (even for etch), certainly nowadays, and I reported it ... Bugs don't necessarily increase in importance with age. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#283161: visudo: please use /tmp or other location for temporary file
On Fri, Nov 26, 2004 at 11:38:46PM +0100, martin f krafft wrote: > Package: sudo > Version: 1.6.7p5-2 > Severity: minor > > visudo creates and uses /etc/visudo.tmp. While this may or may not > be subject to race conditions, a temporary file certainly does not > belong into /etc. Please use /tmp or $TMPDIR instead. We have to be a bit careful here, I think; visudo currently issues a warning if the temporary file is on a different filesystem. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284110: pciutils-udeb would be useful
On Fri, Dec 03, 2004 at 06:30:06PM +, Colin Watson wrote: > It'd be useful to have a reduced pciutils-udeb for use in the installer, > so that we can ask users to run lspci, and to provide a mapping from PCI > IDs to names in images where hotplug is being used instead of discover > (such as the Ubuntu development branch). I wrote this patch: > > http://people.ubuntulinux.org/patches/pciutils.udeb.diff > > (There's also a subsequent version in Ubuntu which bumps the priority of > pciutils-udeb to standard, but I think we'd prefer to avoid that in > Debian until after sarge to avoid possible unwanted consequences for the > installer's low-memory mode.) I've now committed at least some hotplug support to d-i. Could you please apply this patch soon, so that it can work properly? Since sarge is now frozen, you can upload it without fear of breaking sarge. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#279232: What about perl-bug #279232?
# let's have this on both reassign 279232 perl,doc-base thanks On Wed, May 04, 2005 at 09:25:06PM +1000, Brendan O'Dea wrote: > On Fri, Apr 08, 2005 at 08:36:05AM +0200, Henning Glawe wrote: > >it could be "fixed" by introducing a versioned pre-dependency of > >perl-modules on perl-base while letting perl-base conflict with too old > >perl-modules, which forces apt to update both packages together; this > >combination may be highly unstable (conflicts+pre-depends is a loop-like > >construct), but results in the right behaviour. > > Given an alternate option I'd really rather not do this. It seems > fragile at best, disasterous at worst. I would be terrified of accepting a change like this into sarge. It seems to me that it would have very complex and probably undesirable effects on upgrades, causing large swathes of packages to be deconfigured. > Given the recent freeze announcement, I'd suggest that regardless of > what other fixes are made, a good first step would be to get a fixed > doc-base (i.e. one that works with the current stable perl-base only) > package into stable-proposed-updates *now*. > > If nothing else, this reduces the size of the problem if there's a point > release prior to sarge. I agree. Also, having a doc-base in sarge that's fixed in the way you describe means that we shouldn't have this particular incarnation of the problem again, and it would mean that at least we could tell people in the release notes to upgrade doc-base first. I think that would be acceptable as far as sarge is concerned. On Fri, 29 Apr 2005 at 11:11:38PM +0200, Frank Lichtenheld wrote: > On Fri, Apr 29, 2005 at 02:03:23PM -0500, Bill Allombert wrote: > > install-docs should be shipped not executable in doc-base .deb and > > doc-base postinst should a+x it. (and prerm should a-x it). > > This wouldn't help. doc-base doesn't need to be touched at all for the > bug to appear. Perl gets itself in a non-working state... You've said this a couple of times, but I don't think that's true at all. Everything here seems to be working exactly the way it's been told to work, and certainly perl appears to be doing nothing wrong. /usr/bin/perl is working just fine (it's essential, and works even when unconfigured the way it's supposed to). All modules in perl-base work fine too. However, File::Basename is in perl-modules, which is not essential, and therefore in order to ensure that it is usable you *must* declare a dependency on it (or just on perl, as would be more usual). This is all perfectly normal and in accordance with policy. The problem is that the packages that call install-docs do so opportunistically (only if it's available), and so they do not declare a dependency on perl or doc-base. Thus, there is *no way* for them to make sure that install-docs is actually usable; it may be unpacked but not configured. Once the doc-base package enters the configured state, dpkg will have made sure that perl is configured too (as per the definition of Depends) and so install-docs will work fine. Bill's suggestion would therefore fix this bug, although I haven't quite decided whether it's more complicated than just making doc-base work with only essential packages. I could go either way. The following patch to doc-base avoids the use of File::Basename, so it should work with only perl-base. I've tested the substituted functions independently, but I have not yet tested the resulting package. Caveat emptor. Bill's suggestion should definitely be tried out too, since it would probably involve less code. diff -Nru /tmp/At5JVh70EG/doc-base-0.7.18/debian/changelog /tmp/KqzthCt2IB/doc-base-0.7.18.1/debian/changelog --- /tmp/At5JVh70EG/doc-base-0.7.18/debian/changelog2003-03-30 18:14:12.0 +0100 +++ /tmp/KqzthCt2IB/doc-base-0.7.18.1/debian/changelog 2005-05-07 14:49:49.0 +0100 @@ -1,3 +1,11 @@ +doc-base (0.7.18.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Avoid File::Basename, in order to work even when perl is unconfigured +(closes: #278495). + + -- Colin Watson <[EMAIL PROTECTED]> Sat, 7 May 2005 14:49:47 +0100 + doc-base (0.7.18) unstable; urgency=low * postinst: don't die if /usr/lib/menu doesn't exist; closes: #186707 diff -Nru /tmp/At5JVh70EG/doc-base-0.7.18/install-docs /tmp/KqzthCt2IB/doc-base-0.7.18.1/install-docs --- /tmp/At5JVh70EG/doc-base-0.7.18/install-docs2003-03-15 22:08:38.0 + +++ /tmp/KqzthCt2IB/doc-base-0.7.18.1/install-docs 2005-05-07 14:49:45.0 +0100 @@ -16,7 +16,28 @@ # ---end-of-configuration-part--- -use File::Basename; +# This would normally be just 'use File::Basename;'. However, install-docs +# often gets called opportunistically by packages if it's present, and +# th
Bug#303252: acknowledged by developer (Bug#303252: fixed in eject 2.0.13deb-11)
reopen 303252 thanks On Fri, May 06, 2005 at 03:03:23PM -0700, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > #303252: eject: various translations from Ubuntu (el, hu, id, nb, pl, ro), > which was filed against the eject package. > > It has been closed by one of the developers, namely > Frank Lichtenheld <[EMAIL PROTECTED]>. [...] >* Translations from Ubuntu, provided by Colin Watson: > (Closes: #303252) > - debian/po/el.po by Kostas Papadimas > - debian/po/hu.po by Gabor Burjan > - debian/po/id.po by Yoppy Hidayanto > - debian/po/nb.po by Terance Edward Sola > - debian/po/pl.po by Dominik Zablotny > - debian/po/ro.po by Ovidiu Damian It looks like the Polish translation was indeed mangled (and perhaps the others should be converted to UTF-8 with msgconv to match the originals, although that isn't required). Here's a gzipped version of pl.po, which should hopefully survive in better condition. Thanks, -- Colin Watson [EMAIL PROTECTED] pl.po.gz Description: Binary data
Bug#303252: eject: various translations from Ubuntu (el, hu, id, nb, pl, ro)
On Wed, Apr 06, 2005 at 12:31:01AM +0200, Frank Lichtenheld wrote: > On Tue, Apr 05, 2005 at 05:23:26PM +0100, Colin Watson wrote: > > I asked Ubuntu installer translators to translate a master file that > > happened to include eject, and got the attached translations as a > > result. You might want to include them in Debian. > > Two of them aren't UTF-8 but are labelled as such: > [EMAIL PROTECTED]:~/debian/eject$ LANG=C msgfmt -o- debian/po/hu.po > >/dev/null > debian/po/hu.po:24:17: invalid multibyte sequence > debian/po/hu.po:24:30: invalid multibyte sequence > debian/po/hu.po:24:32: invalid multibyte sequence > msgfmt: found 3 fatal errors > [EMAIL PROTECTED]:~/debian/eject$ LANG=C msgfmt -o- debian/po/nb.po > >/dev/null > debian/po/nb.po:28:10: invalid multibyte sequence > msgfmt: found 1 fatal error > > Could you find out which encodings these really are? Looks like they got mangled into ISO-8859-1 by an Apache default encoding on bugs.debian.org. The files in the mail were correctly UTF-8. (Luckily, that's nb's native legacy encoding, and the Hungarian translation was in the subset of characters which are in both ISO-8859-1 and ISO-8859-2.) Sorry I took so long to answer this. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308340: installation-reports
reassign 308340 ethdetect retitle 308340 tolerate old versions of hw-detect in initrd without sysfs-update-devnames tags 308340 pending thanks On Mon, May 09, 2005 at 05:39:22PM +0200, Davide Del Grande wrote: > But the May, 08th 2005 snapshot gives me this error: > > "An installation step failed. You can try to run the failing > step again from the menu, or skip it and choose something else. > The failing step is: Detect Network hardware" > > In the ALT-F4 console: > > main-menu(393): process(4730): sysfs-update-devnames: not found > main-menu(393): WARNING **: Configuring 'ethdetect' failed with error > code 127 > main-menu(393): WARNING **: Menu item 'ethdetect' failed. Thanks for your report. The CD image you were using has a new ethdetect, but an old version of hw-detect in the initrd. I'd forgotten that this kind of desynchronisation was possible. Fixed in Subversion trunk. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308473: lshw-common: architecture-independent?
Package: lshw-common Version: 02.03-2 Is there any reason why lshw-common is Architecture: any? It seems to me that it should be Architecture: all, and put together in 'debian/rules binary-indep'. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
On Fri, Mar 11, 2005 at 06:22:57PM +0100, Bill Allombert wrote: > On Fri, Mar 11, 2005 at 03:26:16PM +0100, Martin Pitt wrote: > > I wholeheartedly agree and second this proposal. Also, /home should be > > root:root 0755 instead of root:staff 2775; it is only confusing and > > actually does not do anything useful. > > Obviously it does: it allows an administrator in the staff group to > install software in /usr/local without having to use root priviledge, > so prevent mistakes that would affect the /usr hierarchy. I don't see > what is confusing here? In Martin's second sentence, he's talking about /home, where it's not especially useful for users other than root to have write access since they can't chown the home directories to the new user anyway. > This is even documented, see > /usr/share/doc/base-passwd/users-and-groups.txt.gz: > > staff > > Allows users to add local modifications to the system (/usr/local, /home) > without needing root privileges. Compare with group 'adm', which is more > related to monitoring/security. base-passwd documents the situation at the moment and the rationale as retroactively understood at the time when the documentation was written (that understanding may have been imperfect); I'd obviously be happy to update it to take account of changes. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299657: evince: case-sensitive find isn't
Package: evince Version: 0.1.5-2 Severity: normal I opened http://www.openbios.info/docs/rec.dse.app10.pdf in evince, pressed Ctrl-F, pressed the "Case Sensitive" button, and searched for "IDE"; evince gave me lower-case matches, for example "wide". It should have given me upper-case matches only. Thanks, -- Colin Watson [EMAIL PROTECTED] -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.9-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages evince depends on: ii gconf2 2.8.1-4 GNOME configuration database syste ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libaudiofile00.2.6-5 Open-source version of SGI's audio ii libbonobo2-0 2.8.1-2 Bonobo CORBA interfaces library ii libbonoboui2-0 2.8.1-2 The Bonobo UI library ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libesd0 0.2.35-2Enlightened Sound Daemon - Shared ii libfontconfig1 2.2.3-4 generic font configuration library ii libfreetype6 2.1.7-2.3 FreeType 2 font engine, shared lib ii libgcc1 1:3.4.3-9 GCC support library ii libgconf2-4 2.8.1-4 GNOME configuration database syste ii libgcrypt11 1.2.0-11LGPL Crypto library - runtime libr ii libglade2-0 1:2.4.2-2 library to load .glade files at ru ii libglib2.0-0 2.6.3-1 The GLib library of C routines ii libgnome-keyring00.4.1-1 GNOME keyring services library ii libgnome2-0 2.8.1-2 The GNOME 2 library - runtime file ii libgnomecanvas2-02.8.0-1 A powerful object-oriented display ii libgnomeprint2.2-0 2.8.2-1 The GNOME 2.2 print architecture - ii libgnomeprintui2.2-0 2.8.2-2 GNOME 2.2 print architecture User ii libgnomeui-0 2.8.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.8.3-11The GNOME virtual file-system libr ii libgnutls11 1.0.16-13 GNU TLS library - runtime library ii libgpg-error01.0-1 library for common error values an ii libgtk2.0-0 2.6.2-3 The GTK+ graphical user interface ii libice6 4.3.0.dfsg.1-12 Inter-Client Exchange library ii libjpeg626b-9The Independent JPEG Group's JPEG ii liborbit21:2.10.5-0.1libraries for ORBit2 - a CORBA ORB ii libpango1.0-01.8.1-1 Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libsm6 4.3.0.dfsg.1-12 X Window System Session Management ii libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 ii libtasn1-2 0.2.10-4Manage ASN.1 structures (runtime) ii libx11-6 4.3.0.dfsg.1-12 X Window System protocol client li ii libxml2 2.6.16-3GNOME XML library ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299686: yaboot: ofpath support for Pegasos and "spi" IDE devices
Package: yaboot
Version: 1.3.13-3
Severity: wishlist
Tags: patch
Very recent versions of Open Firmware on Pegasos support yaboot, at
least for netbooting. It would be useful to be able to use ofpath to
find out the Open Firmware paths to disks on such systems. There are two
obstacles, at least on the development system I have which AFAIK is a
fairly standard configuration:
* ofpath doesn't recognise the Pegasos subarchitecture, and doesn't
know which style of device name -> Open Firmware mangling to use on
it. As far as I can tell, it's straightforward enough at least for
IDE disks (I can't test SCSI, unfortunately) that the same handling
as NewWorld can be used.
* The IDE disk shipped with my development system advertises its
device_type as "spi" (SCSI-3 Parallel Interface, I think,
http://www.openbios.info/docs/rec.scsi3pi.10.pdf - no idea why). The
Open Firmware path appears to be
/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],TARGET.
Here's a patch for both these issues. If Ethan wants to merge this using
arch, then:
tla register-archive http://riva.ucam.org/~cjwatson/archives/[EMAIL PROTECTED]
tla star-merge [EMAIL PROTECTED]/yaboot--pegasos--1.3
* finding or making yaboot--pegasos--1.3--base-0
* finding or making yaboot--pegasos--1.3--patch-2
* computing changeset
A {arch}/yaboot/yaboot--pegasos/yaboot--pegasos--1.3/[EMAIL
PROTECTED]/patch-log/patch-1
A {arch}/yaboot/yaboot--pegasos/yaboot--pegasos--1.3/[EMAIL
PROTECTED]/patch-log/patch-2
M ybin/ofpath
* changeset report
* added files
{arch}/yaboot/yaboot--pegasos/yaboot--pegasos--1.3/[EMAIL
PROTECTED]/patch-log/patch-1
--- /dev/null
+++ mod/{arch}/yaboot/yaboot--pegasos/yaboot--pegasos--1.3/[EMAIL
PROTECTED]/patch-log/patch-1
@@ -0,0 +1,10 @@
+Revision: yaboot--pegasos--1.3--patch-1
+Archive: [EMAIL PROTECTED]
+Creator: Colin Watson <[EMAIL PROTECTED]>
+Date: Tue Mar 15 20:11:08 GMT 2005
+Standard-date: 2005-03-15 20:11:08 GMT
+Modified-files: ybin/ofpath
+New-patches: [EMAIL PROTECTED]/yaboot--pegasos--1.3--patch-1
+Summary: Add support for IDE devices that advertise as "spi"
+Keywords:
+
--- /dev/null
+++ mod/{arch}/yaboot/yaboot--pegasos/yaboot--pegasos--1.3/[EMAIL
PROTECTED]/patch-log/patch-2
@@ -0,0 +1,10 @@
+Revision: yaboot--pegasos--1.3--patch-2
+Archive: [EMAIL PROTECTED]
+Creator: Colin Watson <[EMAIL PROTECTED]>
+Date: Tue Mar 15 20:14:15 GMT 2005
+Standard-date: 2005-03-15 20:14:15 GMT
+Modified-files: ybin/ofpath
+New-patches: [EMAIL PROTECTED]/yaboot--pegasos--1.3--patch-2
+Summary: Add (trivial) support for Pegasos to ofpath
+Keywords:
+
{arch}/yaboot/yaboot--pegasos/yaboot--pegasos--1.3/[EMAIL
PROTECTED]/patch-log/patch-2
--- /dev/null
+++ mod/{arch}/yaboot/yaboot--pegasos/yaboot--pegasos--1.3/[EMAIL
PROTECTED]/patch-log/patch-1
@@ -0,0 +1,10 @@
+Revision: yaboot--pegasos--1.3--patch-1
+Archive: [EMAIL PROTECTED]
+Creator: Colin Watson <[EMAIL PROTECTED]>
+Date: Tue Mar 15 20:11:08 GMT 2005
+Standard-date: 2005-03-15 20:11:08 GMT
+Modified-files: ybin/ofpath
+New-patches: [EMAIL PROTECTED]/yaboot--pegasos--1.3--patch-1
+Summary: Add support for IDE devices that advertise as "spi"
+Keywords:
+
--- /dev/null
+++ mod/{arch}/yaboot/yaboot--pegasos/yaboot--pegasos--1.3/[EMAIL
PROTECTED]/patch-log/patch-2
@@ -0,0 +1,10 @@
+Revision: yaboot--pegasos--1.3--patch-2
+Archive: [EMAIL PROTECTED]
+Creator: Colin Watson <[EMAIL PROTECTED]>
+Date: Tue Mar 15 20:14:15 GMT 2005
+Standard-date: 2005-03-15 20:14:15 GMT
+Modified-files: ybin/ofpath
+New-patches: [EMAIL PROTECTED]/yaboot--pegasos--1.3--patch-2
+Summary: Add (trivial) support for Pegasos to ofpath
+Keywords:
+
* modified files
--- orig/ybin/ofpath
+++ mod/ybin/ofpath
@@ -396,6 +396,10 @@
local MASTER="/@$(($(cat /proc/ide/${IDEBUS}/channel) * 2 + 0))"
local SLAVE="/@$(($(cat /proc/ide/${IDEBUS}/channel) * 2 + 1))"
;;
+ spi)
+ local MASTER="/[EMAIL PROTECTED](cat
/proc/ide/${IDEBUS}/channel),0"
+ local SLAVE="/[EMAIL PROTECTED](cat
/proc/ide/${IDEBUS}/channel),1"
+ ;;
*)
echo 1>&2 "$PRG: Unsupported IDE device type: \"$(cat
/proc/device-tree${DEVSPEC}/device_type 2> /dev/null)\""
return 1
@@ -914,6 +918,8 @@
SUBARCH=OldWorld
elif (cat /proc/cpuinfo 2> /dev/null | grep ^machine | grep -q 'CHRP IBM') ;
then
SUBARCH=CHRP
+elif (cat /proc/cpuinfo 2>/dev/null | grep ^machine | grep -q 'CHRP Pegasos')
; then
+SUBARCH=Pegasos
else
echo 1>&2 "$PRG: This machine is not yet supported"
exit 1
@@ -936,7 +942,8 @@
## use appropriate search for right sub arch.
case "$SUBARCH" in
-NewWorld)
+# Pegasos OF seems to be NewWorld-ish enough to
Bug#61342: Please install libunicode-maputf8-perl on spohr
Hi admins, Please install libunicode-maputf8-perl on spohr; we need it in order to apply a debbugs patch (bug #61342) to do proper handling of MIME From: lines. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#61342: your mail
broken. The BTS shouldn't be writing
> + # HTML into the log... but it does.
> + $this .= de_rfc1522($_);
> } elsif ($normstate eq 'go') {
> s/^\030//;
> if (!$suppressnext && !$found_msgid &&
Not sure that qualifies for an XXX comment here. The right place to note
the design flaw is really in Debbugs/Log.pm, which I've done.
Debbugs::Log also provides a better basis for designing the migration to
a new, less broken-by-design record type.
Again, I think the html record should really be in UTF-8, and a
migration script written.
> @@ -409,7 +411,7 @@
> $thisheader = "Message sent:\n";
> } else {
> s/\04/, /g; s/\n$//;
> - $thisheader = "Message sent to
> ".htmlsanit($_).":\n";
> + $thisheader = "Message sent to
> ".htmlsanit(de_rfc1522($_)).":\n";
> }
> $this = "";
> $normstate= 'kill-body';
And again. Basically, I think mail text should be preserved as-is in the
log (since it means you can send out notifications by mail and preserve
the MIME structure as it was received), but everything else counts as
metadata and should be in a canonical form.
> Index: scripts/process.in
> ===
> RCS file: /cvs/debbugs/source/scripts/process.in,v
> retrieving revision 1.86
> diff -u -r1.86 process.in
> --- scripts/process.in5 Aug 2004 15:09:30 - 1.86
> +++ scripts/process.in11 Jan 2005 16:43:49 -
> @@ -17,6 +17,9 @@
> require "$lib_path/errorlib";
> $ENV{'PATH'} = $lib_path.':'.$ENV{'PATH'};
>
> +# for de_rfc1522
> +use Debbugs::MIME qw(de_rfc1522);
> +
> chdir( "$gSpoolDir" ) || die "chdir spool: $!\n";
>
> #open(DEBUG,"> /tmp/debbugs.debug");
No need for the comment.
> @@ -252,6 +255,7 @@
> }
> $markedby= $header{'from'} eq $replyto ? $replyto :
> "$header{'from'} (reply to $replyto)";
> +$markedby = de_rfc1522($markedby);
> if ($codeletter eq 'F') {
> (&appendlog,&finish) if length($data->{forwarded});
> $receivedat= "[EMAIL PROTECTED]";
I'd suggest instead simply:
- $header{$v} = $_;
+ $header{$v} = de_rfc1522($_);
... and likewise in scripts/service.in. That way, all metadata trivially
gets decoded with very little effort, and is stored in canonical form as
suggested above.
> @@ -430,6 +434,7 @@
> X-$gProject-PR-Package: $data->{package}
> X-$gProject-PR-Keywords: $data->{keywords}
> Reply-To: [EMAIL PROTECTED]
> +Content-Type: text/plain; charset="utf-8"
>
> This is an automatic notification regarding your $gBug report
> #$ref: $data->{subject},
This gets more complicated, and is one of the reasons I'd been avoiding
this work. The right way to do this, and fix a few other bugs along the
way, is to attach the text of the original report using MIME rather than
simply appending it; that way, it can have its original content-type,
including character set. So, I'll avoid this part for the time being. We
won't be making anything significantly worse by doing this in two stages
anyway, since it's already broken.
Do we need to re-RFC1522-encode headers in outgoing messages? I think we
probably do. MIME::Words knows how to do that, and despite the warning
in its documentation I think the encode_mimewords() function is safe for
encoding from UTF-8.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#61342: your mail
On Wed, Mar 16, 2005 at 08:24:56PM +, Colin Watson wrote:
> Do we need to re-RFC1522-encode headers in outgoing messages? I think we
> probably do. MIME::Words knows how to do that, and despite the warning
> in its documentation I think the encode_mimewords() function is safe for
> encoding from UTF-8.
How about this as a simple encode function?
sub encode_rfc1522 ($)
{
my ($string) = @_;
return MIME::Words::encode_mimewords($string, Charset => 'UTF-8');
}
(I've renamed de_rfc1522 to decode_rfc1522 to allow a sensible name for
this function.)
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299863: kernel-package: make-kpkg uses run-parts -v option, which breaks woody->sarge upgrades
On Thu, Mar 17, 2005 at 01:14:04AM +0100, Sven Luther wrote:
> I just got a bug report against my powerpc kernels which use as you
> know the /etc/kernel/*.d scripts, and an installation of this kernels
> on a woody system failed, because the woody runparts doesn't
> understand the -v option (but it does understand the --verbose one).
>
> Since this is could cause problems in woody->sarge migration, it would
> be nice to fix it before the release, or let's say early enough that i
> can rebuild both powerpc kernels with it.
To elaborate a bit, the reason why this affects users upgrading from
woody even if they haven't done anything strange to their system is that
if they attempt to upgrade to a sarge kernel-image first, the sarge
kernel-image packages depend on mkvmlinuz, which ships
/etc/kernel/post{inst,rm}.d/mkvmlinuz scripts; thus, kernel-image tries
to run 'run-parts -v' without them doing anything funny to their system,
and without an appropriate versioned dependency on debianutils being
declared.
s/-v/--verbose/g certainly seems like the simplest fix.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299863: kernel-package: make-kpkg uses run-parts -v option, which breaks woody->sarge upgrades
On Thu, Mar 17, 2005 at 10:10:55PM +0100, Sven Luther wrote:
> On Thu, Mar 17, 2005 at 08:10:36PM +0000, Colin Watson wrote:
> > To elaborate a bit, the reason why this affects users upgrading from
> > woody even if they haven't done anything strange to their system is that
> > if they attempt to upgrade to a sarge kernel-image first, the sarge
> > kernel-image packages depend on mkvmlinuz, which ships
> > /etc/kernel/post{inst,rm}.d/mkvmlinuz scripts; thus, kernel-image tries
> > to run 'run-parts -v' without them doing anything funny to their system,
> > and without an appropriate versioned dependency on debianutils being
> > declared.
> >
> > s/-v/--verbose/g certainly seems like the simplest fix.
>
> Could i also add a versioned dependency in the kernel-images to the first
> version of debian-utils to have the -v option ? This would mean uploading two
> full kernel-images (2.4.27 and 2.6.8) and thus probably around a full 24 hours
> of builds and uploads.
You could, but if you're going to upload anyway you might as well just
use --verbose rather than further complicating the dependency graph.
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314745: openssh-client: please move README.Debian to openssh-server
On Sat, Jun 18, 2005 at 04:27:29PM +0900, Hideki Yamane wrote: > Now openssh package is separeted to -client and -server. > And README.Debian is in -client package but it says about > server's feature, for example, "PermitRootLogin" directive. > > Please consider about moving README.Debian file to -server. I don't want to move it, but it should appear in all of openssh-client, openssh-server, and ssh; I'd like to symlink the documentation directories together. Unfortunately last time I tried this I ran into some very complicated upgrade issues across the package split and ended up with some documentation disappearing entirely (!). I'll try again at some point. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290366: vga= parameter
On Fri, Jun 17, 2005 at 11:07:57AM -0400, Joey Hess wrote: > Well, the installer docs do suggest passing vga=771 for machines with > display problems. Mostly these seem to be laptops there the vga16fb cuts > off part of the screen. > > I guess that we could try turing vga=0x301 (ie 769) on, or 771 on by > default in unstable now and see what breaks. Don't know enough about it > to know which of the two numbers is more likely to work though. IIRC you don't get suspend-to-RAM if you pass vga=anything, since vesafb doesn't support it. http://lists.ubuntu.com/archives/ubuntu-devel/2005-April/006828.html -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314745: openssh-client: please move README.Debian to openssh-server
On Sun, Jun 19, 2005 at 12:31:16AM +0900, Hideki Yamane wrote: > "Sat, 18 Jun 2005 10:45:13 +0100", "Colin Watson" > "Re: Bug#314745: openssh-client: please move README.Debian to > openssh-server" > >I don't want to move it, but it should appear in all of openssh-client, > >openssh-server, and ssh; I'd like to symlink the documentation > >directories together. > > If so, where is target doc directory (what pacakge would contain > that documents)? It'd be visible in all of /usr/share/doc/openssh-client/, /usr/share/doc/openssh-server/, and /usr/share/doc/ssh/. openssh-server and ssh both depend on openssh-client, so the canonical location would have to be /usr/share/doc/openssh-client/. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314860: base-config conflicts tasksel
On Sun, Jun 19, 2005 at 08:33:21AM +1000, Michael Bentzen wrote: > Finally, i apt-get'd install tasksel base-config > > Reading Package Lists... Done > Building Dependency Tree... Done > tasksel is already the newest version. > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > base-config: Conflicts: tasksel (< 2.25) but 2.24 is to be installed > E: Broken packages > > I am running testing and it seems that base-config is conflicting with > tasksel. I've bumped the urgency of tasksel/2.25 in response to this, so it should go into etch tonight. (The testing scripts only enforce installability of single packages, not co-installability of multiple packages, so they didn't spot this situation.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315075: man-db(GNU/k*BSD): FTBFS: out of date config.sub/config.guess
tags 315075 fixed-upstream thanks On Mon, Jun 20, 2005 at 03:11:34PM +0200, Aurelien Jarno wrote: > The current version of man-db fails to build on GNU/kFreeBSD, > because of outdated config.guess and config.sub. Fixed upstream, thanks. I'll be doing 2.4.3 in a week or two, once some updated translations arrive; but I'll build an updated Debian package in the meantime. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314808: Suggestion
On Wed, Jun 22, 2005 at 10:41:39AM +0200, Lukas Kolbe wrote: > I don't really see a problem here. > > The FHS dictates: /src is site-specific. > The Policy dictates: webapps-files in /usr/share/package/, which I > strongly agree. > > Now, what prevents us writing helper-packages to maintain a subset of, > say, /srv/webapps/? The underlined portion above. Consider: it's common practice to have /srv/$HOSTNAME for services hosted by the system. Let's say somebody's internal web applications hostname happens to be 'webapps' (and they decided not to bother with the FQDN in the directory). Now you've just trampled over their local configuration. If anything, /srv/www is even more likely to be already in use. Once something has been declared to be site-specific, you can't go back on that. Now, helper packages that maintained a *generic* location would be fine. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315875: debootstrap --print-debs prints extra output, breaking other tools
Package: debootstrap Version: 0.3.1 Severity: important 'debootstrap --print-debs sid ' prints the following to stdout: I: Retrieving Release I: Retrieving Packages I: Validating Packages base-files base-passwd bash bsdutils coreutils debconf debconf-i18n debianutils diff dpkg dselect e2fslibs e2fsprogs findutils gcc-3.3-base grep gzip hostname initscripts libacl1 libattr1 libblkid1 libc6 libcap1 libcomerr2 libdb1-compat libdb3 libgcc1 liblocale-gettext-perl libncurses5 libnewt0.51 libpam-modules libpam-runtime libpam0g libss2 libstdc++5 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libuuid1 login makedev mawk mount ncurses-base ncurses-bin passwd perl-base procps sed slang1a-utf8 sysv-rc sysvinit tar util-linux zlib1g adduser apt apt-utils aptitude base-config bsdmainutils console-common console-data console-tools cpio cron dhcp-client ed gettext-base groff-base ifupdown info iptables iputils-ping klogd libconsole libdb4.2 libgcrypt11 libgdbm3 libgnutls11 libgpg-error0 liblockfile1 liblzo1 libncursesw5 libopencdk8 libpcre3 libpopt0 libsigc++-1.2-5c102 libssl0.9.7 libtasn1-2 libtextwrap1 libwrap0 logrotate mac-fdisk man-db manpages modutils nano net-tools netbase netcat netkit-inetd nvi powerpc-utils sysklogd tasksel tcpd traceroute wget whiptail yaboot The extra status output at the start causes problems for other tools that parse 'debootstrap --print-debs'; one such tool is debian-cd. Please arrange not to display this status output when doing --print-debs, or to print it to stderr. Thanks, -- Colin Watson [EMAIL PROTECTED]
Bug#315049: autossh: depends on transitional package ssh
On Mon, Jun 20, 2005 at 05:36:14AM -0400, Andrew Schulman wrote: > Package: autossh > Version: 1.3-1 > Severity: important > > autossh depends on the package ssh, which has been marked as > transitional. The ssh client is now provided by the openssh-client > package. > > Maybe autossh should depend on ssh-client, which is provided by > openssh-client. It should probably depend on 'openssh-client | ssh-client' to avoid depending on a pure virtual package. (Assuming it doesn't use any OpenSSH-specific features, that is; if it does, then remove ssh-client.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315940: debootstrap: please add Ubuntu breezy script
Package: debootstrap
Version: 0.3.1.3
Severity: wishlist
Tags: patch
The attached patch adds support for the Ubuntu breezy distribution,
which I've now set up to be determined mostly dynamically (the buildd
variant is still hardcoded because we haven't set up Build-Essential
extraoverrides yet).
The breezy script is very similar to sid, although differs in a few
places:
--- sid 2005-06-16 09:48:23.0 +0100
+++ breezy 2005-06-26 18:39:44.0 +0100
@@ -14,7 +14,16 @@
# ^^ should be getting debconf here somehow maybe
base="$(get_debs Priority: important)"
elif doing_variant buildd; then
- base="$(get_debs Build-Essential: yes)"
+ # TODO: add Build-Essential: yes extraoverrides
+ #base="$(get_debs Build-Essential: yes)"
+
+ add () { if [ "$ARCH" = "$1" ]; then eval "$2=\"\$$2 $3\""; fi; }
+
+ base="apt binutils cpio cpp cpp-4.0 dpkg-dev g++ g++-4.0 gcc gcc-4.0
${LIBC6}-dev libdb4.2 libgdbm3 libstdc++6-4.0-dev linux-kernel-headers make
patch perl perl-modules"
+
+ add ia64 "libunwind7-dev"
+ add sparc "lib64gcc1"
+ add sparc "libc6-dev-sparc64"
fi
}
@@ -68,7 +77,8 @@
in_target /sbin/ldconfig
DEBIAN_FRONTEND=noninteractive
-export DEBIAN_FRONTEND
+DEBCONF_NONINTERACTIVE_SEEN=true
+export DEBIAN_FRONTEND DEBCONF_NONINTERACTIVE_SEEN
baseprog=0
bases=7
Thanks,
--
Colin Watson [EMAIL PROTECTED]
diff -Nru /tmp/eN8i04Oph4/debootstrap-0.3.1.3/Makefile
/tmp/xLNDAjxtQ2/debootstrap-0.3.1.3ubuntu1/Makefile
--- /tmp/eN8i04Oph4/debootstrap-0.3.1.3/Makefile2005-06-16
13:28:52.0 +0100
+++ /tmp/xLNDAjxtQ2/debootstrap-0.3.1.3ubuntu1/Makefile 2005-06-26
19:02:52.0 +0100
@@ -36,6 +36,7 @@
install -o root -g root -m 0644 warty.buildd $(DSDIR)/scripts/
install -o root -g root -m 0644 hoary $(DSDIR)/scripts/
install -o root -g root -m 0644 hoary.buildd $(DSDIR)/scripts/
+ install -o root -g root -m 0644 breezy $(DSDIR)/scripts/
install -o root -g root -m 0644 functions $(DSDIR)/
install -o root -g root -m 0755 debootstrap.8
$(DESTDIR)/usr/share/man/man8/
diff -Nru /tmp/eN8i04Oph4/debootstrap-0.3.1.3/breezy
/tmp/xLNDAjxtQ2/debootstrap-0.3.1.3ubuntu1/breezy
--- /tmp/eN8i04Oph4/debootstrap-0.3.1.3/breezy 1970-01-01 01:00:00.0
+0100
+++ /tmp/xLNDAjxtQ2/debootstrap-0.3.1.3ubuntu1/breezy 2005-06-26
18:39:44.0 +0100
@@ -0,0 +1,161 @@
+mirror_style release
+download_style apt
+finddebs_style from-indices
+variants - buildd
+
+work_out_debs () {
+LIBC6=libc6
+if [ "$ARCH" = "alpha" -o "$ARCH" = "ia64" ]; then LIBC6="libc6.1"; fi
+
+required="$(get_debs Priority: required)"
+
+if doing_variant -; then
+ #required="$required $(get_debs Priority: important)"
+ # ^^ should be getting debconf here somehow maybe
+ base="$(get_debs Priority: important)"
+elif doing_variant buildd; then
+ # TODO: add Build-Essential: yes extraoverrides
+ #base="$(get_debs Build-Essential: yes)"
+
+ add () { if [ "$ARCH" = "$1" ]; then eval "$2=\"\$$2 $3\""; fi; }
+
+ base="apt binutils cpio cpp cpp-4.0 dpkg-dev g++ g++-4.0 gcc gcc-4.0
${LIBC6}-dev libdb4.2 libgdbm3 libstdc++6-4.0-dev linux-kernel-headers make
patch perl perl-modules"
+
+ add ia64 "libunwind7-dev"
+ add sparc "lib64gcc1"
+ add sparc "libc6-dev-sparc64"
+fi
+}
+
+first_stage_install () {
+extract $required
+
+mkdir -p "$TARGET/var/lib/dpkg"
+: >"$TARGET/var/lib/dpkg/status"
+: >"$TARGET/var/lib/dpkg/available"
+
+setup_etc
+if [ ! -e "$TARGET/etc/fstab" ]; then
+echo '# UNCONFIGURED FSTAB FOR BASE SYSTEM' > "$TARGET/etc/fstab"
+chown 0.0 "$TARGET/etc/fstab"; chmod 644 "$TARGET/etc/fstab"
+fi
+
+setup_devices
+
+x_feign_install () {
+local pkg="$1"
+local deb="$(debfor $pkg)"
+local ver="$(
+ar -p "$TARGET/$deb" control.tar.gz | zcat |
+tar -O -xf - control ./control 2>/dev/null |
+sed -ne 's/^Version: *//Ip' | head -n 1
+)"
+
+mkdir -p "$TARGET/var/lib/dpkg/info"
+
+echo \
+"Package: $pkg
+Version: $ver
+Status: install ok installed" >> "$TARGET/var/lib/dpkg/status"
+
+touch "$TARGET/var/lib/dpkg/info/${pkg}.list"
+}
+
+x_feign_install dpkg
+}
+
+second_stage_install () {
+x_core_install () {
+ smallyes '' | in_target
Bug#315875: debootstrap --print-debs prints extra output, breaking other tools
On Sun, Jun 26, 2005 at 05:43:32PM +0100, Colin Watson wrote: > 'debootstrap --print-debs sid ' prints the following > to stdout: > > I: Retrieving Release > I: Retrieving Packages > I: Validating Packages > base-files base-passwd bash bsdutils coreutils debconf debconf-i18n > debianutils diff dpkg dselect e2fslibs e2fsprogs findutils gcc-3.3-base grep > gzip hostname initscripts libacl1 libattr1 libblkid1 libc6 libcap1 libcomerr2 > libdb1-compat libdb3 libgcc1 liblocale-gettext-perl libncurses5 libnewt0.51 > libpam-modules libpam-runtime libpam0g libss2 libstdc++5 > libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libuuid1 > login makedev mawk mount ncurses-base ncurses-bin passwd perl-base procps sed > slang1a-utf8 sysv-rc sysvinit tar util-linux zlib1g adduser apt apt-utils > aptitude base-config bsdmainutils console-common console-data console-tools > cpio cron dhcp-client ed gettext-base groff-base ifupdown info iptables > iputils-ping klogd libconsole libdb4.2 libgcrypt11 libgdbm3 libgnutls11 > libgpg-error0 liblockfile1 liblzo1 libncursesw5 libopencdk8 libpcre3 libpopt0 > libsigc++-1.2-5c102 libssl0.9.7 libtasn1-2 libtextwrap1 libwrap0 logrotate > mac-fdisk man-db manpages modutils nano net-tools netbase netcat netkit-inetd > nvi powerpc-utils sysklogd tasksel tcpd traceroute wget whiptail yaboot > > The extra status output at the start causes problems for other tools > that parse 'debootstrap --print-debs'; one such tool is debian-cd. > Please arrange not to display this status output when doing > --print-debs, or to print it to stderr. This implements the latter, although making it do the former instead would be trivial: http://patches.ubuntu.com/patches/debootstrap.315875.diff -- Colin Watson [EMAIL PROTECTED]
Bug#315444: test case
evalstring(p);
+ evalstring(p, 0);
exitstatus = savestatus;
}
}
@@ -11910,7 +11917,7 @@
handler = &loc;
if ((p = trap[0]) != NULL && *p != '\0') {
trap[0] = NULL;
- evalstring(p);
+ evalstring(p, 0);
}
flushall();
#ifdef CONFIG_FEATURE_COMMAND_SAVEHISTORY
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#313461: base-passwd: should look for and use local passwd/group files
On Mon, Jun 13, 2005 at 12:51:21PM -0700, Ryan Lovett wrote:
> When the package installs, it looks for the package-provided
> /usr/share/base-passwd/{passwd,group}.master. If a site has local
> changes, it is necessary to override the package files. If the site
> wants to do this during noninteractive Debian installation (ks), they
> have no choice but to modify the package before installation.
>
> I've attached a first-pass fix which looks for
> /etc/base-passwd/{passwd,group}.local first.
Hmm, I thought about this a bit. Wouldn't it be better simply to move
passwd.master and group.master to /etc/base-passwd/, and make them
conffiles? Of course, that means you have to do conflict resolution on
them, but it does mean that user/group changes that are assumed by other
Debian packages don't get lost. The current arrangement does have the
benefit that it's very hard to forget about user/group changes.
I'd be slightly happier with an arrangement that allowed files in /etc
to override single items from the master files.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290237: base-passwd: user/group additions and spelling corrections in doc/users-and-groups.sgml
On Wed, Jan 12, 2005 at 11:00:56PM -0500, David Mandelberg wrote: > Package: base-passwd > Version: 3.5.9 > Severity: wishlist > Tags: patch > > Hi, > > I added a few users and groups to doc/users-and-groups.sgml, and > corrected some spelling errors. See the patch below for more info. Thanks! Sorry for the delay in replying to this. > @@ -565,7 +636,8 @@ > shadow > > > - /etc/shadow is readable by this group. Some > + /etc/shadow and > + /var/backups/shadow.bak are readable by this > group. Some > programs that need to be able to access the file are setgid > shadow. > On my system, /var/backups/shadow.bak is owned by group shadow, but is not readable by it (i.e. it's root:shadow 0600). > + > + ssh > + > + > + HELP: /usr/bin/ssh-agent is setgid to ssh, why > I > + don't know. > + > + > + This is to prevent ptrace attacks; you can't strace a setgid program unless you're root. See the changelog for openssh 1:3.5p1-1. > + > + sshd > + > + > + HELP: This is in my /etc/passwd, but doesn't > + appear to be used for anything. It's probably a relic user that > + sshd used to use for its pid file or > + something similar. > + > + > + No, it's the unprivileged user used by (privsep) sshd when communicating with the network before successful authentication. See sshd_config(5). Otherwise, looks good to me. Committed, and will be in 3.5.10. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#219888: hmm
On Tue, Jun 28, 2005 at 09:39:04PM -0400, Joey Hess wrote: > Looking at a cdebconf protocol dump of anna with the patch failing to > install scsi-extra-modules, it seems to me this might be a fixed size > buffer. The SUBST CHOICES line is cut off after lidevmapper1.01-udeb in > the middle of libn(-something). The SET line is cut off in the middle of > libnss-files-u(deb). Both lines are identical length. > > Colin, does cdebconf have some bad hardcoded limits that might affect > this? cdebconf certainly has various bad hardcoded limits, some of which I removed in version 0.80 (but I doubt those are relevant here). What version of cdebconf is this? Knowing the line length in question would be good; I can't seem to get to bugs.debian.org right now to check out the bug. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316484: cdebconf's signal handling is dangerously wrong
Package: cdebconf Version: 0.81 Severity: important debconf, debconf-communicate, and dpkg-reconfigure all attempt to save the debconf database to disk in a signal handler. Words fail me while trying to express how wrong this is, and I'm amazed we haven't had more reports of data corruption, crashes, etc. I ran into this hard while testing cdebconf 0.80 with Linux 2.6.12 on amd64 and powerpc, where it caused various scripts called from debian-installer-startup to hang waiting on a futex. I applied a partial fix (correcting only the SIGCHLD handler) in cdebconf 0.81, but the rest needs to be cleaned up too. Following my SIGCHLD handler fix, we should simply set a volatile sig_atomic_t variable which is occasionally checked in the main control flow; either that or very carefully block signals everywhere that might write to the database in memory or otherwise collide with the signal handler, but I think the first approach is simpler and more robust. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#245506: man-db: French locale too
On Sun, Jul 17, 2005 at 05:13:41PM +0200, Laurent Raufaste wrote: > Package: man-db > Version: 2.4.3-1 > Followup-For: Bug #245506 > > I have sid with a french locale, and I too have some english and some > french man pages truncated. > > It's not truncated anymore when I use 'man -E ascii8' as stated above. [...] > Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Please file a *new* bug against man-db, including the output when using man's --debug switch. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318885: libc6: please drop libdb1-compat dependency for etch
Package: libc6 Version: 2.3.2.ds1-22, 2.3.5-2 Severity: wishlist libc's dependency on libdb1-compat was a transitional measure for sarge, and is not required for etch. Please remove that dependency so that libdb1-compat can be dropped to Priority: extra. Thanks, -- Colin Watson (libdb1-compat maintainer)[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318920: bugs.debian.org: Versioned bugs: Please add a "Distribution: all" option
On Mon, Jul 18, 2005 at 06:33:12PM +0200, Frank Küster wrote:
> Package: bugs.debian.org
> Severity: wishlist
>
> It would be nice to have the possibility to see all (open) bugs of a
> package, regardless of distribution.
>
> This just occurred to me when I looked at ingerman which has no bugs in
> the default view, and none in stable, either - would be nice to check
> whether there are any with a single request.
The default view should provide this already. The list of bugs you see
is the same no matter what &dist= and &version= options you use; they
just get sorted into different piles ("open", "closed", "not applicable
to this version", etc.).
> By the way, it is unclear to me how versioning works with archived bugs
> - is there some explanation somewhere?
It's still all in flux, so not yet. For now the best I can do is what I
wrote in the announcement:
The meaning of the distribution-specific tags (woody, sarge, and so
on) has changed. We now have a good mechanism to say "this bug has
been fixed since sarge was released", so there's no longer any need to
have a tag for that. However, it's still useful to have a tag to mark
bugs that you're planning to fix in, say, a stable point release. So,
for instance, the sarge tag now means "don't archive this bug until it
has been fixed in a version in sarge".
This hasn't yet been implemented, though, and there's still some
discussion about exactly what should happen.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319072: devscripts: please add archpath
Package: devscripts
Version: 2.8.14
Severity: wishlist
To go along with svnpath in current trunk, here's an archpath. It works
with either tla or baz, and has a fairly similar interface to svnpath
except that the branch handling is a bit different to support the way
one normally works in arch (or at least how I normally work).
Thanks,
--
Colin Watson [EMAIL PROTECTED]
Index: debian/control
===
--- debian/control (revision 166)
+++ debian/control (working copy)
@@ -11,12 +11,13 @@
Conflicts: debmake (<< 3.5), dupload (<< 2.1), suidmanager (<< 0.51)
Depends: dpkg-dev, debianutils (>= 2.0), perl (>= 5.8), sed (>= 2.95),
${shlibs:Depends}, ${misc:Depends}
Recommends: fakeroot
-Suggests: devscripts-el, build-essential, cvs-buildpackage, cvs | svn,
debian-keyring, dupload (>=2.1) | dput, gnupg (>= 1.0.7), gnuplot,
libdigest-md5-perl, libtimedate-perl, libwww-perl, lintian | linda, mailx,
patch, patchutils, ssh, strace, wdiff, wget, www-browser
+Suggests: devscripts-el, build-essential, cvs-buildpackage, cvs | svn, tla |
bazaar, debian-keyring, dupload (>=2.1) | dput, gnupg (>= 1.0.7), gnuplot,
libdigest-md5-perl, libtimedate-perl, libwww-perl, lintian | linda, mailx,
patch, patchutils, ssh, strace, wdiff, wget, www-browser
Description: Scripts to make the life of a Debian Package maintainer easier
Contains the following scripts, dependencies/recommendations shown in
brackets afterwards:
- annotate: prepend time and stream (O for stdout E for sterr) for every
line of output
+ - archpath: print tla/Bazaar package names [tla | bazaar]
- bts: a command-line tool for manipulating the BTS [www-browser,
libwww-perl, mailx]
- checkbashisms: check whether a /bin/sh script contains any common
Index: Makefile
===
--- Makefile(revision 166)
+++ Makefile(working copy)
@@ -8,7 +8,7 @@
SH_FILES = cvs-debi.sh cvs-debrelease.sh debclean.sh debrelease.sh \
debrsign.sh debsign.sh dpkg-genbuilddeps.sh mergechanges.sh \
tagpending.sh uscan.sh uupdate.sh wnpp-alert.sh whodepends.sh \
- annotate.sh
+ annotate.sh archpath.sh
LIBS = libvfork.so.0
Index: archpath.1
===
--- archpath.1 (revision 0)
+++ archpath.1 (revision 0)
@@ -0,0 +1,63 @@
+.TH ARCHPATH 1 "Debian Utilities" "DEBIAN" \" -*- nroff -*-
+.SH NAME
+archpath \- output arch (tla/Bazaar) archive names, with support for branches
+.SH SYNOPSIS
+.B archpath
+.br
+.B archpath
+.I branch
+.br
+.B archpath
+.IR branch -- version
+.SH DESCRIPTION
+.B archpath
+is intended to be run in an arch (tla or Bazaar) working copy.
+.PP
+In its simplest usage,
+.B archpath
+with no parameters outputs the package name
+(archive/category--branch--version) associated with the working copy.
+.PP
+If a parameter is given, it may either be a branch--version, in which case
+.B archpath
+will output a corresponding package name in the current archive and
+category, or a plain branch name (without \(oq--\(dq), in which case
+.B archpath
+will output a corresponding package name in the current archive and
+category and with the same version as the current working copy.
+.PP
+This is useful for branching.
+For example, if you're using Bazaar and you want to create a branch for a
+new feature, you might use a command like this:
+.PP
+.RS
+.nf
+.ft CW
+baz branch $(archpath) $(archpath new-feature)
+.ft R
+.fi
+.RE
+.PP
+Or if you want to tag your current code onto a \(oqreleases\(cq branch as
+version 1.0, you might use a command like this:
+.PP
+.RS
+.nf
+.ft CW
+baz branch $(archpath) $(archpath releases--1.0)
+.ft R
+.fi
+.RE
+.PP
+That's much easier than using \(oqbaz tree-version\(cq to look up the
+package name and manually modifying the result.
+.SH AUTHOR
+.B archpath
+was written by
+.na
+Colin Watson <[EMAIL PROTECTED]>.
+.ad
+Like
+.BR archpath ,
+this manual page is released under the GNU General Public License,
+version 2 or later.
Index: archpath.sh
===
--- archpath.sh (revision 0)
+++ archpath.sh (revision 0)
@@ -0,0 +1,45 @@
+#! /bin/sh -e
+
+# Output arch (tla/Bazaar) archive names, with support for branches
+
+# Copyright (C) 2005 Colin Watson <[EMAIL PROTECTED]>
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option) any
+# later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Publi
Bug#319121: FTBFS: Missing build-dependency on libselinux1-dev
reassign 319121 xorg-x11 6.8.2.dfsg.1-2 thanks On Tue, Jul 19, 2005 at 07:22:27AM -0700, Matt Kraai wrote: > Package: groff > Version: 1.18.1.1-8 > Severity: serious > Tags: patch > > groff fails to build because it cannot find libselinux: > > gcc -m32 -o gxditview -g -O2 -fno-strict-aliasing -L/usr/X11R6/lib > xditview.o Dvi.o draw.o font.o lex.o page.o parse.o XFontName.o > DviChar.o device.o -lXaw -lXmu -lXt -lSM -lICE -lXpm -lXp -lXext -lX11 > -lselinux -lm > /usr/bin/ld: cannot find -lselinux There is no mention of "selinux" anywhere in the groff source package, so it feels inappropriate to build-depend on it directly. The -lselinux is being autogenerated by xmkmf. For what it's worth, my build-dependencies are currently: Build-Depends: byacc, debhelper (>= 3.0.9), gs, netpbm, psutils, xutils, libxaw7-dev | libxaw-dev, xlibs-dev (*cough* yes, I know I should stop using xlibs-dev) Please either make some appropriate -dev package, or perhaps even xutils, depend on libselinux-dev, or else stop telling arbitrary programs to link with libselinux. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319072: devscripts: please add archpath
tags 319072 patch
thanks
On Tue, Jul 19, 2005 at 06:23:55PM +0100, Colin Watson wrote:
> Package: devscripts
> Version: 2.8.14
> Severity: wishlist
>
> To go along with svnpath in current trunk, here's an archpath. It works
> with either tla or baz, and has a fairly similar interface to svnpath
> except that the branch handling is a bit different to support the way
> one normally works in arch (or at least how I normally work).
... and here's the corresponding debcommit patch. I also fixed the
broken NAME header in its man page.
--
Colin Watson [EMAIL PROTECTED]
Index: debcommit.pl
===
--- debcommit.pl(revision 171)
+++ debcommit.pl(working copy)
@@ -1,6 +1,6 @@
#!/usr/bin/perl
-=head1 NAME debcommit
+=head1 NAME
debcommit - commit changes to a package
@@ -11,8 +11,8 @@
=head1 DESCRIPTION
debcommit generates a commit message based on new text in debian/changelog,
-and commits the change to a package's cvs or svn repository. It must be run
-in a cvs or svn working copy for the package.
+and commits the change to a package's cvs, svn, or arch repository. It must
+be run in a cvs, svn, or arch working copy for the package.
=head1 OPTIONS
@@ -21,7 +21,7 @@
=item -r --release
Commit a release of the package. The version number is determined from
-debian/changelog, and is used to tag the package in cvs or svn.
+debian/changelog, and is used to tag the package in cvs, svn, or arch.
Note that svn tagging conventions vary, so debcommit uses
L to determine where the tag should be placed in the
@@ -90,6 +90,16 @@
elsif (-d "CVS") {
return "CVS";
}
+ elsif (-d "{arch}") {
+ # I don't think we can tell just from the working copy
+ # whether to use tla or baz, so try baz if it's available,
+ # otherwise fall back to tla.
+ if (system ("baz --version >/dev/null 2>&1") == 0) {
+ return "baz";
+ } else {
+ return "tla";
+ }
+ }
else {
die "not in a cvs or subversion working copy\n";
}
@@ -115,6 +125,11 @@
die "commit failed\n";
}
}
+ elsif ($prog eq 'tla' || $prog eq 'baz') {
+ if (! action($prog, "commit", "-s", $message)) {
+ die "commit failed\n";
+ }
+ }
else {
die "unknown program $prog";
}
@@ -143,14 +158,37 @@
die "failed tagging with $tag\n";
}
}
+ elsif ($prog eq 'tla' || $prog eq 'baz') {
+ my $archpath=`archpath`;
+ chomp $archpath;
+ my $tagpath=`archpath releases--\Q$tag\E`;
+ chomp $tagpath;
+ my $subcommand;
+ if ($prog eq 'baz') {
+ $subcommand="branch";
+ } else {
+ $subcommand="tag";
+ }
+
+ if (! action($prog, $subcommand, $archpath, $tagpath)) {
+ die "failed tagging with $tag\n";
+ }
+ }
}
sub getmessage {
my $ret;
- if ($prog eq 'cvs' || $prog eq 'svn') {
+ if ($prog eq 'cvs' || $prog eq 'svn' ||
+ $prog eq 'tla' || $prog eq 'baz') {
$ret='';
- foreach my $line (`$prog diff debian/changelog`) {
+ my $subcommand;
+ if ($prog eq 'cvs' || $prog eq 'svn') {
+ $subcommand = 'diff';
+ } else {
+ $subcommand = 'file-diff';
+ }
+ foreach my $line (`$prog $subcommand debian/changelog`) {
next unless $line=~/^\+ /;
$line=~s/^\+ //;
next if $line=~/^\s*\[.*\]\s*$/; # maintainer name
Bug#319037: BTS version tracking
On Tue, Jul 19, 2005 at 10:34:23PM -0700, Brian Nelson wrote: > Colin Watson <[EMAIL PROTECTED]> writes: > > The 'reopen' command takes an optional submitter argument, so it was > > difficult to get a version in here unambiguously. Instead, we've > > introduced a new 'found' command, which says "I've found the bug in this > > version of the package". You can use this whether the bug is open or > > closed; if the bug's closed and you give a version more recent than the > > last recorded fixed version, the bug will be considered open again. > > > > found 1234567 1.3-2 > > Shouldn't that be, "you give a version more recent than *or equal to* > the last recorded fixed version..."? Mm, right, that's what I meant to say. > What if the maintainer uploads a version, say 1.3-2 (which is still the > most recent version), which supposedly fixes bug 1234567. However, I > test it and find that it's actually not fixed. Presumably, I would do: > > found 1234567 1.3-2 > > However, since 1.3-2 is equal to the current version, the BTS would > erroneously think that the bug is fixed. That does seem to match > reality: > > http://bugs.debian.org/316089 Yes, this is a bug in version tracking: it's a canonicalisation problem between various internal representations of versions in debbugs, reported as bug #319037. Fortunately I don't think it's *too* hard to solve ... -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319244: openssh-server: Build the package with the OpenSSH LDAP public key patch (openssh-lpk)
On Wed, Jul 20, 2005 at 06:55:12PM +0200, David Ammouial wrote: > OpenSSH LDAP public key patch allows OpenSSH to fetch authorized > public keys for an account from an LDAP server. > > This patch is a very useful and clever way to centralize public > key authentication information into an LDAP server, where password > authentication already is. > > Moreover, the patch is now stable and well tested. If so, it should be relatively easy for somebody who knows it well to get it integrated by Portable OpenSSH upstream. This patch adds a lot of server configuration options, and I do not want to integrate patches like that in Debian. I've been bitten in the past by doing so and then having upstream change the names of the configuration options on me, which means that I'm stuck maintaining compatibility glue forever. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319072: devscripts: please add archpath
On Wed, Jul 20, 2005 at 03:08:18PM +0200, Filippo Giunchedi wrote:
> On Wed, Jul 20, 2005 at 01:33:03PM +0100, Colin Watson wrote:
> > On Tue, Jul 19, 2005 at 06:23:55PM +0100, Colin Watson wrote:
> > > To go along with svnpath in current trunk, here's an archpath. It works
> > > with either tla or baz, and has a fairly similar interface to svnpath
> > > except that the branch handling is a bit different to support the way
> > > one normally works in arch (or at least how I normally work).
> >
> > ... and here's the corresponding debcommit patch. I also fixed the
> > broken NAME header in its man page.
>
> bad timing, I've just uploaded 2.9 to unstable
> applied in svn nevertheless :)
Thanks!
Sorry to flood you with patches, but after some testing here's a further
patch that produces slightly neater output: it's generally good not to
make summary lines of changesets too long, so, if the summary would
exceed 72 characters or be on multiple lines, this patch produces a
shorter summary by cutting it off at the last bit of whitespace before
that and replacing the rest with "...", and uses the full text of the
message as the log message.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
Index: debcommit.pl
===
--- debcommit.pl(revision 175)
+++ debcommit.pl(working copy)
@@ -126,7 +126,17 @@
}
}
elsif ($prog eq 'tla' || $prog eq 'baz') {
- if (! action($prog, "commit", "-s", $message)) {
+ my $summary=$message;
+ $summary=~s/^((?:\* )?[^\n]{1,72})(?:(?:\s|\n).*|$)/$1/ms;
+ my @args;
+ if ($summary eq $message) {
+ $summary=~s/^\* //s;
+ @args=("-s", $summary);
+ } else {
+ $summary=~s/^\* //s;
+ @args=("-s", "$summary ...", "-L", $message);
+ }
+ if (! action($prog, "commit", @args)) {
die "commit failed\n";
}
}
Bug#319072: devscripts: please add archpath
On Wed, Jul 20, 2005 at 09:21:07PM +0200, Filippo Giunchedi wrote: > On Wed, Jul 20, 2005 at 07:39:41PM +0100, Colin Watson wrote: > > Sorry to flood you with patches, but after some testing here's a further > > patch that produces slightly neater output: it's generally good not to > > make summary lines of changesets too long, so, if the summary would > > exceed 72 characters or be on multiple lines, this patch produces a > > shorter summary by cutting it off at the last bit of whitespace before > > that and replacing the rest with "...", and uses the full text of the > > message as the log message. > > I like the idea, I wonder if makes sense to turn this into a commandline > option > (I guess tla's file-diffs are rather verbose, right?) as usually svn/cvs diff > output isn't that long. It's not about the verbosity of tla's file-diffs; it's simply if you've written a longish changelog entry. Arch changesets have separated "summary" and "log" fields, unlike CVS or Subversion, so I think it makes sense to use them. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319378: libusb: need to remove debian/tmp-udeb on clean
Package: libusb Version: 2:0.1.10a-17 Severity: normal Hi, Following my earlier udeb patch, note that you need to 'rm -rf debian/tmp-udeb' during 'debian/rules clean', since it's created during the install target. Sorry I missed that earlier. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314289: to fix problem, reenable POSIX_THREADS (patch included)
On Thu, Jul 21, 2005 at 08:57:49PM -0700, Jonathan Walther wrote: > Disabling POSIX_THREADS was the problem. Here is a patch that reenables > them (which will reopen other, less important bugs). Sorry, I'm not going to re-enable POSIX threads across the board; upstream are vehemently opposed to it and I do need upstream help from time to time. Doing so would reopen other bugs which are equally severe. It's possible that I may create a separate sshd-pthreads binary if there is no alternative. In the meantime, what's in your PAM configuration? I'd like to narrow this down to particular modules. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319370: lintian: duplicate fields in debian/control erroneously tagged as errors
On Fri, Jul 22, 2005 at 09:14:43AM +0200, Marc 'HE' Brockschmidt wrote: > Marco van Zwetselaar <[EMAIL PROTECTED]> writes: > > Probably as a consequence of the fix for bug #299792, lintian now flags > > duplicate fields in different paragraphs of debian/control as an error > > (debian-control-with-duplicate-fields). > > No. The check "knows" about different paragraphs and should only warn > about duplicate fields in one paragraph. Could you please send the > debian/control file ([gb]zipped!) that had the problems? partimage suffers from this, because the line between two of its paragraphs contains a single space rather than being zero-length; lintian's check currently requires a zero-length line. Since parsecdata() in /usr/lib/dpkg/controllib.pl strips off trailing spaces before splitting paragraphs, I've changed lintian to do the same. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319506: groff-base: www.tmac missing
tags 319506 pending thanks On Fri, Jul 22, 2005 at 05:49:35PM +0200, Fabian Pietsch wrote: > www.tmac is included in groff, but not in groff-base. > > If only groff-base is installed, which was the case on my system, > this leads to all uses of .URL macros being skipped in the man page > output, e.g. groff(1)'s AVAILABILITY section becomes unreadable > (if not useless). Thanks, fixed for my next upload. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319638: [l10n] Initial Czech translation of trn4 debconf messagesd
tags 319638 pending thanks On Sat, Jul 23, 2005 at 06:29:14PM +0200, Miroslav Kure wrote: > Package: trn4 > Severity: wishlist > Tags: l10n, patch > > Hi, in attachement there is initial Czech translation (cs.po) of > trn4 debconf messages, please include it. Thanks, committed to my repository. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319902: kbd-chooser contains old fork of code from kbd, which is hard to update
Package: kbd-chooser Version: 1.16 Severity: normal kbd-chooser contains several files which were taken from the kbd package and hacked up for use in d-i. These files are now quite out of date (they date from kbd 1.08, while the current upstream version is 1.12), and it's unclear whether or indeed how to merge upstream changes back into kbd-chooser. I've been trying to track down some problems with Unicode input, and it would be much easier to figure out what's going on if we were using approximately the same code in the installer as we are in the installed system. Ideally, the kbd source package would produce a suitable udeb (maybe containing a library that kbd-chooser can link to, to save the overhead of an additional executable?), but I don't know kbd-chooser's exact requirements so I'm filing this bug here first. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319952: locales not take into account when output is redirected
On Tue, Jul 26, 2005 at 12:09:04AM +0200, Bas Zoetekouw wrote:
> Package: man-db
> Version: 2.4.3-1
> Severity: normal
>
> It looks like man outputs only ASCII7 text if the output is redirected
> to a file or a pipe. This even happens if the locale is explicitly
> specified on the command line.
>
> For example, set your locale to de_DE.UTF-8, and compare the outputs
> of "man chsh", "man chsh|less" and "man -L de_DE.UTF-8|less". The
> first one outputs nice utf8 German umlaut chars, but these chars are
> simply dropped in the latter two cases.
>
> This breaks programs such as pinfo, which uses man as a backend for
> displaying man pages.
>
> I would suggest that man just looks at the current locale (or adding a
> command line param that forces such behaviour). Anyone who
> wants a clean ASCII7 text can simply set the correct locale, or
> specify -7 on the command line.
Actually, all locale support is still present. The problem is that man
pages being output to a file or a pipe are now filtered through 'col
-b', the intent of which was simply:
o When stdout is not a terminal, man pages will be formatted in
plain text without the use of backspace or ANSI formatting
characters.
Unfortunately, and unintentionally, this clobbers characters that aren't
printable ASCII. Bah. 'col -b -p -x' is much better, but exhibits some
minor corruption ("ÜBERSICHT" at the start of a line has some garbage
before it, probably because col can't handle the overstruck "Ü").
Changing the arguments to col seems to be obviously the right thing to
do, but beyond that I'm not sure what to do about this. I could reassign
to bsdmainutils in the hope that col can be changed to deal with UTF-8
in UTF-8 locales, or I could just disable the col command in the
pipeline for multibyte locales. The latter would be a shame given that
it means everyone has to go back to putting explicit 'col -b' in
makefiles and things again, and the breakage pending a col fix is
confined to just a few places ...
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with <= 48mb RAM
On Tue, Jul 26, 2005 at 12:45:48AM +0100, Luke Kenneth Casson Leighton wrote: > On Mon, Jul 25, 2005 at 03:51:22PM -0700, Matt Taggart wrote: > > It would probably be a good idea to record what ought to work in any given > > release and maybe have an ongoing idea what it should be. The answer might > > be > > architecture specific? ISTR either the d-i team or apt/dpkg/aptitude trying > > to > > get sarge systems with 32mb working towards the end of the release. > > if you really want to try that out, without messing with > older hardware, try usin XEN. No need to mess with older hardware *or* Xen. Use the mem=32M (etc.) kernel parameter. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320108: Finnish translation nitpick
On Wed, Jul 27, 2005 at 01:03:59AM +, Antti-Juhani Kaijanaho wrote: > When no manual page for a system call can be found, man says (in the > Finnish locale) "Sovellukselle foo ei ole opastesivua", literally > translated as 'The application foo has no help page'. While the choice > of words may be appropriate for section 1 and section 8 pages, it is not > for other sections (and you really don't know if the man page being > looked would be in section 1 or 8, or not, when you don't find the > page). > > I appreciate that this is a rather difficult translation problem (and > hence I don't have a suggestion for a correction), but the current > wording is suboptimal. It's definitely an issue with just the Finnish translation. The msgid is "No manual entry for %s", which is pretty neutral among sections. Lauri, you contributed this translation - can you supply an improvement? Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#243085: No 'continue' button is confusing for new users
On Tue, Jul 26, 2005 at 07:33:43PM -0500, Matthew Dempsky wrote: > At our last installfest, at least one new user was confused by the lack > of a 'Continue' or 'Next' button to correspond with the 'Go back' > button. This was with Ubuntu 5.04, but since the bug is still open I > presume it's still valid for Debian. > > Is there still any intention to add the 'Continue' buttons back? I added it back for the string and password types in cdebconf 0.81, in response to bug #257969. This bug also mentions select; do you happen to remember exactly which questions caused confusion? Also, note that as of cdebconf 0.81 there's a help line at the bottom of the screen telling you to press Enter to activate buttons; that's not ideal here, but maybe it will provide a clue. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320111: Chopping a sentence in more than one part is bad for localization efforts
tags 320111 fixed-upstream thanks On Wed, Jul 27, 2005 at 01:17:57AM +, Antti-Juhani Kaijanaho wrote: > (This is really a separate issue from my other report. Honest:) > > In a Finnish locale, "man 2 foo" says > > Sovellukselle foo ei ole opastesivua in section 2 > > I'm sure you'll be able to spot the strangeness without knowing Finnish: > a part of that message is untranslated. > > While an untranslated message is undoubtedly the translator's fault, in > this case I also see a programmer error. The simple rule for a > programmer is, the smallest unit of text you should ever mark for > translation is a complete sentence (with some exceptions, which do not > apply here). In this case, which is easily verified by looking at > ltrace output, you construct that message by calling printf twice: > > fprintf(0xb7fd0f60, "Sovellukselle %s ei ole opastesi"..., "foo") = 36 > dcgettext(0, 0x805a2f0, 5, 0xb7eb1f38, 0xb7ea9438) = 0x805a2f0 > fprintf(0xb7fd0f60, " in section %s\n", "2") = 14 > > You really shouldn't do that. Thanks for catching this. That bizarre code predates my time as maintainer, and evidently I never noticed it enough to clean it up. Fixed now: Wed Jul 27 11:29:02 BST 2005 Colin Watson <[EMAIL PROTECTED]> * src/man.c (gripe_no_man): Don't emit a different message in the troff case; it's extra translation load and nobody really cares about the distinction. Avoid splitting up a sentence into two translatable pieces (Debian bug #320111). * po/ca.po, po/cs.po, po/da.po, po/de.po, po/es.po, po/fi.po, po/fr.po, po/it.po, po/ja.po, po/pl.po, po/pt_BR.po, po/ro.po, po/ru.po, po/sv.po: Update with msgmerge. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#227503: marked as done (An error occurred. Dammit. Error was: 222059 state kill-init at end.)
reopen 227503 thanks On Wed, Jul 27, 2005 at 11:36:50PM -0700, Debian Bug Tracking System wrote: > Date: Wed, 27 Jul 2005 19:35:54 -0400 > From: Filipus Klutiero <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Out of date? > > This looks out of date, as accessing > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=222059 shows a > certainly weird but error-less page. Otherwise, shouldn't it be merged > with 207992? Please leave this bug open; the general problem (namely that process doesn't append to bug logs in a safe manner) remains an issue. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#258623: analysis
On Tue, Jul 13, 2004 at 03:56:53PM -0400, Joey Hess wrote: > The grub parser failed because the SuSE menu.lst uses > (hdn,m)/path/to/file notation, which it does not understand, as noted in > its TODO. Furthermore, it fails because the SuSE menu.lst makes use of the fact that 'boot' is implicit at the end of a menu entry. Fedora also makes use of this (https://bugzilla.ubuntu.com/show_bug.cgi?id=8203). I think at least this part is quite a bad bug that we should fix for sarge final; I'm working on a patch now. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#258623: analysis
On Sat, Mar 26, 2005 at 04:37:30PM +, Colin Watson wrote: > On Tue, Jul 13, 2004 at 03:56:53PM -0400, Joey Hess wrote: > > The grub parser failed because the SuSE menu.lst uses > > (hdn,m)/path/to/file notation, which it does not understand, as noted in > > its TODO. > > Furthermore, it fails because the SuSE menu.lst makes use of the fact > that 'boot' is implicit at the end of a menu entry. Fedora also makes > use of this (https://bugzilla.ubuntu.com/show_bug.cgi?id=8203). I think > at least this part is quite a bad bug that we should fix for sarge > final; I'm working on a patch now. This part should be fixed in os-prober 1.05 (I didn't test with an actual Fedora installation, but constructed a test harness to try it out in a normal system). -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301694: lsb-base: missing Replaces
Package: lsb-base Version: 2.0-6 Severity: serious Justification: breaks upgrades With lsb-core 2.0-5 installed: Unpacking lsb-base (from .../lsb-base_2.0-6_all.deb) ... dpkg: error processing /var/cache/apt/archives/lsb-base_2.0-6_all.deb (--unpack): trying to overwrite `/lib/lsb/init-functions', which is also in package lsb-core lsb-core's dependency means that this'll happen to everyone upgrading from systems with previous versions of lsb-core (although a second installation run will clear it up), hence the severity. Please add Replaces: lsb-core (<< 2.0-6). Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301117: [jwm@horde.net: libapache2-mod-ldap-userdir upload]
On Mon, Mar 28, 2005 at 10:48:44AM -0500, John Morrissey wrote: > Date: Mon, 28 Mar 2005 10:47:00 -0500 > From: John Morrissey <[EMAIL PROTECTED]> > To: Fabio Massimo Di Nitto <[EMAIL PROTECTED]> > Subject: libapache2-mod-ldap-userdir upload > > Hi Fabio-- > > You had done the initial upload for my libapache2-mod-ldap-userdir package. > I've released a new version and fixed an RC bug that was filed against it; > would you please upload the new version (lintian(1) runs clean on it)? The > files are up at: > > http://horde.net/~jwm/debian/ I've done this sponsored upload. Note that there's a stray .la file in the diff; you might want to make some clean rule remove that, at some point (I didn't worry about it for this upload because the build always seems to regenerate it). Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302004: debconf: dpkg-reconfigure doesn't work with debconf.py
Package: debconf
Version: 1.4.46
Severity: normal
https://bugzilla.ubuntu.com/show_bug.cgi?id=8345 reports:
since the check in debconf-1.4.42ubuntu4/debconf.py is
if not os.environ.has_key('DEBIAN_HAS_FRONTEND'):
this doesn't work in dpkg-reconfigure:
$ENV{DEBIAN_HAS_FRONTEND}='';
cdebconf does a unsetenv on this, so perhaps change to:
delete $ENV{DEBIAN_HAS_FRONTEND};
I've checked against current trunk and this still applies.
Thanks,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316722: dbs: please add support for new dpkg-architecture
Package: dbs
Version: 0.35
Severity: important
Justification: needed to fix other important bugs, e.g. #314713
Tags: patch
Hi,
Please apply the attached patch to support the new
DEB_{BUILD,HOST}_ARCH_{CPU,OS} variables emitted by new
dpkg-architecture (>= 1.13.2), and to add compatibility code for old
dpkg-architecture so that people don't need to build-depend on new
versions of dpkg-dev in order to use this feature.
The dpkg-architecture change is described here:
http://lists.debian.org/debian-devel-announce/2005/06/msg00010.html
We need to get this sorted out soon so that packages build-depending on
dbs can use consistent compatibility code; at the moment, such source
packages are building incorrect binary packages (#314713).
Thanks,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316722: dbs: please add support for new dpkg-architecture
On Sun, Jul 03, 2005 at 11:31:32AM +0100, Colin Watson wrote: > Please apply the attached patch Sorry, really attached this time. -- Colin Watson [EMAIL PROTECTED] --- dbs-0.35.orig/dpkg-arch.mk 2001-08-30 00:20:45.0 +0100 +++ dbs-0.35/dpkg-arch.mk 2005-07-03 11:23:22.0 +0100 @@ -1,7 +1,38 @@ # see dpkg-architecture(8) DEB_BUILD_ARCH := $(shell dpkg-architecture -qDEB_BUILD_ARCH) +DEB_BUILD_ARCH_CPU := $(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU 2>/dev/null) +DEB_BUILD_ARCH_OS := $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS 2>/dev/null) DEB_BUILD_GNU_CPU := $(shell dpkg-architecture -qDEB_BUILD_GNU_CPU) DEB_BUILD_GNU_SYSTEM := $(shell dpkg-architecture -qDEB_BUILD_GNU_SYSTEM) DEB_BUILD_GNU_TYPE := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +DEB_HOST_ARCH_CPU := $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU 2>/dev/null) +DEB_HOST_ARCH_OS := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS 2>/dev/null) +DEB_HOST_GNU_CPU := $(shell dpkg-architecture -qDEB_HOST_GNU_CPU) DEB_HOST_GNU_SYSTEM:= $(shell dpkg-architecture -qDEB_HOST_GNU_SYSTEM) DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) + +# Take account of old dpkg-architecture output. +ifeq ($(DEB_BUILD_ARCH_CPU),) + DEB_BUILD_ARCH_CPU := $(DEB_BUILD_GNU_CPU) + ifeq ($(DEB_BUILD_ARCH_CPU),x86_64) +DEB_BUILD_ARCH_CPU := amd64 + endif +endif +ifeq ($(DEB_BUILD_ARCH_OS),) + DEB_BUILD_ARCH_OS := $(subst -gnu,,$(DEB_BUILD_GNU_SYSTEM)) + ifeq ($(DEB_BUILD_ARCH_OS),gnu) +DEB_BUILD_ARCH_OS := hurd + endif +endif +ifeq ($(DEB_HOST_ARCH_CPU),) + DEB_HOST_ARCH_CPU := $(DEB_HOST_GNU_CPU) + ifeq ($(DEB_HOST_ARCH_CPU),x86_64) +DEB_HOST_ARCH_CPU := amd64 + endif +endif +ifeq ($(DEB_HOST_ARCH_OS),) + DEB_HOST_ARCH_OS := $(subst -gnu,,$(DEB_HOST_GNU_SYSTEM)) + ifeq ($(DEB_HOST_ARCH_OS),gnu) +DEB_HOST_ARCH_OS := hurd + endif +endif
Bug#314713: coreutils: Includes kill.1.gz when built with new dpkg
tags 314713 patch thanks On Fri, Jun 17, 2005 at 03:37:58PM -0700, Daniel Schepler wrote: > Package: coreutils > Version: 5.2.1-2 > Severity: important > > As the subject says, if I build coreutils with the new dpkg in sid, > the resulting package includes /usr/share/man/man1/kill.1.gz, which > makes it conflict with procps. Taking a quick look at debian/rules, > it appears this is because dpkg-architecture now returns "linux-gnu" > for DEB_HOST_GNU_SYSTEM. Assuming that the dbs patch I just sent as #316722 is applied as dbs 0.36, the attached patch corrects this problem. Cheers, -- Colin Watson [EMAIL PROTECTED] diff -u coreutils-5.2.1/debian/rules coreutils-5.2.1/debian/rules --- coreutils-5.2.1/debian/rules +++ coreutils-5.2.1/debian/rules @@ -75,17 +75,17 @@ mv $(d)/usr/share/man/man1/md5sum.1 $(d)/usr/share/man/man1/md5sum.textutils.1 # some things we don't do for hurd -ifneq ($(DEB_HOST_GNU_SYSTEM),gnu) +ifneq ($(DEB_HOST_ARCH_OS),hurd) # touch used to be in /usr/bin, don't break scripts ln -s /bin/touch $(d)/usr/bin/touch endif # remove stuff provided by other packages -ifeq ($(DEB_HOST_GNU_SYSTEM),linux) +ifeq ($(DEB_HOST_ARCH_OS),linux) # kill from procps is linux-specific rm -f $(d)/usr/bin/kill $(d)/usr/share/man/man1/kill.1 endif -ifneq ($(DEB_HOST_GNU_SYSTEM),gnu) +ifneq ($(DEB_HOST_ARCH_OS),hurd) rm -f $(d)/usr/bin/su $(d)/usr/share/man/man1/su.1 endif @@ -147,7 +147,7 @@ dh_link -a dh_compress -a dh_fixperms -a -ifeq ($(DEB_BUILD_GNU_SYSTEM),gnu) +ifeq ($(DEB_BUILD_ARCH_OS),hurd) chmod u+s $(d)/usr/bin/su endif dh_installdeb -a diff -u coreutils-5.2.1/debian/control coreutils-5.2.1/debian/control --- coreutils-5.2.1/debian/control +++ coreutils-5.2.1/debian/control @@ -3,7 +3,7 @@ Section: base Priority: required Standards-Version: 3.6.0 -Build-Depends: gettext (>= 0.10.37), debhelper, dh-buildinfo, perl-base, texinfo (>= 4.2), groff, help2man, dbs, autoconf (>= 2.57), automake1.8, libattr1-dev | not+linux-gnu, libacl1-dev | not+linux-gnu, bzip2, bison +Build-Depends: gettext (>= 0.10.37), debhelper, dh-buildinfo, perl-base, texinfo (>= 4.2), groff, help2man, dbs (>= 0.36), autoconf (>= 2.57), automake1.8, libattr1-dev | not+linux-gnu, libacl1-dev | not+linux-gnu, bzip2, bison Build-Conflicts: automake1.4 Package: coreutils
Bug#314645: moreinfo, unreproducible, downgrade
On Wed, Jun 29, 2005 at 03:10:35PM -0400, Justin Pryzby wrote: > I suggest tagging this moreinfo,unreproducible, and downgrading when > and if that is necessary for new packages to move to testing (which > should be deliberately prevented until #314289 is fixed). Please leave this bug in its current state. I'm sorry it's taken me so long to get round to investigating it, but from experience I have reason to suspect that it may well be valid and it certainly bears non-statistical investigation. Greg, I need to see your /etc/ssh/sshd_config in order to check this out. I would ask that the discussion about statistical analysis of login attempts please be taken to some different forum; while interesting, it merely means that I have much more information to trawl through when bringing myself up to speed on the bug, most of which is not really relevant to whether or not a timing attack on sshd is possible. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314289: experiencing the same issue
On Fri, Jul 01, 2005 at 02:49:42PM -0700, Adam McKenna wrote: > I'm experiencing the same issue with this package. Here's an strace -f of > the sshd process, starting after I typed my password (password removed). Could I have that strace with '-s 1024' or similar, so that I can see what the log messages were? In the trace you sent they're all cut off at a most unhelpful point. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#313044: /usr/bin/scp: scp: Atomic transfers?
merge 313044 313045 thanks On Sat, Jun 11, 2005 at 02:19:22PM +0200, Olaf van der Spek wrote: > When you transfer a file via scp, it appears the old file is truncated and > then written when bytes arrive. > This means the file is unusable while the transfer is in progress and this is > undesired for certain types of files. > Also, if the transfer is aborted the file is left in an invalid state. > Would it be possible to make transfers atomic? > > Advantages: > File remains valid during transfer. > File remains valid when transfer is aborted. To be honest, I doubt this will be implemented in scp. As http://www.openssh.org/faq.html#2.10 says: 2.10 - Will you add [foo] to scp? Short Answer: no. Long Answer: scp is not standardized. The closest thing it has to a specification is "what rcp does". Since the same command is used on both ends of the connection, adding features or options risks breaking interoperability with other implementations. New features are more likely in sftp, since the protocol is standardized (well, a draft standard), extensible, and the client and server are decoupled. That said, I suppose it would be possible to implement this such that it didn't break interoperability, so I'll leave the bug open. It would be fairly straightforward to write a script on top of scp (or sftp, for that matter) that does atomic transfers by 'scp ...' followed by 'ssh mv ...'. The only fiddly bit would be doing the command-line parsing. > When you upload a file while the destination file is in-use, you get the Text > file busy error. > Could this be avoided? > I'd guess either by trying an unlink when you get that error or by the atomic > transfers feature request. I think the only sane way to implement that would be by copying then atomically renaming, so I've merged the two bugs. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312312: woody->sarge upgrade updates ssh_host_key, but not ssh_host_key.pub
On Tue, Jun 07, 2005 at 08:25:52PM +1000, Vincent McIntyre wrote: > The title pretty much says it all. Apologes if I'm missing something, > but the upgrades I did during woody didn't remake the ssh_host_key. > Should this be happening when upgrading to the sarge version? > I didn't see this mentioned in a quick grep thru /usr/share/doc/ssh. > > I upgraded from 1:3.4p1-1.woody.3 to 1:3.8.1p1-8.sarge.4 today, > and noticed a change. [...] > md5sum /etc/ssh/ssh_host_key /old/etc/ssh/ssh_host_key > (just showing the first 4 bytes; but they differ all right) > 5cd1 /etc/ssh/ssh_host_key > 7b8d /old/etc/ssh/ssh_host_key I think I know what this might be. To confirm, could you compare the actual host key material? ssh-keygen -l -f /etc/ssh/ssh_host_key ssh-keygen -l -f /old/etc/ssh/ssh_host_key I'm betting that they're the same. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314956: Excess permission or bad ownership on file /var/log/btmp
tags 314956 pending thanks On Sun, Jun 19, 2005 at 09:53:31AM -0700, dean gaudet wrote: > openssh 4.x now tries to append to /var/log/btmp (on bad passwords for > example), but it's excessively anal about the permissions on that file. it > doesn't permit group or other to have any of read/write/execute. > > the default debian setup is this: > > -rw-rw-r-- 1 root utmp 3840 Jun 18 14:40 /var/log/btmp > > and there are legit reasons for group utmp writability... such as: > > -rwxr-sr-x 1 root utmp 306616 Nov 14 2004 /usr/bin/screen > > i really don't know what to recommend as the right fix for this... you > could disable USE_BTMP entirely, which was the pre-4.0 behaviour anyhow. > or modify it to permit the debian perms... I could persuade myself to cope with the latter option if it were just group utmp readability/writability, but the world-readability is completely contrary to the comment in openssh/loginrec.c: * The most common login failure is to give password instead of username. * So the _PATH_BTMP file checked for the correct permission, so that * only root can read it. I've disabled USE_BTMP in CVS. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314596: Cannot ssh OUT from host as non-root user
On Fri, Jun 17, 2005 at 11:29:04AM +0100, Alistair Cockeram wrote: > Since carefully upgrading to Sarge from an uptodate Woody install I can no > longer ssh out as a non root user to any other host. What are the permissions on that user's ~/.ssh/config? This might be #314347/#314649. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314649: Bug#314347: openssh-client: "Bad owner or permissions on $HOME/.ssh/config" check too aggressive
tags 314347 pending
thanks
On Wed, Jun 15, 2005 at 03:59:38PM -0500, Branden Robinson wrote:
> 1148 {0} [EMAIL PROTECTED]:~/packages/xorg-x11/svn/trunk/debian$ svn up
> Bad owner or permissions on /home/branden/.ssh/config
> svn: Connection closed unexpectedly
> 1149 {1} [EMAIL PROTECTED]:~/packages/xorg-x11/svn/trunk/debian$ l -l
> $HOME/.ssh/config
> -rw-rw-r-- 1 branden branden 125 Jun 26 2004 /home/branden/.ssh/config
> 1150 {0} [EMAIL PROTECTED]:~/packages/xorg-x11/svn/trunk/debian$ chmod 644
> /home/branden/.ssh/config
> 1151 {0} [EMAIL PROTECTED]:~/packages/xorg-x11/svn/trunk/debian$ svn up
> At revision 220.
>
> I think that check is excessively paranoid.
Evidently I made all my ~/.ssh/config files mode 0644 ages ago for some
other reason, since I never noticed this change in behaviour ...
> I can think of a few possibilities for resolving this bug:
[...]
> 2) Simply tolerate group-writable files if the group name in question is
>identical to the user name.
>
> 3) Alternatively or additionally to 2), ensure that the user is the only
>member of the group owning the group-writable file.
The combination of these two suggestions seems to be the best fix. I've
implemented this in CVS and sent a patch upstream.
> 5) As part of the many migrations done to the new openssh world order, walk
>/home and chmod g-w on all .ssh/config files. Some people might
>consider this intrusive, though, and it doesn't prevent the creation of
>new accounts with this problem.
That would run into problems with NFS, too.
On Fri, Jun 17, 2005 at 12:59:45PM -0400, Frederic Briere wrote:
> I assume this is an attempt to make sure ~/.ssh/config is 0600 or
> something.
Actually, it's really to check that it's not *writable* by other
parties. The relevant ChangeLog entry says:
- [EMAIL PROTECTED] 2004/04/18 23:10:26
[readconf.c readconf.h ssh-keysign.c ssh.c]
perform strict ownership and modes checks for ~/.ssh/config files,
as these can be used to execute arbitrary programs; ok markus@
NB. ssh will now exit when it detects a config with poor permissions
> * There's no mention of this behavior in the documentation
ssh(1) says:
$HOME/.ssh/config
This is the per-user configuration file. The file format
and configuration options are described in ssh_config(5).
Because of the potential for abuse, this file must have
strict permissions: read/write for the user, and not
accessible by others.
ssh_config(5) has similar text.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#313044: /usr/bin/scp: scp: Atomic transfers?
On Sun, Jul 03, 2005 at 05:04:17PM +0200, Olaf van der Spek wrote: > Colin Watson wrote: > > New features are more likely in sftp, since the protocol is > > standardized (well, a draft standard), extensible, and the client and > > server are decoupled. > > Does sftp support the scp usage like scp local_file remote_host:? > I don't care that much about exactly which protocol is used, but I do > care about the 'interface' and the sftp interface didn't appear to > provide the scp interface. Unfortunately, nobody's implemented this in OpenSSH yet. pscp (in the putty-tools package) supports an scp-like interface over sftp, so perhaps some day somebody will do that in OpenSSH too. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#268584: [INTL:ru] Russian translation man-db
On Mon, Jun 06, 2005 at 08:57:31PM +0400, Yuri Kozlov wrote: > On Sat, 4 Jun 2005 12:31:24 +0100 > Colin Watson <[EMAIL PROTECTED]> wrote: > >On Sun, Nov 07, 2004 at 02:42:59PM +, Colin Watson wrote: > >I've belatedly committed the program translation; thanks! > > > >The translation statistics with respect to current CVS are: > > > > 145 translated messages, 7 fuzzy translations. > > Updated version is attached. Committed, thanks. > >If you'd like CVS commit access to update this directly, that can be > >arranged. > > It is will be nice. OK, let me know your username on savannah.gnu.org and I'll add you. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
