Bug#642249: libnih: [INTL:de] Initial German translation
Are you happy to keep this german translation up to date on an ongoing basis? On Wed, Sep 21, 2011 at 1:35 PM, Chris Leick c.le...@vollbio.de wrote: Hi Scott, Scott James Remnant: I'm not sure what you mean by debconf' here? Oh, sorry. It's a mistake - you can ignore it. Kind regards, Chris
Bug#642249: libnih: [INTL:de] Initial German translation
If you can update on a bzr branch I can pull from, that would be superb. On Wed, Sep 21, 2011 at 1:45 PM, Chris Leick c.le...@vollbio.de wrote: Scott James Remnant: Are you happy to keep this german translation up to date on an ongoing basis? Good idea. What is the preferred way for updates?
Bug#642249: libnih: [INTL:de] Initial German translation
http://code.launchpad.net/libnih would be the place to start. On Wed, Sep 21, 2011 at 1:51 PM, Chris Leick c.le...@vollbio.de wrote: Scott James Remnant: If you can update on a bzr branch I can pull from, that would be superb. ok.
Bug#642249: libnih: [INTL:de] Initial German translation
No, I'll pull from you when you have a branch available On Wed, Sep 21, 2011 at 1:57 PM, Chris Leick c.le...@vollbio.de wrote: Scott James Remnant: http://code.launchpad.net/**libnih http://code.launchpad.net/libnihwould be the place to start. I will read the manpage of bazaar and when I'm ready, I will try to update my translation. (Is it already checked in?)
Bug#642249: libnih: [INTL:de] Initial German translation
I'm not sure what you mean by debconf' here? 2011/9/20 Chris Leick c.le...@vollbio.de ** Package: libnih Version: 1.0.3 Severity: wishlist Tags: l10n Hi, please find attached the inital German debconf translation of libnih. Kind regards, Chris
Bug#625257: libnih1: uninstallable in sid
On Mon, May 2, 2011 at 1:07 PM, brian m. carlson sand...@crustytoothpaste.net wrote: libnih1 depends on libc6 ( 2.12). libc6 2.13 is now in unstable, rendering libnih1 uninstallable. I'm not sure why such a strict dependency would be needed, but perhaps a mention in the documentation why might be appropriate if it is. That strict dependency appears to come from libc itself; it's not a source dep. Scott
Bug#625257: Strict dependencies due to __abort_msg
If upstart crashes, a crash dump is most definitely saved. Upstart handles SIGSEGV by catching it and forking a child and unmasking that signal in the handler - this means it's an Upstart child process that actually crashes and dumps core while the parent waits for it to exit and reaps it. This is sufficient to ensure the core dump actually hits disk or appropriate core handler. Also Upstart's code makes heavy use of assert to catch errors, so you'd most definitely want these dumped to disk as well. Finally libnih actually declares this a weak link anyway, so the versioned dependency is not strictly necessary at all. I'll upload a rebuild now, and see if it's possible to override dpkg-shlibs - since it's perfectly happy if a libc update drops that symbol. Scott On Mon, May 2, 2011 at 2:37 PM, brian m. carlson sand...@crustytoothpaste.net wrote: I've done some more looking into this bug, and it seems the reason that the dependency is so strict is that libnih1 depends on the __abort_msg symbol, which, since it is GLIBC_PRIVATE, triggers a stricter dependency. I personally think that the inflexibility of the dependencies outweighs the usefulness of the nih_log_abort_message. upstart is the only binary package using libnih1 from a non-libnih source package, and if upstart crashes, well, no crash dump will be saved and no debuggers will be run. Take from that what you will. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Bug#624442: RFA: libnih
I will adopt this; I'm the upstream author and will be adopting Upstart as well On Thu, Apr 28, 2011 at 6:46 AM, Michael Biebl bi...@debian.org wrote: Package: wnpp Severity: normal I request an adopter of the libnih package. The package should ideally be adopted together with upstart [1] Package description: libnih is a light-weight standard library of C functions to ease the development of other libraries and applications, especially those normally found in /lib. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624440
Bug#624440: RFA: upstart -- event-based init daemon
I will adopt this; I'm the upstream author, and have been wanting to get properly back into Debian for a while now. On Thu, Apr 28, 2011 at 6:43 AM, Michael Biebl bi...@debian.org wrote: Package: wnpp Severity: normal As I don't actively use upstart anymore I request an adopter for the upstart package. Ideally the package is adopted along with libnih, which is a library package used by upstart. A RFA bug for libnih will be filed separately. The package description is: upstart is a replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running.
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
On Wed, Jan 12, 2011 at 6:38 PM, Kurt Roeckx k...@roeckx.be wrote: On Wed, Jan 12, 2011 at 12:50:21AM -0600, Steve Langasek wrote: On Mon, Jan 10, 2011 at 09:17:33PM +0100, Kurt Roeckx wrote: A lot of the scripts currently in /etc/rcS.d/ come from the initscripts package. Is the alternative supposed to implement all the functionality by those scripts? Or do we expect them to run the scripts from /etc/rcS.d/ as 9.3.4. seems to suggest? Well, the initscripts package in Ubuntu does provide one script that's run in /etc/rcS.d (urandom) and several other scripts that are run in other runlevels (some in 0/6; some in 1; some in 2 3 4 5). But there's definitely a delta in the initscripts package when used with sysvinit vs. upstart. I'm not sure if this is something that needs to be specified in policy though, as opposed to just being worked through in the implementation. I'm fine with leaving it up to the implementation on exactly which part it does itself and which it takes from initscripts or somewhere else. But what I do expect is that in the end the system is in the same state, and I guess I sometimes think too much about the details of how this is supposed to happen. Does Ubuntu just ship a package with less scripts in initscripts, or does upstart lists somewhere which ones it wants or doesn't want? The Ubuntu initscripts package contains fewer and modified scripts (the plan is for it to not exist at all), since the conversion has been made for those tasks to be performed by Upstart jobs. (Systemd largely has support for those tasks built-in) What should packages do that want to have their script run at that time? For sysvinit scripts this is calling update-rc.d with S as the runlevel. I don't know if the alternatives support something like a runlevel, and which they support. I think this is covered already by requiring alternative init implementations to support running sysvinit scripts - rcS.d is definitely part of this, just as rc[0-6].d are. Do you think we should be more explicit about the supported runlevels? (It's awkward to talk about rc[0-6].d directly, precisely because this is an internal detail of sysv-rc vs. file-rc) So you're saying that rcS.d and rc[0-6].d will keep existing? I assumed it wouldn't exist anymore, or atleast not for all cases, and that update-rc.d would do something with it that's specific to the init system. I would have thought that rcS.d/rc[0-6].d are not compulsory parts, as replacement init systems may simply read the LSB headers from the top and allow them to be overridden in some way. To me, the update-rc.d/chkconfig style standard is the right one. Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
On Mon, Jan 10, 2011 at 8:17 PM, Kurt Roeckx k...@roeckx.be wrote: + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the file/etc/rcS.d//file + scripts and may not have a one-to-one correspondence with the init + scripts. + /p A lot of the scripts currently in /etc/rcS.d/ come from the initscripts package. Is the alternative supposed to implement all the functionality by those scripts? Or do we expect them to run the scripts from /etc/rcS.d/ as 9.3.4. seems to suggest? Well, in the systemd case, all the things those scripts used to do are built in and hardcoded in systemd itself. And in the Upstart case, there is a separate implementation of those as well. So yes, I think an init system should deal with core boot by itself, as sysvinit does with the initscripts package. I guess this means policy needs to specify what needs to be done ;-) (otherwise people may find they get a shock if systemd's hardcoded mounting doesn't match what they expected) Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558782: This patch is wrong
Upstart jobs are not supposed to have accompanying files in /etc/default. Please revert this patch in Debian (I will do so in Ubuntu) Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part
Bug#558782: This patch is wrong
On Tue, 2009-12-01 at 16:21 -0500, Joey Hess wrote: BTW, have you considered that some packages have other scripts than init scripts that source the default files. This includes cron jobs, acpi scripts, X session scripts, etc. There has been some scope creep there that could arguably be slightly beyond the original intent of defaults files, but would inarguably break if the defaults files were dropped. Upstarts goal is that for a given package, you'll have a single file in /etc/init that describes all of its services, tasks, cron jobs, etc. So they'll all share the common settings in that one file. Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part
Bug#543666: Add -b (boot) option
Package: hostname
Version: 2.95
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jaunty ubuntu-patch
In Ubuntu, we've applied the attached patch to achieve the following:
* Add -b option that allows the file specified by -F to be non-existant
or empty, in which case the default hostname of localhost will be set
if none is set currently.
We thought you might be interested in doing the same.
This patch removes the need for the logic in /etc/init.d/hostname.sh,
replacing it with a simple hostname -b -F /etc/hostname call. This
has a significant performance improvement (0.15s - 0.001s)
-- System Information:
Debian Release: 5.0
APT prefers jaunty-updates
APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500,
'jaunty-proposed'), (500, 'jaunty')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.28-15-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru hostname-2.95/hostname.c hostname-2.95ubuntu1/hostname.c
--- hostname-2.95/hostname.c 2007-12-27 11:45:12.0 +
+++ hostname-2.95ubuntu1/hostname.c 2009-08-26 13:21:18.0 +0100
@@ -5,7 +5,7 @@
*
* Usage: hostname [-d|-f|-s|-a|-i|-y]
* hostname [-h|-V]
- * hostname {name|-F file}
+ * hostname [-b] {name|-F file}
* dnsdomainname
*
* Authors: Peter Tobias tob...@et-inf.fho-emden.de
@@ -115,7 +115,7 @@
usage(FILE *stream)
{
fprintf(stream,
- Usage: hostname [-v] {hostname|-F file} set host name (from file)\n
+ Usage: hostname [-v] [-b] {hostname|-F file} set host name (from file)\n
domainname [-v] {nisdomain|-F file} set NIS domain name (from file)\n
hostname [-v] [-d|-f|-s|-a|-i|-y] display formated name\n
hostname [-v] display host name\n\n
@@ -127,6 +127,7 @@
-f, --fqdn, --longlong host name (FQDN)\n
-d, --domain DNS domain name\n
-y, --yp, --nis NIS/YP domain name\n
+ -b, --bootset default hostname if none available\n
-F, --fileread host name or NIS domain name from given file\n\n
This command can get or set the host name or the NIS domain name. You can\n
also get the DNS domain or the FQDN (fully qualified domain name).\n
@@ -261,13 +262,20 @@
}
char *
-read_file(char *filename)
+read_file(char *filename, int boot)
{
struct stat st;
FILE *fp;
char *buf;
- if ((fp = fopen(filename, r)) == NULL || fstat(fileno(fp), st) == -1
+ if ((fp = fopen(filename, r)) == NULL) {
+ if (boot)
+ return NULL;
+ else
+ err(1, NULL);
+ }
+
+ if (fstat(fileno(fp), st) == -1
|| (buf = (char *) malloc(st.st_size + 1)) == NULL)
err(1, NULL);
@@ -289,13 +297,15 @@
int
main(int argc, char **argv)
{
- char *progname, *name = NULL;
+ char *progname, *file = NULL, *name = NULL;
enum type_t type = DEFAULT;
+ int boot = 0;
int o;
static const struct option long_options[] =
{
{domain, no_argument, 0, 'd'},
+ {boot, no_argument, 0, 'b'},
{file, required_argument, 0, 'F'},
{fqdn, no_argument, 0, 'f'},
{help, no_argument, 0, 'h'},
@@ -315,7 +325,7 @@
if (!strcmp(progname, dnsdomainname))
type = DNS;
- while((o = getopt_long(argc, argv, adfF:h?isVvy, long_options, NULL)) != -1)
+ while((o = getopt_long(argc, argv, adfbF:h?isVvy, long_options, NULL)) != -1)
switch (o) {
case 'd':
type = DNS;
@@ -335,10 +345,11 @@
case 'y':
type = NIS;
break;
+ case 'b':
+ boot = 1;
+ break;
case 'F':
- if (name)
-free(name);
- name = read_file(optarg);
+ file = optarg;
break;
case 'v':
/* Does not do anything. */
@@ -354,7 +365,23 @@
usage(stderr);
}
- /* The hostname is the first non-option argument. */
+ /*
+ * Hostname may be read from a file, it's ok for this file to not
+ * exist or be empty if -b is given in which case we default to
+ * localhost if there is not one already set.
+ */
+ if (file) {
+ name = read_file(file, boot);
+ if (boot (name == NULL || name[0] == '\0')) {
+ free(name);
+
+ name = localhost();
+ if (name[0] == '\0')
+strcpy(name, localhost);
+ }
+ }
+
+ /* Otherwise the hostname is the first non-option argument. */
if (optind argc) {
/*
* It is an error to specify a host name as an argument, and to
diff -Nru hostname-2.95/hostname.1 hostname-2.95ubuntu1/hostname.1
--- hostname-2.95/hostname.1 2007-11-14 22:22:58.0 +
+++ hostname-2.95ubuntu1/hostname.1 2009-08-26 13:25:16.0 +0100
@@ -26,6 +26,8 @@
.PP
.B hostname
.RB [ \-v ]
+.RB [ \-b ]
+.RB [ \-\-boot ]
.RB [ \-F\ filename ]
.RB [ \-\-file\ filename ]
.RB [ hostname ]
@@ -110,6 +112,11 @@
.I \-a, \-\-alias
Display the alias name of the host (if used).
.TP
+.I \-b, \-\-boot
+Always set a hostname; this allows the file specified by \fI-F\fR to be
+non-existant or empty, in which case the default hostname
Bug#543666: updated patch
Package: hostname
Version: 2.95
Followup-For: Bug #543666
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jaunty ubuntu-patch
I've updated the patch since Linux actually sets the initial hostname to
(none) not , and we want to replace that with localhost too.
-- System Information:
Debian Release: 5.0
APT prefers jaunty-updates
APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500,
'jaunty-proposed'), (500, 'jaunty')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.28-15-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru hostname-2.95/hostname.c hostname-2.95ubuntu1/hostname.c
--- hostname-2.95/hostname.c 2007-12-27 11:45:12.0 +
+++ hostname-2.95ubuntu1/hostname.c 2009-08-26 14:54:04.0 +0100
@@ -5,7 +5,7 @@
*
* Usage: hostname [-d|-f|-s|-a|-i|-y]
* hostname [-h|-V]
- * hostname {name|-F file}
+ * hostname [-b] {name|-F file}
* dnsdomainname
*
* Authors: Peter Tobias tob...@et-inf.fho-emden.de
@@ -115,7 +115,7 @@
usage(FILE *stream)
{
fprintf(stream,
- Usage: hostname [-v] {hostname|-F file} set host name (from file)\n
+ Usage: hostname [-v] [-b] {hostname|-F file} set host name (from file)\n
domainname [-v] {nisdomain|-F file} set NIS domain name (from file)\n
hostname [-v] [-d|-f|-s|-a|-i|-y] display formated name\n
hostname [-v] display host name\n\n
@@ -127,6 +127,7 @@
-f, --fqdn, --longlong host name (FQDN)\n
-d, --domain DNS domain name\n
-y, --yp, --nis NIS/YP domain name\n
+ -b, --bootset default hostname if none available\n
-F, --fileread host name or NIS domain name from given file\n\n
This command can get or set the host name or the NIS domain name. You can\n
also get the DNS domain or the FQDN (fully qualified domain name).\n
@@ -261,13 +262,20 @@
}
char *
-read_file(char *filename)
+read_file(char *filename, int boot)
{
struct stat st;
FILE *fp;
char *buf;
- if ((fp = fopen(filename, r)) == NULL || fstat(fileno(fp), st) == -1
+ if ((fp = fopen(filename, r)) == NULL) {
+ if (boot)
+ return NULL;
+ else
+ err(1, NULL);
+ }
+
+ if (fstat(fileno(fp), st) == -1
|| (buf = (char *) malloc(st.st_size + 1)) == NULL)
err(1, NULL);
@@ -289,13 +297,15 @@
int
main(int argc, char **argv)
{
- char *progname, *name = NULL;
+ char *progname, *file = NULL, *name = NULL;
enum type_t type = DEFAULT;
+ int boot = 0;
int o;
static const struct option long_options[] =
{
{domain, no_argument, 0, 'd'},
+ {boot, no_argument, 0, 'b'},
{file, required_argument, 0, 'F'},
{fqdn, no_argument, 0, 'f'},
{help, no_argument, 0, 'h'},
@@ -315,7 +325,7 @@
if (!strcmp(progname, dnsdomainname))
type = DNS;
- while((o = getopt_long(argc, argv, adfF:h?isVvy, long_options, NULL)) != -1)
+ while((o = getopt_long(argc, argv, adfbF:h?isVvy, long_options, NULL)) != -1)
switch (o) {
case 'd':
type = DNS;
@@ -335,10 +345,11 @@
case 'y':
type = NIS;
break;
+ case 'b':
+ boot = 1;
+ break;
case 'F':
- if (name)
-free(name);
- name = read_file(optarg);
+ file = optarg;
break;
case 'v':
/* Does not do anything. */
@@ -354,7 +365,23 @@
usage(stderr);
}
- /* The hostname is the first non-option argument. */
+ /*
+ * Hostname may be read from a file, it's ok for this file to not
+ * exist or be empty if -b is given in which case we default to
+ * localhost if there is not one already set.
+ */
+ if (file) {
+ name = read_file(file, boot);
+ if (boot (name == NULL || name[0] == '\0')) {
+ free(name);
+
+ name = localhost();
+ if (name[0] == '\0' || !strcmp(name,(none)))
+strcpy(name, localhost);
+ }
+ }
+
+ /* Otherwise the hostname is the first non-option argument. */
if (optind argc) {
/*
* It is an error to specify a host name as an argument, and to
diff -Nru hostname-2.95/hostname.1 hostname-2.95ubuntu1/hostname.1
--- hostname-2.95/hostname.1 2007-11-14 22:22:58.0 +
+++ hostname-2.95ubuntu1/hostname.1 2009-08-26 13:25:16.0 +0100
@@ -26,6 +26,8 @@
.PP
.B hostname
.RB [ \-v ]
+.RB [ \-b ]
+.RB [ \-\-boot ]
.RB [ \-F\ filename ]
.RB [ \-\-file\ filename ]
.RB [ hostname ]
@@ -110,6 +112,11 @@
.I \-a, \-\-alias
Display the alias name of the host (if used).
.TP
+.I \-b, \-\-boot
+Always set a hostname; this allows the file specified by \fI-F\fR to be
+non-existant or empty, in which case the default hostname \fIlocalhost\fR
+will be used if none is yet set.
+.TP
.I \-d, \-\-domain
Display the name of the DNS domain. Don't use the command
.B domainname
Bug#510634: [Pkg-cups-devel] Bug#510634: cups doesn't allow introspection in dbus config file
On Mon, 2009-03-23 at 15:39 +0100, Martin Pitt wrote: Matthew Johnson [2009-01-03 22:36 +]: The cups config file for dbus doesn't allow introspection requests. Because all it does is send signals this isn't an RC issue, but it should have working introspection for those signals. As far as I can see, cups does not need any D-BUS configuration at all, since it does not provide any service. It only sends signals, which are allowed by default anyway. Thus I'm going to drop the file entirely. Because it emits signals, it should allow for introspection of the objects that emit the signal that details the name of the signal, number, name and type of its arguments, etc. This introspection is generally provided at the binding level, but you still need the policy to allow it (it's a method call on your object). Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part
Bug#510634: [Pkg-cups-devel] Bug#510634: cups doesn't allow introspection in dbus config file
On Mon, 2009-03-23 at 17:12 +0100, Martin Pitt wrote: Signals are all declared in an interface and emitted from an object. That's what I meant, there is nothing to query *against*. cupsd does not provide any d-bus object. It opens the bus, fires the signal, and tears it down again. It's really very primitive. This approach is really going to bite! Current practice is to always explicitly name the origin bus name when adding signal matches, many bindings are hardcoded to behave like this. Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Fri, 2009-03-20 at 00:40 +0100, Frans Pop wrote: I think my 2 cents are played out by now, so I'll drop things here. Maybe someone else will be willing to take up the batton. At least the issue is somewhat documented now. I'll inform others in Debian that the issue exists and fix things locally for my own use case. Doesn't Debian run depmod in the postinst of the kernel package - and iirc, again on boot anyway? In which case, you'd always have module files that match the version of depmod in the host environment not the build environment. Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Fri, 2009-03-20 at 12:05 +0100, Marco d'Itri wrote: On Mar 20, Scott James Remnant sc...@canonical.com wrote: Doesn't Debian run depmod in the postinst of the kernel package - and iirc, again on boot anyway? Not anymore on boot, but I can't see why depmod should NOT being run when the kernel is installed. Me neither. The only file in /lib/modules/2.x.y-z (other than the modules) we include in the kernel packages is modules.order. The rest of the modules.* come by running depmod when the package is installed; we also update it when any further packages containing modules for that kernel are installed. Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part
Bug#512013: Ubuntu patches
Package: libtool
Version: 2.2.6a-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu intrepid ubuntu-patch
We have a couple of patches in Ubuntu which you might want to apply:
- libltdl7-dev provides libltdl3-dev since the two are API-compatible.
- install libtool.info-*.gz as well. LP: #254182.
- force /bin/bash as shell for generated libtool script.
-- System Information:
Debian Release: lenny/sid
APT prefers intrepid-updates
APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'), (500,
'intrepid-proposed'), (500, 'intrepid')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.27-11-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u libtool-2.2.6a/debian/rules libtool-2.2.6a/debian/rules
--- libtool-2.2.6a/debian/rules
+++ libtool-2.2.6a/debian/rules
@@ -86,7 +86,7 @@
sed -i -e 's/^#.*prognam...@version@$$/ Debian-$(DEBIAN_REVISION)/'
libltdl/config/ltmain.m4sh
sed -i -e 's/^VERSION.*/VERSION=@VERSION@ Debian-$(DEBIAN_REVISION)/'
libltdl/config/ltmain.m4sh
./bootstrap
- ./configure --prefix=/usr $(confflags) CFLAGS=$(CFLAGS)
+ CONFIG_SHELL=/bin/bash /bin/bash ./configure --prefix=/usr $(confflags)
CFLAGS=$(CFLAGS)
touch config-stamp
diff -u libtool-2.2.6a/debian/control libtool-2.2.6a/debian/control
--- libtool-2.2.6a/debian/control
+++ libtool-2.2.6a/debian/control
@@ -64,6 +64,7 @@
Recommends: libtool
Conflicts: libtool ( 1.5.20), libtool1.4, libltdl3-dev
Replaces: libtool ( 1.5.20), libltdl3-dev
+Provides: libltdl3-dev
Depends: libltdl7 (= ${binary:Version})
Description: A system independent dlopen wrapper for GNU libtool
This package contains the header files and static libraries for the
diff -u libtool-2.2.6a/debian/libtool-doc.info
libtool-2.2.6a/debian/libtool-doc.info
--- libtool-2.2.6a/debian/libtool-doc.info
+++ libtool-2.2.6a/debian/libtool-doc.info
@@ -1,0 +2 @@
+doc/libtool.info*
diff -u libtool-2.2.6a/debian/changelog libtool-2.2.6a/debian/changelog
Bug#512013: Ubuntu patches
On Fri, 2009-01-16 at 19:29 +0100, Kurt Roeckx wrote: Someone else found a bug about this already. - force /bin/bash as shell for generated libtool script. Why are you doing that? I know someone (Clint?) has reported some problems using dash as /bin/sh I think, but I can't find the bug report for that now. I was atleast under the impression upstream was looking into it, no idea if it was fixed. Right - it was dash related. Colin Watson should remember more details. Did ubuntu have many problems switching to the libtool 2.2 version? No, we've had to go around updating things and teaching them about autoreconf - rather than the manual way they run commands in the wrong order, but generally it's been ok. Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part
Bug#511652: udev rules shouldn't be empty by default
On Thu, 2009-01-15 at 18:48 +0100, Richard Atterer wrote: On Tue, Jan 13, 2009 at 02:35:39AM +, Scott James Remnant wrote: * Modify the package so that the udev rules aren't actually installed by default, and instruct the user to copy out of examples and then modify; otherwise they'll get conffile hell forever after. Is this a general Ubuntu policy of no empty conffiles that you're implementing here? No, this is the Ubuntu policy that packages are not permitted to install into /etc/udev/rules.d and instead must install into /lib/udev/rules.d This matches the upstream udev software, it's Debian that's strange in using /etc for such things. Since this is a rules file that *requires* editing, it doesn't make sense to ship it in /lib - you can't edit it. You'd have to copy to /etc anyway. But also since this requires editing in a harmful way, it's not suitable for dpkg's conffile handling - anyone editing it would be doomed to conffile prompts if you ever changed the file - and these are not a simple resolution of keeping one or the other - you'd always have to redo your changes on the new file. Thus the best solution appears to be to use examples, which is what it's there for. You copy the file from examples, and edit to taste. Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part
Bug#511952: avoid apt-cache call if all information in lsb-release
Package: lsb
Version: 3.2-20
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu intrepid ubuntu-patch
*** /tmp/tmpLNnEJz
In Ubuntu, we've applied the attached patch to achieve the following:
* Since /etc/lsb-release overrides detected information, there's no
need to try and detect that information if lsb-release contains
everything we need. This saves us calling the hugely expensive
apt-cache. LP: #262050.
We thought you might be interested in doing the same.
-- System Information:
Debian Release: lenny/sid
APT prefers intrepid-updates
APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'), (500,
'intrepid-proposed'), (500, 'intrepid')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.27-11-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru lsb-3.2/debian/changelog lsb-3.2/debian/changelog
diff -Nru lsb-3.2/lsb_release lsb-3.2/lsb_release
--- lsb-3.2/lsb_release 2008-07-24 20:03:03.0 +0100
+++ lsb-3.2/lsb_release 2009-01-15 21:26:38.0 +
@@ -241,9 +241,15 @@
return distinfo
def get_distro_information():
-distinfo = guess_debian_release()
-distinfo.update(get_lsb_information())
-return distinfo
+lsbinfo = get_lsb_information()
+# OS is only used inside guess_debian_release anyway
+for key in ('ID', 'RELEASE', 'CODENAME', 'DESCRIPTION',):
+if key not in lsbinfo:
+distinfo = guess_debian_release()
+distinfo.update(lsbinfo)
+return distinfo
+else:
+return lsbinfo
def main():
parser = OptionParser()
Bug#511652: udev rules shouldn't be empty by default
Package: hama-slide-mouse-control Version: 1.0-2 Severity: minor Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu intrepid ubuntu-patch *** /tmp/tmp--VmoN In Ubuntu, we've applied the attached patch to achieve the following: * Modify the package so that the udev rules aren't actually installed by default, and instruct the user to copy out of examples and then modify; otherwise they'll get conffile hell forever after. We thought you might be interested in doing the same. -- System Information: Debian Release: lenny/sid APT prefers intrepid-updates APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'), (500, 'intrepid-proposed'), (500, 'intrepid') Architecture: amd64 (x86_64) Kernel: Linux 2.6.27-11-generic (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -u hama-slide-mouse-control-1.0/debian/rules hama-slide-mouse-control-1.0/debian/rules --- hama-slide-mouse-control-1.0/debian/rules +++ hama-slide-mouse-control-1.0/debian/rules @@ -33,6 +33,7 @@ dh_clean -k dh_installdirs $(MAKE) DESTDIR=$(CURDIR)/debian/hama-slide-mouse-control install + rm -rf debian/hama-slide-mouse-control/etc/udev # Build architecture-independent files here. binary-indep: build install diff -u hama-slide-mouse-control-1.0/debian/README.Debian hama-slide-mouse-control-1.0/debian/README.Debian --- hama-slide-mouse-control-1.0/debian/README.Debian +++ hama-slide-mouse-control-1.0/debian/README.Debian @@ -1,8 +1,10 @@ hama-slide-mouse-control for Debian --- -You can configure udev to set up the mouse whenever it is plugged in, by editing -/etc/udev/rules.d/hama-slide-mouse-control.rules +You can configure udev to set up the mouse whenever it is plugged in, by copying +60-hama-slide-mouse-control.rules from +/usr/share/doc/hama-slide-mouse-control/examples into /etc/udev/rules.d + See the manpage hama-slide-mouse-control(1) or the equivalent HTML documentation in /usr/share/doc/hama-slide-mouse-control/hama-slide-mouse-control.html for details. diff -u hama-slide-mouse-control-1.0/debian/changelog hama-slide-mouse-control-1.0/debian/changelog diff -u hama-slide-mouse-control-1.0/debian/control hama-slide-mouse-control-1.0/debian/control --- hama-slide-mouse-control-1.0/debian/control +++ hama-slide-mouse-control-1.0/debian/control @@ -1,7 +1,8 @@ Source: hama-slide-mouse-control Section: utils Priority: extra -Maintainer: Richard Atterer atte...@debian.org +Maintainer: Ubuntu MOTU Developers ubuntu-m...@lists.ubuntu.com +XSBC-Original-Maintainer: Richard Atterer atte...@debian.org Build-Depends: debhelper (= 5), libusb-dev Standards-Version: 3.7.2 only in patch2: unchanged: --- hama-slide-mouse-control-1.0.orig/debian/hama-slide-mouse-control.examples +++ hama-slide-mouse-control-1.0/debian/hama-slide-mouse-control.examples @@ -0,0 +1 @@ +60-hama-slide-mouse-control.rules
Bug#488271: cryptsetup: use a loop to wait for the root device
On Tue, 2008-07-01 at 22:03 +0200, Reinhard Tartler wrote: Oh, I needed to do some investiagtions about that file, it has been submitted by you as #414842. However, that particular patch has not been applied to ubuntu's udev. Scott, can you have a look at this patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=udev-support_rootdelay.patch;att=1;bug=414842 Is that acceptable for ubuntu? No. We already have a loop in mountroot() to deal with this problem, it waits until the root device is actually available before proceeeding. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#488271: [Pkg-cryptsetup-devel] Bug#488271: cryptsetup: use a loop to wait for the root device
On Tue, 2008-07-01 at 23:11 +0200, David Härdeman wrote: On Tue, Jul 01, 2008 at 09:09:19PM +0100, Scott James Remnant wrote: On Tue, 2008-07-01 at 22:03 +0200, Reinhard Tartler wrote: Oh, I needed to do some investiagtions about that file, it has been submitted by you as #414842. However, that particular patch has not been applied to ubuntu's udev. Scott, can you have a look at this patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=udev-support_rootdelay.patch;att=1;bug=414842 Is that acceptable for ubuntu? No. We already have a loop in mountroot() to deal with this problem, it waits until the root device is actually available before proceeeding. Which is after all initramfs scripts have already had their chance of executing. No initramfs script should use the root device before it has been mounted. If you want to modify or create root devices, it should be done with a udev rule. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#488271: [Pkg-cryptsetup-devel] Bug#488271: Bug#488271: cryptsetup: use a loop to wait for the root device
On Tue, 2008-07-01 at 23:44 +0200, David Härdeman wrote: On Tue, Jul 01, 2008 at 10:25:50PM +0100, Scott James Remnant wrote: On Tue, 2008-07-01 at 23:11 +0200, David Härdeman wrote: On Tue, Jul 01, 2008 at 09:09:19PM +0100, Scott James Remnant wrote: We already have a loop in mountroot() to deal with this problem, it waits until the root device is actually available before proceeeding. Which is after all initramfs scripts have already had their chance of executing. No initramfs script should use the root device before it has been mounted. If you want to modify or create root devices, it should be done with a udev rule. Ummm, are we still talking about the same thing? cryptsetup creates the root device in an initramfs script...of course it won't use any root devices... What does it create it from? If it creates it from block devices, it should be written as a script called by a udev rule, not as an initramfs script. See mdadm, lvm, etc. for comparison -- in Ubuntu, those are called from udev, when the underlying block device is actually ready. cryptsetup should behave in the same way; when a block device is ready for use, it should be called by a udev rule and make the devmapper device -- that will release the loop in mountroot() and allow the initramfs to exit. This is one of a number of major differences between Ubuntu and Debian. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#481369: run ioniced and in background
On Thu, 2008-05-15 at 18:09 +0200, Julian Andres Klode wrote: Am Donnerstag, den 15.05.2008, 17:14 +0200 schrieb Alberto: Since version 1:0.20050517.0220-0ubuntu4, readahead runs in the foreground, not the background, in order to avoid i/o concurrency (which is slow). Not true. It runs in the foreground because the entire point of using readahead is to perform boot I/O in one optimal pass. Running it in the background would mean you were seeking the disk all over the shop, and attempting to readahead pages that were already read by an application running in parallel. While you do see a slight performance improvement when in the background, you always see an improvement in the foreground. Likewise ioniceing readahead is basically moronic. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#462470: PTS: don't show changelog-only ubuntu patches
On Mon, 2008-02-04 at 16:10 +0100, Raphael Hertzog wrote: On Mon, 04 Feb 2008, Scott James Remnant wrote: On Fri, 2008-01-25 at 19:24 +0100, Raphael Hertzog wrote: Scott, could you exclude those from the PATCH file that you generate? (http://patches.ubuntu.com/PATCHES) Please file it as a wishlist bug: http://launchpad.net/merge-o-matic/+bugs Done: https://bugs.launchpad.net/merge-o-matic/+bug/188955 Also note that the source to MoM/patches is public now (see the Code tab), so if there's anyone on Debian's side who want to help out - feel free to point it at them. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#462470: PTS: don't show changelog-only ubuntu patches
On Fri, 2008-01-25 at 19:24 +0100, Raphael Hertzog wrote: On Fri, 25 Jan 2008, Paul Wise wrote: Package: qa.debian.org Severity: wishlist I would like it if the PTS didn't link to changelog-only Ubuntu patches. Here is an example: http://packages.qa.debian.org/s/synfig.html http://patches.ubuntu.com/s/synfig/synfig_0.61.07-1build1.patch By changelog-only, one must understand binnmu in the Ubuntu world. Scott, could you exclude those from the PATCH file that you generate? (http://patches.ubuntu.com/PATCHES) Please file it as a wishlist bug: http://launchpad.net/merge-o-matic/+bugs Thanks, Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#456327: replace udevinfo call with udevadm
On Sat, 2008-01-05 at 10:57 -0800, [EMAIL PROTECTED] wrote: On Fri, Dec 14, 2007 at 04:34:28PM +, Scott James Remnant wrote: Package: ltspfs Version: 0.1cvs20060518-1 Severity: wishlist Tags: patch the patch appears to be for ltspfs version 0.5, and 0.1cvs20060518-1 was never in debian... Sorry, I don't know what versions you do and don't have in Debian; I simply removed the ubuntuX from the version number to file the bug. *** /tmp/tmp36ZDNv In Ubuntu, we've applied the attached patch to achieve the following: * scripts/add_fstab_entry: call udevadm instead of udevinfo We thought you might be interested in doing the same. udevadm does not appear to be present in the current version of udev in debian (0.114-2). is this part of a newer release of udev? Yes, it may be that it hasn't reached Debian yet - though Marco does tend to keep pretty up to date. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#456324: use udevadm instead of udevtrigger
On Fri, 2007-12-14 at 19:23 -0700, Martin Michlmayr wrote: * Scott James Remnant [EMAIL PROTECTED] [2007-12-14 16:21]: Package: dkms Version: None There's no such package in Debian and I cannot even find a binary with that name. Any idea if this really exists in Debian? Heh, I somewhat assumed that reportbug would notice if I tried to file a bug on a non-existant package and tell me ;) See, Ubuntu gives back all of its patches, even if Debian doesn't have the package in question g Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#456324: use udevadm instead of udevtrigger
Package: dkms
Version: None
Severity: wishlist
Tags: patch
Recept versions of udev have made this change, including the one in
Debian.
*** /tmp/tmpUlSV5I
In Ubuntu, we've applied the attached patch to achieve the following:
* dkms: call udevadm instead of udevtrigger
We thought you might be interested in doing the same.
-- System Information:
Debian Release: lenny/sid
APT prefers gutsy-updates
APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u dkms-2.0.17.4/dkms dkms-2.0.17.4/dkms
--- dkms-2.0.17.4/dkms
+++ dkms-2.0.17.4/dkms
@@ -1248,8 +1248,8 @@
fi
# Notify udev if we installed something for the currently running kernel
-if [ -x /sbin/udevtrigger -a ${kernelver_array[0]} == $(uname -r) -a
${arch_array[0]} == $(uname -m) ]; then
- /sbin/udevtrigger
+if [ -x /sbin/udevadm trigger -a ${kernelver_array[0]} == $(uname -r)
-a ${arch_array[0]} == $(uname -m) ]; then
+ /sbin/udevadm trigger
fi
echo $
Bug#456327: replace udevinfo call with udevadm
Package: ltspfs
Version: 0.1cvs20060518-1
Severity: wishlist
Tags: patch
tools merged into a single binary upstream
*** /tmp/tmp36ZDNv
In Ubuntu, we've applied the attached patch to achieve the following:
* scripts/add_fstab_entry: call udevadm instead of udevinfo
We thought you might be interested in doing the same.
-- System Information:
Debian Release: lenny/sid
APT prefers gutsy-updates
APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- ltspfs-0.5.orig/scripts/add_fstab_entry
+++ ltspfs-0.5/scripts/add_fstab_entry
@@ -6,7 +6,7 @@
DEVICENAME=$(basename $1)
FSTYPE=$2
-export $(udevinfo -qenv -n ${DEVICENAME})
+export $(/sbin/udevadm info -qenv -n ${DEVICENAME})
ROOT=/var/run/drives
FSTAB=/var/run/ltspfs_fstab
Bug#456328: call udevadm instead of udevsettle
Package: mouseemu Version: 0.15-8 Severity: wishlist Tags: patch tools have been merged into a single binary upstream *** /tmp/tmp_AQvpB In Ubuntu, we've applied the attached patch to achieve the following: * debian/mouseemu.init: call udevadm instead of udevsettle We thought you might be interested in doing the same. -- System Information: Debian Release: lenny/sid APT prefers gutsy-updates APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -u mouseemu-0.15/debian/mouseemu.init mouseemu-0.15/debian/mouseemu.init --- mouseemu-0.15/debian/mouseemu.init +++ mouseemu-0.15/debian/mouseemu.init @@ -41,8 +41,8 @@ log_daemon_msg Starting $DESC $NAME modprobe -q uinput || true # Give udev some time to create the device node - if which udevsettle /dev/null 21; then - udevsettle + if which udevadm settle /dev/null 21; then + udevadm settle fi set +e start-stop-daemon --start --quiet --exec $DAEMON --nicelevel -10 -- $MOUSEEMU_OPTS
Bug#456326: use udevadm instead of udevsettle
Package: cryptsetup
Version: 2:1.0.5-2
Severity: wishlist
Tags: patch
udevadm merges all the old udev tools
*** /tmp/tmpxsyZ2u
In Ubuntu, we've applied the attached patch to achieve the following:
* debian/initramfs/cryptroot-script: call udevadm instead of udevsettle
* debian/patches/06_call_udevsettle.dpatch: likewise
We thought you might be interested in doing the same.
-- System Information:
Debian Release: lenny/sid
APT prefers gutsy-updates
APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u cryptsetup-1.0.5/debian/initramfs/cryptroot-script
cryptsetup-1.0.5/debian/initramfs/cryptroot-script
--- cryptsetup-1.0.5/debian/initramfs/cryptroot-script
+++ cryptsetup-1.0.5/debian/initramfs/cryptroot-script
@@ -159,8 +159,8 @@
activate_evms $cryptsource
fi
# Wait for udev to be ready, see https://launchpad.net/bugs/85640
- if [ -x /sbin/udevsettle ]; then
- /sbin/udevsettle --timeout=30
+ if [ -x /sbin/udevadm settle ]; then
+ /sbin/udevadm settle --timeout=30
fi
if [ ! -e $cryptsource ]; then
@@ -239,8 +239,8 @@
if [ $count -lt 3 ]; then
# Wait for udev to be ready, see
https://launchpad.net/bugs/85640
- if [ -x /sbin/udevsettle ]; then
- /sbin/udevsettle --timeout=30
+ if [ -x /sbin/udevadm settle ]; then
+ /sbin/udevadm settle --timeout=30
fi
return 0
else
diff -u cryptsetup-1.0.5/debian/patches/06_call_udevsettle.dpatch
cryptsetup-1.0.5/debian/patches/06_call_udevsettle.dpatch
--- cryptsetup-1.0.5/debian/patches/06_call_udevsettle.dpatch
+++ cryptsetup-1.0.5/debian/patches/06_call_udevsettle.dpatch
@@ -22,8 +22,8 @@
+ * checking here if udevsettle is available and call it if it
+ * is.
+ */
-+ if (0 == access(/sbin/udevsettle, X_OK)) {
-+ system(/sbin/udevsettle);
++ if (0 == access(/sbin/udevadm settle, X_OK)) {
++ system(/sbin/udevadm settle);
+ }
+
r = 0;
Bug#456325: use udevadm instead of udevsettle
Package: lirc Version: 0.8.0-9 Severity: wishlist Tags: patch tools have been merged into one utility upstream *** /tmp/tmptRK4mG In Ubuntu, we've applied the attached patch to achieve the following: * debian/lirc.init.d: call udevadm instead of udevsettle We thought you might be interested in doing the same. -- System Information: Debian Release: lenny/sid APT prefers gutsy-updates APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -u lirc-0.8.3~pre1/debian/lirc.init.d lirc-0.8.3~pre1/debian/lirc.init.d --- lirc-0.8.3~pre1/debian/lirc.init.d +++ lirc-0.8.3~pre1/debian/lirc.init.d @@ -35,9 +35,9 @@ START_LIRCD=false fi - if test -x /sbin/udevsettle [ ! -z $3 ] [ $3 != udev ]; + if test -x /sbin/udevadm settle [ ! -z $3 ] [ $3 != udev ]; then - if ! /sbin/udevsettle; then + if ! /sbin/udevadm settle; then echo timeout waiting for devices to be ready fi fi
Bug#456330: use udevadm instead of udevinfo
Package: xen-3.1
Version: None
Severity: wishlist
Tags: patch
binaries have merged into one upstream
*** /tmp/tmpA31Fyl
In Ubuntu, we've applied the attached patch to achieve the following:
* tools/examples/Makefile: call udevadm instead of udevinfo and thus
simply version comparisons
* tools/check/check_udev, install, install.sh: likewise
We thought you might be interested in doing the same.
-- System Information:
Debian Release: lenny/sid
APT prefers gutsy-updates
APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u xen-3.1-3.1.0/install xen-3.1-3.1.0/install
--- xen-3.1-3.1.0/install
+++ xen-3.1-3.1.0/install
@@ -27,8 +27,8 @@
echo Installing Xen from '$src' to '$dst'...
(cd $src; tar -cf - * ) | tar -C $tmp -xf -
-[ -x $(which udevinfo) ] \
- UDEV_VERSION=$(udevinfo -V | sed -e 's/^[^0-9]*
\([0-9]\{1,\}\)[^0-9]\{0,\}/\1/')
+[ -x $(which udevadm) ] \
+ UDEV_VERSION=$(udevadm version)
if [ -n $UDEV_VERSION ] [ $UDEV_VERSION -ge 059 ]; then
echo - installing for udev-based system
diff -u xen-3.1-3.1.0/debian/changelog xen-3.1-3.1.0/debian/changelog
only in patch2:
unchanged:
--- xen-3.1-3.1.0.orig/tools/check/check_udev
+++ xen-3.1-3.1.0/tools/check/check_udev
@@ -9,10 +9,10 @@
which ${TOOL} 1/dev/null 21 || RC=1
;;
Linux)
- TOOL=udevinfo
+ TOOL=udevadm
UDEV_VERSION=0
test -x $(which ${TOOL} 2/dev/null) \
- UDEV_VERSION=$(${TOOL} -V | sed -e 's/^[^0-9]*
\([0-9]\{1,\}\)[^0-9]\{0,\}/\1/')
+ UDEV_VERSION=$(${TOOL} version)
if test ${UDEV_VERSION} -ge 059; then
RC=0
else
only in patch2:
unchanged:
--- xen-3.1-3.1.0.orig/tools/examples/Makefile
+++ xen-3.1-3.1.0/tools/examples/Makefile
@@ -46,7 +46,7 @@
ifeq ($(findstring $(DI),$(DE)),$(DI))
HOTPLUGS=install-hotplug install-udev
else
-ifeq ($(shell [ -x /usr/bin/udevinfo ] [ `/usr/bin/udevinfo -V | sed -e
's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/'` -ge 059 ] echo 1),1)
+ifeq ($(shell [ -x /sbin/udevadm ] [ `/sbin/udevadm version` -ge 059 ]
echo 1),1)
HOTPLUGS=install-udev
else
HOTPLUGS=install-hotplug
only in patch2:
unchanged:
--- xen-3.1-3.1.0.orig/install.sh
+++ xen-3.1-3.1.0/install.sh
@@ -27,8 +27,8 @@
echo Installing Xen from '$src' to '$dst'...
(cd $src; tar -cf - * ) | tar -C $tmp -xf -
-[ -x $(which udevinfo) ] \
- UDEV_VERSION=$(udevinfo -V | sed -e 's/^[^0-9]*
\([0-9]\{1,\}\)[^0-9]\{0,\}/\1/')
+[ -x $(which udevadm) ] \
+ UDEV_VERSION=$(udevadm version)
if [ -n $UDEV_VERSION ] [ $UDEV_VERSION -ge 059 ]; then
echo - installing for udev-based system
Bug#455975: recognise Sun's LDOM virtual block devices
Package: lvm2
Version: 2.02.26-1
Severity: wishlist
Tags: patch
Please consider applying our patch to recognise Sun's LDOM virtual block
devices, I have also mailed this upstream.
-- System Information:
Debian Release: lenny/sid
APT prefers gutsy-updates
APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- lvm2-2.02.26.orig/lib/filters/filter.c
+++ lvm2-2.02.26/lib/filters/filter.c
@@ -75,6 +75,7 @@
{aoe, 16}, /* ATA over Ethernet */
{device-mapper, 1}, /* Other mapped devices */
{xvd, 16}, /* Xen virtual block device */
+ {vdisk, 8}, /* SUN's LDOM virtual block device */
{NULL, 0}
};
Bug#455976: drop build-dependencies on libccs-dev and libgulm-dev
Package: lvm2 Version: 2.02.26-1 Severity: wishlist Tags: patch fabbione asserts that gulm locking is obsolete and thus these build-dependencies are not required, we carry a diff from Debian to remove them and our package appears to build just fine without them. Please consider removing them as well, or explain why we shouldn't remove them. Thanks -- System Information: Debian Release: lenny/sid APT prefers gutsy-updates APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -u lvm2-2.02.26/debian/control lvm2-2.02.26/debian/control --- lvm2-2.02.26/debian/control +++ lvm2-2.02.26/debian/control @@ -1,7 +1,7 @@ Priority: optional Maintainer: Debian LVM Team [EMAIL PROTECTED] Uploaders: Bastian Blank [EMAIL PROTECTED] -Build-Depends: debhelper ( 4.2), libdevmapper-dev ( 2:1.02.20), autotools-dev, libccs-dev, libcman-dev, libdlm-dev ( 1.02.00), libgulm-dev, libselinux1-dev, libreadline5-dev +Build-Depends: debhelper ( 4.2), libdevmapper-dev ( 2:1.02.20), autotools-dev, libcman-dev, libdlm-dev ( 1.02.00), libselinux1-dev, libreadline5-dev Standards-Version: 3.6.2 Package: lvm2
Bug#455978: build clvm daemon and package
Package: lvm2
Version: 2.02.26-1
Severity: wishlist
Tags: patch
We are currently carrying a patch to build the clvm daemon and place it
in an extra clvm package, for use with the RedHat cman cluster
infrastuture.
Please consider applying the same patch to reduce our diff, or
explain why we shouldn't be applying this patch.
Thanks
-- System Information:
Debian Release: lenny/sid
APT prefers gutsy-updates
APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- lvm2-2.02.26/debian/control
+++ lvm2-2.02.26/debian/control
@@ -35,0 +36,9 @@
+Package: clvm
+Section: admin
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}, lvm2 ( 2.0.23), cman
+Description: Cluster LVM Daemon for lvm2
+ This package provides the clustering interface for lvm2, when used with
+ Red Hat's cman cluster infrastructure. It allows logical volumes to
+ be created on shared storage devices (eg Fibre Channel, or iSCSI).
--- lvm2-2.02.26/debian/rules
+++ lvm2-2.02.26/debian/rules
@@ -28,7 +28,7 @@
BUILD_DIR = debian/build
-PACKAGES_DEB = lvm2
+PACKAGES_DEB = lvm2 clvm
PACKAGES_UDEB = lvm2-udeb
$(BUILD_DIR)/build-deb/config.status: DIR = $(BUILD_DIR)/build-deb
@@ -41,8 +41,9 @@
cp --remove-destination /usr/share/misc/config.sub
/usr/share/misc/config.guess $(DIR)/autoconf
cd $(DIR); \
./configure CFLAGS=$(CFLAGS) $(CONFIGURE_FLAGS) \
- --with-cluster=none \
+ --with-cluster=shared \
+ --with-clvmd=cman \
--enable-readline
$(BUILD_DIR)/build-udeb/config.status: DIR = $(BUILD_DIR)/build-udeb
$(BUILD_DIR)/build-udeb/config.status:
@@ -130,6 +134,7 @@
# dh_installpam -a
# dh_installmime -a
dh_installinit -plvm2 --no-start -- start 26 S . start 50 0 6 .
+ dh_installinit -p clvm --no-restart-on-upgrade -- start 65 S . start 3
0 6 .
# dh_installcron -a
# dh_installman -a
# dh_installinfo -a
--- lvm2-2.02.26.orig/debian/clvm.default
+++ lvm2-2.02.26/debian/clvm.default
@@ -0,0 +1,3 @@
+# Specify how many seconds the init script should wait
+# for other nodes of the cluster to join before giving up.
+# CLVMDTIMEOUT=60
--- lvm2-2.02.26.orig/debian/clvm.init
+++ lvm2-2.02.26/debian/clvm.init
@@ -0,0 +1,72 @@
+#! /bin/sh
+
+PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+DAEMON=/sbin/clvmd
+NAME=clvmd
+DESC=Cluster LVM Daemon
+
+test -x $DAEMON || exit 0
+
+if [ -f /etc/default/clvm ] ; then
+ . /etc/default/clvm
+fi
+
+[ -n $CLVMDTIMEOUT ] || CLVMDTIMEOUT=60
+
+if [ ! -f /etc/cluster/cluster.conf ]; then
+ echo clvmd: cluster not configured. Aborting.
+ exit 0
+fi
+
+if ! cman_tool status /dev/null; then
+ echo clvmd: cluster is not running. Aborting.
+ exit 0
+fi
+
+set -e
+
+wait_for_nodes() {
+ vgscan /dev/null 21
+ wait=0
+ while [ -n $(vgchange -a y 21 |grep clvmd not running) ]; do
+ if [ $wait -lt $CLVMDTIMEOUT ]; then
+ echo clvmd: Waiting for other nodes to join the
cluster..
+ sleep 3
+ wait=$(($wait + 3))
+ else
+ echo failed.
+ exit 1
+ fi
+ done
+ echo done.
+ exit 0
+}
+
+case $1 in
+ start)
+ echo -n Starting $DESC
+ if start-stop-daemon --start --quiet --exec $DAEMON -- $DAEMON_OPTS;
then
+ wait_for_nodes
+ fi
+ ;;
+ stop)
+ echo -n Stopping $DESC
+ start-stop-daemon --stop --oknodo --quiet --exec $DAEMON
+ echo done.
+ ;;
+ reload|restart|force-reload)
+ echo -n Restarting $DESC
+ start-stop-daemon --stop --oknodo --quiet --exec $DAEMON
+ sleep 1
+ if start-stop-daemon --start --oknodo --quiet --exec $DAEMON --
$DAEMON_OPTS; then
+ wait_for_nodes
+ fi
+ ;;
+ *)
+ N=/etc/init.d/$NAME
+ echo Usage: $N {start|stop|restart|reload|force-reload} 2
+ exit 1
+ ;;
+esac
+
+exit 0
Bug#455979: activate lvm devices from udev
Package: lvm2
Version: 2.02.26-1
Severity: wishlist
Tags: patch
We activate LVM2 devices from udev, detecting when block devices
containing LVM Physical Volumes are added to the system or changed and
running lvm vgscan and vgchange afterwards.
Please consider migrating to the same.
(This almost certainly depends on our patches to devmapper and mdadm).
-- System Information:
Debian Release: lenny/sid
APT prefers gutsy-updates
APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- lvm2-2.02.26/debian/lvm2.postinst
+++ lvm2-2.02.26/debian/lvm2.postinst
@@ -6,6 +6,8 @@
echo -n Backing up any LVM2 metadata that may exist...
/sbin/vgcfgbackup /dev/null 21 || true
echo done.
+
+update-initramfs -u
fi
#DEBHELPER#
--- lvm2-2.02.26/debian/control
+++ lvm2-2.02.26/debian/control
@@ -8,10 +9,9 @@
Package: lvm2
Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, udev (= 111-0ubuntu1), initramfs-tools (=
0.85eubuntu11), dmsetup
Conflicts: lvm-common
Replaces: lvm-common
-Suggests: dmsetup
Description: The Linux Logical Volume Manager
This is LVM2, the rewrite of The Linux Logical Volume Manager. LVM
supports enterprise level volume management of disk and disk subsystems
--- lvm2-2.02.26/debian/rules
+++ lvm2-2.02.26/debian/rules
@@ -130,7 +134,7 @@
# dh_installemacsen -a
# dh_installpam -a
# dh_installmime -a
- dh_installinit -plvm2 --no-start -- start 26 S . start 50 0 6 .
+ dh_installudev -a --priority=85
# dh_installcron -a
# dh_installman -a
# dh_installinfo -a
--- lvm2-2.02.26/debian/initramfs-tools/hooks/lvm2
+++ lvm2-2.02.26/debian/initramfs-tools/hooks/lvm2
@@ -1,6 +1,6 @@
#!/bin/sh
-PREREQ=
+PREREQ=udev
prereqs()
{
@@ -22,6 +22,8 @@
-copy_exec /sbin/vgchange /sbin
+copy_exec /sbin/lvm /sbin
+
+cp -p /etc/udev/rules.d/85-lvm2.rules ${DESTDIR}/etc/udev/rules.d
for x in dm_mod dm_snapshot dm_mirror; do
- manual_add_modules ${x}
+ force_load ${x}
done
--- lvm2-2.02.26/debian/initramfs-tools/scripts/local-top/lvm2
+++ lvm2-2.02.26.orig/debian/initramfs-tools/scripts/local-top/lvm2
@@ -1,70 +0,0 @@
-#!/bin/sh
-
-PREREQ=mdadm mdrun
-
-prereqs()
-{
- echo $PREREQ
-}
-
-case $1 in
-# get pre-requisites
-prereqs)
- prereqs
- exit 0
- ;;
-esac
-
-activate_vg()
-{
- local vg=$1
-
- # Make sure that we have a non-empty argument
- if [ -z ${vg} ]; then
- return 1
- fi
-
- # Take care of lilo boot arg, risky activating of all vg
- case $vg in
- fe[0-9]*)
- vgchange -ay
- exit 0
- ;;
- # FIXME: check major
- /dev/root)
- vgchange -ay
- exit 0
- ;;
- esac
-
- # Make sure that we have a d-m path
- vg=${vg#/dev/mapper/}
- if [ $vg = $1 ]; then
- return 1
- fi
-
- # Make sure that the device includes at least one dash
- if [ $(echo -n $vg | tr -d -) = $vg ]; then
- return 1
- fi
-
- # Split volume group from logical volume.
- vg=$(echo ${vg} | sed -e 's#\(.*\)\([^-]\)-[^-].*#\1\2#')
- # Reduce padded --'s to -'s
- vg=$(echo ${vg} | sed -e 's#--#-#g')
-
- vgchange -ay ${vg}
-}
-
-if [ ! -e /sbin/vgchange ]; then
- exit 0
-fi
-
-modprobe -q dm-mod
-modprobe -q dm-snapshot
-modprobe -q dm-mirror
-
-activate_vg $ROOT
-activate_vg $resume
-
-exit 0
--- lvm2-2.02.26.orig/debian/lvm2.udev
+++ lvm2-2.02.26/debian/lvm2.udev
@@ -0,0 +1,6 @@
+# This file causes block devices with LVM signatures to be automatically
+# added to their volume group.
+# See udev(8) for syntax
+
+SUBSYSTEM==block, ACTION==add|change, ENV{ID_FS_TYPE}==lvm*|LVM*, \
+ RUN+=watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'
Bug#455745: apply patch to provide more atomic device creation
Package: devmapper
Version: 2:1.02.20-2
Severity: wishlist
Tags: patch
Please apply our patch (also submitted upstream) to make the device node
creation more atomic, and avoid races with udev which also attempts to
create these devices.
-- System Information:
Debian Release: lenny/sid
APT prefers gutsy-updates
APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- devmapper-1.02.20.orig/lib/libdm-common.c
+++ devmapper-1.02.20/lib/libdm-common.c
@@ -252,12 +252,11 @@
static int _add_dev_node(const char *dev_name, uint32_t major, uint32_t minor,
uid_t uid, gid_t gid, mode_t mode)
{
- char path[PATH_MAX];
+ char path[PATH_MAX], tmppath[PATH_MAX + 7];
struct stat info;
dev_t dev = MKDEV(major, minor);
mode_t old_mask;
-
- _build_dev_path(path, sizeof(path), dev_name);
+ int retval;
if (stat(path, info) = 0) {
if (!S_ISBLK(info.st_mode)) {
@@ -269,31 +268,39 @@
/* If right inode already exists we don't touch uid etc. */
if (info.st_rdev == dev)
return 1;
-
- if (unlink(path) 0) {
- log_error(Unable to unlink device node for '%s',
- dev_name);
- return 0;
- }
}
+ _build_dev_path(path, sizeof(path), dev_name);
+ strcpy (tmppath, path);
+ strcat (tmppath, .dm-tmp);
+
old_mask = umask(0);
- if (mknod(path, S_IFBLK | mode, dev) 0) {
- log_error(Unable to make device node for '%s', dev_name);
+ retval = mknod(tmppath, S_IFBLK | mode, dev);
+ umask(old_mask);
+ if (retval 0) {
+ log_error(Unable to make temporary device node for '%s', dev_name);
return 0;
}
- umask(old_mask);
- if (chown(path, uid, gid) 0) {
+ if (chown(tmppath, uid, gid) 0) {
log_error(%s: chown failed: %s, path, strerror(errno));
+ unlink(tmppath);
return 0;
}
#ifdef HAVE_SELINUX
- if (!dm_set_selinux_context(path, S_IFBLK))
+ if (!dm_set_selinux_context(tmppath, S_IFBLK)) {
+ unlink(tmppath);
return 0;
+ }
#endif
+ if (rename(tmppath, path) 0) {
+ log_error(Unable to replace device node for '%s', dev_name);
+ unlink(tmppath);
+ return 0;
+ }
+
return 1;
}
signature.asc
Description: This is a digitally signed message part
Bug#455746: udev support
Package: devmapper
Version: 2:1.02.20-2
Severity: wishlist
Tags: patch
Please consider applying our attached patch that enables udev to know
about the devicemapper device nodes, create /dev/disk symlinks to them
and populate vol_id information so that filesystems on the devices can
be used.
This patch depends on the dmsetup export option filed as Debian
#434241 and the atomic device creation patch filed as Debian #455745.
-- System Information:
Debian Release: lenny/sid
APT prefers gutsy-updates
APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- devmapper-1.02.20.orig/debian/dmsetup.udev
+++ devmapper-1.02.20/debian/dmsetup.udev
@@ -0,0 +1,31 @@
+# This file causes devicemapper devices to be assigned names by udev
+# based on the name given to dmsetup.
+# See udev(8) for syntax.
+
+SUBSYSTEM!=block, GOTO=dmsetup_end
+KERNEL!=dm-*, GOTO=dmsetup_end
+ACTION!=add|change, GOTO=dmsetup_end
+
+# Obtain device status
+IMPORT{program}=/sbin/dmsetup export -j%M -m%m
+ENV{DM_NAME}!=?*, GOTO=dmsetup_end
+
+# Make the device take the /dev/mapper name
+OPTIONS+=string_escape=none, NAME=mapper/$env{DM_NAME}
+SYMLINK+=disk/by-id/dm-name-$env{DM_NAME}
+ENV{DM_UUID}==?*, SYMLINK+=disk/by-id/dm-uuid-$env{DM_UUID}
+
+# Skip vol_id for suspended devices and those with empty or error tables
+ENV{DM_STATE}==SUSPENDED, GOTO=dmsetup_end
+ENV{DM_TARGET_TYPES}==|*error*, GOTO=dmsetup_end
+
+# by-uuid and by-label symlinks
+IMPORT{program}=vol_id --export $tempnode
+OPTIONS=link_priority=-100
+ENV{DM_TARGET_TYPES}==*snapshot-origin*, OPTIONS=link_priority=-90
+ENV{ID_FS_USAGE}==filesystem|other|crypto, ENV{ID_FS_UUID_ENC}==?*, \
+ SYMLINK+=disk/by-uuid/$env{ID_FS_UUID_ENC}
+ENV{ID_FS_USAGE}==filesystem|other, ENV{ID_FS_LABEL_ENC}==?*, \
+ SYMLINK+=disk/by-label/$env{ID_FS_LABEL_ENC}
+
+LABEL=dmsetup_end
--- devmapper-1.02.20/debian/control
+++ devmapper-1.02.20/debian/control
@@ -26,6 +27,7 @@
Priority: required
Architecture: any
Depends: ${shlibs:Depends}
+Recommends: dmsetup (= 2:1.02.08-1ubuntu2)
Provides: libdevmapper
Description: The Linux Kernel Device Mapper userspace library
The Linux Kernel Device Mapper is the LVM (Linux Logical Volume Management)
@@ -44,6 +46,7 @@
Architecture: any
Depends: ${shlibs:Depends}
Provides: libdevmapper1.02.1
+Recommends: dmsetup-udeb
Description: The Linux Kernel Device Mapper userspace library
This is a udeb, or a microdeb, for the debian-installer.
.
--- devmapper-1.02.20/debian/rules
+++ devmapper-1.02.20/debian/rules
@@ -78,6 +80,7 @@
clean:
dh_testdir
rm -rf $(BUILD_DIR)
+ rm -f debian/dmsetup-udeb.udev
dh_clean
@@ -94,6 +98,10 @@
rm -rf $(INSTALL_DIR)
$(MAKE) -C $(DIR) install DESTDIR=$(CURDIR)/$(INSTALL_DIR)
LIB_VERSION=$(LIBDEVMAPPER_ABINAME)
+ install -d $(INSTALL_DIR)/usr/share/initramfs-tools/hooks
+ install -m 0755 debian/dmsetup.initramfs \
+ $(INSTALL_DIR)/usr/share/initramfs-tools/hooks/dmsetup
+
dh_install --sourcedir=$(INSTALL_DIR)
install-udeb: export DH_OPTIONS = $(addprefix -p,$(PACKAGES_UDEB))
@@ -108,6 +116,8 @@
rm -rf $(INSTALL_DIR)
$(MAKE) -C $(DIR) install DESTDIR=$(CURDIR)/$(INSTALL_DIR)
LIB_VERSION=$(LIBDEVMAPPER_ABINAME)
+ cp -a debian/dmsetup.udev debian/dmsetup-udeb.udev
+
dh_install --sourcedir=$(INSTALL_DIR)
# Build architecture-independent files here.
@@ -119,7 +129,7 @@
dh_testroot -a
dh_installchangelogs WHATS_NEW -a
dh_installdocs -a
- dh_installinit -a -- start 25 S .
+ dh_installudev -a --priority=65
dh_strip -a
dh_link -p libdevmapper-dev lib/libdevmapper.so.$(LIBDEVMAPPER_ABINAME)
usr/lib/libdevmapper.so
dh_compress -a
--- devmapper-1.02.20.orig/debian/dmsetup.initramfs
+++ devmapper-1.02.20/debian/dmsetup.initramfs
@@ -0,0 +1,24 @@
+#!/bin/sh -e
+# initramfs hook for dmsetup
+
+PREREQ=udev
+
+# Output pre-requisites
+prereqs()
+{
+ echo $PREREQ
+}
+
+case $1 in
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+
+. /usr/share/initramfs-tools/hook-functions
+
+copy_exec /sbin/dmsetup /sbin
+
+cp -p /etc/udev/rules.d/65-dmsetup.rules ${DESTDIR}/etc/udev/rules.d
--- devmapper-1.02.20/debian/dmsetup.install
+++ devmapper-1.02.20/debian/dmsetup.install
@@ -2,0 +3 @@
+usr/share/initramfs-tools/hooks/dmsetup
--- devmapper-1.02.20.orig/debian/dmsetup.postinst
+++ devmapper-1.02.20/debian/dmsetup.postinst
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+if [ $1 = configure ]; then
+ if type update-initramfs /dev/null 21; then
+ update-initramfs -u
+ fi
+fi
+
+#DEBHELPER#
Bug#455747: udev support
Package: devmapper
Version: 2:1.02.20-2
Severity: wishlist
Tags: patch
Please consider applying our attached patch that enables udev to know
about the devicemapper device nodes, create /dev/disk symlinks to them
and populate vol_id information so that filesystems on the devices can
be used.
This patch depends on the dmsetup export option filed as Debian
#434241 and the atomic device creation patch filed as Debian #455745.
-- System Information:
Debian Release: lenny/sid
APT prefers gutsy-updates
APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- devmapper-1.02.20.orig/debian/dmsetup.udev
+++ devmapper-1.02.20/debian/dmsetup.udev
@@ -0,0 +1,31 @@
+# This file causes devicemapper devices to be assigned names by udev
+# based on the name given to dmsetup.
+# See udev(8) for syntax.
+
+SUBSYSTEM!=block, GOTO=dmsetup_end
+KERNEL!=dm-*, GOTO=dmsetup_end
+ACTION!=add|change, GOTO=dmsetup_end
+
+# Obtain device status
+IMPORT{program}=/sbin/dmsetup export -j%M -m%m
+ENV{DM_NAME}!=?*, GOTO=dmsetup_end
+
+# Make the device take the /dev/mapper name
+OPTIONS+=string_escape=none, NAME=mapper/$env{DM_NAME}
+SYMLINK+=disk/by-id/dm-name-$env{DM_NAME}
+ENV{DM_UUID}==?*, SYMLINK+=disk/by-id/dm-uuid-$env{DM_UUID}
+
+# Skip vol_id for suspended devices and those with empty or error tables
+ENV{DM_STATE}==SUSPENDED, GOTO=dmsetup_end
+ENV{DM_TARGET_TYPES}==|*error*, GOTO=dmsetup_end
+
+# by-uuid and by-label symlinks
+IMPORT{program}=vol_id --export $tempnode
+OPTIONS=link_priority=-100
+ENV{DM_TARGET_TYPES}==*snapshot-origin*, OPTIONS=link_priority=-90
+ENV{ID_FS_USAGE}==filesystem|other|crypto, ENV{ID_FS_UUID_ENC}==?*, \
+ SYMLINK+=disk/by-uuid/$env{ID_FS_UUID_ENC}
+ENV{ID_FS_USAGE}==filesystem|other, ENV{ID_FS_LABEL_ENC}==?*, \
+ SYMLINK+=disk/by-label/$env{ID_FS_LABEL_ENC}
+
+LABEL=dmsetup_end
--- devmapper-1.02.20/debian/control
+++ devmapper-1.02.20/debian/control
@@ -26,6 +27,7 @@
Priority: required
Architecture: any
Depends: ${shlibs:Depends}
+Recommends: dmsetup (= 2:1.02.08-1ubuntu2)
Provides: libdevmapper
Description: The Linux Kernel Device Mapper userspace library
The Linux Kernel Device Mapper is the LVM (Linux Logical Volume Management)
@@ -44,6 +46,7 @@
Architecture: any
Depends: ${shlibs:Depends}
Provides: libdevmapper1.02.1
+Recommends: dmsetup-udeb
Description: The Linux Kernel Device Mapper userspace library
This is a udeb, or a microdeb, for the debian-installer.
.
--- devmapper-1.02.20/debian/rules
+++ devmapper-1.02.20/debian/rules
@@ -78,6 +80,7 @@
clean:
dh_testdir
rm -rf $(BUILD_DIR)
+ rm -f debian/dmsetup-udeb.udev
dh_clean
@@ -94,6 +98,10 @@
rm -rf $(INSTALL_DIR)
$(MAKE) -C $(DIR) install DESTDIR=$(CURDIR)/$(INSTALL_DIR)
LIB_VERSION=$(LIBDEVMAPPER_ABINAME)
+ install -d $(INSTALL_DIR)/usr/share/initramfs-tools/hooks
+ install -m 0755 debian/dmsetup.initramfs \
+ $(INSTALL_DIR)/usr/share/initramfs-tools/hooks/dmsetup
+
dh_install --sourcedir=$(INSTALL_DIR)
install-udeb: export DH_OPTIONS = $(addprefix -p,$(PACKAGES_UDEB))
@@ -108,6 +116,8 @@
rm -rf $(INSTALL_DIR)
$(MAKE) -C $(DIR) install DESTDIR=$(CURDIR)/$(INSTALL_DIR)
LIB_VERSION=$(LIBDEVMAPPER_ABINAME)
+ cp -a debian/dmsetup.udev debian/dmsetup-udeb.udev
+
dh_install --sourcedir=$(INSTALL_DIR)
# Build architecture-independent files here.
@@ -119,7 +129,7 @@
dh_testroot -a
dh_installchangelogs WHATS_NEW -a
dh_installdocs -a
- dh_installinit -a -- start 25 S .
+ dh_installudev -a --priority=65
dh_strip -a
dh_link -p libdevmapper-dev lib/libdevmapper.so.$(LIBDEVMAPPER_ABINAME)
usr/lib/libdevmapper.so
dh_compress -a
--- devmapper-1.02.20.orig/debian/dmsetup.initramfs
+++ devmapper-1.02.20/debian/dmsetup.initramfs
@@ -0,0 +1,24 @@
+#!/bin/sh -e
+# initramfs hook for dmsetup
+
+PREREQ=udev
+
+# Output pre-requisites
+prereqs()
+{
+ echo $PREREQ
+}
+
+case $1 in
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+
+. /usr/share/initramfs-tools/hook-functions
+
+copy_exec /sbin/dmsetup /sbin
+
+cp -p /etc/udev/rules.d/65-dmsetup.rules ${DESTDIR}/etc/udev/rules.d
--- devmapper-1.02.20/debian/dmsetup.install
+++ devmapper-1.02.20/debian/dmsetup.install
@@ -2,0 +3 @@
+usr/share/initramfs-tools/hooks/dmsetup
--- devmapper-1.02.20.orig/debian/dmsetup.postinst
+++ devmapper-1.02.20/debian/dmsetup.postinst
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+if [ $1 = configure ]; then
+ if type update-initramfs /dev/null 21; then
+ update-initramfs -u
+ fi
+fi
+
+#DEBHELPER#
Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start
On Fri, 2006-12-15 at 15:18 +0100, Tore Anderson wrote: * Scott James Remnant I'd actually argue that you wouldn't want to forcibly change the clock once the first service is *starting*. As soon as you have at least one service running, it's arguably dangerous to slew the clock, and instead we should always step it from there on. Say what?! I hope you've just mixed up the terms here... slew - adjtime() - safe, clock will never leap step - settimeofday() - unsafe, clock will leap [back in time] I'll read the rest of your email assuming you exchanged those two. It's entirely probable ;-) Step to me implies taking small steps, whereas slew implies sliding the clock the entire way. Not the most unambiguous of terms g We think it's a bug in our current install; but one that is less than the previous bug of the clock being not changed at all. Debian certainly shouldn't follow suit, unless they're also happy to have an open bug that the clock is slewed whenever a network interface comes up. I actually submitted a bug to Launchpad about this and had it closed because it was allegedly fixed in the latest release. I didn't verify that myself, though... Maybe I should. I didn't find an open bug about it either. Do you have a link? It looks like a community member closed it in error, I have reopened the bug. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start
Matt's asked me to jump in here to explain the Ubuntu changes, and our long-term plan for such thing; as there seems to be a little confusion and/or argument on this topic. On Fri, 5 May 2006 15:17:53 +0200, Ingo Oeser wrote: The proposed solution of using /etc/networking/if-up.d/ works without any problem for most of your users. Actually unbuntu Dapper Drake is just doing it this way and I never had any problems. We fixed it for our customers the same way. Our reason for moving this to an if-up.d script is because we're increasingly relying on udev to drive the hardware parts of our boot sequence; this meant that there was no point in the SysV boot sequence where networking was up, so no point to run the ntpdate script. Moving to an if-up.d script meant that the clock would be adjusted during boot when the each ethernet card came up; the first not being sufficient as that one might not actually get an IP. This isn't ideal either, as now ntpdate gets run every time you fiddle with an interface. Our preferred solution is to use upstart to manage the ntpdate task, and don't run it once it has succeeded at least once. On Tue, 12 Dec 2006 08:41:12 +0100, Tore Anderson wrote: I know. Maybe I should have been clearer though, what I'm objecting to is primarily the suggestion to mimic the way Ubuntu does it, as they invoke ntpdate with the -b parameter in the if-up.d script, ensuring that the clock will _always_ leap. We use -b because it was what was suggested in the manual page: -b Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time. The if-up.d ntpdate script is intended to set the clock at boot time, once the first interface with a reachable ntp server has come up. If no NTP server is available at bootup, well, then you'll just have to wait for a network connection and possibly step the time then. That's what we're trying to do with the ntpdate script. On Wed, 13 Dec 2006 12:01:36 +0100, Tore Anderson wrote: Ranked in order of preference (as defaults, at least): 1) No gratuitous clock adjustments whatsoever (no if-up.d script) 2) No gratuitous clock stepping whatsoever (use of -B) 3) No gratituous clock stepping unless large offset (default ntpdate) 4) Gratituous clock stepping (use of -b) Ubuntu went with #4 for their Dapper release. Given the above, how would you recommend we sync the clock during boot if no clock adjustments would be preferred? Or are you referring specifically to additional clock adjustments after the first one has been made? Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start
On Thu, 2006-12-14 at 13:07 +0100, Tore Anderson wrote: * Scott James Remnant We use -b because it was what was suggested in the manual page: -b Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time. The if-up.d ntpdate script is intended to set the clock at boot time, once the first interface with a reachable ntp server has come up. But right now it does not check if any of this is true, which is my main grief here. When the services are done being started (and I think you'll have to assume they do during bootup), it is not safe to step the clock. That is true, in practice this hasn't caused us many problems; but it is noted as a bug we need to fix. One of the principal differences between Debian and Ubuntu is that we don't have the luxury of a long release cycle, so sometimes the immediate bug is fixed leaving another lesser bug in place to be fixed in a later release. I'd actually argue that you wouldn't want to forcibly change the clock once the first service is *starting*. As soon as you have at least one service running, it's arguably dangerous to slew the clock, and instead we should always step it from there on. If ntpdate is lucky enough to get run before the first service is starting, there's no real harm in slewing it. The trick is weighing up the odds; if it's slewed, it can harm servers; but if it's stepped, desktop users will complain that their clock is wrong on boot, and takes a long time to get itself right again. Our primary reason for running it at all is dealing with desktops/laptops with broken hardware clocks. Servers will almost certainly be running ntpd if they care about the time. Given the above, how would you recommend we sync the clock during boot if no clock adjustments would be preferred? Note gratuitous. I realise that's a matter of personal opinion, but I agree both with you and ntpdate's manual page that stepping on bootup is fine. On the other hand, I think stepping at an arbitrary time after the system is up and running is just asking for trouble, at least for production systems (and again, it might be for desktops too). If I understand you correctly you/Ubuntu think this is an acceptable trade- off and I obviously disagree with you on that. We think it's a bug in our current install; but one that is less than the previous bug of the clock being not changed at all. Debian certainly shouldn't follow suit, unless they're also happy to have an open bug that the clock is slewed whenever a network interface comes up. So my recommendation would be to call ntpdate on bootup after udev was started (maybe using Required-Start: $network instead if that's working). The udev daemon being started doesn't have any bearing on whether a network interface is up or not; network interfaces come up at their own leisure. I believe there's a fair amount of resistance to running ntpd in our default installation. If you insist on coupling this to ifup, though: Our plan for feisty is to run ntpdate as an upstart job (an init script in SysV terms), the state in which it can be run defined as a point after a network interface has come up, but before the boot sequence has finished. If someone needs a clock syncing afterwards, we can either require ntpd; or use -B. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#398488: libgecode7-dev should be libgecode8-dev to match SONAME
Package: gecode Severity: serious The source package as exists in Debian generates a libgecode8 binary package that contains, as one would expect, a libgecode.so.8 library. Yet the matching development binary package is named libgecode7-dev, while it contains a libgecode.so that links to libgecode.so.8 There's no mention of any specialness in the changelog, so I assume this is simply a case of forgetting to change the -dev package name? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385722: [Pkg-sysvinit-devel] Bug#385722: please consider splitting off sysvutils
On Fri, 2006-09-08 at 09:46 -0300, Henrique de Moraes Holschuh wrote: As a sidenote, I'd really appreciate if the Ubuntu guys would consider adopting this instance (don't take this as you're doing a bad job, because you are not. Please take it as please go through a bit more pain to make sure we all get a chance to agree the job is being done right, or at least that we all had the change to give input), and at least post a question to pkg-sysvinit-devel about changes to the initscript packaging and tools. That's a three to five *days* delay I am asking about on an upload of one of the most critical pieces of infrastructure of the entire distro (be it Debian or Ubuntu), which seems quite fair to me. We'll adopt whatever name Debian ultimately decide. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#385722: [Pkg-sysvinit-devel] Bug#385722: please consider splitting off sysvutils
On Fri, 2006-09-08 at 12:44 -0300, Henrique de Moraes Holschuh wrote: On Fri, 08 Sep 2006, Scott James Remnant wrote: We'll adopt whatever name Debian ultimately decide. Thanks, although that was not the main point of my request :-) Umm, then I missed it? :P What was the main point? Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#385722: Fwd: Re: please consider splitting off sysvutils
On Wed, 2006-09-06 at 05:34 +0200, martin f krafft wrote: Scott, why does sysvinit pre-depend on sysvutils? How did you work around this problem? Because as an Essential package, sysvinit has to work unconfigured ... which means that if it requires it's dependencies they must actually be Pre-Depends. Not sure what problem Petter is having, it's not one I've encountered -- unless he's just installing the sysvutils package without also upgrading sysvinit Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#354163: apmd: Computer does not switch off any more
On Fri, 2006-07-21 at 23:21 +1000, Aníbal Monsalve Salazar wrote: On Thu, Feb 23, 2006 at 09:32:32PM +0100, Andreas Tille wrote: after my last upgrade to latest testing I observed that the computer does not switch off after a halt command any more. The effect occurs with differen kernels and different boxes. At console the usual last messages occure (system halted / harddisk stoped or something like that) but the machine keeps on running and I have to press the power switch for a couple of seconds. After rebooting the machine a fscheck is forced. I think Scott has implemented a fix for this bug. It would be nice if he could provide a patch. As soon as it's merged in the sysvinit package, I'll do the correponding changes to apmd. I don't think I do? Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#375680: Ubuntu and Fedora patches reviewing
On Tue, 2006-06-27 at 11:10 -0700, Matt Zimmerman wrote: On Tue, Jun 27, 2006 at 05:19:19PM +0200, Aur??lien G??R??ME wrote: Package: yaboot Severity: wishlist As Sven suggested, I post the current Ubuntu patch against Yaboot, because the URL http://patches.ubuntu.com/y/yaboot/yaboot_1.3.13-4.1ubuntu5.patch given in the Debian PTS does *not* seem to work reliably. The patch archive was being regenerated. This process seems to have been started some hours ago, however, and I would not expect it to take this long. CCing Scott to check on it. It takes about 6 hours to perform a scorched-earth regeneration of the patch set. It's done main so far, and is into universe now. As the new patches system hasn't yet been announced (Sesse jumped the gun when he announced his RSS feed change) it didn't seem appropriate to announce the downtime either. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#375680: Ubuntu and Fedora patches reviewing
On Tue, 2006-06-27 at 20:52 +0200, Martin Michlmayr wrote: * Matt Zimmerman [EMAIL PROTECTED] [2006-06-27 11:10]: Ubuntu feedback to Debian really sucks. :( This isn't a very constructive comment; it would have been more appropriate to report this (transient) problem to Ubuntu instead. If you'd send patches to the BTS, as has been suggested before, such transient problems wouldn't affect us. Maybe this can be considered again. This was discussed at Debconf and the PTS was selected as a more appropriate target than the BTS ... and we have been sending things to the PTS under the derivatives keyword for a while. Per-upload diffs are coming soon. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#116500: Making Automake 1.9 the default in Ubuntu
On Mon, 2006-06-12 at 19:44 -0400, Eric Dorland wrote: * Scott James Remnant ([EMAIL PROTECTED]) wrote: I notice that with a recent change to automake-1.9 you have adjusted the priorities so that 1.9 is the default, instead of 1.4. However this still does not solve many of the problems people have had in Ubuntu, so we've proposed a specification to transition the archive to the newest Automake and drop 1.4. https://wiki.ubuntu.com/AutomakeTransition As the Debian maintainer, we'd really appreciate your opinion on this; especially as there are several options listed which we have yet to choose between. Looking at the wiki page, you have some good ideas there. From Debian's perspective I think option 3 is a non-starter. Even if we banish all automake 1.4 using packages from the distro there will still be old code out there that will want it. But it is fairly deprecated garbage at this point, so its use should be discouraged. I agree that Option #3 is probably not desirable, it was put there for completeness. Here's what I believe would make the most sense: Have added this to the wiki as Option 2b. For this to happen in Debian anything depending on automake would need to be fixed. As of yesterday, 79 packages are still build depending on automake by my reckoning. Most of these are likely trivial to fix. This is certainly somewhere Ubuntu can help; we've had good results in the past by trialling migrations before Debian and providing them all the patches they need. All of the 79 packages would receive patches which have already been shipped in a released distribution, which makes it somewhat easier for people to apply them. It also makes it easier for you to change things in Debian because you can say all packages are changed or have patches in the BTS and then it's their fault if they brake. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#228604: Making Automake 1.9 the default in Ubuntu
I notice that with a recent change to automake-1.9 you have adjusted the priorities so that 1.9 is the default, instead of 1.4. However this still does not solve many of the problems people have had in Ubuntu, so we've proposed a specification to transition the archive to the newest Automake and drop 1.4. https://wiki.ubuntu.com/AutomakeTransition As the Debian maintainer, we'd really appreciate your opinion on this; especially as there are several options listed which we have yet to choose between. Obviously any work we do will have the patches for all packages (including depending ones) supplied both to you and to the respective maintainers, so that there is a minimum amount of work to get it into Debian. Many thanks in advance, Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#365865: use update-notifier to get user to restart
On Tue, 2006-06-06 at 14:26 +0100, Ian Jackson wrote: Eric Dorland writes (Re: Bug#365865: use update-notifier to get user to restart): I couldn't find any docs [for update-notifier] myself, if you could point me to some that would be great. Hmm. It looks like I can't find them either. The package doesn't seem to contain any. I did find this: https://wiki.ubuntu.com/InteractiveUpgradeHooks which is a sort of melange of design and spec. Scott, you seem to be the most recent person listed in the `upstream' ChangeLog for update-notifier. Where is the documentation ? Never found any, the person you need to ask is Michael Vogt; the author. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#368969: rounding error causes generation of invalid filesystems
Package: squashfs-tools
Version: 1:2.2r2-2ubuntu2
Severity: critical
Tags: patch
Justification: causes the kernel to PANIC on an attempt to read from the
generated filesystem (unrelated package to break); and vital indexes are
lost so data in the generated filesystem cannot be retrieved (data loss)
Attached is a patch to correct a rounding error in the generation of the
fragment table indexes of generated squashfs filesystems. If the number
of fragments divides evenly into the size of each fragment table chunk
then the code believes that there are 0 bytes available in the buffer
rather then 8192 bytes.
This results in code being unable to obtain the final part of the
fragment index, making the files inaccessible and due to insufficient
sanity checking in the kernel code, the kernel PANIC.
I've also sent this patch upstream, who has verified that it is correct
and there is indeed a bug here. Note that although the patch is against
2.2r2, the difference is small enough that it will apply successfully to
3.0
Scott
--
Scott James Remnant
[EMAIL PROTECTED]
diff -ruNp squashfs-2.2r2~/squashfs-tools/mksquashfs.c squashfs-2.2r2/squashfs-tools/mksquashfs.c
--- squashfs-2.2r2~/squashfs-tools/mksquashfs.c 2006-05-26 03:13:44.0 +0100
+++ squashfs-2.2r2/squashfs-tools/mksquashfs.c 2006-05-26 03:25:33.0 +0100
@@ -942,7 +942,7 @@ unsigned int write_fragment_table()
}
for(i = 0; i meta_blocks; i++) {
- int avail_bytes = i == meta_blocks - 1 ? frag_bytes % SQUASHFS_METADATA_SIZE : SQUASHFS_METADATA_SIZE;
+ int avail_bytes = i == meta_blocks - 1 ? frag_bytes - SQUASHFS_METADATA_SIZE * i : SQUASHFS_METADATA_SIZE;
c_byte = mangle(cbuffer + block_offset, buffer + i * SQUASHFS_METADATA_SIZE , avail_bytes, SQUASHFS_METADATA_SIZE, noF, 0);
if(!swap)
memcpy(cbuffer, c_byte, sizeof(unsigned short));
signature.asc
Description: This is a digitally signed message part
Bug#332826: Many wrong man page references
On Sat, 2005-10-08 at 22:08 +0200, Frank Lichtenheld wrote: It seems most man pages have changed their section from 8 to 1 (even though I haven't found the changelog entry for that yet) but the references were only sparsely updated and many false ones remain. 2005-01-14 Scott James Remnant [EMAIL PROTECTED] * man/C/dpkg.8: Moved to section 1 where it belongs. * man/C/dpkg-query.8: Moved to section 1 where it belongs. * man/C/dpkg-split.8: Moved to section 1 where it belongs. * man/C/dselect.8: Moved to section 1 where it belongs. et al. Was this change really intended? Yes, they were in the wrong place :) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#322309: Debian woody dpkg no longer works with recent linux kernel.
On Mon, 2005-10-10 at 00:16 +0900, Junichi Uekawa wrote: dpkg in Debian woody (3.0) is broken by recent linux kernels; due to the following command changing behavior (mmap of zero-byte length): addr=mmap(NULL, 0, PROT_READ, MAP_SHARED, fd, 0); These bugs are caused by mmap changing behavior; it used to return NULL when given a length of 0. However, it now returns -1, and gives back an errno=EINVAL. Indeed. This was the sole change in the 1.13.8 release. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#328685: udev: main: action, subsystem or devpath missing
This is simultaneously caused by the kernel input subsystem not using
the new driver core, and the changes to udev to obsolete the /etc/dev.d
and /etc/hotplug.d directories.
With the new driver core the driver has an opportunity to add
environment to the uevent[0] generated along with the sysfs information
before the event is sent to userspace via the netlink socket and, for
backwards compatibility, the /proc/sys/kernel/hotplug interface.
However the input subsystem isn't yet doing this, so the sysfs-generated
event doesn't carry any of the PRODUCT, EV, KEY, etc. environment
variables describing the input device.
Instead the input subsystem has its own function to generate the
environment for a call to the /proc/sys/kernel/hotplug helper. This is
done in drivers/input.c input_call_hotplug().
Because this isn't related to the sysfs event, there's no way for it to
include the DEVPATH variable that points to the path in the sysfs
filesystem.
There are patches starting to float around now to update the kernel to
use the new driver core; at this point udev will be able to
drop /proc/sys/kernel/hotplug compatibility completely as all events
will come from the netlink socket and be well-formed.
udev *used* to handle this; when it received an event without the
required variables it would skip any udev.rules processing and just run
the old /etc/hotplug.d/ scripts.
udev-0.059 dropped direct support for these scripts, and instead
included a udev_run_hotplugd helper that distributions could chose to
ship alongside and add a udev.rules entry to run it.
This also meant that support for the malformed uevents was dropped at
the same time, as there's no way to perform udev.rules checking with
them.
The right solution, long-term, is for the kernel to use the new driver
core for the input subsystem. This will mean all sorts of hacks will go
away, and bring us one step closer to world peace and stuff.
The short term solution we've adopted in Ubuntu is the attached patch
that handles input subsystem events that are missing a devpath by
directly execing udev_run_hotplugd and letting that deal with it.
Scott
[0] the new name for what used to be hotplug events.
--
Scott James Remnant
[EMAIL PROTECTED]
diff -ruNp udev-060.orig/udev.c udev-060/udev.c
--- udev-060.orig/udev.c 2005-09-23 23:08:25.374883000 +0100
+++ udev-060/udev.c 2005-09-23 23:22:45.034195864 +0100
@@ -114,11 +114,25 @@ int main(int argc, char *argv[], char *e
if (!subsystem argc == 2)
subsystem = argv[1];
- if (!action || !subsystem || !devpath) {
- err(action, subsystem or devpath missing);
+ if (!action || !subsystem) {
+ err(action or subsystem missing);
goto exit;
}
+ if (!devpath) {
+ if (!strcmp(subsystem, input)) {
+ dbg(input event without devpath);
+ logging_close();
+
+ execv(/sbin/udev_run_hotplugd, argv);
+ err(exec of child failed);
+ _exit(1);
+ } else {
+ err(devpath missing);
+ goto exit;
+ }
+ }
+
/* export log_priority , as called programs may want to do the same as udev */
if (udev_log_priority) {
char priority[32];
signature.asc
Description: This is a digitally signed message part
Bug#317333: The case of udev and the missing /dev/input/mice
On Wed, 2005-09-21 at 11:51 +0200, Kay Sievers wrote: On Wed, Sep 21, 2005 at 03:38:06AM +0100, Scott James Remnant wrote: Background: in the upcoming Ubuntu 5.10 we've been having some problems with /dev/input/mice not being created on startup despite the mousedev module being hard-loaded early in the boot sequence. (http://bugzilla.ubuntu.com/show_bug.cgi?id=12915 for those interested). Debian has had similar problems too (http://bugs.debian.org/317333) and found that starting udevd earlier manually seemed to fix it. Yes, that's a good way to fix it. One thing I'd like to see changed in udevd is to move the init_udevd_socket() and init_uevent_netlink_sock() calls to above the daemonization; that way when you call udevd --daemon from the init script, you *know* that the next command may cause a netlink event. Right now there's an unknown amount of time between calling udevd --daemon and being able to safely modprobe. This'd also mean that udevd could exit with an error status if it's unable to create the necessary sockets; rather than the child exiting and the status being lost. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#317333: The case of udev and the missing /dev/input/mice
Background: in the upcoming Ubuntu 5.10 we've been having some problems with /dev/input/mice not being created on startup despite the mousedev module being hard-loaded early in the boot sequence. (http://bugzilla.ubuntu.com/show_bug.cgi?id=12915 for those interested). Debian has had similar problems too (http://bugs.debian.org/317333) and found that starting udevd earlier manually seemed to fix it. After much debugging, I've finally figured out what's going on ... it's a bit of a story, but here goes... Your system boots up and gets to the S:S20modules-init-tools stage, that's where we read /etc/modules and modprobe the modules in order. Now modprobe is basically just a kernel request, and these days tends to return pretty quicky to userspace without blocking for everything to happen. Deep Black Magic happens inside the kernel, and once it's done it generates a series of hotplug events which it passes back to userspace through two means; by running the program specified in /proc/sys/kernel/hotplug with interesting environment; and also through a netlink socket. /proc/sys/kernel/hotplug is udevsend, a tool that gathers up this environment and sends it over a local socket to the udevd process that marshals all of these events. If there's no daemon listening it tries to start one up, and will retry sending the event for a while until it gets to the other end. Now we have a whole bunch of udevsend processes all run at pretty much the same time, all of these try to start up udevd and all of the udevd processes try to bind to the local socket to receive events on. One of them wins, the rest die and go away. A little time passes by which time all of the running udevsend will have dispatched their event to this udevd that will marshal them. This udevd _also_ begins listening on the netlink socket, as it's a better way to get events from the kernel than having it execute something which mucks around with IPC to get it to us. Meanwhile the kernel is happily generating both /proc/sys/kernel/hotplug and netlink events for what's happening on the box, in fact it's been doing this all the time udevd has been getting its clothes on. If the module sequence loaded is something like psmouse, mousedev, ..., lp (exactly as it is in breezy machines that have been upgraded from warty/hoary[0]) you may find that the first netlink event you receive is actually for the printer port. But that's ok, we had udevsend events for the rest... Well, that's the theory; sadly here's the practice. On receiving the netlink event for the printer port, udevd disables receipt of any sequence numbered events from udevsend (ie. those that will almost certainly be duplicated over the netlink socket). Unfortunately this means all the udevsend events we're about to receive from the processes that backed off a second or so while fighting over who got to start udevd[1]. These udevsend processes deliver their events to udevd, which cheerfully ignores them because it thinks it's going to get another copy over the netlink socket any second now. Unfortunately the netlink event has already been and gone, and we just ignored an event we weren't supposed to. The two problems as I see them are: 1) The fact that receiving a netlink event disables sequence numbered udevsend events, when there's already code to deal with de-duping events anyway. Is there actually any need for this additional check, can't we just queue both events and have them ignored by msg_queue_insert() ? 2) That this ignoring of events is done at receipt, rather than in queue order. This means that the later parport_pc netlink event is able to disable queueing of udevsend events with a lower sequence number. I can envisage that #1 is necessary in case the time between receiving the udevsend and netlink event is so long that we've already processed and removed one of the events by the time the second is queued. In which case the problem becomes fixing #2, however unless the kernel promises strict ordering of events over the netlink socket (which I doubt, otherwise it wouldn't need sequence numbers), we can't assume that we've received all of the pre-netlink events we are going to. I suspect the right solution is actually to implement history of what events we've already processed, and de-dupe them that way; rather than ignoring messages on receipt. Scott [0] A common fix has been to simply install breezy fresh; this happens to change the /etc/modules order slightly and thus hide the bug. [1] And if we deliberately start udevd before we begin any of this module loading, it sees the netlink event, and thus again hides the bug. -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#327444: dpkg-buildpackage: -I does not work on dot-directories
On Sat, 2005-09-10 at 08:01 +0200, Wouter Verhelst wrote: Subject says it all. Specifically: I have my debian packages in a svn repository, but prefer to run dpkg-buildpackage manually inside that directory, rather than using something like svn-buildpackage. For that, I tried to use dpkg-buildpackage -I.svn to make sure these .svn directories don't get included in the package. However, this does not appear to work; the .diff.gz still contains the .svn directories if I run dpkg-buildpackage like 'dpkg-buildpackage -I.svn -rfakeroot'. Try -i instead? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#326986: amd64 dpkg-architecture gives no information
On Tue, 2005-09-06 at 17:46 -0700, Aaron T Porter wrote: Further digging shows an error reading /etc/libnss-ldap.conf, opening up permissions to this file produces the expected output from dpkg-architecture. This file does however contain an ldap bind password that would be best kept private. What is reading this file? dpkg-architecture doesn't itself. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#326986: amd64 dpkg-architecture gives no information
reassign 326986 perl,libnss-ldap
retitle 326986 getpwnam fails if libnss-ldap.conf is not readable
thanks
On Wed, 2005-09-07 at 10:30 -0700, Aaron T Porter wrote:
On Wed, Sep 07, 2005 at 01:09:22PM +0100, Scott James Remnant wrote:
On Tue, 2005-09-06 at 17:46 -0700, Aaron T Porter wrote:
Further digging shows an error reading /etc/libnss-ldap.conf,
opening up permissions to this file produces the expected output from
dpkg-architecture. This file does however contain an ldap bind password
that would be best kept private.
What is reading this file? dpkg-architecture doesn't itself.
Seems to be perl's getwnam on line 56 of
/usr/lib/dpkg/controllib.pl. This makes no sense to me, as that seems to
return valid data. However simply replacing the line with a hand generated
array makes things work:
if (defined ($ENV{'LOGNAME'})) {
#@fowner = getpwnam ($ENV{'LOGNAME'});
@fowner = { atporter,foo,21002,124};
if (! @fowner) { die (sprintf ('unable to get login information for
username %s', $ENV{'LOGNAME'})); }
}
The following produces the same output both as a non root user (where I
still see the error on libnss-ldap.conf) and as root:
@fowner = getpwnam (atporter);
@fowner = @fowner[2,3];
for (@fowner) {
print $_\n;
}
It's either a Perl or libnss-ldap problem then.
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
Bug#317967: probably fixed in .11 ..
On Sun, 2005-09-04 at 16:18 -0400, Joey Hess wrote: Presumably this bug was fixed in dpkg 1.13.11, which was released well after the fixed zlib got into the archive. Although I've not actually checked all the builds to see. Therefore I am not tracking this bug as a security hole, and IMHO it should be closed, unless the fact that dpkg still embeds a static zlib and still will be vulnerable and need recompiles because of future holes in that library is a problem worth leaving a bug open for. This bug was open because the Debian security team have still not uploaded a fixed version for stable! Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#325804: dpkg: typo in Russian man start-stop-daemon
On Wed, 2005-08-31 at 17:49 +0200, Christian Perrier wrote: Quoting Stepan Golosunov ([EMAIL PROTECTED]): Package: dpkg Version: 1.10.28 Severity: minor Tags: l10n patch man -L ru start-stop-daemon says that short vershion of --nicelevel is -n Scott, you fix or I fix? If it's just in the russian version, you can... :) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#325890: Installing a package when disk space is full results in segfault
On Wed, 2005-08-31 at 11:38 -0400, Frans Flippo wrote: OK :) I moved some stuff from /usr/share/doc and managed to install the new dpkg now. Was just going to try to see if the problem still existed but I guess you answered that. It's worth testing to make sure. How would I have found an existing bug report for this? I know the KDE bug system always searches for you when you report a bug, but the Debian BTS site seems kind of vague in this area... Select stable instead of unstable from http://www.debian.org/Bugs/ Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#192981: If this is considered a bug...
On Thu, 2005-08-25 at 19:19 +0200, Thomas Hood wrote: I take it that dpkg will be changed someday so that an unmodified conffile will have its perms updated? Yeah, that should be supported I think. Don't know whether it'll get fixed in 1.13, but 2.0 would inherently fix it I think. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#323909: dpkg-dev: Ignore Revision Control directories during making source package
On Fri, 2005-08-19 at 10:30 +0300, Jari Aalto wrote: Problem: W: foo source: source-contains-svn-control-dir src/os/.svn It is typical that packages are put into Revision control and worked in there. However not all programs are aible to export things (like RCS). It would help if there was a way to suppress including certain directories from source *.deb builds. Is this source a native (.tar.gz) or non-native (.orig.tar.gz and .diff.gz) package? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#267688: Shouldn't ...
On Sun, 2005-08-21 at 20:12 +0200, Marcello Maggioni wrote: Shouldn't the package in sarge be corrected too?? Sarge has been released; no more bug fixes are applied to it. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#324741: dpkg-gencontrol - loosed support for arch depend Depends line somewhere ago
reopen 170575 merge 170575 324741 thanks On Tue, 2005-08-23 at 20:21 +0200, Bastian Blank wrote: #170575 was marked fixed some time ago, but the version in sid does not accept such dependency lines. dpkg has _never_ had support for arch-specific Depend lines, just Build-Depend. That bug should not have been closed. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#324741: dpkg-gencontrol - loosed support for arch depend Depends line somewhere ago
On Wed, 2005-08-24 at 15:25 -0500, Adam Heath wrote: On Wed, 24 Aug 2005, Scott James Remnant wrote: On Tue, 2005-08-23 at 20:21 +0200, Bastian Blank wrote: #170575 was marked fixed some time ago, but the version in sid does not accept such dependency lines. dpkg has _never_ had support for arch-specific Depend lines, just Build-Depend. That bug should not have been closed. This is correct, _dpkg_ has never had support. However, dpkg-dev/dpkg-gencontrol did have support at one time(or the support is there but broken), and the arch-specific depends lines are fixed up when generating debian/tmp/DEBIAN/control. Then it was broken from release; I went back and checked the release that was in and it doesn't work -- because although the support is in the code, the crucial , 1) is missing from the call to the function that does it. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#323824: /usr/bin/dpkg-source: wishlist: include attached /etc/bash_completion.d/dpkg-source file
On Thu, 2005-08-18 at 19:48 +0200, Sven Mueller wrote: Basically the subject says everything needed: Please include the attached file as /etc/bash_completion.d/dpkg-source. This will enable bash command completion for dpkg-source in a (hopefully correct and) intelligent way. Sorry for being stupid, but shouldn't this be part of bash -- like the zsh completions come with zsh? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#317082: Not just a dpkg bug
reassign 317082 libc6-dev,dpkg-dev thanks I managed to grab Matthias Klose and he helped me get a working demo of the problem on my lowly i386, and I understand the bug now -- there's some missing context in the above mails. For those following, the problem is that people are building 64-bit libraries on a 32-bit platform (or the other way around) as part of the package build. dpkg-shlibdeps uses plain old ldd to find out the dependencies of a binary or shared library, but the ldd on the system won't be able to identify the impostor libraries. Build yourself a quick demo (on ubuntu breezy i386): $ sudo aptitude install libc6-dev-amd64 $ apt-get source zlib $ cd zlib # edit debian/rules: add i386 to 64-ARCHS # edit debian/control: add i386 to Architecture of lib64z1 and lib64z1-dev $ debian/rules build $ fakeroot debian/rules binary This'll fail with: dpkg_shlibdeps -p lib64z1 -lbuild-tree/zlib-1.2.3 /usr/bin/ldd: line 161: /lib64/ld-linux-x86-64.so.2: cannot execute binary file dpkg-shlibdeps: failure: ldd on `debian/lib64z1/usr/lib64/libz.so.1.2.3' gave error exit status 1 dh_shlibdeps: command returned error code 256 In this example, the 32-bit i386 ldd on my system can't read the amd64 binaries that have been generated. I don't think this is just a dpkg-dev bug, these bi-arch systems need to provide ldd or an equivalent that can read either form of shared library that it would support. objdump isn't a solution either, while it sometimes can read the other shared library, it doesn't provide the linker search patch which is of critical importance to get this stuff right. So I'm including libc6-dev (for want of a better package) in this bug, as we first need ldd on these bi-arch systems (or something similar) for dpkg-shlibdeps to use before we can fix that! Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#320925: leaks dpkg.log filedescriptor to child processes
On Fri, 2005-08-05 at 18:38 +0300, Török Edvin wrote: I have made a patch that sets close-on-exec. Tell me if this is what you expected, and if my patch really fixes what you meant. Also please test if dpkg still works correctly That kinda patches gettext g Already fixed this one, yet another bug that suffered from moving this from the initialisation routine (which took care of all this) into a when needed bit of code. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#317082: Uh, help!
tags 317082 moreinfo thanks Unfortunately I don't have either a 64-bit platform, or any real knowledge of them. I've read this bug a dozen times, and I have absolutely no idea what I'm supposed to do about it. Could someone please supply a guide for idiots/dpkg maintainers or better yet, a patch! Thanks, Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#318416: Acknowledgement (/usr/bin/dpkg-shlibdeps: add udeb support)
On Fri, 2005-07-15 at 21:16 +0200, Goswin von Brederlow wrote: talking to joeyh he said that he did a patch for the same thing as well. Comparing the two his is the preferable solution so please ignore this patch and stick with his. I don't suppose you happen to know where joeyh's patch _is_ do you? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#97320:
On Sat, 2005-07-16 at 12:49 +1000, Michael Wardle wrote: Would it not be more efficient if this information were stored in /var/lib/dpkg/status? I would find this feature very useful. Out of interest, what would you find it useful _for_ ? I can't think of a use-case for this field that isn't covered by /var/log/dpkg.log Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#322217: halt and bootmisc.sh is not in the initscripts package
On Wed, 2005-08-10 at 10:34 +0200, Thomas Hood wrote: Raphael Wegmann wrote: When I remove /etc/init.d/halt and /etc/init.d/bootmisc.sh before I call apt-get --reinstall install initscripts, the files halt and bootmisc.sh do not get restored. This is a bug^Wfeature of dpkg. To restore conffiles that have been deleted you have to purge the package before reinstalling it. Or use --force-confmiss when you reinstall. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#97320:
On Mon, 2005-08-15 at 11:01 +1000, Michael Wardle wrote: On Sun, 2005-08-14 at 22:41 +0100, Scott James Remnant wrote: On Sat, 2005-07-16 at 12:49 +1000, Michael Wardle wrote: Would it not be more efficient if this information were stored in /var/lib/dpkg/status? I would find this feature very useful. Out of interest, what would you find it useful _for_ ? I can't think of a use-case for this field that isn't covered by /var/log/dpkg.log Neither the apt nor the dpkg manual page mentions this log file, so I didn't know to look for it. The first thing that worries me about this file is that it only contains very recent actions, and it's not controlled by /etc/logrotate.conf, so it looks like dpkg itself is pruning old entries. /etc/logrotate.d/dpkg Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#310390: clarification
This mail is just to clarify for myself, because I'm dizzy and forgetful at times, that this bug doesn't appear to be dpkg not removing diverted files during upgrade. It's more subtle than that, it's dpkg not removing the NOT diverted file during an upgrade. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: Digital signature
Bug#317967: [CAN-2005-2096] dpkg-deb contains a statically linked copy of zlib
On Tue, 2005-07-12 at 18:10 +0200, Florian Weimer wrote: dpkg-deb seems to contain a statically linked copy of zlib version 1.2.2. This means it's potentially vulnerable to CAN-2005-2096. Please check, and advise the security team if an update for stable is required. From what I understand dpkg would be vulnerable, it will just need rebuilding. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#296026: Okay...
tags 296026 pending thanks So we can replicate this with a banana: syndicate tmp# dpkg -i banana.deb Selecting previously deselected package banana. (Reading database ... 126150 files and directories currently installed.) Unpacking banana (from banana.deb) ... Setting up banana (1.0) ... syndicate tmp# dpkg --purge banana (Reading database ... 126150 files and directories currently installed.) Removing banana ... Purging configuration files for banana ... Failing to purge dpkg: error processing banana (--purge): subprocess post-removal script returned error exit status 1 Errors were encountered while processing: banana syndicate tmp# dpkg -l banana pi banana 1.0yellow fruit And it turns out this is caused by the dpkg error handling doesn't work, and has never worked, OMFG WHY HAVE WE NOT NOTICED THIS? bug marga found ... syndicate tmp# ~/co/debian/dpkg-1.13/src/dpkg --purge banana (Reading database ... 126150 files and directories currently installed.) Removing banana ... Purging configuration files for banana ... Failing to purge dpkg: error processing banana (--purge): subprocess post-removal script returned error exit status 1 Errors were encountered while processing: banana syndicate tmp# dpkg -l banana pc banana 1.0yellow fruit Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#113626: Confirmed
Found this by accident while making a test case for another bug, glad to see this one's open already... syndicate tmp# dpkg-divert --package banana --divert /banana.other --add /banana Adding `diversion of /banana to /banana.other by banana' syndicate tmp# dpkg -i banana.deb Selecting previously deselected package banana. (Reading database ... 126152 files and directories currently installed.) Unpacking banana (from banana.deb) ... Setting up banana (1.0) ... syndicate tmp# dpkg -i banana-icecream.deb Selecting previously deselected package banana-icecream. (Reading database ... 126152 files and directories currently installed.) Unpacking banana-icecream (from banana-icecream.deb) ... (Noting disappearance of banana, which has been completely replaced.) Setting up banana-icecream (1.0) ... Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#310390: Example with DIVERTED file being removed during upgrade
So it turns out this way is true too: syndicate tmp# dpkg-divert --package banana --divert /banana.other --add /banana Adding `diversion of /banana to /banana.other by banana' syndicate tmp# dpkg -i banana.deb Selecting previously deselected package banana. (Reading database ... 126152 files and directories currently installed.) Unpacking banana (from banana.deb) ... Setting up banana (1.0) ... syndicate tmp# dpkg -i banana-icecream.deb Selecting previously deselected package banana-icecream. (Reading database ... 126153 files and directories currently installed.) Unpacking banana-icecream (from banana-icecream.deb) ... Setting up banana-icecream (1.0) ... syndicate tmp# dpkg -L banana-icecream /. /banana diverted by banana to: /banana.other /icecream syndicate tmp# dpkg -i banana-icecream2.deb (Reading database ... 126154 files and directories currently installed.) Preparing to replace banana-icecream 1.0 (using banana-icecream2.deb) ... Unpacking replacement banana-icecream ... Setting up banana-icecream (2.0) ... syndicate tmp# dpkg -L banana-icecream /. /icecream /banana-flavouring syndicate /# cat /banana.other This is banana from banana-icecream 1.0. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#310390: Example with UNDIVERTED file being removed during upgrade
As well as this way round: syndicate tmp# dpkg-divert --package banana-icecream --divert /banana.other --add /banana Adding `diversion of /banana to /banana.other by banana-icecream' syndicate tmp# dpkg -i banana.deb Selecting previously deselected package banana. (Reading database ... 126152 files and directories currently installed.) Unpacking banana (from banana.deb) ... Setting up banana (1.0) ... syndicate tmp# dpkg -i banana-icecream.deb Selecting previously deselected package banana-icecream. (Reading database ... 126153 files and directories currently installed.) Unpacking banana-icecream (from banana-icecream.deb) ... Setting up banana-icecream (1.0) ... syndicate tmp# dpkg -L banana /. /banana diverted by banana-icecream to: /banana.other /stamp syndicate tmp# dpkg -i banana2.deb (Reading database ... 126154 files and directories currently installed.) Preparing to replace banana 1.0 (using banana2.deb) ... Unpacking replacement banana ... Setting up banana (2.0) ... syndicate tmp# dpkg -L banana /. /stamp /banana-fruit syndicate tmp# cat /banana.other This is banana 1.0. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#310390: Example during removal
syndicate tmp# dpkg -i banana.deb Selecting previously deselected package banana. (Reading database ... 126152 files and directories currently installed.) Unpacking banana (from banana.deb) ... Setting up banana (1.0) ... syndicate tmp# dpkg -i banana-icecream.deb Selecting previously deselected package banana-icecream. (Reading database ... 126153 files and directories currently installed.) Unpacking banana-icecream (from banana-icecream.deb) ... Setting up banana-icecream (1.0) ... syndicate tmp# dpkg --remove banana-icecream (Reading database ... 126153 files and directories currently installed.) Removing banana-icecream ... syndicate /# cat banana.other cat: banana.other: No such file or directory So we're only dealing with upgrades, and not removals here... Scot -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#310390: Example with UNDIVERTED file being removed during upgrade
On Sat, 2005-07-16 at 18:50 +0300, Scott James Remnant wrote: As well as this way round: Uh, that demo was bogus! It was demonstrating a diverted file again, wasn't it. Here's the right demo (and still proving this it happens this way too...) syndicate tmp# dpkg-divert --package banana --divert /banana.other --add /banana Adding `diversion of /banana to /banana.other by banana' syndicate tmp# dpkg -i banana.deb Selecting previously deselected package banana. (Reading database ... 126152 files and directories currently installed.) Unpacking banana (from banana.deb) ... Setting up banana (1.0) ... syndicate tmp# dpkg -i banana-icecream.deb Selecting previously deselected package banana-icecream. (Reading database ... 126153 files and directories currently installed.) Unpacking banana-icecream (from banana-icecream.deb) ... Setting up banana-icecream (1.0) ... syndicate tmp# dpkg -L banana /. /banana package diverts others to: /banana.other /stamp syndicate tmp# dpkg -i banana2.deb (Reading database ... 126154 files and directories currently installed.) Preparing to replace banana 1.0 (using banana2.deb) ... Unpacking replacement banana ... Setting up banana (2.0) ... syndicate tmp# dpkg -L banana /. /stamp /banana-fruit syndicate tmp# cat /banana This is banana 1.0. And we can combine the two demos and get some very interesting behaviour: syndicate tmp# dpkg -i banana-icecream2.deb (Reading database ... 126155 files and directories currently installed.) Preparing to replace banana-icecream 1.0 (using banana-icecream2.deb) ... Unpacking replacement banana-icecream ... Setting up banana-icecream (2.0) ... syndicate tmp# cat /banana.other cat: /banana.other: No such file or directory It seems that the undiverted file not being owned by a package matters to whether the diverted file is removed or not... (doing this in reverse is also true). Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#15695: Not a dpkg bug
unmerge 15695 reassign 15695 lilo merge 15162 15965 kthxbye This is another bug that's a copy of 15162, dpkg is informing the old version that an upgrade to it was aborted -- and lilo's postinst is failing to catch that particular postinst argument. (ps. Andrés, as you can guess, you can just close these g -- we're just drinking too much coke in our little BSP here and having fun) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#15162: Not a dpkg bug
unmerge 15162 reassign 15162 lilo kthxbye This is not a bug in dpkg, it has caught the fact it can't change the ownership of /boot/boot.b on an MS-DOS filesystem and has aborted the upgrade (as you can tell from your own status output). As part of the process of aborting the upgrade, it will run the postinst of the old version of lilo with the arguments abort-upgrade 20-0.1. Clearly the postinst of lilo version 19-2 does not expect to get abort-upgrade, and carries on as normal. Please check whether the current version still exhibits this bug. Thanks, Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#65690: Unreplicable
unmerge 65690 close 65690 kthxbye This is an old bug, and cannot be replicated. dpkg is extra-ordinarily anal about checking that every write() and the close() succeed -- and will roll-back the installation or upgrade of a package if the disk becomes full while it does so. If you can come up with a test case for this on a real filesystem, please feel free to file a new bug report. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#269614: Please provide the .deb
Core dump isn't that useful (dpkg isn't compiled with debugging symbols on your system) -- but PLEASE provide that broken.deb Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#89771: Old bug
unmerge 89771 close 89771 kthxbye This is an old bug that cannot be replicated; there have been other bug fixes in this error that may have corrected that segfault -- if it happens again, please file a new bug. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#106224: Old bug
unmerge 106224 close 106224 kthxbye This is an old bug, and is currently unreproducible. There were recent fixes to dpkg's error handling and unpack clean-up that may have fixed this. Please try again, and if you still get the problem, open a new bug. The intended behaviour is that on the unpack failing, dpkg rolls back the package to the previous state and leaves your system as it found it -- this is tested and seems to work in the cases I have here. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#96391: Hmm...
unmerge 96391 close 96391 kthxbye I don't really think it's dpkg's problem that you ran out of disk space, it did the best it could and will roll back the install/upgrade of that package and leave your system how it found it. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#313605:
severity 313605 minor thanks This bug should not be serious, it is not a severe violation of Debian policy, and does not, in my opinion make the package unsuitable for release. Neither is it grave (it does not make dpkg unusuable, or mostly so, or introduce a security hole) or critical (in order to justify that it makes unrelated software _break_ you'd need to provide an example Bug# caused by this diversion). This bug doesn't affect dpkg's usefulness and is trivial to fix once an upload of coreutils to fix Bug#313258 has taken place. Therefore the appropriate severity is minor. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#313381: reopen 313381, not all cases are fixed
On Fri, 2005-07-01 at 11:13 +0200, Wolfram Quester wrote: On Thu, Jun 30, 2005 at 05:02:36PM +0100, Scott James Remnant wrote: On Thu, 2005-06-30 at 17:38 +0200, Wolfram Quester wrote: there is another appearence of the same bug, but with another extension, which was not captured by the last upload: This won't be the same bug, but a different one; turning this into a new bug report. Well, I think it is the same as #316470. Bit of a silly thing to argue about ;) It's a different line of code, so a different bug, just a similar one... but, in fact: Yes, lintian inkscape_0.41-5.dsc works, but the output I sent was from a new package I just built. You can download the new orig.tar.gz via wget http://switch.dl.sourceforge.net/sourceforge/inkscape/inkscape-0.41+0.42pre0.tar.gz mv inkscape-0.41+0.42pre0.tar.gz inkscape_0.41+0.42pre0.orig.tar.gz .dsc and .diff.gz are appended to this mail. If I do lintian inkscape_0.41+0.42pre0.dsc I get the aforementioned error. Those are illegal filenames, diff.gz _MUST_ have a Debian revision. Therefore this isn't a bug (other than a confusing error message). Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
