Bug#491200: Version 2.23-03 is current
http://www.webalizer.org/download.html has version 2.23-03. Lots of bug fixes and handy new features. Is the pull from upstream ever going to happen? I do not want to be pushy, but this bug is 2.5 years old now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597748: ps -o incorrectly truncates fields
Package: procps Version: 3.2.8-9 According to the POSIX spec for the -o option of the ps command (http://www.opengroup.org/onlinepubs/9699919799/utilities/ps.html): The field widths shall be selected by the system to be at least as wide as the header text (default or overridden value). The 3.2.8 version of procps violates this specification. To reproduce: ln -s /bin/sleep hellohellohowareyou # Create command with long name ./hellohellohowareyou 180 # run it in the background ps -o comm= # Do ps -o with a wide field header You will find the process name gets truncated to 15 characters (hellohellohowar) no matter how wide you make the overridden header text. This actually caused me some trouble with an old shell script I am migrating from Solaris, which does not have this bug. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579624: [Debian-ha-maintainers] Bug#579624: Me too
On Fri, Jul 2, 2010 at 7:35 AM, Guido Günther a...@sigxcpu.org wrote: I'm unsure why you picked Lucid as a base but thanks a lot for testing! I used Red Hat from version 4.0 (note no Enterprise...) A few years ago, I tried Ubuntu and never looked back. Or elsewhere. Did you put your configuration somewhere so we could point other users trying to do the same there? Right now it is a bunch of unreadable notes. I would like to put something better together, eventually, time permitting... But I started with this: https://wiki.ubuntu.com/ClusterStack/LucidTesting If you Jjust skip the parts about setting up the ubuntu-ha PPA repository and use the Debian experimental packages instead, you will get something that looks a lot like my cluster. The basic procedure is the same: First set up pacemaker/corosync, then use crm configure to set up dlm and o2cb resources on all hosts, then go to town with mkfs.ocfs2 and mount.ocfs2. - Pat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579624: [Debian-ha-maintainers] Bug#579624: Me too
I have now built a fully working Pacemaker cluster -- with OCFS2 on top -- using Ubuntu Lucid and Debian experimental packages, including those from redhat-cluster. So, based on my testing, this bug appears to resolved by the latest experimental packages. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587287: mkfs.ocfs2 depends on libdlm-dev
On Mon, Jun 28, 2010 at 1:02 AM, Jeremy Lainé jeremy.la...@m4x.org wrote: It looks as though there are two issues here: a/ My understanding is that upstream does a dlopen() on libdlm_lt.so in order to be able to use libdlm_lt.so.2 or libdlm_lt.so.3 depending on the system. OK, but that will also pull in lidlm_lt.so.4, or libdlm_lt.so.5, or libdlm_lt.so.6... It would be wrong for libo2dlm to load libdlm_lt.so.4 before the developers even know what it is. The results would be unpredictable; potentially even dangerous. The whole point of libfoo.so.N is that N changes when and only when binary compatibility is broken. It also allows multiple Ns to co-exist on the same system. Using dlopen() on libfoo.so breaks both of those. libfoo.so is a development library. libfoo.so.N is a production (run-time) library. To have a production binary depend on libfoo.so is simply a bug, and I would like to help fix this bug upstream. I can think of three ways to do so: 1) Link against -ldlm_lt at compile time. This was rejected by the ocfs2 maintainers some time ago for introducing undesired dependencies. or 2) Have configure detect the version of libdlm_lt.so.N at compile time, and have libo2dlm use that. or 3) Modify libo2dlm/o2dlm.c to attempt to dlopen() libdlm_lt.so.3, then try libdlm_lt.so.2 if that fails. This is simplest, and maximizes portability of the binary, so it would be my suggestion. Joel, I volunteer to create and test a patch for any of these approaches, if you would find any of them acceptable. Just let me know. I have added a patch for the next upload of ocfs2-tools which does just that: http://svn.debian.org/wsvn/collab-maint/deb-maint/ocfs2-tools/trunk/debian/patches/libo2dlm-dlopen-libdlm_lt.patch Thank you. Apparently, Suse is already applying exactly the same patch. But instead of every distribution fixing this bug for themselves, I would like to work together to get it fixed upstream. - Pat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587365: mcelog decodes timeout flag backwards
Package: mcelog
Version: 1.0~pre3.2
(I apologize for submitting this via Debian, but I have been
completely unable to locate contact information for the upstream
mcelog maintainer.)
According to the Intel® 64 and IA-32 Architectures Software
Developer’s Manual, section 15.9.2.5 (Table 15-13), the T (timeout)
bit has the following interpretation:
1 = Request timed out
0 = Request did not time out
But in mcelog-1.0pre3/p4.c, we have the following function:
static char* get_T_str(__u8 t)
{
static char* T[] = {Request-timeout, Request-no-timeout};
if (t = NELE(T)) {
return UNKNOWN;
}
return T[t];
}
This code is interpreting the bit exactly backwards. (An
understandable mistake, since Intel's manual oddly describes the
meaning of 1 before the meaning of 0.)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587365: addendum
Here is a direct link to Table 15-13 in the Intel Software Developer's Manual describing the intepretation of the T (timeout) bit: http://www.intel.com/Assets/PDF/manual/253668.pdf#page=655 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587284: ocfs2_controld.pcmk should be in /usr/sbin, not /sbin
Package: ocfs2-tools-pacemaker Version: 1.4.4-2 The new ocfs2-tools-pacemaker package (thank you, by the way!) installs ocfs2_controld.pcmk under /sbin. Unfortunately, the /usr/lib/ocf/resource.d/o2cb script from the pacemaker package -- which starts this daemon -- expects to find it under /usr/sbin. Consequently, the daemon refuses to start when configured as part of a standard Pacemaker cluster stack. Please move the ocfs2_controld.pcmk daemon to /usr/sbin or at least put a symlink there. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587285: Please add /lib/udev/rules.d/51-ocfs2.rules to ocfs2-tools package
Package: ocfs2-tools Version: 1.4.4_2 The file ocfs2-tools-1.4.4/vendor/common/51-ocfs2.rules must be installed under /lib/udev/rules.d or /etc/udev/rules.d in order for OCFS2 to function properly, at least for Pacemaker support (and possibly in general). Without this file, ocfs2_controld.pcmk refuses to start, logging the following error: Error opening control device: Unable to access cluster service This is because ocfs2_control.pcmk is trying to access /dev/misc/ocfs2_control, which udev does not create unless this .rules file is in place. Relevant ocfs2-users thread: http://oss.oracle.com/pipermail/ocfs2-users/2010-June/004602.html Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587287: mkfs.ocfs2 depends on libdlm-dev
Package: ocfs2-tools Version: 1.4.4-2 While trying to run mkfs.ocfs2 (Pacemaker cluster stack), I consistently got the following error: Unable to access cluster service while initializing the dlm I tracked this down to mkfs.ocfs2 attempting to dlopen() libdlm_lt.so. Unfortunately, this symlink is part of the libdlm-dev package. Production releases should not depend on development packages. And if they do, the dependencies need to be explicit, because errors like this are painstaking to diagnose. :-) To be honest, I am not sure whether this is a bug in ocfs2-tools (which has this unmentioned dependency on libdlm-dev) or in redhat-cluster (which puts this .so link in libdlm-dev). Normally, .so links are part of development packages, but in this case, perhaps it belongs in libdlm3 (?). Let me know if you think I should submit this bug against redhat-cluster instead. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586778: ocfs2-tools is missing Pacemaker support (ocfs2_controld.pcmk)
Package: ocfs2-tools Version: 1.4.3-2 The current Debian ocfs2-tools package does not include the Pacemaker variant of the OCFS2 DLM controller (ocfs2_controld.pcmk). This should build itself automatically if the Pacemaker headers and libraries are installed. (The ocfs2-tools configure script auto-detects these; grep for pcmk in configure.in to see what I mean.) It would be really handy if ocfs2-tools were ready to interact with a modern and standard cluster stack. Please bundle this support. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586784: Import upstream ocfs2-tools 1.4.4
Package: ocfs2-tools Version: 1.4.3-2 The current upstream release (as of April 2010) of ocfs2-tools is 1.4.4. Please consider upgrading the Debian package. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579624: Me too
The Ubuntu folks are running off and doing this themselves... Pacemaker is the official cluster stack of Suse and (soon) Ubuntu. Debian should support it by default, IMO. Is this not a trivial change? What can I do to help make it happen? Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
