LVM packages up for adoption
What with a change of circumstances and lack of time recently I don't honestly think I'm doing a good enough job on the LVM packages, so I'm offering them up for adoption to anyone who thinks they can do a better job. The packages are: lvm2- in active development, upstream helpful but often busy. device-mapper - largely stable. occasional releases. lvm10 - stable. no more upstream development at all. lvm-common - native package. small number of bugs need sorting out multipath-tools - in active development, upstream very helpful. If nobody wants them I'll continue to do the best I can with the time available. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LVM packages up for adoption
On Tue, Jan 18, 2005 at 03:46:18PM +, Tim Cutts wrote: > > On 17 Jan 2005, at 5:42 pm, Bastian Blank wrote: > > >On Mon, Jan 17, 2005 at 09:28:56AM +, Patrick Caulfield wrote: > >>lvm2- in active development, upstream helpful but often > >>busy. > >>device-mapper - largely stable. occasional releases. > >>lvm10 - stable. no more upstream development at all. > >>lvm-common - native package. small number of bugs need sorting > >>out > >>multipath-tools - in active development, upstream very helpful. > > > >I'm interrested onm co-maintaining lvm2 and device-mapper. > > As am I - we use these heavily on some fairly serious kit at work, so I > can justify the time... co-maintaining sounds like a sensible thing to > do. > So how about you three co-maintain lvm2 & devmapper (and maybe lvm-common ? it's as much part of LVM as the lvm2 package really), and I'll hang onto lvm10 & multipath. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LVM packages up for adoption
On Tue, Jan 18, 2005 at 01:11:09PM -0500, Andres Salomon wrote: > > My recommendation would be an LVM alioth project, w/ a svn or arch > (preferred) repository. I've kept track of lvm2 stuff in arch for a > number of years, it has worked well. > > Patrick, it might even be worth all 4 of us maintaining all the LVM > related packages (throwing lvm10 in with the rest), since Tim uses > multipath-tools, and none of us care much for lvm10. > That sounds like a good plan. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: stable executable names
On Wed, Nov 05, 2003 at 06:05:44PM +0800, Cameron Patrick wrote: > On Wed, Nov 05, 2003 at 08:47:29PM +1100, Zenaan Harkness wrote: > > | Now, what's finally got to me one too many times: > | * I run firebird then can't run mozilla. > | * I run mozilla then can't run firebird. > > I've also noticed this. A quick look at the BTS shows that someone has > already filed a bug on it: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=216264 > > Apparently it has been fixed upstream. That's nice to hear. What I ended up doing was running Mozilla with a different profile name called "editor" mozilla -edit -P editor patrick
New kernel headers break LVM build
LVM1 includes kernel headers in its build - yeah, I know, but it does interface (rather too) tightly into the kernel. The problem now is that the linux-kernel-headers package has Linux 2.6 files in it rather than 2.4 and LVM(1) is not supported in 2.6. so it doesn't build. This isn't a new problem with LVM. ie: not upgrading to 1.0.7 isn't the answer as 1.0.7 won't build in this environment either. Bug: #221663 The only solution I can think of is for the lvm10 package to build-depend on (eg) kernel-source-2.4.19, then in the build script untar the header files, make the arch symlink (ugh) and compile against that. Does anyone else have any nicer ideas? apart from getting everyone to migrate to LVM2 :-) -- patrick
Re: New kernel headers break LVM build
On Wed, Nov 19, 2003 at 03:33:53PM +0100, Christoph Hellwig wrote: > On Wed, Nov 19, 2003 at 02:18:34PM +0000, Patrick Caulfield wrote: > > The only solution I can think of is for the lvm10 package to build-depend on > > (eg) kernel-source-2.4.19, then in the build script untar the header > > files, make the arch symlink (ugh) and compile against that. > > > > Does anyone else have any nicer ideas? apart from getting everyone to > > migrate to > > LVM2 :-) > > Fix LVM1 to keep copies of the headers it needs in it's source tree. including asm directories for all 18 architectures. Ah well; if it's already gross, making it hugely gross is not much of a descent. -- patrick
Bug#277898: ITP: multipath-tools -- Command-line utilities for administering multipath disk access
Package: wnpp Severity: wishlist * Package name: multipath-tools Version : 0.3.3 Upstream Author : christophe varoqui <[EMAIL PROTECTED]> * URL : http://christophe.varoqui.free.fr/ * License : LGPL, GPL Description : Command-line utilities for administering multipath disk access These tools are in charge of maintaining the disk multipath device maps and react to path and map events. They recquire a 2.6 kernel patched with the -udm patchset hosted at http://source.redhat.com/dm/ This patchset shouldn't be necessary from kernel 2.6.10 onwards. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: sparc (sparc64) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=en_GB.ISO-8859-1
Re: Library namespace conflicts
On Fri, Aug 09, 2002 at 04:40:43AM -0400, Simon Law wrote: > > I grant you that, this piece of software is a young 'un; > although I'm surprised that this didn't come up any sooner. (Lucky us.) > > I don't think either library has more than one piece of software > that currently requires it; but this could change for libdnet.sf.net in > the future, seeing as there is activity on the nmap mailing lists. > Since you've had the name for such a long time, I'd like to defer > judgement to you. What do you think is a reasonable way to handle this? > Rename one of the libraries and tweak code that depends on it? Rename > one of the libraries and make them both conflict with each other? > Provide libdnet.sf.net in fragroute and link statically? As the man page at http://libdnet.sourceforge.net/dnet.3.txt refers to the library as "dnet - dumb networking library" how about renaming it libdumbnet? :-) patrick
Re: Library namespace conflicts
On Wed, Aug 14, 2002 at 08:06:54AM -0400, Simon Law wrote: > On Wed, Aug 14, 2002 at 10:11:33AM +0100, Patrick Caulfield wrote: > > On Fri, Aug 09, 2002 at 04:40:43AM -0400, Simon Law wrote: > > As the man page at http://libdnet.sourceforge.net/dnet.3.txt refers to the > > library as "dnet - dumb networking library" how about renaming it > > libdumbnet? > > > > :-) > > One step ahead of you. That's exactly what the package I'm in > the process of creating is named[1]. I though you might, but it was worth mentioning. > Could you be a dear and mention > libdumbnet in your package description, for people who would be looking > for the canonical name? Certainly. patrick
