Bug#281154: RFA: ipsec-tools -- IPsec tools for Linux
Package: wnpp Severity: normal I am planning to maintain this package in the meanwhile, and would love to help out with the racoon-tool script that configures the daemon. I have an interest in making this work for my new laptop, but IPSEC and VPNs are no longer part of my day-to-day work, and other things have far more priority than this. (I do some email for an aid organisations and medical work in the developing world - this work has higher priority for obvious reasons). Not just any person should take this package on, as it is highly technical. I am looking for someone with a background in IPSEC and in network programming. I am also looking to help out from time to time and add new functionality. Cheers, Mattthew Grant -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.9-laptop-pmac-2.6 Locale: LANG=en_NZ, LC_CTYPE=en_NZ
Re: pkg-config issues
On Fri, 2004-11-12 at 14:47 +0100, Bartosz Fenski aka fEnIo wrote: > I've just started packaging some library which provides .pc file for > pkg-config. So I was wonder where to put this file and if my -dev package > should depend on pkg-config. > > As usual I started looking how it is done in other libraries and > unfortunatelly this didn't lead me to clear answer. > Seems that policy doesn't describe it either. > > Problem a: > > Where .pc file should be put? > Let's say I've got libXXX and libXXX-dev packages. > libXXX-dev ... it's part of the development side of your package, like the Libtool .la file, and any other "how to build this" information. > I suppose that I should put it in libXXX-dev package, but I found some > packages which contain this file in libXXX. > They're buggy. > Problem b: > > Should my package depend on pkg-config? > I thought yes, but many packages didn't do that. > No -- not unless your package, for some mad reason, requires users to use pkg-config to build against your shared library. Packages that use pkg-config to find out about the shared libraries they need to build, build-depend on pkg-config. 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
Re: Introducing pmount in Debian / New plugdev group
On Tue, 09 Nov 2004 18:50:39 +0100, Martin Pitt wrote: > However, I was not satisfied with this solution because of several > reasons: [Several excellent reasons] > So the Ubuntu approach is a bit different: we let hal run as normal > user, do not modify /etc/fstab at all and instead use a program > called 'pmount' (policy mount) that allows normal users to mount > removable devices without an /etc/fstab entries. All sounds good. Have you heard that mount's upstream is looking for someone to adopt mount (and the rest of util-linux)? Interested? -- Thomas Hood
Re: Nagios Packages
Ce jour Sun, 14 Nov 2004, Joerg Jaspert a dit: > Hi > built, installed, and ran fine on PPC. it's now happily running as before. -- ,''`. http://www.debian.org/ http://www.nuit.ca/ : :' : Debian GNU/Linux http://simonraven.nuit.ca/ '-- `- GPG Print: 7C49 FD9C 1054 7300 3B7B 8BF4 6A88 7AE2 711D F097 signature.asc Description: Digital signature
Re: sarge security (was: Re: Release update: please upload to unstable; toolchain; buildds; ...)
* Marc Haber ([EMAIL PROTECTED]) [041113 19:20]: > On Sat, 13 Nov 2004 14:53:25 +0100, Martin Schulze <[EMAIL PROTECTED]> > wrote: > >Adrian 'Dagurashibanipal' von Bidder wrote: > >> Will the start of official security support for sarge be announced widely, > >> to get as much testing as possible? (Like: general debian-announce, press > >> contacts, ...) > >No. Why should it? > Because it was widely announced to start on September 15, and many > people are already running sarge. We learned from that mistake, and don't announce any fixed dates until we have it working (and, BTW, we announced also that we won't make it at that date - but I also know that enough magazines have just ignored that). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: sarge security (was: Re: Release update: please upload to unstable; toolchain; buildds; ...)
Marc Haber wrote: > >Adrian 'Dagurashibanipal' von Bidder wrote: > >> Will the start of official security support for sarge be announced widely, > >> to get as much testing as possible? (Like: general debian-announce, press > >> contacts, ...) > > > >No. Why should it? > > Because it was widely announced to start on September 15, and many > people are already running sarge. It will probably be announced on the same channels by the same people. Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists.
Re: Introducing experimental php5 packages
|| On Sat, 13 Nov 2004 18:42:47 +0100 || Piotr Roszatycki <[EMAIL PROTECTED]> wrote: pr> If it is possible, I'd like to upload the packages to the experimental pr> archive. I think is the right place to put it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house."
Looking for co-maintainers for MySQL and Quaga
Hello I'm looking for a co-maintainer for my MySQL and Quagga packages. Any volunteers? :-) bye, -christian- pgpD6y7qSVqF0.pgp Description: PGP signature
Re: Documentation for upstream software authors
Adrian 'Dagurashibanipal' von Bidder wrote: > I've just started http://wiki.debian.net/SoftwarePackaging, intended to > collect thoughts of packagers how upstream developers can make the life of > a packager easier. > > I'm sure all packagers have wondered about "brain-dead" upstream developers > who have not put much thought into how their software might be distributed > in a pre-compiled/pre-configured package. Compile-time options are one > example, user-modifiable files outside of /etc are another, to name the two > that I could think of just now. What comes to my mind: - public version control (cvs, arch, svn) by upstream - public development mailing list - public availability of old and new versions at a defined location (for watch files etc.) - clean clean target - don't distribute auto-generated files except for configure/autofoo but add rules to the Makefile to generate them on-demand - add a private mail address of the lead developer to the distributed files (contrary to only a mailing list, this is important for security problems that need to be discussed off the public first) - configurability of path names (so that the pkg can be made FHS compatible easily without loads of patches) - an announce list and a packager list may also be helpful to notify packages of new versions / security problems (private) Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists.
Re: any comments on diagram?
Kevin Mark wrote: > Hi DD folks, > i made a diagram in xfig of what I think is the debian development > model. Could folks give me a few comments on what's not correct. > http://kmark.home.pipeline.com/debian.png Oh dear! Several remarks: . user serif-less fonts . there is no path from volatile to stable . there is no path from volatile to proposed-updates . the path from proposed-updates to stable is by SRM (stable RM) . the path from testing-proposed-updates by RM is missing . the automatic path from security to proposed-updates is missing . I have no idea why Libraries is different from stable . I have no idea what the bugfixes patch from foo to debian-source is mean to explain . some arrows are not horizontally/vertically aligned as they should . there may be missing an arrow from securityteam.deb to unstable (in case the maintainer doesn't respond) Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists.
Re: Nagios Packages
Joerg Jaspert <[EMAIL PROTECTED]> writes: > Hi > > A while ago the old Nagios Maintainer filed an O: for nagios. A group of > people, including myself, started an Alioth-Project for it and did some > work with the packaging. > Now we are at a point where we can consider an upload into the archive, > but I think it would be good to have some extra tests of the packages > before doing this, because we did some big changes to the package. The package doesn't ship an init script, debian/nagios-common.init.d needs to be renamed to debian/nagios-common.nagios.init. Otherwise the package works fine for me (fresh install on amd64). -- ilmari
Re: Documentation for upstream software authors
Hi! Martin Schulze [2004-11-14 20:13 +0100]: > Adrian 'Dagurashibanipal' von Bidder wrote: > > I've just started http://wiki.debian.net/SoftwarePackaging, intended to > > collect thoughts of packagers how upstream developers can make the life of > > a packager easier. > > > > I'm sure all packagers have wondered about "brain-dead" upstream developers > > who have not put much thought into how their software might be distributed > > in a pre-compiled/pre-configured package. Compile-time options are one > > example, user-modifiable files outside of /etc are another, to name the two > > that I could think of just now. > > What comes to my mind: > > - public version control (cvs, arch, svn) by upstream > - public development mailing list > - public availability of old and new versions at a defined location >(for watch files etc.) > - clean clean target > - don't distribute auto-generated files except for configure/autofoo >but add rules to the Makefile to generate them on-demand > - add a private mail address of the lead developer to the distributed >files (contrary to only a mailing list, this is important for security >problems that need to be discussed off the public first) > - configurability of path names (so that the pkg can be made FHS compatible >easily without loads of patches) > - an announce list and a packager list may also be helpful to notify >packages of new versions / security problems (private) - Refrain from including source code from libraries which are externally available, or at least make it easy to use the external version of a library instead. Half a thousand copies of one and the same library scattered throughout Debian is an outright security nightmare. Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: debian.org e-mail address and SPF/SRS
Osamu Aoki wrote: > > Stephane Bortzmeyer wrote: > > > I remail my email from debian.org machines, I do not forward it. So, I > > > do not have the problem (I have others, but it is a different story). > > > > > > master:~ % cat .procmailrc > > > > > > :0 > > > ! [EMAIL PROTECTED],[EMAIL PROTECTED] > Sigh, it does not fool SPF with this way. Whether that remails or not seems to be a feature of procmail. Some do and some don't so this is apparently a configure option for procmail. In any case you can remail this way. Pipe the message to /usr/sbin/sendmail -oi. :0 | $SENDMAIL -oi [EMAIL PROTECTED] Bob signature.asc Description: Digital signature
Bug#281283: ITP: mux -- The MUX mush server
Package: wnpp Severity: wishlist * Package name: mux Version : 2.3.3.22 Upstream Author : Stephen Dennis <[EMAIL PROTECTED]> * URL : http://www.tinymux.com/ * License : Artistic Description : The MUX mush server This is the MUX flavor of mud servers of the MUSH branch. It provides a number of robust features to enable players to extend the virtual world. This is done by building new rooms and objects, and utilizing its internal programming language, MUSHcode.
Bug#281279: ITP: mudmagic -- The MUDMagic MUD and MUSH client for X
Package: wnpp Severity: wishlist * Package name: mudmagic Version : 1.0.4 Upstream Author : Calvin Ellis <[EMAIL PROTECTED]> * URL : http://www.mudmagic.com/mud-client/ * License : GPL Description : The MUDMagic MUD and MUSH client for X MUDMagic is a robust, expandable, and portable client for connecting to MUD family game servers (LP, Diku, MUSH, MOO, MUCK, etc...). It is designed to for both Linux and Windows, be portable enough to fit on a floppy disk, yet support a wide range of features by loading additional plugins on demand.
