Removal of freeswan from sarge
Hi all, [Please CC me in replies, I am currently not subscribed to -devel. This is also cross-posted to debian-user because it might affect users that are not subscribed to -devel.] I have thought for quite some time about this issue and have now come to a decision. Sorry that it's rather late in the release process, but I really think it'll be better this way. If nobody wants to argue in favor of it, I hereby request freeswan to be removed from the archive (unstable and testing). (Please read further before actually doing it or starting to flame. Thanks.) Reasoning: freeswan is dead. It's upstream development has been discontinued, it has a lot of open bugs in the Debian BTS that I sometimes can't and for others won't fix. Besides all of that, the freeswan package has always been a bloody mess, with sometimes >10 (usually conflicting) patches needing to be applied to get all the features necessary for today's IPSec demands. Yes, package updates to new upstream version have not (only) taken that long because I am lazy. But don't despair, a new contender is here for rescue: openswan. It is a fork of the freeswan codebase, but already integrates most of the third-party patches I have been applying to the Debian package over the last years. It is therefore more feature-complete than native freeswan ever was. Since quite some time, I am also packaging openswan, and for nearly that long it is also in the Debian archive (unstable and testing). I am a lot more happy with my contacts to openswan upstream than I have been to my contacts to freeswan upstream (although some of them simply moved from freeswan to openswan). I can't give some facts here, but the openswan team is extremely responsive to any requests, which I like very much. In fact, most of the time the upstream package will include the latest Debian packaging, so the .diff.gz is generally _very_ small. One of the best points for openswan, from a user point of view, is that it is config-file compatible. I.e. if you remove (not purge) freeswan, install openswan, and - if you use the KLIPS kernel part instead of the native Linux IPSec kernel stack - recompile the kernel (or the modules) with openswan instead of freeswan, no other changes should be necessary. The same ipsec.conf, ipsec.secrets and X.509 certificates can be used. To make a long story short: If you have any compelling reason to continue using freeswan, i.e. if for some reason you can not use openswan, then please let me know now. And no, not wanting to compile a new kernel because of the switch is not a compelling reason. If you can't recompile your kernel, you either a) shouldn't have compiled it in the first place or b) should not be running unstable or testing. Remember that nothing will change for stable. I am probably being presumptuous with regard to current freeswan users here, but I am looking for the best solution for users of the to-be-stable release, and freeswan is not good for that. Better a clear cut now. If there are no objections within 2 weeks from now, I will ask the ftp maintainers and release managers to remove freeswan from unstable and testing. I am still thinking about doing an "upgrade" package of freeswan though, which depends on openswan and simply moves the configuration of the old freeswan configuration to openswan. Any preferences towards such a package? with best regards, Rene pgpZkmyRXYDgx.pgp Description: PGP signature
Getting openswan 2.2.0 back into sarge
Hi all, [Please CC me in replies, I am currently not subscribed to this list.] As some have already noticed, openswan has been removed from testing a while ago, most probably because of bug #291274, which did not apply to package version 2.2.0-4 (the one that has been removed from testing). As 2.3.0 upstream is currently not production quality (this is my personal opinion, since it basically triggers a DoS on 2.2.0 installations, cf. #292132), I did not work on getting it into testing. Of course, I have to admit that I have been lazy in not filing a RC bug report to prevent it from entering testing and fixing this bug. However, it looked like 2.3.1 might get released soon at that time, so I had decided to wait for it and push it into testing as soon as the new upstream is there. At the moment, 2.3.1 is nowhere to be seen and I would really like to have a working (and not DoS-triggering) openswan in testing. My current intention would be to get 2.2.0-4 back into testing, which worked well in all of my own tests (I am still using that particular version on many production boxes) and does not seem to be broken for other users. What is the general opinion on that? with best regards, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
openswan 2.3.1 is now available - Call for Help
Hi all, [Please CC me in replies, I am currently not subscribed to this list.] Since yesterday, openswan upstream 2.3.1 is on the download servers, and it should supposedly fix the problems of 2.3.0 (specifically that it caused all other openswan daemons, be it 2.2.0 or 2.3.0, to crash in some cases) that prevented me from pushing that version into testing (and subsequently led to the removal of openswan from testing). I am currently working hard on updating the package to 2.3.1 (which unfortunately again changed the source tree layout, sigh) and will then go through the bug reports and check if 2.3.1 fixes them. Since we are very late in the sarge release process, I know well that it is an extremely bad time for updating to new upstream versions. Nonetheless, I really think that openswan (a working version) should be part of the new stable and am now trying to get this back into testing. I will probably need some help with this to do it in the next few days. Anybody who is using freeswan or openswan right now and is interested in having it in testing (and unstable, in fact), please help. I could definitely use help in testing, but anybody who wants to work on packaging itself is of course also welcome (e.g. on the minor bugs like debconf translations). If I am completely wrong in trying this now, at the current stage of the release cycle, then please tell me now and I'll use my weekend for something else and only work on getting this into unstable during next week with best regards, Rene pgpEWsPxC97z8.pgp Description: PGP signature
Re: openswan 2.3.1 is now available - Call for Help
Am Samstag, 9. April 2005 17:31 schrieb Paul TBBle Hampson: > I'm interested in testing the new version, although the problem I was > suffering was a windows interoperability bug (Win2K Ipsec would crash > pluto) which I reported to the Openswan list and was told it would > probably be fixed in 2.3.1. I've built from the debian/ directory in CVS > at the moment, but haven't tried it in a few weeks to see if CVS fixed > my problem. > > I also had two 2.3.0 openswans talking to each other for L2TP, but I > didn't see the crashing problem you've mentioned above (and which is to > do with NAT-T if the 2.3.1 changelog is anything to go by), both using > the 2.6 built-in IPSec stack for kernel support. If you can, then please test as much as you can. My current test packages are at http://www.gibraltar.at/~rene/openswan/ I have tried openswan-modules-source with both 2.4 and 2.6 kernel trees and it compiles fine now (many fixes during the last hours...), although I have not yet tried the modules that have been built. I still need to try kernel-patch-openswan and work further on that earlier crash problem. with best regards, Rene pgpp6HgVkay1f.pgp Description: PGP signature
Re: openswan 2.3.1 is now available - Call for Help
Am Samstag, 9. April 2005 22:32 schrieb Rene Mayrhofer: > If you can, then please test as much as you can. My current test packages > are at > http://www.gibraltar.at/~rene/openswan/ I have just uploaded new packages with a small change in kernel-patch-openswan (a file was missing). If anybody has already downloaded this package, please re-get it, with best regards, Rene pgphkJO4dhA4M.pgp Description: PGP signature
Re: openswan 2.3.1 is now available - Call for Help
Am Sonntag, 10. April 2005 06:59 schrieb Paul TBBle Hampson: > I just tried openswan-modules-source under 2.6.10 with make-kpkg, and it > installed > /lib/modules/2.6.10/kernel/net/ipsec/ipsec.o > instead of > /lib/modules/2.6.10/kernel/net/ipsec/ipsec.ko Thanks for the hint - I have fixed a type and uploaded a new openswan-modules-source package. Could you please try this one? > Also, 2.3.1 didn't fix my problem with Windows, so I'll build a local > unstripped version and see if I can get some useful answers from upstream. Any news on that? I am also bombarding upstream with error logs right now with best regards, Rene pgpIeyGTvyNk8.pgp Description: PGP signature
Re: openswan 2.3.1 is now available - Call for Help
Hi Yas, Am Sonntag, 10. April 2005 15:57 schrieb Yaacov Akiba Slama: > openswan 2.2.0-4 still crashes when using 2.3.1 (your package from > http://www.gibraltar.at/~rene/openswan/) as roadwarrior. Yes, I have also noticed that and can currently reproduce it here on my system. I have already bombarded upstream with detailed logs, core dumps etc. and am now waiting for response with best regards, Rene pgpXl8EnY89KZ.pgp Description: PGP signature
Re: packages missing from sarge
Am Dienstag, 10. Mai 2005 02:40 schrieb Anthony DeRobertis: > Seconded! The only RC-bug in openswan is for a newer version of the > kernel which will not ship with Sarge. Yes, that's true. I have to admit that I messed up in not marking this bug sid. My current best solution would be to put 2.2.0-4 back into testing (which got removed because of that RC bug that's for 2.3.0). What is the general opinion on this? with best regards, Rene pgpOPG0kUiSok.pgp Description: PGP signature
Re: packages missing from sarge
Steve Langasek schrieb: >>If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why >>not just get 2.3.x pushed into sarge? Are there any other big issues >>with it, that weren't in 2.2.x? Some people might certainly like the >>agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is >>fine for me though --- anything but 2.1.x for me :-) Mainly because 2.3.x causes other openswan boxes to crash in some (reproducable) cases - that's a pretty bad regression from 2.2.0 and I keep bugging upstream with it for at least 3 months. No fix until now, so we can't wait until it will be fixed. I would vote for 2.2.0-4. (or even 2.2.0-5). > Because 2.2.3 is no longer in the archive, and resurrecting new binaries via > t-p-u gives us even less than the usual protection against breakage caused > by a lack of testing. :/ Does that mean that the only way to get the known stable 2.2.0-x back into testing is an upload to unstable with an epoch? I really wouldn't like to go that route if I can avoid it with best regards, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#291274: openswan in sarge
Hi all, Does anybody want to test the current openswan 1:2.2.0-7 packages at http://www.gibraltar.at/~rene/openswan/ or should I upload to unstable? If nobody can give it a try, I intent to upload tomorrow morning (GMT+2). with best regards, Rene pgpfPMFhLmWTB.pgp Description: PGP signature
Re: ITP: pptpd
Chris Cheney wrote: > > I am appling to become a new maintainer. I am intending to package pptpd > which is the point to point tunneling protocol daemon. I already applied and have the pptpd package sitting on my machine. It is already tested on 2 corporate firewalls. I also have modified ppp and kernel packages so that the data encryption actually works. Is somebody interested in sponsoring these ? At the moment I have them ready for slink, but it takes about 2 minutes to make potato packages. greets Rene
Re: ITP: pptpd
> Is it okay to go into the primary distribution, or would it be forced > into nonus? If it's okay for ftp.debian.org, I can sponsor it for you. I am not sure about this. pptpd itself should be ok in main, but the modified ppp and kernel packages (these are needed for the data encryption) contain RC4, MD4, MD5 and SHA codes with a key length of up to 128 bit. Please excuse my total ignorance of the algorithms at this point. I only know from the source codes that these algorithms are used and that MPPE (Microsoft Point-to-Point Encryption) is used with up to 128 bit encryption. Another problem is that the Microsoft-crypto patches for pppd and the kernel ppp implementation contain code with this license: /* crypto/sha/sha.h */ /* Copyright (C) 1995-1997 Eric Young ([EMAIL PROTECTED]) * All rights reserved. * * This package is an SSL implementation written * by Eric Young ([EMAIL PROTECTED]). * The implementation was written so as to conform with Netscapes SSL. * * Added Microsoft's Get_Key() per mppe draft by mag <[EMAIL PROTECTED]> * * This library is free for commercial and non-commercial use as long as * the following conditions are aheared to. The following conditions * apply to all code found in this distribution, be it the RC4, RSA, * lhash, DES, etc., code; not just the SSL code. The SSL documentation * included with this distribution is covered by the same copyright terms * except that the holder is Tim Hudson ([EMAIL PROTECTED]). * * Copyright remains Eric Young's, and as such any Copyright notices in * the code are not to be removed. * If this package is used in a product, Eric Young should be given attribution * as the author of the parts of the library used. * This can be in the form of a textual message at program startup or * in documentation (online or textual) provided with the package. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: *"This product includes cryptographic software written by * Eric Young ([EMAIL PROTECTED])" *The word 'cryptographic' can be left out if the rouines from the library *being used are not cryptographic related :-). * 4. If you include any Windows specific code (or a derivative thereof) from *the apps directory (application code) you must include an acknowledgement: *"This product includes software written by Tim Hudson ([EMAIL PROTECTED])" * * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * The licence and distribution terms for any publically available version or * derivative of this code cannot be changed. i.e. this code cannot simply be * copied and put under another distribution licence * [including the GNU Public Licence.] */ I think it will have to go into non-free, but I am not sure about non-US. I am CC-ing this to debian-devel in th hope that somebody can answer if the codes have to go into non-US. thanks Rene
ITP: portsentry
portsentry is a daemon that listens for port scans (also stealth scans) and is able to disconnect and remember the attacking hosts in real-time. It uses ipchains for disconnecting and tcp wrappers for preventing hosts from further connections. Please look at http://www.psionic.com/abacus/portsentry/ for a closer description. A beta version of the package is already used at 2 production firewalls and 3 servers that I administer. Rene
ITP: logcheck
logcheck runs periodically and checks the system logs for unusual and alerting events. These are reported to the administrator by email. The logcheck package is suggested by portsentry. Please look at http://www.psionic.com/abacus/logcheck for more information. I have also a beta version of the logcheck package running at my servers. PS: I have a written statement from the author that distribution with Debian is permitted. Rene
Re: ITP: portsentry
Matthew Vernon wrote: > > Rene Mayrhofer writes: > > portsentry is a daemon that listens for port scans (also stealth scans) > > and is able to disconnect and remember the attacking hosts in real-time. > > It uses ipchains for disconnecting and tcp wrappers for preventing hosts > > from further connections. > > Please look at http://www.psionic.com/abacus/portsentry/ for a closer > > description. > > ISTR this being rather non-free... I think it has to go into non-free, but I have the permission of the author to distribute it with Debian (even that was not clear with the license). greets Rene
Re: ITP: logcheck
Thomas Schoepf wrote: > > On Wed, Sep 29, 1999 at 10:25:32AM +0200, Rene Mayrhofer wrote: > > > PS: I have a written statement from the author that distribution with > > Debian is permitted. > > Why do you need such a statement? Doesn't the original license permit > distributing modified versions? > I could be wrong, but AFAIR if Debian needs a special permission from the > upstream author(s), we don't consider to place the software into 'main'. Here goes the same as for portsentry. It was not clear with the license half an year ago (I did not check the license now), so I contacted the author. But it will have to go into non-free I fear. Maybe we should try to convince the author to release it under a Debian compatible license. greets Rene
Re: ITP: portsentry
Guido Guenther wrote: > > I've also packaged portsentry: > > http://honk.physik.uni-konstanz.de/~agx/debian/dists/stable/main/binary-i386/ > Sean Perry and me contacted the upstream maintainer and he is currently > reconsidering the > license. Maybe we can join efforts? We should definitely do so. IMHO portsentry should be one of the base packages (including logcheck) as it enhances the security of the system a lot. What was the last statement the author sent you ? I think I missed your ITP because I was temporarily offline. Do you plan to upload your package soon or should I try to find a sponsor for mine ? greets Rene
PGP/GPG Keys
Hi all Is it possible to use a key created by pgp5 for package signing ? The key works for me when I use it with gpg, both the opposite is not true (e.g. pgp5 is unable to verify a signature created with a gpg key). I am no maintainer yet and so I want to start cleanly. What is the "right" way if I want to use gpg and pgp5 and communicate with people using pgp5 ? Can I create a gpg key usable by pgp5 or is it possible to use the pgp5 key for administrative purposes ? I really want to revoke my rsa key and use only one key for all purposes. greets, Rene
Re: PGP/GPG Keys
Joseph Carter wrote: > > On Mon, Oct 04, 1999 at 07:45:23PM +0200, Rene Mayrhofer wrote: > > Is it possible to use a key created by pgp5 for package signing ? The > > key works for me when I use it with gpg, both the opposite is not true > > (e.g. pgp5 is unable to verify a signature created with a gpg key). I am > > no maintainer yet and so I want to start cleanly. What is the "right" > > way if I want to use gpg and pgp5 and communicate with people using pgp5 > > ? Can I create a gpg key usable by pgp5 or is it possible to use the > > pgp5 key for administrative purposes ? > > I really want to revoke my rsa key and use only one key for all > > purposes. > > By default gpg will use OpenPGP sigs. This is probably your problem. > Yes, you can import the pgp5 key into gpg and use it directly. There's > also some documentation on how to get gpg to generate pgp5 compatible > sigs in the manpage. So it is ok to use a pgp5 created key (gpg works with it) to sign packages ? I would like to use a pgp5 key because even if pgp5 can read gpg-key signatures, I think it is impossible to use a gpg key with pgp5. This is something I want to do because I have to work under Windows sometimes (therefore forced to use pgp5). greets, Rene
Re: linking binfmt_misc with mime-types
Brian May wrote: > When you loaded that image, whether you used apache, gimp, xv, or > something else, it would automatically know what file type it is without > any excessive overhead. In my opinion one of the best features of BeOS is that the file type is an extra attribute stored at file system level. I would really like to have something, and mime types seem to be the best way for it (I do not know how BeOS stores the type). greets, Rene
ITP: freeswan
I intent to package freeswan (currently version 1.5) and have already taken the freeswan 1.3 package from Tommi Virtanen and the freeswan 1.5 package from Aaron Johnson. I will merge those with my own package and hope to get something that can be uploaded into woody in the next 2 weeks. Since I live in Austria, uploading to non-US should be no problem and will be accepted by the freeswan project members (they do not accept any contribution from people living in the US). Please CC me in replies, I am currently not subsribed to debian-devel. best greets, Rene
Going to vacation, make NMUs if needed
Hi all I am going to vacation for the next 3 weeks, so if there is anything wrong with one of my packages (pptpd, logcheck, mkinitrd-cd) then please feel free to do NMUs. best greets, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITU: freeswan 1.8
Hi all Please reply directly to me as I am currently not subscribed to -devel. I have ITPed for freeswan quite a while ago and have made "semi-official" (people who were interested at that time knew of the download location) packages since then. Now I am happy enough with my version of the freeswan 1.8 package, which also creates a kernel-patch-freeswan package from the source and includes the x509 patches for using x509 certificates during key negotiation (important for interoperability with Win2000 and PGPNet). I would like to get it uploaded (if somebody would sponsor it please, my account has not been created until now) now because of 2 reasons: I would like to get more people testing it and I am getting more and more questions about the status of my package. If you don't want the package (which is now at ftp://ftp.vianova.at/pub/gibraltar/source/) in unstable, please tell me so now, because I would like to get it uploaded soon. best greets, Rene
Re: ITU: freeswan 1.8
Adam Heath wrote: > > On Mon, 8 Jan 2001, Rene Mayrhofer wrote: > > > [snip] > > Could you please run dpkg-scanpackages, and dpkg-scansources, so that we can > use apt to install this stuff? Txs. Done. It should not be apt-able with deb ftp://ftp.vianova.at/pub/gibraltar source/ deb-src ftp://ftp.vianova.at/pub/gibraltar source/ But please use with care. Our server is poorly connected, so please only use this if you desperately want to test freeswan before it is uploaded into unstable (should be in less than a week). best greet Rene
Re: The future of the boot system in Debian
[Please CC me in replies, I am currently not subscribed to -devel]. On Saturday 05 September 2009 01:21:00 pm Petter Reinholdtsen wrote: > The plan is to > change upstart to actually use /etc/inittab, to ease the switch > between sysvinit and upstart. Please don't. As you correctly pointed out, the current Debian init architecture is one of the most painful and outdated (not to say broken) parts in the whole system. It's really time to move away from old cruft (and I consider inittab to be cruft of little use at this time) and start using something that will not cause more pain in the future. There is definitely a need to support inittab during the transition period, but this can be done like the file-rc package has been doing for years: with conversion scripts to and from the old format, supporting those legacy features that make sense but not committed to care for every corner case. Leave those (probably multiple-100-lines perl/shell beasts) in place for a couple of years, declare inittab deprecated with squeeze (or squeeze+1), and remove afterwards. I would also _strongly_ suggest to do another iteration over all init scripts and mandate the implementation of a "status" command as well as parameters to "start" (or add a "start-nofork" command or something like that) to start the service with exec instead of fork. This would pave the way for using daemon/service supervision in the future (e.g. using upstart and deferring to standard init scripts to implement its native event.d files), and thus for more robust embedded systems support. Full ack for all other points in your mail, though. I have been using upstart on the current beta and upcoming release of Gibraltar firewall as well as all my Debian servers for the better part of 1 1/2 years and have not had any issues with it so far. best regards, Rene signature.asc Description: This is a digitally signed message part.
Re: Bits from the RM
Anthony Towns wrote: * #203339 - freeswan - Rene Mayrhofer FTBFS, patch in the bug log since July, no further activity I feel that I need to respond to that, after being mentioned here :) I fully admit that I have simply overlooked this one, because it is very easy to fix (and indeed has been fixed in my development tree, but didn't make it into the last upload). The reasons for not paying close attention to "the other" bugs for quite some time were mostly: - trying to get the whole kernel patch mess to work with the Debian kernels and still trying to retain compatibility with vanilla kernels - constantly fighting with the hack that's called NAT Traversal - a lot of "real life" issues since August, like moving into a new flat This is no real excuse and I should pay closer attention to _all_ RC bug reports, thanks for reminding me ;) PS: 2.01-4, which fixes at least some of the bugs, is stuck in the incoming queue since about 2003-11-20, nobody to blame for that of course. 2.04-1, which fixes all RC bugs and a few of the other ones, is currently in the works, but is having problems with the kernel-patch-freeswan package (because the changes from 2.01 to 2.04 upstream are larger than one would expect). If anybody wants to give it a try, please drop me a mail and I will send what I currently have. I could need some help in testing it with various kernel configurations PPS: I am not subscribed to debian-devel, so please CC me in replies. best regards, Rene
Problems with freeswan upload
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, [Please CC me in replies, I am currently not subscribed to debian-devel.] I have, most probably due to my own stupidity, problems uploading new packages of freeswan. Since 2002-08-05, there is a 1.98b-1 package sitting in queue/new on ftp-master (and a 1.96-2 package since 2002-04-26). However, I don't know why it does not get installed. The "problem" might be that 1.96-2 did the move from non-US to main (not changing much besides this) and I am currently not really sure if linking with libssl is OK for freeswan. It is mentioned in the CREDITS file, but maybe it is not solved properly. If somebody could shed light on this, I would be more than happy. With the current package, a new binary package named kernel-patch-freeswan-ext (which contains the kernel patch with additional crypto algorithms) is available in addition to kernel-patch-freeswan. This might also be a reason for the delay. Since I am getting more and more bug-reports about users requesting an updated package, I would like to get this resolved quickly. Therefore, I am happy about any hint on what I am doing wrong (RTFM with a pointer to the respective document is more than welcome :) ). best regards, Rene -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iEYEARECAAYFAj1Wx1YACgkQq7SPDcPCS97yLwCggJ5pIfd6dWDLI6NxnBGfQZ3g TREAnA79nmQrVvUkfRJQqSxmFYVJbsuW =Cd56 -END PGP SIGNATURE-
Excluding a binary package from Debian archives
Hi all Please CC me in replies, I am currently not subscribed to -devel. I am the maintainer of the mkinitrd-cd package and have made many improvements since the last release so, I would like to update it. But because of a restructuring of the package, the source package has been renamed from mkinitrd-cd to gibraltar-bootcd and generates the binary packages mkinitrd-cd and gibraltar-bootsupport. But only the package mkinitrd-cd is interesting for Debian users / developers, the gibraltar-bootsupport package is very Gibraltar specific and has no use elsewhere. What should I do when I upload the package so that the old source package gets removed from the archive and the gibraltar-bootsupport package gets excluded from the upload and from the automatic build on Debian machines. The packages are created from the same source package because they share a lot of common code, so I do not want to create different source packages. best regards, Rene
Re: Excluding a binary package from Debian archives
Wouter Verhelst wrote: > Is Debian really that unpopular on Gibraltar? > Why not simply include them, so that Debian users in Gibraltar can use it? Gibraltar is Debian-based, a firewall distribution bootable from CD-ROM. But installing the gibraltar-bootsupport package on a Debian system that is installed on a harddisk partition (and not especially prepared for this) will break things. Therefore the package should not be installable by Debian users, it will break their system. > If you really think it serves no purpose at all, then comment the build > for the gibraltar-specific package out in your debian/rules file. It serves a purpose, but only for Gibraltar installations. So the package is needed, it simply should not be included in the Debian archive, but should only be downloadable from a separate apt source. best regards, Rene
prism2 driver package anyone ?
Hi Bastiaan, [To readers of debian-devel: please CC me and possibly [EMAIL PROTECTED] in replies so that we can follow discussions. I am currently not subscribed to debian-devel.] Bastiaan Niels Veelo wrote: > I have hopes that my Gibraltar box can act as a wireless LAN Access > Point. I bought a cheap PCI card (D-Link DWL-500) which is based on the > Prism2 chipset. Jouni Malinen has written a driver that supports a so > called Host AP mode of these chipsets, turning the host computer into an > access point, without the need for special firmware. Would you please > consider inclusion of his driver for the next release of Gibraltar? > > You can find everything you need here: > http://people.ssh.com/jkm/Prism2/ > > I have compiled the driver on my laptop and it seems to work fine (did > not actually test networking though, that would require swapping PC > intestins). If I understand the web page correctly, it is mainly a user-space software and a stand-alone kernel module that can be compiled when the kernel source is available, but does not need a patched kernel tree. Therefore it would be very easy if there was a Debian package for the user-space software and a package containing the module source code (ready for being automatically compiled with make-kpkg). I am CCing this to the debian-devel mailing list in the hope that somebody is interested in creating a package of this software (if there is one already and I have missed it, then please flame away... :-) ). If nobody wants to maintain such a package, then I will create on for my use, which will probably not find its way into Debian unstable because of lack of time on my side. But I would be more than willing to assist in the initial packaging when somebody would maintain it afterwards. best regards, Rene
Re: intent to package PortSentry
Am Sun, 16 May 1999 schrieb Samu: > i'd like to make the debian packages of portSentry by www.psionic.com > is there another one working on it ? I did it already and I am working on logcheck now. However, I am not a registered debian developer at the moment (I'm planning to register). If you have access to the CVS, I could send you the source packages. Rene (Student of Computer Science at the Johannes Kepler University of Linz, Austria) -- ------ Rene Mayrhofer, ViaNova KEG NIC-HDL: RM1677-RIPE Email: [EMAIL PROTECTED] Snail: Penz 217, A-4441 Behamberg PGP(DSS): E661 2E45 9B7F B239 D422 0A90 A4C2 DA09 F72F 6EC5 PGP(D/H): B77F 51A8 B046 87A6 4D61 2C5D 742F F433 6732 E4DC GPG: D356 69B6 6A08 E033 257B 1872 6AEA 88FB C805 63BD --
Abacus Portsentry License
Hi As I am new to creating Debian packages, I am not sure if Abacus Portsentry's license allows it to be put in the main (or if it has to go into non-free) section. The program is free to use by anybody and can be distributed in any form, the only problem is that the author prohibits modifications he is not aware of. Please could somebody check it (at www.psionic.com) ? I have a written statement by the Author that he allows packages (including the needed minor modifications on scripts and Makefiles) to be made and that Portsentry can be included in a distribution if the distribution is not sold because of Portsentry. Thanks in advance Rene -- -- Rene Mayrhofer, ViaNova KEG NIC-HDL: RM1677-RIPE Email: [EMAIL PROTECTED] Snail: Penz 217, A-4441 Behamberg PGP(DSS): E661 2E45 9B7F B239 D422 0A90 A4C2 DA09 F72F 6EC5 PGP(D/H): B77F 51A8 B046 87A6 4D61 2C5D 742F F433 6732 E4DC GPG: D356 69B6 6A08 E033 257B 1872 6AEA 88FB C805 63BD --
Re: better /etc/init.d/network
Am Sun, 16 May 1999 schrieb Massimo Dal Zotto: > Hi, > > The /etc/init.d/network script created by the debian installation is very > simple and not flexible enough if you need to manage complex networks with > many interfaces. > > I have written a generic network interface management command, net, which > can be used to start/stop/show/configure network interfaces, and a smarter > replacement for the /etc/init.d/network script. I will try it out and maybe use it for a firewall with more than 10 network cards. This could be a good test for the new script. Rene -- -- Rene Mayrhofer, ViaNova KEG NIC-HDL: RM1677-RIPE Email: [EMAIL PROTECTED] Snail: Penz 217, A-4441 Behamberg PGP(DSS): E661 2E45 9B7F B239 D422 0A90 A4C2 DA09 F72F 6EC5 PGP(D/H): B77F 51A8 B046 87A6 4D61 2C5D 742F F433 6732 E4DC GPG: D356 69B6 6A08 E033 257B 1872 6AEA 88FB C805 63BD --
