Bug#328888: ITP: llconf -- utility and library for loss less configuration file parsing
Package: wnpp Severity: wishlist Owner: Oliver Kurth <[EMAIL PROTECTED]> * Package name: llconf Version : 0.4.0 Upstream Author : Oliver Kurth <[EMAIL PROTECTED]> * URL : http://people.debian.org/~oku/llconf/ * License : GPL Description : utility and library for loss less configuration file parsing llconf is a utility and a C library for lossless configuration file parsing and unparsing. It is useful to read and modify different configuration files with different formats, using a modular approach, and can also be used for any application to read its configuration. It includes parsers for shell, table (for example /etc/passwd, /etc/fstab), ifupdown, pair, ini, syslog-ng, iptables, mgetty, snmpd, ipsec, ppp and others. More parsers can be easily added. The files are parsed into trees, and functions allow access and modification of the trees. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_movefiles, tar vs. mv
On Fri, 2005-02-25 at 20:25 +0100, GOMBAS Gabor wrote: > On Fri, Feb 25, 2005 at 07:54:27PM +0100, Frank Küster wrote: > > > Correct. So, why not use mv? > > Add a new "--move" flag to dh_installfiles, come up with some exact > numbers showing the build time/disk usage savings for your favorite Big > Package (hard numbers usually very helpful for promoting new features), > and send the numbers together with the patch to the debhelper maintainer. > > Someone already mentioned that a complex package might want to install > the same file to multiple different locations, so making this the > default is probably not feasible. How about hard linking with ln instead? You would have the best of both approaches: it is fast, and still possible to have the same file in multiple packages. Greetings, Oliver signature.asc Description: This is a digitally signed message part
Re: [Ipw2100-devel] debian, ipw2200 and wlan0
On Mon, 2005-02-07 at 21:36 +0100, Christoph Hellwig wrote: > On Mon, Feb 07, 2005 at 04:50:27PM +0100, Mike Hommey wrote: > > Debian is a distribution which tries to provide good software, implying > > changes if necessary. Wireless interfaces should be called wlan%d, not > > eth%d, and upstream doesn't want to change because "There are fewer > > compatability issues with existing distributions by defaulting to eth%d > > vs. wlan%d." [1] > > And all upstream drivers do use eth%d. Wrong. - the orinoco drivers use eth - the hostap drivers use wlan - madwifi uses ath - at76c503 uses wlan ... It seems that every driver uses its own scheme. It's a mess. Fortunately, some drivers give you an option to change it. > > I'll encourage Debian kernel maintainers to make the adequate changes. > > No, it's a totally arbitrary and pointless change. It isn't pointless, but it is certainly better to convince upstream and have a quasi standard. And I propose to use wlan%d for all WLAN devices, because it simplifies a lot. See my other mail for reasons. Greetings, Oliver signature.asc Description: This is a digitally signed message part
Re: [Ipw2100-devel] debian, ipw2200 and wlan0
On Mon, 2005-02-07 at 18:45 +, Matthew Garrett wrote: > Oliver Kurth <[EMAIL PROTECTED]> wrote: > > > Naming wired network eth%d and wireless wlan%d would make things a lot > > easier. For example, it is easier to find out whether to start ifplugd > > or waproamd when the interface is created. > > There's other (more resiliant) ways of doing that. In 2.6, wireless > cards will have a directory called wireless under sys/class/net/foo. I still use 2.4 as long as sound support for my cs46xx card is broken in 2.6. Also, I will still use 2.4 on embedded devices (yes, they use pcmcia cards). > > I dislike naming wireless interfaces eth%d, because I often plug in a > > wired network card into my notebook at work, and a wireless card at > > home. They would both get eth1, but I may want different > > configurations.=20 > > But really, that's a problem that should be solved in a more generic > fashion. If I plug in two different wired cards, I'm probably doing so > because they've been left in two different places, and so want two > different configurations. But they'll both end up as eth2 anyway. I use guessnet to find out where I am. But I will always start waproamd for wlan, and ifplugd for wired network. > It makes more sense to either bind configuration to specific cards > (using the mac address, for instance), or different classes of card. I know that there are other ways. But it makes things more complicated. Complicated things break more easily. Why not leave it simple, and just use an easy name scheme? Greetings, Oliver signature.asc Description: This is a digitally signed message part
Re: [Ipw2100-devel] debian, ipw2200 and wlan0
On Mon, 2005-02-07 at 18:17 +0200, Lars Wirzenius wrote: > ma, 2005-02-07 kello 16:50 +0100, Mike Hommey kirjoitti: > > Wireless interfaces should be called wlan%d, not eth%d > > Why is this important? Why does the name of a network interface matter? > All the tools in Debian that can deal with network interfaces are > neutral about the name and the name isn't particularly significant to > users either. If one is worried about which interface name corresponds > to which physical device, guessing from the name is not a good way. > Using ifconfig or iwconfig or other tools to do it is a better way. > > (I'm not saying that using wlan%d is bad or wrong, I am asking for > justifications for that name over eth%d.) Naming wired network eth%d and wireless wlan%d would make things a lot easier. For example, it is easier to find out whether to start ifplugd or waproamd when the interface is created. I dislike naming wireless interfaces eth%d, because I often plug in a wired network card into my notebook at work, and a wireless card at home. They would both get eth1, but I may want different configurations. Also, 'private' names like ath%d are annyoing, because in the waproamd package I have to care for all of these. And it does not make sense, all wired ethernet devces get eth%d, so why do the wireless devices get names depending on the driver? It is possible to work around these issues, but using eth%d for wired and wlan%d for wireless makes life a lot easier. Greetings, Oliver signature.asc Description: This is a digitally signed message part
Re: How to avoid multiple dependencies with shlibdeps
On Tue, Dec 09, 2003 at 07:44:48PM +0100, Adam Byrtek / alpha wrote:
> Hi,
>
> I maintain a program which needs to depend on certain version of some
> library (the earlier ones are incompatibile, despite soname wasn't
> changed), but I would also like to use shlib:Depends for other
> libraries.
>
> Now I use:
>
> Depends: libtlen1 (>= 20021117), ${shlibs:Depends}
>
> But it generates duplicate dependency upon libtlen1, causing:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=171847
>
> Is it possible to fix this in a simple way, or should I write my
> dependencies manually, not using dh_shlibdeps?
You can use debian/shlibs. You will find documentation about this
in the man page for dpkg-shlibdeps.
> If you answer, PLEASE CC to me, as I don't read debian-devel
> regularly.
Greetings,
Oliver
--
.''`.
: :' :Oliver Kurth [EMAIL PROTECTED]
`. `' Debian GNU/Linux maintainer - www.debian.org
`-
today in my TODO list: prove the Goldbach conjecture
signature.asc
Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 01:25:24PM -0800, Don Armstrong wrote: > On Wed, 19 Nov 2003, Oliver Kurth wrote: > > Sigh. So if Atmel says these files are no longer GPL'ed, but are just > > freely distributable, it could at least go to non-free? > > Yes. > > > Sounds ridiculous. (Law is too complicated to me, so I stick to > > programming ;-) ) > > Thats part and parcel of the GPL... if the company doesn't include the > prefered form for modification, no one else can distribute it. > > > Is there any way to get this into main, maybe regarding the fact that > > this code is not run on the host but just on the device? I think > > Atmel would be open to change the license, but I do not think they > > will give the source to their holy (and btw buggy) firmware. > > Ugh. That's always annoying. Perhaps just a non-free package > containing the firmware? (assuming we get permision to freely > distribute it.) Is the firmware even necessary for the driver to work? The firmware is needed. Without it, the device is completely dumb. But there are some devices which can store the fw permanently. Also, the fw is distributed on their (windows) installation CDs. > One wonders why they don't just open up the source to the firmware > drivers since they aren't planning on making any more updates to it. I am not sure about this. I think this is true only for the devices with Intersil radio. But anyway, it is annoying. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 10:41:58PM +0100, Guido Guenther wrote: > On Wed, Nov 19, 2003 at 08:36:31PM +0100, Oliver Kurth wrote: > > I am sure these lines in the files can be removed, by bugging the > > Atmel people, or at least 'override' it with an 'It is okay' message > > from them. > O.k., we can upload to non-free then. Unfortunately, in this thread it turned out we can't. Unless we convince Atmel to not license the files under the GPL, but just as freely distributable. > > But you do not seem to see my point: the human readable sources of the > > firmware files are _not_ open. The hex files, ie. the compiled form, > > in ACSII format they say _are_ GPL'ed (despite the disclaimer in those > > files, see above). > I fully see your point. Without the source code to the firmware we can't > upload into main IMHO. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 08:25:44PM +, Henning Makholm wrote: > Scripsit Oliver Kurth <[EMAIL PROTECTED]> > > > > If the hex files are GPLed, they are probably not distributable -- hex .c > > > files probably do not fall into the GPL's definition of source > > > code > > > Maybe there can be an exception because the code is not run on the host > > but on the device? > > Who do you imagine making such an exception? The only one who can make > an exception from the GPL's conditions is the copyright holder. And he > can make whatever exceptions he likes, irrespective of where the code > runs. See, the copyright holder has no problem if those files are distributed. They will not care. I can also reconfirm this by asking them. So the problem is if this can still comply with the DFSG. So the exception should be made by Debian. If this is not possible, maybe one workaround could be to make the paxkage without the firmmware files, and put them elsewhere on the web. So like libdvdread does it. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 08:00:48PM +, Henning Makholm wrote: > Scripsit Oliver Kurth <[EMAIL PROTECTED]> > > > But you do not seem to see my point: the human readable sources of the > > firmware files are _not_ open. The hex files, ie. the compiled form, > > in ACSII format they say _are_ GPL'ed (despite the disclaimer in those > > files, see above). > > What you're missing is that if one applies the GPL is applied to > compiled code alone, it does not give any permission to distribute > at all. GPL allows compiled code to be distributed only if it is > accompanied with source, which these firmware files are not according > to the GPL's own definition. So in this context GPL is equivalent to > "no permission to distribute". > > That may not be a problem for the original author (who, owning the > copyright, can permit himself to distribute no matter what the license > he offers to others say), but it is certainly a problem for Debian. > > Sourceless GPLed code cannot be distributed even in non-free. Sigh. So if Atmel says these files are no longer GPL'ed, but are just freely distributable, it could at least go to non-free? Sounds ridiculous. (Law is too complicated to me, so I stick to programming ;-) ) Is there any way to get this into main, maybe regarding the fact that this code is not run on the host but just on the device? I think Atmel would be open to change the license, but I do not think they will give the source to their holy (and btw buggy) firmware. Also CC'ing deebian-legal. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 08:41:32PM +0100, Steinar H. Gunderson wrote:
> On Wed, Nov 19, 2003 at 07:52:22PM +0100, Oliver Kurth wrote:
> > There may also be issues with the firmware: the source is /not/ GPL'ed, but
> > the hex files from Atmel are. I am not sure if this is possible, and if it
> > is a problem for Debian to get it into main.
>
> IANAL, but...
>
> If the hex files are GPLed, they are probably not distributable -- hex .c
> files probably do not fall into the GPL's definition of source code ("the
> preferred form of making alterations"); without the driver source we do not
> have the source code and such can't distribute it without violating GPL.
> Check with debian-legal, perhaps?
Maybe there can be an exception because the code is not run on the host
but on the device?
CC'ing debian-legal.
Greetings,
Oliver
--
.''`.
: :' :Oliver Kurth [EMAIL PROTECTED]
`. `' Debian GNU/Linux maintainer - www.debian.org
`-
When sending passwords, please use my gpg key. That's what it's good for.
signature.asc
Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 08:26:56PM +0100, Guido Guenther wrote: > On Wed, Nov 19, 2003 at 08:01:40PM +0100, Oliver Kurth wrote: > > Okay, but you placed an email into the URL field. > Cut'n'Paste erro. It's correct in the package. Fine. > > This is okay. Atmel allows to distribute those files, I have got a message > > from one of their developers, it should also be on the mailing list of the > > sf driver. I will try to find it again. > I think this won't be sufficient. We also must be allowed to modify it > to put the package into main. The current license violates at least > clause 2 and 3 of the DFSG so there's no chance to put it into main. We > might be able to put it into non-free if we're at least allowed to > redistribute the files. I am sure these lines in the files can be removed, by bugging the Atmel people, or at least 'override' it with an 'It is okay' message from them. But you do not seem to see my point: the human readable sources of the firmware files are _not_ open. The hex files, ie. the compiled form, in ACSII format they say _are_ GPL'ed (despite the disclaimer in those files, see above). Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 08:06:32PM +0100, Guido Guenther wrote: > Hi Oliver, > On Wed, Nov 19, 2003 at 07:43:30PM +0100, Oliver Kurth wrote: > > That is my email addrss in the URL field... not the site to > > download. It is really > > http://at76c503a.berlios.de/ > > My name is correct for upstream, but you should also add Joerg Albert. > Sure. It is (and always was) correct in the package (including Joergs > Name). I just tried to keep things short in the ITP. Okay, but you placed an email into the URL field. > > I already filed an ITP for it, but I did not yet package it, for lack of > > time. > > It would be nice if I can work as co-maintainer for this package. > You're very welcome! Thanks :-) > > There may also be issues with the firmware: the source is /not/ GPL'ed, but > > the > > hex files from Atmel are. I am not sure if this is possible, and if it is a > > problem > > for Debian to get it into main. > This looks bad: > > /* license agreement. Any un-authorized use, duplication, > * transmission, distribution, or disclosure of this software is expressly > * forbidden. > > Do you have an agreement with Atmel to distribute the firmware? With > this license the package can't even go into non-free. This is okay. Atmel allows to distribute those files, I have got a message from one of their developers, it should also be on the mailing list of the sf driver. I will try to find it again. The problem is just that they do not give the source for these files, and this may be a problem for Debian. Not for Atmel. Cc to debian-devel. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 07:04:45PM +0100, Guido Guenther wrote: > Package: wnpp > Severity: wishlist > > * Package name: at76c503a-source > Version : 0.11.beta5 > * URL : Oliver Kurth > * License : GPL > Description : at76c503a driver source That is my email addrss in the URL field... not the site to download. It is really http://at76c503a.berlios.de/ My name is correct for upstream, but you should also add Joerg Albert. > . > Alternative driver for the Atmel AT76C503A based USB WLAN adapters. This > driver > is for linux kernel versions 2.4.X. > . > Currently, the driver has some limitations: > * no promiscous, monitor or station mode and no support for libpcap, i.e. > it does not work with Kismet or Airsnort and it cannot act as an WLAN > access point. This is a restriction imposed by the current firmware. > * The firmware for Intersil radios is old (Atmel doesn't update it > anymore) > and has more restrictions. > > -- System Information: > Debian Release: testing/unstable > Architecture: powerpc > Kernel: Linux bogon 2.4.23-pre5-ben0-bogon #1 Mon Nov 17 15:45:41 CET 2003 ppc > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 I already filed an ITP for it, but I did not yet package it, for lack of time. It would be nice if I can work as co-maintainer for this package. There may also be issues with the firmware: the source is /not/ GPL'ed, but the hex files from Atmel are. I am not sure if this is possible, and if it is a problem for Debian to get it into main. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Question about shlibs.local, bug in dpkg-cross?
Hi, I have a short question about the debian/shlibs.local syntax. I understand that the first field gives the lobrary name, the second the so version and the third the package to depend on. In the sources of apt the third field is omitted for some entries (the shlibs.local* files are created dynamically, so you see them after a build only). So question: what does it mean if the third field is omitted? I guess 'no dependency', which makes sense, because the libs are part of the package itself. Is this correct? Okay, if so, I can report a bug to dpkg-cross, which does not do parse it like that correctly. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
3 packages for adoption
Hi there, I would like to give three of my packages for adoption: dumpasn1 This is a useful program if you work with files using the ASN.1 syntax, eg. X.509 cerificates. I needed this in my previous job, but not any more. Upstream is responsive, no bugs. tcpreen This is a sort of proxy. It listen on some configrable port, and forwards net traffic to another arbitrary server and, and prints all the information goinf back and forth. I thought it was useful, when I packaged it, but in reality I use ethereal. I will orphan this in two week, if noone else wants it. One wishlist bug, for a new version. Upstream is very responsive. memtester This is (very) useful if you want to test your RAM, but want the box to keep running, eg. if it's an important server and you are not sure if it does strange things because of RAM failures or other reasons. I will keep this if noone wants it, because I sometimes use it. Two bugs, one of them specific to large memory systems, the other contains a patch. Shame on me... For more nformation start at my QA page: http://qa.debian.org/developer.php?gpg_key=451EAB1B Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 06:04:45PM -0500, Steve Langasek wrote: > On Tue, Oct 07, 2003 at 12:30:45AM +0200, Oliver Kurth wrote: > > On Mon, Oct 06, 2003 at 10:08:57PM +0200, martin f krafft wrote: > > > also sprach Mark Brown <[EMAIL PROTECTED]> [2003.09.22.1109 +0200]: > > > > Well, what you seem to want is to have the kernel source avaliable > > > > in a format that makes packaging kernel patches easy. That seems > > > > like a different issue to me. > > > > No, this is the issue. I want the kernel sources to be what they > > > promise, and not what Herbert wants them to be. I can opt-in on have > > > the bells and whistles Herbert thinks should belong in every > > > kernel-image, but if I don't make that choice, I want to have the > > > kernel-source with just the security fixes. After all, Debian is > > > known for two things: purity and security. I don't see the first one > > > applying to kernel-source, and given that IPsec is in beta state, > > > I don't see the second either. > > > I agree with Martin. If patches in the base package make additional > > kernel patch packages impossible, they should not be applied. Users > > should have the choice which patches they want to apply. > > As stated above, this is not a reasonable restriction. An arbitrary > kernel patch package might conflict with *any* changes made to the > kernel-source package, including simple security fixes. The Security fixes are another matter. If it conflicts with a patch, so be it, but in that case the maintainer of that patch is responsible to change the patch accordingly - which should not be difficult. > kernel-source maintainer must have some flexibility to maintain his > packages in the manner he believes best meets their primary purpose, > which AIUI is to provide a suitable base from which to build > kernel-image packages to be distributed in Debian. How can a vanilla kernel prevent the packager to build (any) kernel images? Or how does a kernel, built with any patches, hinder from building kernel-images? > The burden is on the kernel patch maintainer to provide something which > works with the packages it depends on. If this is achieved by > *persuading* the kernel source maintainer to revert a given patch, so > much the better; but there's one kernel source maintainer and n kernel > patch maintainers -- it's clear which end rightly bears the > responsibility of making those n packages work. So it's the kernel source maintainer, because that's only one person? Sorry, I have the feeling that I missed something. Greetings, Oliver, going to sleep now. -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 10:08:57PM +0200, martin f krafft wrote: > also sprach Mark Brown <[EMAIL PROTECTED]> [2003.09.22.1109 +0200]: > > Well, what you seem to want is to have the kernel source avaliable > > in a format that makes packaging kernel patches easy. That seems > > like a different issue to me. > > No, this is the issue. I want the kernel sources to be what they > promise, and not what Herbert wants them to be. I can opt-in on have > the bells and whistles Herbert thinks should belong in every > kernel-image, but if I don't make that choice, I want to have the > kernel-source with just the security fixes. After all, Debian is > known for two things: purity and security. I don't see the first one > applying to kernel-source, and given that IPsec is in beta state, > I don't see the second either. I agree with Martin. If patches in the base package make additional kernel patch packages impossible, they should not be applied. Users should have the choice which patches they want to apply. So the proper way IMHO is to provide a vanilla kernel-source package and an IPSec backport package. > Moreover: 2.4 users have the choice to run IPsec: FreeS/WAN works > just fine, and it happily coexists with grsecurity. It's also just > another IPsec stack. Weird, huh? Maybe the 2.5 IPsec stack does > patch more than add an IPsec stack? Herbert? BTW, I do not use the kernel-source package, I always build my own kernel using make-kpkg - with cryptoloop patch. But that's not the point. If I find that that patch conflicts with the Debian kernel source, I would get very irritated. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: autoconf and setting prefix
On Tue, Sep 09, 2003 at 10:45:15AM +0900, Miles Bader wrote: > James Michael Greenhalgh <[EMAIL PROTECTED]> writes: > > > (cd build && $(MAKE) install prefix=$(CURDIR)/debian/gcc4arm/usr) > > > > Dunno about 'prefix=' ... I've always used 'DESTDIR='? > > Specifying prefix on the make command line should work and not try to > install to /usr (though he appears to be using it incorrectly so > probably won't get what he wants). Using prefix is dangerous, because it may be compiled into the code or scripts. It may work with most packages, but not all. prefix is meant to be the final destination. > DESTDIR is convenient, but not supported by as many packages (gcc does > support it though). If DESTDIR is not supported, we should make it to support it, and send the fix to upstream. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. pgpsKmrm2JVU2.pgp Description: PGP signature
Bug#208566: ITP: x25-utils -- utilities to configure X.25 networks
Package: wnpp Version: unavailable; reported 2003-09-03 Severity: wishlist * Package name: x25-utils Version : 2.3.93 Upstream Author : Jonathan Simon Naylor * URL : http://www.baty.hanse.de/linux-x25/utils/ * License : unknown (have to clear that up, probably BSD) Description : utilities to configure X.25 networks These utilities include the utilities x25route, x25trace and a telnet client and a daemon for testing and as examples. If anyone knows of a newer version, please let me know. Greetings, Oliver -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux debian 2.4.21 #3 Thu Jun 26 14:08:29 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Bug#208560: ITP: pc300 -- utilities for configuring the Cyclades PC300 synchronous PCI adapters
Package: wnpp Version: unavailable; reported 2003-09-03 Severity: wishlist * Package name: pc300 Version : 4.0.0 Upstream Author : Cyclades Coperation * URL : ftp://ftp.cyclades.com/pub/cyclades/pc300/linux/ * License : GPL Description : utilities for configuring the Cyclades PC300 synchronous PCI adapters The package includes utilities and a kernel module for the Cyclades PC300 synchronous PCI adapters. The package will be split into a two parts, one for the utilities and the other for the module source. It requires kernel 2.4.21 or higher. Greetings, Oliver -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux debian 2.4.21 #3 Thu Jun 26 14:08:29 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: Zeroconf Debian?
On Fri, Aug 08, 2003 at 01:28:15PM +1000, Andrew Pollock wrote: > I'm currently at the SAGE-AU annual conference, and Apple presented a > paper about their Rendezvous technology, which is their implementation of > Zeroconf[1]. > > Is anyone working on getting Debian to do any of this sort of stuff? If > not, I might look into spinning off a subproject. I don't think it would > be significantly difficult to get parts of this working relatively > quickly. Minor changes to ifupdown would allow for allocating an IP > address without a HCP server, for example. > > [1] http://www.zeroconf.org Almost certainly you can make use of ifplugd for this: Description: A configuration daemon for ethernet devices ifplugd is a daemon which will automatically configure your ethernet device when a cable is plugged in and automatically unconfigure it if the cable is pulled. This is useful on laptops with onboard network adapters, since it will only configure the interface when a cable is really connected. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. pgp0QNp0t2XlQ.pgp Description: PGP signature
Re: Packaging some Redhat admin tools
On Thu, Aug 07, 2003 at 11:04:45AM +0200, C?dric Delfosse wrote: > Hello > > at work, I have played a little bit with a Redhat 9. There are lots of > nice system setup tools that could be useful for Debian users. These > tools are GPL. > The problems are: > - no source tar.gz / tar.bz2 distribution (AFAIK), > - no Redhat anonymous CVS access (AFAIK), > - only SRPM distribution. > > So, I wonder if someone has already built a package from a SRPM package > ? srpms include a .tar.gz. I think you should be able to extract that using rpm. There is rpm in Debian. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. pgpRfMIoVk7a0.pgp Description: PGP signature
Re: About NM and Next Release
On Wed, Aug 06, 2003 at 08:01:35PM +0200, Francesco Paolo Lovergine wrote: > On Wed, Aug 06, 2003 at 05:10:24PM +0200, Eduard Bloch wrote: > > Interessting analysis. Many things that hold up the release can only be > > solved by active and experienced maintainers since the packages are often > > essential. New developers can help maintaining them in cooperation with > > main developer and get the experience after some time and reading of the > > policy, developers reference, lib packaging guide, etc, but having a > > sponsor between them and the upload queue is still better. > > > > Someone should point NMs to difficulty of entering the development > mainstream of FreeBSD or becoming maintainer for the kernel... > IMO it's generally too easy entering in Debian. So letting NMs wait for months without notice makes it better? Please explain this to me. Greetings, Oliver -- An MTA for home users, notebooks and PDAs: http://masqmail.cx/masqmail/ A driver for Atmel at76c503 based WLAN Adapters: http://masqmail.cx/at76c503/ pgp72Cgv3RTWQ.pgp Description: PGP signature
Re: Should MUA only Recommend mail-transfer-agent?
On Wed, Aug 06, 2003 at 10:27:38AM -0700, Steve Lamb wrote: > On Wed, 06 Aug 2003 18:50:21 +0200 > Tollef Fog Heen <[EMAIL PROTECTED]> wrote: > > * Steve Lamb > > | How many local users are you going to have on a laptop whose correct > > SMTP| server changes as a function of their location? > > > Usually: one, I guess. > > So 1 person, 1 location to change. > > > | Oddly enough I only have one program for that now. Sylpheed-Claws. > > | Fortunately it can do something that most SMTP servers can't without some > > | rather painful configuration: send mail through different SMTP servers > > based| on the account from which the mail was sent. > > > Why do you want to do that? > > Imagine being at work, polling mail from home and then wanting to send > mail back out. If the computer, say the laptop, is configured to forward to > work mail now you're using the company server to send out personal mail. Even > forgiving the whole idea of "Ya'll shouldn't do that on the clock" because > people do have lunch breaks and so on some companies archive all mail that > travels through their servers. Do you want your private mail ending up in the > company archives for several years? I don't. > > Conversely while at home and answering work mail, presumably on the same > machine, you'd want the mail to hit the corporate SMTP server first. Why? > Because of the archives above. If you're communicating with an off-site > contact and skip the corporate server their archives are incomplete. > > With this dual system you'd want mail from account A to go to SMTP server > A, mail from account B to go to SMTP server B regardless of location. masqmail is an MTA especially designed for notebooks. It can send mail with the conf depending on your location and account. It's relatively small and it's debconfed. Greetings, Oliver -- An MTA for home users, notebooks and PDAs: http://masqmail.cx/masqmail/ pgp3MHngRjhIW.pgp Description: PGP signature
Re: debconf 2005 in Vienna, Austria
On Thu, Jul 31, 2003 at 10:44:26AM +0200, Sven Luther wrote: > On Thu, Jul 31, 2003 at 10:22:34AM +0200, Oliver Kurth wrote: > > On Thu, Jul 31, 2003 at 09:48:01AM +0200, Sven Luther wrote: > > > On Thu, Jul 31, 2003 at 02:29:06AM +0200, Bernd Eckenfels wrote: > > > > On Thu, Jul 31, 2003 at 02:12:08AM +0200, Amaya wrote: > > > > > Martin List-Petersen dijo: > > > > > > Something like that sounds sane. It gives even the possibility > > > > > > organising a "shuttle"-bus or something likewise from LinuxTag to > > > > > > Vienna > > > > > > > > > > That sound so appealing that I would even consider also attendig > > > > > LinuxTag :-) > > > > > > > > Keep in mind, this is 730km and will take up to 8-12h > > > > > > Nothing compared to the 1800 km from Karlsruhe to Oslo, And if there is > > > a bus, you could sleep or just rest, not needing to drive or something > > > such. > > > > There is also a direct night train, takes 9:30 hours. Just look at > > http://www.bahn.de. > > But trains would be much more expensive, i think, than a common (full) > bus. Probably yes. Of course it depends on your preference, and what you can afford. Traveling by train is much more relaxing, especially if you have a bed there. Sort of, at least. It was just a suggestion. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- pgpwQkV11Enkr.pgp Description: PGP signature
Re: debconf 2005 in Vienna, Austria
On Thu, Jul 31, 2003 at 09:48:01AM +0200, Sven Luther wrote: > On Thu, Jul 31, 2003 at 02:29:06AM +0200, Bernd Eckenfels wrote: > > On Thu, Jul 31, 2003 at 02:12:08AM +0200, Amaya wrote: > > > Martin List-Petersen dijo: > > > > Something like that sounds sane. It gives even the possibility > > > > organising a "shuttle"-bus or something likewise from LinuxTag to > > > > Vienna > > > > > > That sound so appealing that I would even consider also attendig > > > LinuxTag :-) > > > > Keep in mind, this is 730km and will take up to 8-12h > > Nothing compared to the 1800 km from Karlsruhe to Oslo, And if there is > a bus, you could sleep or just rest, not needing to drive or something > such. There is also a direct night train, takes 9:30 hours. Just look at http://www.bahn.de. > > Wien is not exactly close to western europe. > > But not all that far also. Pretty close, I'd say, writing from near Munich... Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- pgpQVwAmo7ayb.pgp Description: PGP signature
Re: Bug#200793: ITP: libdaemon -- leightweight C library for daemons
On Fri, Jul 11, 2003 at 08:55:49AM +0100, Stephen Quinney wrote: > I suspect 'leightweight' is not the spelling you want. The correct > english spelling is lightweight if you mean "something that weighs > relatively little or less than average" Thanks, I'll change that. It was copied and pasted from the upstream description... > > Description : leightweight C library for daemons Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- pgpiKXjowq8GN.pgp Description: PGP signature
Bug#200793: ITP: libdaemon -- leightweight C library for daemons
Package: wnpp Version: unavailable; reported 2003-07-10 Severity: wishlist * Package name: libdaemon Version : 0.2 Upstream Author : Lennart Poettering * URL : http://www.stud.uni-hamburg.de/~lennart/projects/libdaemon/ * License : GPL Description : leightweight C library for daemons libdaemon is a leightweight C library which eases the writing of UNIX daemons. It consists of the following parts: * A wrapper around fork() which does the correct daemonization procedure of a process * A wrapper around syslog() for simpler and compatible log output to Syslog or STDERR * An API for writing PID files * An API for serializing UNIX signals into a pipe for usage with select() or poll() Routines like these are included in most of the daemon software available. It is not that simple to get it done right and code duplication cannot be a goal. The new version of ifplugd depends on this library, that's why it is needed. Greetings, Oliver -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux debian 2.4.21 #3 Thu Jun 26 14:08:29 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=de_DE
Re: ITP: sredird
On Tue, Jul 08, 2003 at 11:56:41PM +1000, Russell Coker wrote: > Description: RFC 2217 compliant Telnet serial port redirector > Sredird is a serial port redirector that is compliant with the RFC 2217 > "Telnet Com Port Control Option" protocol. This protocol lets you share a > serial port through the network. > > Copyright GPL v2 > > > NB Apart from kermit there seems to be a huge lack of GPL client software > for > this. If you know of any good client software then please let me know as > packaging it is much easier than writing it. ;) This seems to be similar to termpkg, which I recently uploaded, a few days ago. It has not yet been accepted, should happen this week. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- pgpVSAFZq2jEv.pgp Description: PGP signature
Re: woody/sid packages in dists/potato
On Fri, Jul 04, 2003 at 11:58:49AM +, Miquel van Smoorenburg wrote: > I'm trying to run debootstrap to see if it plays nice with sysvinit. > And the other way around. > > But at the moment, it bails out because it wants to install > libident which still is in the potato part of the archive ... > and my local mirror doesn't carry dists/potato anymore. > > There's a handful of packages that have the same problem: > > % grep ^Filename: Packages | grep -v ": pool/" | wc -l > 24 > > They're all in potato. What would be the right way to fix this ? > > - file 24 bug reports > - fix the FTP archive manually by copying the packages to pool/ > - it's not really a problem, so do nothing Option #2. We had this discussed here several times before. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- pgptRyj5DCKpj.pgp Description: PGP signature
Bug#199348: ITP: termpkg -- remote modem utilities
Package: wnpp Version: unavailable; reported 2003-06-30 Severity: wishlist * Package name: termpkg Version : 3.3 Upstream Author : Joe Croft <[EMAIL PROTECTED]> * URL : http://www.linuxlots.com/~termpkg/ * License : GPL Description : remote modem utilities The package consists of three programs, which I will package separately: Package: ttyd Description: Remote Modem Utility for Unix The ttyd daemon is fully telnet compatible allowing programs to connect to any remote device such as networked modems and terminal servers as if they were local devices as long as the device utilizes the telnet protocol, eg. another host running termnetd or a console access server. Package: termnetd Description: Terminal Server daemon This daemon allows telnet sessions to be established with a unit's serial ports. This is particularly useful if you want to give access to a local serial port to another host which runs ttyd. Package: termnet Description: Simple Telnet replacement for termnetd This package is a simple telnet replacement. It does not implement the complete telnet protocol, but does provide a few nifty features of it's own, especially when used with the termnetd terminal server daemon. Greetings, Oliver -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux debian 2.4.21 #3 Thu Jun 26 14:08:29 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: maildirmake
On Tue, Jun 24, 2003 at 09:45:30AM +0200, Ralf Hildebrandt wrote: > * Andreas Metzler <[EMAIL PROTECTED]>: > > > You could start by telling us what maildirmake is supposed to do. Why > > do we need it? Any program I know of which can handle Maildir is not > > only capable of storing messages in Maildir folders but also of > > generating them. This includes e.g. the exim(4) MTA, MDAs like > > procmail or maildrop, and the MUA mutt. > > Same for Postfix. > Who needs maildirmake? Same for masqmail... But why not create a small utility that creates it? It's trivial, and I can recycle some code from masqmail. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- pgpfGn8NFLXoE.pgp Description: PGP signature
Re: Fwd: Please confirm your message
On Thu, Dec 05, 2002 at 10:09:31AM +1100, Brian May wrote:
> On Wed, Dec 04, 2002 at 11:57:05PM +0100, Oliver Kurth wrote:
> > MAIL FROM: <[EMAIL PROTECTED]>
> > RCPT TO: <[EMAIL PROTECTED]>
>
> Would this work? Or would you need to be authenticated first?
$ telnet mx0.gmx.net 25
Trying 213.165.64.100...
Connected to mx0.gmx.net.
Escape character is '^]'.
220 {mx015-rz3} GMX Mailservices ESMTP
MAIL FROM: <[EMAIL PROTECTED]>
250 {mx015-rz3} ok
RCPT TO: <[EMAIL PROTECTED]>
250 {mx015-rz3} ok
quit
221 {mx015-rz3} GMX Mailservices
Connection closed by foreign host.
It does. For gmx at least.
> (ie. I thought we were discussing checking purely based on
> the MAIL FROM address, not checking for relaying).
This is handled differently. Some servers check if the domain part
has a valid mx pointer, some do not. But I am not sure, if the
example above works for any server, I am sure you can set it up
so that it does not accept local addresses from other networks
than its own to a local address. It would make sense though, because
many spammers try to set a local MAIL FROM: address. If someone wants
to send a mail with a local MAIL FROM: from a foreign network, he
should be authenticated.
Greetings,
Oliver
--
Oh my, the stars!
me, first time I stared at the night sky with my new contact lenses
pgpdbvufsTkDT.pgp
Description: PGP signature
Re: Fwd: Please confirm your message
On Thu, Dec 05, 2002 at 09:20:47AM +1100, Brian May wrote:
> On Wed, Dec 04, 2002 at 12:48:14AM +, Darren Salt wrote:
> > see if you still don't have a problem. Or try giving the server a local (to
> > it) address after MAIL FROM: the server should complain unless you're on a
> > network which it considers to be local.
>
> Tried that with both qmail and postfix, and it still accepts it.
>
> (ie. telnet to remote server, entered "MAIL FROM: $remoteaddress",
> and the server still accepts it even though it considers it a
> local address).
Did you also give RCPT TO: after that?
$ mx gmx.net
gmx.net MX 10 mx0.gmx.de
gmx.net MX 10 mx0.gmx.net
$ telnet mx0.gmx.net 25
Trying 213.165.64.100...
Connected to mx0.gmx.net.
Escape character is '^]'.
220 {mx018-rz3} GMX Mailservices ESMTP
EHLO test
250-{mx018-rz3} GMX Mailservices
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-AUTH LOGIN CRAM-MD5 PLAIN
250-PIPELINING
250 8BITMIME
MAIL FROM: <[EMAIL PROTECTED]>
250 {mx018-rz3} ok
RCPT TO: <[EMAIL PROTECTED]>
550 {mx018-rz3} We do not relay - access denied
Connection closed by foreign host.
$
This is from a dial up line. Both addresses exist. The reply is completely
okay, if I wanted to send a mail as [EMAIL PROTECTED] I would have to
authorize myself via the AUTH mechanism or do pop-before-smtp, which I did
not.
The same would have happened if I set MAIL FROM: to another address.
The other way round would have worked, ie. MAIL FROM: <[EMAIL PROTECTED]>
and RCPT TO: <[EMAIL PROTECTED]>. That's how you would send a mail to me.
Greetings,
Oliver
--
Oh my, the stars!
me, first time I stared at the night sky with my new contact lenses
pgpD9lUxEqTuw.pgp
Description: PGP signature
Re: /tmp/root ???
On Wed, Dec 04, 2002 at 12:40:27AM -0700, Bob Proulx wrote:
> Atsuhito Kohda <[EMAIL PROTECTED]> [2002-12-04 13:11:40 +0900]:
> >
> > I'm not sure but after recent upgrading of unstable
> > I found /tmp/root
> >
> > And can anyone guess which package created this /tmp/root ?
>
> Try this on your machine. It might be a clue. Or it might not turn
> up anything at all. But it is worth a try.
>
> cd /var/lib/dpkg/info
> grep /tmp/root *
No, I think it is from somewhere else:
debian:~# cd /var/lib/dpkg/info
debian:/var/lib/dpkg/info# grep tmp/root *
debian:/var/lib/dpkg/info#
debian:~# ls -ld /tmp/{kurth,root}
drwx--2 kurthkurth4096 Dec 3 11:53 /tmp/kurth
drwx--2 root root 4096 Dec 3 21:22 /tmp/root
I did my last upgrade yesterday morning, well before 21:22. I think
its created by xemacs, or gcc, or similar. Nothing to worry about,
I guess. You see that there is also a directory 'kurth', that's my
login on that box.
Greetings,
Oliver
--
DAM approval waiting time: 168 days.
See http://nm.debian.org/nmstatus.php?email=oku%40masqmail.cx
pgpfDMQKFGArT.pgp
Description: PGP signature
Re: New maintainer process
On Fri, Nov 22, 2002 at 11:13:00PM +0100, Martin Michlmayr wrote: > * Andrew Pollock <[EMAIL PROTECTED]> [2002-11-22 21:52]: > > Since satie.d.o has been destroyed, where does this leave the NM process? > > I tried adding all applicants again. I have probably missed some, but > most should be there again. Your application can be reviewed at > http://nm.debian.org/amstatus.php?&user=me%40andrew.net.au Just like > before the fire, you're waiting for an AM. And while you're quite far > up in the "waiting for AM" queue, it might take a while for an AM to > accept a new applicant since they will be busy sorting out their > current applicants for a while. My status seems to be reset :-(. I had passed all checks, and was approved by my AM. The mail from my AM is here: http://lists.debian.org/debian-newmaint/2002/debian-newmaint-200206/msg00018.html My key is signed by Gerrit Pape, id BC70A6FF I was just waiting for DAM approval (156 days now). Greetings, Oliver pgpsKvuzTIVZY.pgp Description: PGP signature
Re: New maintainer process
On Fri, Nov 22, 2002 at 04:38:36PM +0100, [EMAIL PROTECTED] wrote: > On Fri, Nov 22, 2002 at 04:10:39PM +0100, Martin Michlmayr wrote: > > > Never underestimate the power of Google's cache. :-) > > > > Google's cache was unfortunately out of date, too. So, while we > > haven't lost everything, we have certainly lost the last few > > months/weeks. I will post an announcement when I know more. In the > > what about www.archive.org? I believe a web mirror would not help at all. There were php scripts, and databases, and these _cannot_ (hopefully) be mirrored. Recently there was a bug, and the php code was exposed - I made a copy of that, just for curiosity. So, if nmlist.php is missing, I have a copy here. Few days old. Greetings, Oliver -- DAM approval waiting time: 156 days. See http://nm.debian.org/nmstatus.php?email=oku%40masqmail.cx pgpDLpA0E61aV.pgp Description: PGP signature
Re: Some proposals about the Email-subsystem, was Re: RFC: OpenLDAP and TLS/SSL
On Tue, Sep 03, 2002 at 10:59:14AM -0600, [EMAIL PROTECTED] wrote: > Hello! > > On Mon, Sep 02, 2002 at 01:52:13PM +0200, Javier Fernández-Sanguino Peña > wrote: > > On Sun, Aug 25, 2002 at 02:56:46PM +1000, Martijn van Oosterhout wrote: > ... > > > What I'm saying is that to must have a mail-server install, even if it is > > > just ssmtp or something like that. > > > > Yes, however the mail server should not be running as a daemon nor > > listening for incoming port 25 connections. > ... > > I checked out ssmtp and it is not what we would eventually want. It > does not deliver _any_ mail locally. > > Indeed procmail cannot deliver local mail, and I though about writing > some script which acomplishes the simple task of distinguishing > between local and remote recipients and pipe the local ones a copy via > the default delivery method, while putting the remote ones into a kind > of outgoing queue. However has it done or is faster than I, go ahead. I do not really understand what the point of this is, but if it is a small, minimal MTA, you can use masqmail. It happens that I am both up/downstream of it, so I can modify it to, say, masqmail-tiny, which does nothing but deliver mail locally, or, if required, remote via SMTP. It should not be too much work, I think. Incoming connections can be disabled, or can be done with inetd. Small drawback for masqmail is however, that it depends on libglib. I already have configure options to link that statically, increasing the size by ~30K. A pro is that it does not depend on procmail, and can deliver to mbox, maildir and an mda. Patches for MH are welcome. > Javier states it clearly, it is not necessary to have a daemon running > for this. You still need a queue running daemon for the case that the mailbox is locked, or a mail cannot be delivered for any reason. But this can also be done with a cron job. I will start a project of this kind only if I am somewhat sure that it will be used. So, give me feedback ;-). Otherwise I'll hide under my rock again. Greetings, Oliver -- debian/rules http://zork.net/~nick/srom/ pgpr9yqpFLehr.pgp Description: PGP signature
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote: > > > > Sounds like you want dpkg --force-confmiss. > > > > > > I wouldn't expect that since the documentation states: > > > > > > confmiss: Always install a missing configuration > > > file. This is dangerous, since it means not pre- > > > serving a change (removing) made to the file. > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > If the default configuration data in the file do something you don't want. > > For example... autofs. First thing I do when I install autofs in at networked environmemt is rm /etc/auto.* because I want to use the NIS maps. Greetings, Oliver -- Oliver Kurth mailto:[EMAIL PROTECTED] http://leinekanal.de pgps2x4kwT8dp.pgp Description: PGP signature
Re: RFC: OpenLDAP and TLS/SSL
On Wed, Aug 21, 2002 at 03:05:48PM +0100, Colin Watson wrote:
> On Wed, Aug 21, 2002 at 03:52:12PM +0200, Oliver Kurth wrote:
> > On Wed, Aug 21, 2002 at 03:18:38PM +0200, Torsten Landschoff wrote:
> > > So - what should I do to handle this? Can the priority of libssl0.9.6 be
> > > easily changed? Or should I rather provide libldap2{,-ssl}? Technically
> > > it would not be a big deal since the interface of libldap2 does not
> > > change if you enable ssl. Also I wonder if a slapd package without
> > > ssl would be in order. After all there are still people using Debian
> > > who are not allowed to import all that crypto stuff from the US.
> >
> > I would suggest that you make an extra -ssl package, along the lines
> > of eg. fetchmai{,-ssl}l. It reduces dependencies and solves your
> > problem. Maybe people want ldap, but not ssl.
>
> Now that we have crypto in main, I think we should have fewer -ssl
> packages, not more.
Alright, if this is consensus.
Greetings,
Oliver
--
debian/rules http://zork.net/~nick/srom/
pgpEdmy7OQgov.pgp
Description: PGP signature
Re: RFC: OpenLDAP and TLS/SSL
On Wed, Aug 21, 2002 at 03:18:38PM +0200, Torsten Landschoff wrote:
> Hi *,
Hi Torsten :-)
>
> Today I was convinced by Stephen Frost that I can just enable SSL support
> in the OpenLDAP packages I maintain. No problem so far, but:
>
> - libldap2 is Priority: important
> - this change will make it depend on libssl0.9.6
> - libssl0.9.6 is Priority: standard
>
> So - what should I do to handle this? Can the priority of libssl0.9.6 be
> easily changed? Or should I rather provide libldap2{,-ssl}? Technically
> it would not be a big deal since the interface of libldap2 does not
> change if you enable ssl. Also I wonder if a slapd package without
> ssl would be in order. After all there are still people using Debian
> who are not allowed to import all that crypto stuff from the US.
I would suggest that you make an extra -ssl package, along the lines of
eg. fetchmai{,-ssl}l. It reduces dependencies and solves your problem. Maybe
people want ldap, but not ssl.
Greetings,
Oliver
--
debian/rules http://zork.net/~nick/srom/
pgpwnehOIJqbw.pgp
Description: PGP signature
Re: Bug#156407: ITP: free-java-sdk -- Complete Java SDK environment consising of free Java tools
On Mon, Aug 12, 2002 at 02:22:49PM -0500, Adam Heath wrote: > On 12 Aug 2002, Grzegorz Prokopski wrote: > > > W li¶cie z pon, 12-08-2002, godz. 18:13, Adam Heath pisze: > > > Er, you say free, but are restricting me to only use what is listed in the > > > depends. > > So, what about kaffe? What about gcj? Why are you saying that sable is > better than these others? Anybody is free to create another version with any component replaced, if she/he wants to, and has enough time to do so. Suggestion: Any such package should provide java-sdk. > Debian should not be a popularity contest. Who said that it should? I think it is a nice idea. I would love to see this in Debian. Greetings, Oliver -- Oliver Kurth mailto:[EMAIL PROTECTED] http://leinekanal.de pgpYvCGf187d8.pgp Description: PGP signature
